How My Agentic Coding Workflow Changed in a Year

A year ago, before I let a coding agent touch anything, I wrote four files.

There was project.md with a full description of what I was building. A CLAUDE.md or AGENTS.md with project rules and coding conventions. A todo.md with the work broken into ordered tasks. And prompt.md, usually somewhere north of 800 words, to kick the whole thing off. Only then would I paste the prompt in and let the agent start.

Last month I built a playable roguelike. The first message was one sentence.

That gap is what this post is about. Testing Fable 5.1 and GPT-6 Astra made it obvious how much my own habits had drifted, and I don't think I'm the only one. The scaffolding I built in 2025 was a reasonable response to models that needed it. The current generation mostly doesn't.

What Agentic Coding Actually Means in 2026

Quick definition so we're on the same page. Agentic coding is when you give an AI agent a goal instead of a completion target, and it plans, reads your codebase, edits multiple files, runs your tests, reads the failures, and keeps going until it thinks it's done. You review and sign off.

That's different from autocomplete, which predicts the next few lines inside the file you're already in. It's also different from vibe coding, where you're accepting output without reading it. Agentic coding still has you in the loop. It just moves you from writing the code to directing and verifying it.

The Old Workflow: Four Markdown Files Before You Start

The 2025 version of my process was front-loaded. I'd spend maybe 45 minutes on setup before a single line got written.

project.md described the whole thing: what it does, who uses it, the data model, the screens. CLAUDE.md held the rules, and mine used to run 200 lines or more, covering everything from error handling patterns to how I like imports sorted. todo.md was my attempt to decompose the work into a sequence the agent could follow without wandering. And prompt.md restated most of it again, because I didn't fully trust the files to be read.

It worked. I shipped things this way and the results were fine. But look at what I was actually doing: I was writing a spec, then writing a summary of the spec, then writing a plan derived from the spec, and hoping the model would reconcile all three. Every one of those documents was a guess about what the model would need. And I made those guesses before I'd seen a single line of its output.

Why It Stopped Being Necessary

Two things changed. One I noticed, one got measured.

The one I noticed: shorter prompts started producing better results. Not always exactly what I had pictured, but usually something good, and often something better than what I would have specified. When it wasn't right, I'd say so, and the next iteration fixed it. At some point the cost of correcting the model dropped below the cost of specifying everything upfront, and once that flips, all the front-loading is just work you didn't need to do.

The one that got measured: researchers at ETH Zurich published the first proper controlled study on repository context files in February (arXiv:2602.11988). Across SWE-bench Lite and a new 138-task benchmark, context files did not generally improve task success rates while adding over 20% to inference cost. Auto-generated files were worse than having no file at all. Human-written ones did better, around 4% on their benchmark, so this isn't an argument for deleting everything. I went through that paper properly in CLAUDE.md: Helpful or Just Expensive Noise? if you want the full breakdown.

The interesting bit for me was the ablation. When they stripped a repo of its README and docs, context files suddenly did help. Which suggests most of what I'd been writing into project.md was already sitting in the repository, and the model was perfectly capable of going and reading it.

There's a second reason worth naming. A long spec written before you've seen anything is mostly assumptions. You're describing a thing that doesn't exist yet, in a language the model interprets loosely, and any detail you got wrong becomes a constraint the agent now faithfully honours. Overspecifying doesn't just waste tokens. It locks in your mistakes.

The New Workflow

Here's what I actually do now.

Write the shortest description that still contains your requirements. One to three sentences on what you want built. Add the language, framework, platform, or target audience only if it genuinely constrains the outcome. If you'd be happy either way, leave it out.
Let it run. Don't interrupt to add the detail you forgot. You'll get a chance in a few minutes.
Test the first iteration. Run it, don't read it. Reading the diff tells you what the agent thinks it built. Running it tells you what it built.
Give feedback as a bullet list. Short, direct, one item per thing that's wrong or missing. No explanation of why, no restating the original brief.
Repeat.

The whole thing is a loop, and the loop is fast enough that you can afford to be wrong on the first pass. That's the actual unlock. Not that the models got smarter in the abstract, but that iteration got cheap enough to replace planning.

What This Looks Like: A Roguelike From One Sentence

I wanted to test this properly, on something with enough surface area that sloppy direction would show up fast. So I built a game.

Grokue Like is a turn-based roguelite that runs in the browser. Ten procedurally generated floors, loot (normal, rare, epic, and unique), a skill tree, a merchant, and legacy embers you bank between runs so a failed run still leaves you something. It's free, there's no account, and it's kinda fun to play, which surprised me more than it should have.

The stack was Grok 4.6 driving the Pi coding agent. Grok 4.6 landed in August with a 500k context window, and xAI put a lot of emphasis on interactive and visual first passes, which is exactly the shape of this problem. That turned out to be the right call. The first playable version came back with a coherent visual direction I hadn't asked for.

For art, I gave the agent a tool instead of assets. I wrote a small CLI wrapper around Meta's Muse Image, then wrapped that in a skill so the agent could call it directly and generate its own sprites and backgrounds. Muse Image has an anchored composition mode where you pin a series of generations to a few reference images, which is how a set of sprites ends up looking like it came from one artist rather than eleven. At a cent per image, the agent could also afford to throw away the bad ones. Sound and music came from ElevenLabs.

The first message was one sentence: build a turn-based roguelike that runs in the browser. Everything after that was me playing a build and coming back with bullets. Combat feels floaty. The map needs a fog reveal. Death should carry something forward. Merchant prices are wrong. That's the entire creative process.

Things I never specified and would probably have got wrong: the ember mechanic, the art style, and the line on the status bar that reads "the dark moves only when you do." That last one is better writing than I'd have put in a spec.

It Feels Like Leading a Team, Not Writing a Spec

The mental shift that made this click was giving up on the idea that I'm programming the agent.

I'm not. I'm directing it. The relationship that fits best is the one you have with a good developer on your team: you tell them what you want and roughly why, you let them make the calls inside that, and you give feedback on what comes back. You don't hand a senior engineer an 800-word document specifying their variable names. If you did, you'd get worse work and they'd start looking at job ads.

This is also the thing that makes multiple agents workable. Heavy per-project scaffolding doesn't scale past one or two agents, because you're maintaining a spec for each of them and paying the context cost every session. Short briefs and bullet-list feedback scale fine. I can keep three going and my job in each of them is the same 30 seconds of reading and reacting. It's closer to standup than to programming.

Where You Still Need a Real Prompt

None of this means prompting is dead. I want to be clear about that, because "the models are smart now, just talk to them" is a take that will cost you real money in the wrong context.

The dividing line I use is repetition. If a task runs once, iterate conversationally. If it runs more than once, write the prompt properly.

Conversational works	Written prompt and context still wins
Building something new	Anything you'll run more than once
Creative and exploratory work	Information extraction and processing
Prototypes and one-off tools	Production pipelines
Work where you'll know "right" when you see it	Work with a fixed output contract

The reason is that conversational iteration has no memory across runs. You converge on a good result through five rounds of feedback, and then the whole thing evaporates. That's fine for a game. It's terrible for an invoice extractor that has to behave identically on Tuesday. For that work, the prompt and the context assembly are the product, and I'd point you at context engineering for AI agents and my prompt engineering notes rather than repeating myself here.

Client work sits mostly on the right side of that table. Personal projects sit mostly on the left. That's roughly the split.

What I Still Put in CLAUDE.md and AGENTS.md

Shorter, not gone. My files run about 10 to 40 lines now and contain only things the agent can't work out by looking around: non-obvious build and test commands with their exact flags, architectural decisions that contradict what the code structure implies, and conventions that go against the obvious default. Everything else got deleted, because it was either duplicating the README or telling the model something it already knew.

Anything that genuinely cannot be broken goes in a hook, not a markdown file. Markdown is a request. A hook is a rule.

FAQ

What is agentic coding?

Agentic coding is a development workflow where an AI agent takes a goal, plans the work, edits files across your codebase, runs the tests, and self-corrects until it's done, with a human reviewing and approving the result. The distinction from autocomplete is autonomy over multiple steps. The distinction from vibe coding is that you still verify.

How do you prevent AI coding agent mistakes with shorter prompts?

By testing every iteration and correcting fast. Short prompts don't reduce mistakes, they change when you catch them. Instead of trying to prevent errors with an upfront spec, you find them by running the build and fixing them in the next round. Keep iterations small enough that any single one is easy to review.

How do you prevent architecture drift in AI coding agents?

Verification you can automate, plus short sessions. Hooks and a test suite catch drift deterministically where instructions in a markdown file won't. Instruction compliance degrades as a session fills up, so starting fresh sessions for distinct pieces of work does more for architectural consistency than a longer rules file.

Is prompt engineering dead?

No. It moved. For one-off building work, conversation beats a carefully written prompt because the correction loop is faster than the specification loop. For anything repeated, automated, or running in production, a well-built prompt and a deliberate context pipeline still make the difference between a system that works and one that works most of the time.

Should I still write a CLAUDE.md or AGENTS.md?

Yes, but keep it under about 40 lines and put only non-discoverable things in it. Committing auto-generated output unreviewed measurably underperforms having no file at all.

The Workflow Will Change Again

I'm aware that everything above has a shelf life. My 2025 process was correct for 2025 models and it's dead weight now. Something similar will happen to this one, probably faster than I'd like.

The part I'd bet on outlasting the specifics: the work is moving from specification to direction and verification. Getting good at describing what you want in three sentences, and at recognising quickly whether what came back is right, is a more durable skill than any particular file layout. Go build something small with one sentence and see what happens.