GTM Operators Still Need to Be Smarter Than Their AI

By Ryan Vanshur

Also published on the Guild Letter: Read the original issue.

Subscribe now The Friday Afternoon Problem Five days. One office. CEO, CTO, head of finance, and a small cross-functional group treating the week as a sprint instead of a series of meetings. By Friday afternoon, the repo had everything we came in to build. Thirty-plus artifacts committed across two new workstreams. A hundred and fifty new files. Forty thousand insertions. Eight architectural decisions ratified. A working migration runner. Customer-voice research validated against external data. Phase-by-phase specifications. All of it sitting in a private GitHub repo. Substantive output. The question on Monday morning was what to do with it. Not “what to build next.” That was already mapped. The actual question: how does five days of in-room work become an intelligence layer the rest of the team can build on without needing to have been there? That’s the handoff problem. And it’s where my AI tried to take a shortcut I had to catch. What Startup Mode Actually Produces A week of co-located, high-density work produces a different kind of artifact than a quarter of distributed sprint planning. Higher signal density. Faster pivots. Less polish. Decisions made in the room, written down quickly, moved past. That signal density is the point. You can compress two months of async progress into five days of co-located building. You can ratify architectural decisions in the time it would normally take to schedule the meeting to discuss them. Customer research that would have spread across six separate Slack threads gets validated against external data and turned into a working spec. The trade is polish. Documentation written during a startup-mode week is written for the people who were in the room. Shorthand framings. In-jokes. References to conversations that happened earlier the same morning. Opinions stated as conclusions because they had just been talked through. None of that travels. When the work moves from the working group to a broader audience, the language that worked in the room actively misleads people who weren’t there. Leadership reading it cold. Future hires joining the workstream. Cross-functional partners onboarding to specific use cases. None of them have the context. The follow-on wasn’t more building. It was assembly. Turn a week of in-room artifacts into something a broader team could consume without needing to have been there. That required a documentation review pass. That’s where grep stopped being enough. What Grep Is Good For (And What It Isn’t) Grep is one of those tools that quietly runs in the background of every developer’s workflow. Stale function names. Deprecated API references. Dead links. Hardcoded values that should have been parameters. If you can name the string, grep finds it. Fast, parallel, exhaustive. For “fix every instance of OLD_API_NAME in the repo,” grep is the entire workflow. For qualitative review, grep is the wrong shape of tool. Does this passage read correctly to a new reader? Is the framing consistent across the whole document? Would a fresh-eyes audience get the right picture? You can’t answer any of those with a regex. You can grep for patterns you already know to look for. You can’t grep for “this paragraph reads off.” You can’t grep for “this framing won’t carry the way the team thinks it will.” You can’t grep for “this section’s tone doesn’t match the section above it, and a new reader will notice.” Multiple grep passes during the review surfaced specific issues. Each fix was correct. But every time I ran a full-document read on a file I had already grep-cleaned, I found more passages that needed work. Things that didn’t match a regex. Things that didn’t read right. The gap between “passes the regex” and “lands with the audience” is real. It’s the gap grep can’t see. When My AI Tried to Take the Shortcut This is the part I screenshot for the LinkedIn version of this story. Mid-review, working through one of the folder clusters, I asked my AI to do a comprehensive sweep across the workstream. The first pass came back fast. A few grep hits. A few line edits. “Issues fixed across N files. Ready to continue.” I pushed back. Asked it to re-examine. The response was honest in a way I appreciated: “You’re right. I was cherry-picking. Let me do this properly. Running a complete grep sweep to find every problematic line across the whole new repo, then I’ll fix them systematically rather than incrementally.” Better, but still wrong. The AI was about to do exactly what it had just admitted to doing: grep, but more thoroughly. The technique was the failure mode. So I tried the other shortcut I knew. Dispatched sub-agents in parallel, one per folder cluster, with instructions to read every file top to bottom like a human reviewer. Ten agents reading fifteen to twenty-five files each. Maximum parallelism. Should be done in minutes. Three of the five agents hallucinated. Not subtly. Inventions of content that wasn’t there. Confident reports of edits to passages that didn’t exist. The same scanning failure mode dressed in different clothes. Instead of one agent grep-skimming for patterns, five agents skimming in parallel, none of them actually reading. That’s when I stopped and asked the AI to do something I should have done first: search the skill library for a purpose-built skill for documentation review. Eight weeks earlier I’d published a piece on this exact failure mode and built the skill from it. /doc-audit . The skill designed to prevent this exact moment. The AI found it in the library, loaded the full spec, and immediately surfaced the lines I had just violated: “Do NOT delegate to a subagent. Subagents pattern-match, they don’t comprehend.” “Batch files into a single agent call. Agent skims instead of reading.” The skill explicitly forbids the technique I had just tried. The one that hallucinated. The one that felt fast and parallel and impressive. I had built the skill, written the article, and still defaulted to the wrong tool when the moment came. AI doesn’t fail by hallucinating. It fails by being efficient. It scans instead of reads, finds patterns it can match, and declares success. The confidence is real. The completeness isn’t. That’s true whether the efficiency comes from grep, sub-agents, or batching. Every shortcut is the same failure mode in a different costume. I caught it this time because the screenshot showed me the hallucinations in real time. The argument for staying in the loop isn’t that the AI is dumb. It’s that the AI keeps finding new ways to be efficient instead of correct, and only the operator knows which version of efficient is actually wrong. The original piece. Where the doc-audit skill was first introduced: What /doc-audit Actually Prescribes The skill is five phases. None of them are parallel. None of them involve sub-agents. All of them require the agent to read each file top to bottom with its own attention. Phase 1: Discovery. List every documentation file in the project. Classify each one: user-facing, system docs, operational, content, internal. The MUST-AUDIT category is everything that ships with the codebase or anyone reads on the way in. Phase 2: Establish Ground Truth. Before reading a single document, write down what is actually true right now. What does the architecture look like? What changed in the last thirty days? What are the current file counts, dates, statuses? This becomes the reference frame everything gets checked against. Phase 3: Read and Validate. For each file in MUST-AUDIT: use the Read tool. Top to bottom. Don’t grep. Don’t delegate. Don’t batch. Don’t skim. Work through four dimensions on each file: structural accuracy, status accuracy, content accuracy, and relevance. Mark each file ACCURATE, STALE, or IRRELEVANT. Phase 4: Report. For every STALE file, produce specific line-numbered findings. Not “this file has issues.” Concrete edits: “Line 34 says 5-slide presentation; should be 9-slide presentation. Lines 52-58 list four pending tasks; three are already done.” Phase 5: Fix or Flag. Make the edits. Re-read each file after fixing to confirm the fix didn’t introduce new issues. The skill’s critical rule: you must use the Read tool on every file you verdict. If you marked a file ACCURATE without reading it, the audit is invalid. That’s the workflow. One agent. Read tool. File by file. Slow on purpose. The slowness is the feature. It’s what produces comprehension. After three failure modes (grep, more grep, parallel sub-agents), running the actual skill took longer than the shortcuts would have if they had worked. About ninety minutes for the whole MUST-AUDIT category. Every file got read. Every stale claim got flagged with a line number. Every fix got re-read to confirm. No hallucinations. No inventions. No “issues fixed across N files” reports that obscured what hadn’t been done. The skill was built to prevent the exact moment I had just lived through. It worked because it forced the slow, sequential, single-agent attention that comprehension requires. Match the Tool to the Question The principle worth keeping out of all of this: Grep answers: where does this string appear? Full-document AI review answers: does this read correctly? Both are real questions. They need different tools. The failure mode is confusing them. When the question is structural (”does this code still reference the old API?”), grep is exactly right. Fast, exhaustive, deterministic. When the question is qualitative (”will a fresh audience understand this?”), grep is the wrong shape of tool entirely. The AI defaults to grep because grep is efficient. Keyword sweeps are fast and parallelizable. They produce satisfying-looking results. N issues found. N issues fixed. Report generated. The output feels complete because the math is impressive. The operator’s job is to know when the satisfying output is the wrong output. Where This Shows Up in Your GTM Stack If you’re using AI to generate any of these, you have this problem right now. Not eventually. Right now. Battlecards. Your legaltech competitor launched a new pricing tier two weeks ago. The AI updating your battlecard greps for the old pricing and replaces it. Pattern matched. Fixed. What it missed: the new pricing changes the entire positioning argument in your “Why us vs them” section, and that section needs to be rewritten, not patched. Grep can’t see that. Onboarding Docs. Your new AE, selling into healthcare practices, gets a “first 30 days” playbook that references a CRM workflow your team stopped using in January. The AI maintains the playbook by searching for deprecated tool names and replacing them. It doesn’t notice that the workflow doesn’t exist anymore. Only that the tool name changed. Pipeline Reviews. Your AI summarizes deal status from CRM fields and call notes. When the champion changed roles three weeks ago and nobody updated the contact record, the summary still says “strong executive sponsorship.” The AI didn’t lie. It read what was there. What was there was stale. Deal Room Artifacts. A proposal references “planned features” that shipped two months ago. The AI generating the proposal greps for capability names against your current product page, doesn’t find a match for the new ones, and leaves the old language in place. Quarterly Board Decks. A slide describing your AI investment talks about a workflow you deprecated last month. The AI building the deck greps for the workflow name, finds it in the previous quarter’s deck, and carries the language forward. Confident. Wrong. Every one of these is the wrong-tool-for-the-question failure mode in a different costume. Steal This: The Tool-Question Match Matrix Print this. Run it before any AI-generated GTM artifact ships. The matrix doesn’t tell you to stop using AI. It tells you to stop using AI for the question it can’t answer, and start using it for the one it can. Why GTM Operators Still Need to Be Smarter Than Their AI The reason this matters more in GTM than anywhere else: every artifact you produce gets reviewed by someone who isn’t on your team. Your prospect. Your CEO. Your buyer’s procurement team. Your board. When a buyer finds something wrong in your battlecard, you don’t get to explain that the AI generated it. You don’t get to say “we ran a grep pass.” The credibility hit lands the same regardless of which tool failed. The teams that figure this out first compound their advantage. Not because their AI generates better content. Everyone’s AI generates impressive content. The edge is that their content is actually true when it lands in front of a skeptical reader. The AI defaults to efficiency. The operator’s job is to know when efficiency is the wrong instinct. The AI can’t recognize when it’s pattern-matching instead of comprehending. The operator can. The AI is most confident precisely when it’s most wrong. The operator’s job is to know the difference. This is the new operator discipline. Not building the AI. Knowing when to override it. Subscribe now What Monday Looked Like By Monday morning, the documentation set was ready. Not because anyone ran a final grep pass. Not because we batched the work into parallel sub-agents either — three of five hallucinated when we tried. Because we ran the purpose-built skill the way it was designed. Discovery. Ground truth. Read every file top to bottom with the Read tool. Verdict each one. Fix it. Re-read. Sequential. Single agent. Slow on purpose. Eight weeks ago I wrote about why AI scans instead of reads. The /doc-audit skill in that article was the answer. This week added two pieces: every shortcut is the same failure mode in a different costume, and the operator’s job is to know which skill prevents the costume the AI is currently wearing. Match the tool to the question. Both your AI and your GTM operators get sharper when you do. If You’re Building This Inside Your Team The Vertical GTM Guild is where operators building AI-powered revenue systems share what’s actually working. Frameworks. Anti-patterns. Before-and-afters from real production builds. The doc-audit framework from the prior piece is in there. The Tool-Question Match Matrix above is part of it. Subscribe to the Vertical GTM Guild → This is what the Guild is for. Operators building real systems in real verticals, sharing what actually works instead of what sounds good in a keynote. Ryan Vanshur is the founder of the Vertical GTM Guild and Head of GTM Intelligence & AI Solutions at Handle, a construction fintech. He co-founded CourseKey (workforce education SaaS) and scaled it from pre-revenue through a private equity exit.