From Builders to Hardeners
The founder’s repository was cloned, checked out and open in a senior engineer’s editor before the senior engineer had finished his first coffee. Seven minutes past nine on a Monday morning. He read the first commit message aloud to nobody in particular, because that is what he does when something is either very good or very suspicious. It said initial working demo — registration, payments, email, the diff ran to eleven thousand lines across seventy-two files, and the timestamp was two thirty-one on Sunday morning. The founder — I will call him Felix, and the specifics of his product are not the point here — had pushed his code from bed, or his kitchen, gone to sleep and mailed the link on his phone. We had the repository open before he woke up.
That reversal — we are reading his code before he has read it twice — is the shift this chapter is about.
For fifteen years the Sliday inbox opened on a brief. Sometimes the brief was a napkin, sometimes a forty-page specification with a signed budget attached, more often something in between. The work of the first week was always the same. We would read what the founder had written, sit with what he had meant, and produce a document that restated the product in terms an engineer could implement. We charged for that document. We charged well for it, because it was genuinely difficult, and because there was no other way to cross the distance between an idea in the founder’s head and a thing on the App Store. The core skill the studio sold was interpretation.
Interpretation is no longer the work. Our Monday-morning engineer is paid to take an honest look at a product that has already been written.
That is the role shift, and I want to name it cleanly before the walk-through. The old core skill was interpretation; the new core skill is a pair. One half is editorial judgement — deciding what survives the week and what is cut. The practitioner of editorial judgement is a Sculptor. The other half is engineering hardening — taking what survives and making it production-ready in the specific, unglamorous senses the next pages will deepen. The practitioner of hardening is a Hardener. In our practice most senior engineers are now both, in sequence, on the same repository, in the same week. They were doing the second half of this pair for a decade before anyone gave them a word for the first half. What has changed is that the first half is now priceable.
What follows is one day with one engineer on one repository. It is chosen because it is ordinary.
On the first pass he reads as a Sculptor. He opens the repo in full-screen, kills every notification and makes a three-column page on his desk: keep, harden, cut. He walks the route map first. Felix has eight routes exposed; the ninth is commented out with a note saying maybe later. That ninth route is the first thing into the cut column before any code is read. A feature a founder hesitated on at two in the morning is a feature a user will not thank us for at eleven on a Tuesday. He then walks the data model. Four tables, three of them with fields that have no UI and no writes. Those fields go into the cut column. Next the dependency list. Forty-one packages in the lockfile. Twelve are transitive children of a single template Felix forked. Half of those twelve are doing nothing this product needs. The list of things to cut grows faster than the list of things to keep, which is how this pass is supposed to go.
We used to guess forward from a brief; we now trim backward from an artefact.
Keep the three-column page physical if you can: paper, whiteboard, a text file you print and mark. The goal is to finish the Sculptor pass before opening the editor to write a single line. Once you start writing code, the instinct shifts from cutting to completing, and features that should have been in the cut column become features with half a migration attached.
By lunchtime the keep column is short, the cut column is long, and the harden column is the one Felix will find difficult. A prototype the founder has stayed up until two in the morning building is, by definition, a prototype he has fallen in love with. He has not been asked, on any previous engagement with any previous studio, to lose features his own hands shipped. Saying no to him is part of the work now, and it is the part that travels under the studio owner’s name even when a senior engineer holds the pen. The pricing of that skill waits for Pricing the Cut; the discipline of subtraction itself — how to cut without apologising, how to make the founder feel the cut as a gift — waits for The Discipline of Subtraction. We are naming the role here.
The afternoon is the hardening pass. The Hidden Axiom named the list and ran through it quickly; here is the list running at working speed, and the detail matters because the detail is where the engagement is billed. Artem, a frontend engineer on our team, put the shift plainly: he now spends roughly five per cent of his time writing code from scratch and the rest working with AI-generated code, and the quality of what ships has gone up because there is finally time to optimise it properly rather than just to finish it.
At every boundary that takes input from a user, a third party or a model, the engineer writes or audits validation. Prototypes regularly parse JSON out of an LLM response and trust it, and the cost of that trust in production is a Monday morning incident, a refund and a new line in the post-mortem document. The auth model is the second pass — who is logged in, what they are allowed to do and whether any route in the keep column can be reached without the right session. Most prototypes have one kind of user and no second check; most products need three. Secrets follow. Felix has almost certainly committed at least one API key to git at some point in the last forty-eight hours; some of those keys are still live, and the engineer rotates them before anything else ships. Rate limiting on anything a bot can reach — signup, password reset, the public contact form, any unauthenticated endpoint that writes to the database — is next. Founders do not wake up thinking about bots, and their prototypes do not either. Idempotency and sane retry behaviour is the fifth pass, and it is the one that most obviously separates the demo from the product: a payment flow that works once on the founder’s laptop is not the same flow under a mobile network that drops halfway through a POST, retried by the client library and charged twice. One client asked us to design backpressure between Kafka consumers, producers and a database; the AI assistant confidently proposed a thread sleep to throttle the load. In a distributed system, blocking a thread to manage throughput is a flaw that compounds under pressure — demoable, and catastrophic at scale. Observability — structured logs, traces and metrics thick enough to see which of the previous five just broke — is the sixth. Dependency provenance is the seventh; a model suggested a package, the founder typed yes, and sometimes the package is a six-month-old fork with four stars and a maintainer who has stopped answering issues. A rollback plan is the eighth, and it is the one no prototype has ever had and no production system should ship without. We name this milestone the production readiness gate; it is the moment the codebase is allowed to leave the studio’s keep.
The senior engineer is not discovering these categories. He has been doing each of them for ten years and knows the ordering in his sleep. Dmytro, a backend engineer with seventeen years in the stack, including time in enterprise banking systems, described the shift this way: what AI has not changed is how he defines correctness, only where his day goes, which is now towards enforcing it, because the tools are built to produce something demoable, not to catch edge cases that only become visible under load. His maths and systems training acts as a structural filter; it catches logically unsound generated code faster than any linter. What is new is that these categories are now the centre of the engagement rather than the final sprint before launch, and that they are the work the founder cannot do himself — not for lack of cleverness, but because his model did not suggest them, and the cost of getting them wrong is work he has never had to carry.
Run the hardening pass in this sequence for a reason: each category in the list makes the next one cheaper to fix. Validation at the boundary catches the malformed input before it reaches the auth layer. Auth tells you which routes need rate limiting. Rotating secrets before you add observability means your logs never contain a live key. Idempotency before observability means your traces show intent, not noise from duplicate requests. The order avoids reopening earlier work.
A studio owner reading this chapter will want the commercial consequences of the split, because that is where the hiring and the firing live.
The senior engineers already on the team are, in almost every case, already both roles. They have been doing the hardening work for ten years, and most of them are sharper editors than we have ever given them credit for, because the same temperament that notices a missing idempotency key also notices an unused screen. They do not need a retraining programme. They need a new job description, a clearer seat at the editorial table and, in some cases, a correction on the years we priced the editing at zero. Pay them for the morning as well as the afternoon.
The designers are changing shape faster than anyone else. The best of them are now closer to sculptors than to visual-layer technicians, because design taste and editorial taste run on similar instincts; the designer who has spent a decade removing the wrong button from the wrong screen already knows how to remove the wrong screen from the wrong product. Promote the sharpest of them into explicit Sculptor roles, and let them run the first-pass read before the engineer opens the repository at all. We have started doing exactly this, and the first-pass reads come back tighter.
The roles under most pressure are the business analysts and the junior project managers whose work was to produce the scoping artefact. That artefact is no longer the centre of the engagement. A subset of these people are among the sharpest editors in the building — they read founders for a living — and should be moved into Sculptor roles immediately, with the rate adjusted up rather than down. The rest were good at interpretation specifically, and the honest thing to do is to help them find what else they can do, inside the studio or outside it, rather than keep them writing documents the engagement no longer pays for. This is an uncomfortable paragraph to write. It is also the honest one.
On hiring into the studio from outside, we now interview differently. We give the candidate a small, ugly founder-built repository and forty-five minutes, and we ask them to produce the three-column page. We watch what they cut, what they flag and what they keep. We read their reasoning back to them and listen for whether they argued the founder’s corner or their own. It is the single most useful interview we have ever run, because it distinguishes the engineer who can say this should not exist from the engineer who can only implement what is already there. We do not hire the second kind any more.
A note on the utilisation model, for the studio owner reading with a calculator open. In the old engagement, interpretation sat in the first third of the calendar and billed at analyst rates, construction sat in the middle and billed at engineering rates, and hardening was squeezed into the last two weeks. In our current engagements the proportions have roughly inverted. The Sculpting pass is days rather than weeks, but it is booked at the senior rate because the judgement is where the value now is. The hardening pass is the long centre of the engagement and is billed as engineering work, because that is what it is. The construction phase has mostly gone, folded into what the founder did at the weekend. That is the line a studio owner should be modelling against.
Some of this is now being argued for in the academic literature, which has noticed the shift before the industry has named it. A 2026 arXiv paper frames code itself as moving from scarce, laboriously crafted artefact to abundant, disposable commodity, and argues the discipline must reorganise around orchestration, verification and the human–machine collaboration rather than around authorship of lines.1 A separate 2025 paper uses the label SE 3.0 — agentic software engineering — for the same transition.2 Both are descriptions of the same observation Felix’s Monday-morning engineer is already living. Neither, as of this writing, has a word for the editorial half of the job. That word is in this book, and this chapter is where it starts earning its keep.
The studio that has spent fifteen years building senior engineers who can cut a repository in the morning and harden it in the afternoon is already most of the way across. What remains is the will to charge for the morning as well as the afternoon, the willingness to retire a job description that was honest in 2018 and the nerve, week after week, to defend both halves of the pair when the founder asks, with genuine hope in his voice, whether the ninth route can come back.
A studio that cannot say no to a founder’s pet feature is a studio that has not yet adapted.