Last August I published Master GenAI Prompting for Better Coding Outcomes. The core argument was that most bad GenAI output is a prompting problem, not a model problem, and I walked through a TDD-based workflow — write the failing test first, ask for the minimal implementation, then push the model through a real review-and-refactor pass.
Eleven months later, I want to revisit that post honestly: what held up, what didn’t, and what the difference between the two has taught me about where software engineering is actually going.
What held up better than I expected
The TDD framing aged remarkably well — just not for the reason I wrote it.
When I wrote that post, red-green-refactor was a technique for me. It forced clarity before implementation and gave me a concrete way to check the model’s work. Today, the agentic coding tools we use don’t need me to run that loop. They run it themselves: write a test, watch it fail, implement, watch it pass, refactor, repeat — dozens of times in a session, without a human touching the keyboard between iterations.
Which means the tests stopped being my verification step and became the model’s steering mechanism. An agent with a good test suite converges on working software. An agent without one converges on something that looks like working software. The discipline I recommended as a prompting technique turned out to be the load-bearing infrastructure for autonomous coding. If your codebase has weak tests, no amount of prompting skill will save you now — and if it has strong ones, you need far less prompting skill than you think.
The other thing that held up: the review pass. I wrote “no one ships code without a final pass,” and that’s more true today, not less. More on that below, because who does that pass has changed.
What didn’t hold up
The premise in the title. “Prompting” as an individual craft — the careful wording, the role-setting, the well-turned instruction — mattered a lot in mid-2025 and matters much less now. Not because the advice was wrong, but because the unit of work changed.
A year ago, the unit of work was a prompt: one request, one response, evaluate, iterate. Today the unit of work is a task: here’s the issue, here’s the repo, go. The model reads the code, forms a plan, writes the change, runs the tests, and comes back with a diff. In that world, the thing that determines output quality isn’t the sentence you typed. It’s everything the agent finds when it gets there: the conventions file in the repo root, the CI configuration, the quality of the existing code it will pattern-match against, the tests that tell it when it’s done.
I’ve started thinking of it this way: we used to prompt the model; now the repository is the prompt. A codebase with clear structure, honest names, a strong test suite, and a written statement of its own conventions produces good agent output almost regardless of how the task is phrased. A messy codebase produces messy output no matter how artful the instructions. Prompting skill was always a proxy for the real skill, which is the ability to specify what you want precisely enough that someone — or something — else can build it. We used to call that writing a good ticket. Some things don’t change.
What this did to my job — and my team’s
Here’s the part I didn’t see coming when I wrote the original post.
That post was written for individual developers, by someone acting as one. The advice was personal technique: how you should phrase things to get better output on your task. What I’ve learned since, watching my own organization adopt these tools in production, is that individual technique stopped being the leverage point.
If the repository is the prompt, then the highest-leverage prompting work in my organization isn’t done in a chat window. It’s done in our coding standards, our test coverage, our architectural decision records, and our definition of done. Those documents used to be for onboarding humans. Now they’re onboarding models, hundreds of times a day. The teams getting the best results from AI aren’t the ones with the best prompt libraries — they’re the ones whose engineering hygiene was strong before the agents showed up. AI turned out to be a multiplier on discipline we should have had anyway.
And the review pass I insisted on? It’s now most of the job. When the marginal cost of generating code drops toward zero, the constraint moves to judgment: is this the right change, does it fit the architecture, do these tests actually test anything, should this exist at all? My engineers spend less time writing code and more time deciding whether code should ship. That’s a real shift in what the role is, and it deserves its own post — the short version is that we’re all becoming editors, and editing well is a different skill than writing well.
What I’d tell the reader of the original post
If you read last August’s post and built the habit, keep it. The instincts it trains — define the behavior before the implementation, verify against something concrete, never accept “looks good” — are exactly the instincts that make someone effective in an agentic workflow. You were practicing for a job that has since arrived.
But redirect the effort. Spend less time perfecting the wording of individual requests and more time on the things every request inherits: your tests, your conventions, your repo’s ability to explain itself. Write the standards document you’ve been putting off. It’s not documentation anymore. It’s configuration.
And hold on tight to the review pass. It’s the last part of the loop that’s still yours — and it’s the part that was always worth the most.
This post revisits Master GenAI Prompting for Better Coding Outcomes (August 2025).
