/ THE SHIFT
Coding isn't the job anymore
For eighteen years, my job description was "write the code". Eighteen months ago that ended. Today the job is to specify what should happen, give the model enough context to choose well, and review what it did. The code itself is a byproduct.
That shift sounds small. It is not. It changes which skills compound. The senior engineers I know who refused to make the shift are now slower than mid-level engineers who embraced it. The ones who did make it are running businesses that used to require teams. The dividing line is not raw talent. It is how willing you were to learn a new craft from scratch in your forties or fifties.
The new craft has a name. I call it agentic engineering: the discipline of getting agentic AI systems to do high-leverage work reliably, repeatably, and at a cost-quality point that beats the human alternative.
/ WHAT AGENTIC MEANS
"Agentic" is not "autonomous"
The word agentic gets thrown around as a synonym for "fully autonomous". It is not. An agentic system is one that can take multi-step actions on its own, but reliable agentic systems are the ones where you have decided which steps it can take, in which contexts, with what rollback and review surface. Autonomy is the dial you can turn up once the guardrails work; it is never the goal in itself.
The mental model I use: an agent is a junior engineer who is unbelievably fast, never gets tired, has read every public codebase ever, and has the worst possible memory for project-specific context. Your job is to be a senior who supplies the context, sets the constraints, and reviews the diff. Anyone who has managed juniors will recognise the pattern instantly. Anyone who has not will mistake the speed for skill and pay a tax for it.
/ THE FOUR LAYERS
A working agentic stack has four layers
Strip away the marketing and almost every production agentic setup decomposes into four layers. Knowing which layer you are operating in saves enormous amounts of debugging time.
- Conversation. A model that takes natural-language instructions and produces work. This is the layer people start at. It is the layer where most people stop, because it already feels miraculous compared to last year's tooling.
- Tools. The same model, plus the ability to read files, run commands, search the web, call APIs. The moment a model can run a command and see the output, you have crossed from "smart autocomplete" to "agent". Almost every interesting capability lives downstream of this jump.
- Orchestration. Multiple agentic loops cooperating. One agent specifies, another implements, a third reviews, a fourth deploys. Each loop has its own context window, its own model, its own permissions. This is the layer where most agentic businesses actually live, and it is the one most tutorials skip.
- Memory. Persistent state across sessions. Files that the agent reads on every turn ("system prompt extensions"), running notes the agent updates between conversations, retrieval over old work. Memory is what stops every Monday from being Monday-zero.
The big mistake at every layer is the same: confusing the technology with the system. A better model does not save you from sloppy orchestration. A better orchestration does not save you from absent memory. A better memory does not save you from a vague conversation. The layers stack, and the weakest one bottlenecks the rest.
/ THE DAILY LOOP
What a day on the keyboard actually looks like
Six months ago my day was eight hours of typing. Today it is eight hours of reading, deciding, and intervening. The keyboard time is closer to ninety minutes, and most of that is short corrections, not original code. The other six and a half hours go to specification, review, and prioritisation.
A typical block looks like this: I open a conversation, paste in a single problem, the relevant files, and the success criteria. The model proposes a plan. I read the plan, push back on two things, accept the third. The model implements. I read the diff while it runs the tests. The tests fail. The model reads the failure, proposes a fix. I either let it, or I notice the root cause is somewhere it would never look, and I intervene. Repeat for ninety minutes. The output is what would have taken a junior engineer a full day, and I never wrote a function signature.
Crucially, I do not chain agents on this kind of loop. The temptation to set up "agent A calls agent B which calls agent C" is enormous and almost always wrong at this granularity. Chaining only makes sense when you have already proven the work is repeatable, the inputs are clean, and the failure modes are scoped. Most of the day, one conversation with one agent under your supervision beats any orchestration scheme you can build.
/ WHEN TO ORCHESTRATE
The orchestration test
The single best test I have for "should I orchestrate this or just do it conversationally" is the repetition test. If I have done a piece of work three times the same way and the output was acceptable each time, then it deserves an orchestrated pipeline. Anything done fewer times is still a research question, and turning a research question into a pipeline gives you a brittle, expensive, hard-to-debug system that produces wrong answers at high speed.
The piece of the business that runs this site is orchestrated end-to-end: research a market niche → propose a product → review → write the content → critique → render the PDF → generate the cover art → publish to four platforms → schedule the social posts. That entire pipeline runs unattended, and I tap a single button to advance each product to the next stage. It works because every step was first done conversationally, fifteen or twenty times, until the failure modes were known and the constraints were sharp. Only then did I lift it into orchestration.
Most people invert this. They start by building the orchestration and then debug the components afterwards. That order produces a system that fails in twenty places at once, with no clear way to isolate which component is wrong. It is the most expensive way I know to learn the same lessons twice.
/ GUARDRAILS
Guardrails are where leverage actually comes from
Untrained operators worry about which model they use. Trained operators worry about guardrails. The model is interchangeable. The guardrails are not.
A guardrail is anything that catches a class of mistakes before it reaches production. It can be a programmatic check ("if the output has more than three em-dashes, the model has gone into purple-prose mode, retry"), a structural rule ("every API endpoint must respond within ten seconds or the caller treats it as failed"), or a workflow gate ("human approval required before publishing to Etsy"). They are boring. They are tedious to design. They are the single biggest difference between an agentic system that holds up under load and one that collapses on the third Tuesday.
The guardrail framework I use has three lines of defence. Prevention: the prompt itself says what not to do. Detection: programmatic checks after the model output catch what slipped through the prompt. Repair: small auto-fix routines patch known recoverable mistakes without re-invoking the model. Every layer is cheaper than the next, and stacking all three is what makes the difference between "ninety percent acceptable" and "ninety-nine percent acceptable", which sounds like a small gap but is, in practice, the gap between a system you can leave running overnight and one you cannot.
/ MEMORY
Memory is the silent multiplier
The default agentic setup has the memory of a goldfish. Every Monday is Monday-zero: the agent does not remember what it learned last week, does not remember the decisions you made together, does not remember which approach failed last time. The cost shows up everywhere, but it shows up softly enough that most operators never name it.
Three forms of memory matter. Project memory: a versioned file in the repo that the agent reads on every turn (CLAUDE.md is the canonical example). Operator memory: persistent notes the agent keeps about you, your preferences, your past feedback. Conversation continuity: the ability to pick up an old conversation rather than starting fresh. The first two are mostly under your control today; the third is what the tooling vendors are racing to build.
If you only have time to invest in one thing this quarter, invest in project memory. A well-tuned CLAUDE.md or equivalent saves more model time than any other intervention I know. I wrote a separate field manual for it; the gist is to treat it as part of the system prompt, not as a README, and prune it monthly.
/ THE COST DIMENSION
Cost is the constraint that shapes everything
The third Tuesday of every month I sit down with the API bills and trace the spend back to specific operations. Almost every month there is a single pipeline step that is responsible for half the cost and a third of the failures. Fix it, and the system gets cheaper and more reliable in the same patch.
A few patterns that have paid back repeatedly. Match the model to the task: the cheap model handles classification and extraction, the medium model handles writing, the expensive model handles strategy and editing. Routing by task type often cuts spend by sixty to eighty percent with no loss of quality. Cap retries with intent: a retry loop that fires a more expensive model on each attempt is a slow-motion bill explosion; a retry loop that backs off to a cheaper model and accepts a degraded output is a self-throttling system. Truncate at the boundary: ask the model for a soft cap above your hard limit, then truncate programmatically. Trying to make the model hit an exact length never works reliably and burns retries trying.
/ WHAT DOES NOT WORK
Things that look great in demos and rot in production
A short list of patterns I would warn anyone away from after watching them eat my time.
- Multi-agent debate. Two agents arguing to produce a better answer. Plausible-sounding research literature, almost no real-world wins. Costs three to five times more, quality rarely improves, and you have doubled the surface area for failure. Skip until proven otherwise.
- "Autonomous agent" frameworks that promise to do everything. The general lesson: any framework whose pitch is "tell it your goal and walk away" is selling you a demo. The interesting work is everywhere the demo does not show.
- Vector databases as a first reach. Often the right answer is a grep over the repo, not embedding everything into a vector store and praying. Vector search is great for fuzzy similarity at scale; it is overkill for "where is this function called" and worse than grep at it.
- Speculative parallelisation. Running ten variations in parallel and picking the best sounds clever and usually produces ten mediocre outputs that take ten times the budget. Quality comes from iteration with feedback, not from amplifying a poor signal ten ways.
/ THE NEW SKILLS
What you actually need to be good at
The skills that compound in agentic engineering are not the skills that compounded in classical engineering. There is overlap, but the shape of the daily expertise is different.
- Specification. The ability to describe an outcome precisely enough that a fast, eager, context-poor collaborator can hit it. This is closer to product writing than to code writing. Spend the hour on the spec; you will save five on the implementation.
- Reading diffs at altitude. When the agent ships fifteen file changes in a minute, you cannot read each one carefully. You need a calibrated radar for "this is the kind of edit I trust" versus "this is the kind I always end up regretting". That radar is built by review reps, not by typing reps.
- Choosing the right altitude of intervention. When the agent goes off the rails, do you correct the prompt, restart the conversation, fix the underlying spec, or change the orchestration? Each of those has a different time cost, and picking the wrong one is the most common way operators bleed hours.
- Knowing when to stop. A working agentic system tempts you to add features endlessly. The good ones know which features earn their weight and which add surface area without adding revenue. This is the same skill product managers have always needed, but now you cannot offload it to anyone.
/ WHO THIS IS FOR
The transition is happening whether you like it or not
A lot of senior engineers I respect are sitting this out, on the theory that it is hype and will pass. I do not think it is going to pass. I think it has already changed the economics of small software businesses irreversibly, and the engineers who keep waiting will find their classical skills repriced downward at a rate they did not budget for.
The encouraging news, if you are one of them, is that the transition curve is shorter than you expect. Six weeks of serious daily use puts you ahead of ninety percent of people who say they use AI coding tools. Six months puts you ahead of almost everyone. It is not a five-year retraining; it is a six-month rewiring of how you spend the workday.
If you are not from an engineering background at all (a product person, a founder, an operator), you are at a different starting line but on the same curve. You no longer need to hire engineers to ship software. You need to learn to specify, review, and orchestrate. The skills that translate from non-engineering backgrounds (writing precisely, judging quality, knowing what users actually want) are exactly the skills agentic engineering rewards.
/ CLOSING NOTE
Two parts, one craft
The playbook PDF that anchors this post is two-part on purpose. Part one is the mental model: what changed, why, and what to invest in to land on the right side of the shift. Part two is the daily mechanics: the loop, the guardrails, the orchestration rules, the cost discipline. You can read either alone, but the bundle is what most readers will want, because the mental model is what justifies the practice and the practice is what makes the mental model land.
One operator can now ship what five used to. The discipline that makes that real is small, learnable, and almost entirely about restraint: knowing what to delegate, what to specify, and what to leave alone. That is the playbook. The rest is reps.