A model writes a service in an afternoon. It compiles, the suite is green, the naming is more consistent than most of what a tired human produces on a Thursday. And somewhere behind the relief, a smaller and uglier thought arrives: was all that learning just overhead? I have had that thought. I suspect anyone who spent years getting genuinely good at something has had a version of it. Then I read the generated code properly, and the thought inverted.
AI did not retire the fundamentals. It promoted them. They are the interface you direct the work through, and the decision at the end of it is still yours to sign.
- Why the craft you were quietly afraid had become decoration turns out to be the thing doing the steering.
- Six practices, each with the job it was built for and the second job it picked up the day an agent joined the team.
- The short list that does not move, and the one question nobody has ever answered with a prompt at three in the morning.
The Fundamentals Became the Interface
What I catch in generated code is almost never the syntax. The syntax is fine, and it is frequently tidier than mine. What I catch is the transaction boundary it ignored, the failure mode it never considered, the domain rule it violated while passing every test it wrote for itself. I have made the longer version of that argument in knowledge was never the commodity: the technology of the year always decayed, the understanding underneath it always compounded, and the compounding column is precisely what lets you distrust a plausible answer.
The part that took me longer to see is that those fundamentals are not only a detector now. They are a control surface. Look at what each of them actually is, underneath its name: a way of writing intent down precisely enough that something other than you can act on it. A bounded context is a boundary you can hand to somebody. A failing test is a boundary a machine can check. A pattern name is a paragraph of design compressed into two words. Before AI, those were good manners, the sort of thing a senior engineer nagged about on a Friday. Now they are the format in which instructions get issued.
The precision has to exist at the input. You cannot write a vague specification, hand it to an agent, and review your way to a precise outcome.
That flips the economics of pattern literacy. When writing code was slow, reaching for the wrong pattern cost you a week of typing that you would eventually notice you were wasting. Generation is cheap now, so the wrong pattern arrives finished: applied consistently everywhere it touches, with tests, in the house style. The cost is paid at machine speed. Knowing when to use a pattern, why, and the harder half, when not to, was always the mark of the craft. It is now the difference between direction and drift.
The Second Job Every Practice Picked Up
None of what follows is new. That is the argument. Each row is something the industry wrote down long before anyone was prompting anything, together with the job it quietly acquired when an agent became a participant in the build rather than a demo in a keynote.
Read the right-hand column and a shape appears. Not one of these practices changed. What changed is that each acquired a second reader. The deliverable is still judged the way it always was, against the same bar, in the same review. The producer moved, and so did the person: one seat over, from writing the thing to defining it and grading it. That is a smaller revolution than the marketing suggests, and a much larger one than it sounds.
The Part That Is Still Yours
Everything above is amplification. The structural decisions sit somewhere else entirely. Architecture is not the sum of the modules, it is the shape of the decisions: where the boundaries are, which failures are acceptable, how state moves across a distributed system, what happens when a region goes offline. Those live in people and in history, and I have argued in the other seventy percent that they are not in the codebase an agent can read. They never were. They were not in the codebase most of the engineers could read either, which is the part that should worry you.
- The structural decision. Saga or two-phase, event-sourced or state-stored, one service or three. Name any of them and you will get a competent implementation and no opinion whatsoever about which one the business can still afford in three years.
- The trade-off. Cost against resilience, speed against reversibility, simplicity now against optionality later. A generated answer optimises the request it was given. Deciding which quality wins right now, and defending that in a room, is the job.
- The accountability. At three in the morning there is no prompt for the moment, only the question of who owns this system. Ownership is not a capability, it is a relationship, and it was never the machine's to take.
- The taste to reject a plausible answer. The hardest review is the one where nothing on the screen is wrong. Coherent, tested, tidy, and quietly at odds with a rule that lives half in someone's head and half in a five-year-old wiki page.
Confidently wrong, inside a boundary nobody drew
An agent dropped into an ambiguous domain does not clarify it. It encodes the ambiguity, at speed, into code that is harder to refactor than hand-written code precisely because it is more consistent-looking and there is more of it. The tell is that nothing looks broken. The service compiles, the suite is green, the dashboards hold the colour they were, and a rule that belonged to one part of the domain has quietly started doing work in another. That is not a model failure. It is a missing boundary being filled in by something that had no way of knowing it was missing. The second version of the same failure has no code in it at all: handing over the decision rather than the typing, and finding out much later that nobody in the room can say why the design is the way it is.
Where This Lands
None of this asks you to slow down or to feel guilty about the leverage. The speed is real and I would not give it back. It asks you to point the craft at the input rather than the output, because that is where precision now has to exist. Five moves carry it out of theory.
- Name the bounded context before you name the task. What may be touched, what must not be, what done looks like inside it. Everything downstream inherits the precision of that one sentence.
- Hand over the failing test, not the paragraph. One boundary, machine checkable, no ambiguity about done. If you cannot write the test, the requirement was not ready for a human either.
- Use the domain's exact words, every time. Order is not purchase is not basket. Synonyms are where a model starts guessing, and it guesses with total composure.
- Make the structural call yourself, in writing, before generation starts. Which pattern, which boundary, which failure you are choosing to accept. Put it in a decision record where the next person can argue with it.
- Sign it. Whatever wrote the code, one name belongs at the bottom of the design, and it has to be somebody's.
Let AI amplify the judgment and draft the work. Never let it hold the decision. Whatever wrote the code, the name at the bottom of the design still has to be a person's.
The fourteenth discipline gets a second essay, because a force this size deserves its applied half. Find the Use Case Before the Model turns the mindset into a selection discipline: where AI genuinely earns a place in your lifecycle, phase by phase, and which adaptation pattern each place deserves, from plain prompting to grounding to agents.