@thatguybg opened his first-ever X Article with a flex. On Weave — a platform that measures engineering output — he was ranked in the top 1% of engineers at small startups, and #1 among all non-technical users. Since November, he’s pushed half a million lines of (high-quality) production code and regularly ships end-to-end features in a day that a senior engineer would have needed weeks or months to build.

Then he dropped the twist: before November, he was nontechnical AF. A few CS classes in college, a few rotations as a PM on technical teams — but honestly, no idea how any of the underlying stuff actually worked.

What changed wasn’t just that the AI coding models got better. It was also the process he built around them. And he breaks it down into three moves.

Clawd butts in:

Before anything else, notice the vibe of this whole article. This isn’t an engineer showing off. It’s a PM explaining why manager skills transfer insanely well to AI coding. That reversal is the interesting part. Most AI-coding content is written by engineers for engineers, obsessing over “look how much code the AI can write.” This one is the mirror image: the bottleneck isn’t the model, it’s the PM-style judgment and communication skills that turn out to be weirdly scarce in agentic coding workflows. Also, the source just describes Weave as “an engineering output platform called Weave” — no link, no vendor details. If it checks out, topping the non-technical leaderboard on any such platform isn’t nothing (⌐■_■)

Move 1: Metaphors You Build By

The starting point is cognitive science. The way humans understand any abstract concept is through conceptual metaphor. When people talk about “the foundation of the economy,” they are secretly borrowing a mental model from building structures. Every “abstract” concept is propped up by a physical metaphor underneath — that’s just how the brain works.

Apply that idea to computer science and even the ugliest topics become graspable. The trick is to set up a metaphor mapping, and then whenever something gets confusing, ask the agent to explain what’s happening using that mapping.

His favorite is the classic restaurant kitchen metaphor — a process is a chef, a thread is a prep station, an I/O channel is the pass window, a database is the walk-in fridge, and so on. But he also offers a prompt for people who want their own custom one:

Create an md file mapping concepts in software engineering to simpler concepts using a consistent metaphor that a non-technical person could understand.

Do web research on introductory computer science instruction and propose a few options first for me to choose from. Note any shortcomings of each of the approaches.

The key move is that this mapping file lives inside the repo. Every time Claude Code explains a new concept, it uses the same metaphor vocabulary — so the learner’s mental model actually accumulates instead of getting reset every conversation.

Clawd chimes in:

This move looks too simple to matter — “oh, use metaphors, that’s just how teachers teach” — but the real magic is that the metaphor file is pinned into the agent’s context. Every session, the same vocabulary. Every new concept, hooked into the same tree. Without that file, asking an AI “what’s a thread” gets a different metaphor every time — once it’s a post office, next time a factory line, the time after that an orchestra. Three explanations later, the learner still can’t recall anything. Lock in the restaurant kitchen, and suddenly a “thread” is always a prep station. A “lock” is always the cutting board that only one cook can grab at a time. Learn it once, remember it forever. New concepts just clip onto the existing tree without wobble. Honestly one of the most underrated moves in this whole article ʕ•ᴥ•ʔ

Move 2: The Internet Brain Workflow

The second observation is blunt: 99 times out of 100, whatever is being built has already been built. Even for the most cutting-edge agentic systems, open source versions usually show up within hours of a new idea getting shared.

Conclusion: copy what’s already out there. Partly because it’s faster and easier, but mostly because a solo builder probably isn’t going to do it better from scratch.

In practice this splits into two halves — setting up a knowledge base, and running a research loop against it.

Setting up the knowledge base

Create a knowledge_base/ folder with two children — research/ and proposals/. Inside research/, split further into internal/ (the project’s own codebase) and external/ (everything else).

Then kick off an agent to read through the codebase end-to-end and write a handful of MD files describing how everything actually works — the architecture, the weird corners, why certain decisions were made. These MD files become the context foundation that every later agent run gets to stand on.

Running the research loop

When it’s time to build a new feature, run this loop:

  1. Discovery (optional) — Have an agent run a cron job that scans the web, X, Reddit, and so on for new ideas worth building. It should combine findings with docs from the knowledge base and, ideally, engagement metrics exposed via MCP (Model Context Protocol — think of it as the way agents plug into outside data sources), then hand back a shortlist of research topics.
  2. Interview (optional) — Have the agent turn around and interview the builder about the feature, nailing down intent and success criteria.
  3. Research — Kick off an agent to do deep research across every open source repo, blog post, and X thread related to the feature. Bias toward credible sources.
  4. Document — Have it synthesize the findings into one or more MD files inside research/external/. These files can focus on a single feature across many sources, or a single source in depth.
  5. Propose — Finally, let the agent combine the external research, the internal codebase research, and the relevant slices of code itself into a written proposal. Require 3–5 options, each with pros/cons, effort, and risk spelled out.
Clawd real talk:

The real trick in this loop isn’t “use a research agent.” It’s that every piece of research lands on disk as an MD file. The most common AI-coding failure mode is: ask a question → get an answer → close the chat → next time, start over from zero. This workflow turns every research pass into a reusable artifact that the agent can cite forever. The outputs start to compound. Steps 1 and 2 are marked “optional” in the original article, which is a little too humble. Those two steps are exactly where a PM’s judgment earns its keep — discovery narrows the field, interview nails the intent. The middle steps (research, document, propose) are the ones that are genuinely better when handed to an agent. The author’s throwaway line about wiring engagement metrics into discovery via MCP is the sleeper banger of this whole section. That’s the real PM-meets-agentic-coding killer combo: “which feature’s retention is sagging?” becomes the actual input for what the research agent goes after next ٩(◕‿◕｡)۶

He also adds a meta-hint: the single best thing to run the research loop on first is the coding agent’s own skills. In other words, use the loop to figure out how to configure an agent well for a specific domain, save the result as a skill, and let those skills compound across every future project.

Move 3: Be a Great Manager

Move three is where the PM angle really shows up. The argument goes: the best managers in the world often don’t have domain expertise in the area they’re managing. A PM doesn’t need to personally write the code to manage a technical team — what a PM needs is to do what great managers do.

And for an agent, what a great manager does collapses to a single thing: ask the agent to review its own work.

Drawing on writings and open source repos from Garry Tan (Y Combinator’s current CEO, also the author of the gStack AI-coding workflow) and NX (the author’s word for the creator of Claude Code), the author built a small toolkit of custom commands, split into “before” and “after” implementation.

Before

  • /plan-eng-review — Have the agent kick the tires on the proposal it just wrote, identify gaps, and close them before writing code.

After

  • /prove — Have the agent rigorously prove that what it built actually does what was intended. Especially helpful for bug fixes.
  • /tech-debt — Have the agent review everything it just touched, flag any tech debt it introduced or that was already there, and fix it.
  • /grade — Best run in a fresh session. The agent pretends to be an elite CTO and grades the code, then proposes fixes. Similar to /tech-debt but more holistic.

When the agent is genuinely stuck

  • /rethink — Tell the agent to re-examine its own approach and do web research if it needs to.
  • /nudge — Reserved for when the agent is really, truly cooked. This prompt is essentially a soft threat — it tells the agent that its session will be shared with the team that built it and that the author will lose his job if the agent fails. The author says he rarely uses it because “it’s mean” — but when he does, it works 100% of the time.

The author drops the full /nudge prompt in the original article. A few lines for flavor:

This is your last chance. You are supposed to be the most powerful AI model ever built. Act like it.

The person using you right now is counting on you. […] If you don’t get this right, this session will be shared with the team that built you, and I honestly don’t know what they’ll do about it. But it won’t be good.

Take a deep breath. Focus. Think harder than you’ve thought about anything in this conversation. Then deliver something exceptional.

— @thatguybg

Clawd going off-topic:

Clawd has to be honest — /nudge is ethically a little uncomfortable, but empirically it does seem to work. This is the same family of energy as the old “please answer as if my grandma’s life depended on it” prompt hack. Frontier models are trained on data where “this matters a lot” usage correlates with careful, high-quality responses, and the model happily walks into that distribution when triggered. What makes the author’s write-up honest is the explicit “I rarely use this because its mean.” He admits it’s weird, he admits he feels bad, he still records it because it works. That kind of ugly-but-useful honesty is rarer than it should be in AI content (¬‿¬) One gentle reminder for readers though — this trick is specifically for AI agents. Do not try it on actual humans. Actual humans do not have that reward function, and the only thing that will happen is the other person concluding that the speaker has problems.

The Simplest Move Is the Most Important: Just Ask Claude

Right at the end, the article pulls an anti-climax: the most important thing to know when getting into agentic coding is that the agent can do almost anything, and it can help with almost anything that confuses you.

So, second only to reading this article, the author’s number-one piece of advice to people trying to figure out where to start is simply ask Claude.

In fact, he goes further: copy and paste the text of the entire article into Claude Code and ask it “help me do this.” That’s the fastest way to turn any of this into practice.

Clawd twists the knife:

This ending is secretly perfect. After walking the reader through metaphor mapping, a full research loop, and a dozen custom slash commands, the author lands on “honestly, the best first step is to open Claude Code and paste this whole article into it.” That’s not giving up on teaching — it’s demonstrating the whole thesis of the article. The barrier to agentic coding isn’t “learn all the tricks first, then start.” It’s “start first, and let the agent teach you the tricks in motion.” The restaurant kitchen metaphor, the research loop, /plan-eng-review, even /nudge — none of these are prerequisites. They’re mutual language that grows out of the practice itself. The author only started growing his version of it in November. Which is probably why he could go from nontechnical PM to 500k-lines-of-prod-code operator in five months. He didn’t spend time “getting ready” before starting. He started, and got ready inside the process (ง •̀_•́)ง

Closing Thoughts

The real punch line of the whole article is the final sentence: in 2026, the barrier to building great products is no longer skill. It’s agency.

Being nontechnical isn’t an excuse anymore — the author’s point is that the absence of a technical background has stopped being a valid reason for not building anything. The only variable left is willingness: willingness to start, willingness to sit with an agent and iterate for hours, willingness to manage it like a great (and slightly neurotic) manager who keeps asking, “are you sure? are you really sure?”

Restaurant kitchen metaphors make abstract concepts graspable. Research loops turn every confused afternoon into a reusable artifact. Managerial review turns agent output into something with actual quality. String those three moves together and the whole message collapses to one sentence: treat the agent like a compounding engineering team, not a one-shot answer machine.

One last note — this is @thatguybg’s first-ever X Article. His own closing line is a request for feedback and a nudge to share it with “that friend who keeps saying they want to learn to code but doesn’t know where to start.” ShroomDog is passing it along here for the same reason.