A lot of AI coding setups get worse as they get more impressive.
The screenshots look serious. The workflow diagrams look serious. There is memory, orchestration, prompt layering, task routing, auto-compaction, five model roles, and a stack of tools that mostly exist to manage the complexity created by the last layer of tools.
Then you actually try to ship with it.
And the overhead starts eating the gain.
That is why my day-to-day setup is pretty boring.
I do not want an AI workflow that feels clever. I want one that keeps the model close to the code, shortens the feedback loop, and reduces the amount of state drift I have to clean up later.
What I optimize for
The goal is not “maximum capability” in the abstract.
The goal is:
- strong code output
- low workflow drag
- fast correction when the model goes wrong
- clean handoff when the thread gets bloated
- enough outside context to unblock real work without turning the prompt into a tool catalog
That pushes me toward a much smaller setup than most people expect.
One strong coding model beats a committee
Right now I use OpenAI’s Codex for coding.
I mostly work with gpt-5.4 and gpt-5.5, usually with high reasoning enabled.
That is not because I think model choice is the whole game. It is because a lot of agent pain comes from switching too many things at once. If the model is unstable, the workflow becomes hard to evaluate. If the workflow is bloated, model quality gets masked by process noise.
One strong default is easier to reason about.
It also makes rework easier to notice. If a run goes badly, I do not have to guess whether the problem came from model routing, memory contamination, prompt layering, or a subagent chain I barely wanted in the first place.
The system prompt should bias behavior, not impersonate a methodology
A lot of coding-agent system prompts are trying to be a textbook, a project manager, and a cultural manifesto at the same time.
I do not think that helps much.
The model usually does not need a giant theory of software engineering. It needs a narrow set of constraints that reliably bias it toward how I want to work.
The prompt I use is opinionated, but it is small.
It mostly pushes the model toward things like:
- treat the user’s direction as the source of truth
- read the real code before proposing changes
- keep scope tight
- avoid speculative abstractions
- prefer Bun in TypeScript repos unless the repo already chose something else
- estimate work based on actual file and module impact
That is enough.
The point is not to lecture the model. The point is to reduce a few predictable failure modes.
Safer edits matter more than people think
A surprising amount of coding-agent pain is not reasoning failure.
It is state drift.
The model read one version of the file. The file changed. The next edit lands slightly off. Then the whole run starts accumulating small positional mistakes that are annoying to detect and even more annoying to recover from.
That is why I really like Pi’s hash-anchored read/edit flow.
Every line gets a short hash. Edits target the exact version of the file that was read. If the file changed underneath the edit, the patch fails loudly instead of landing in the wrong place.
That sounds like a small implementation detail until you use it for a while.
Then it starts feeling like one of the few workflow improvements that actually removes a category of pain instead of adding ceremony around it.
Immediate diagnostics beat delayed elegance
I pair that editing flow with immediate diagnostics.
In practice, that matters more to me than most of the fancier workflow features people get excited about.
I want the model to make a change and then get told right away if the code now fails type checks, imports, or language-server diagnostics. Not ten tool calls later. Not after the model has already started building on top of a broken assumption.
That tight correction loop does more for output quality than a lot of high-ceremony agent patterns.
It keeps mistakes local.
I prefer clean handoffs over memory systems
I do not use memory much.
Every time I push harder on memory systems, I end up spending more effort managing context strategy than shipping code. The promise sounds good: the agent remembers everything, accumulates preferences, and keeps improving across sessions.
In practice, I often get the opposite. Old context lingers. Half-relevant summaries stick around. The model becomes more likely to inherit stale assumptions than to gain useful continuity.
So when a thread gets bloated, I do something simpler.
I generate a clean handoff prompt, start a fresh session, and continue with a tighter brief.
That is a better trade for me than pretending lossy memory is the same thing as real context.
External tools are useful when they stay lazy
I do use outside tools, just not as a lifestyle.
The few times I want web search or external docs, I use them through a lazy-loading adapter. That way the tool metadata does not bloat the prompt up front, and I only pay the complexity cost if the run actually needs it.
That has been a much better fit than keeping a giant always-on tool surface in the model’s face.
Most of the time, the model should be reading local code, editing local code, and checking local diagnostics. Everything else should be opt-in.
Visual context matters as soon as the work stops being purely textual
Models are still pretty mediocre at design judgment.
They can produce acceptable interface code. They can get you to “fine.” But if the work is about spacing, hierarchy, rhythm, or visual emphasis, prose-only feedback gets clumsy fast.
So for UI work I like having a way to annotate the actual interface directly.
Point at the real element. Call out the spacing bug. Mark the alignment issue. Feed back structured visual context instead of writing an essay about a margin.
That is a much better loop than trying to teach taste through chat.
I also like using image generation for mockups and branding work when the job is visual rather than code-first. Same account, same environment, less context switching.
What I do not really use
Day to day, I do not lean much on:
- subagent-heavy workflows
- memory systems
- elaborate tracking layers
- giant prompt scaffolds
- high-ceremony orchestration
I have tried plenty of them.
My experience is that they feel impressive for a week and then quietly create more model drift, more prompt weight, and more maintenance overhead than they are worth.
That does not mean nobody gets value from them. It means I do not.
The setup in one sentence
If I had to compress the whole thing down, it would be this:
One strong coding model, a narrow prompt, safer edits, immediate diagnostics, lazy external tools, and better visual feedback once the work stops being purely textual.
That is basically it.
It is not a maximalist AI stack. It is a practical one.
And for me, that has been the difference between “playing with an agent workflow” and actually shipping with one.