loading…
From producing every line to designing, directing, and verifying the system that produces software
AI does not remove engineering work. It changes its center of gravity. When implementation can be generated quickly, the engineer spends proportionally more time deciding what should be built, shaping the environment in which AI works, reviewing evidence, and operating the resulting system.
In the factory model, the engineer's most leveraged output is not an individual piece of generated code. It is the system that repeatedly turns intent into reviewed software: specifications, repository context, tools, test environments, evals, policies, and deployment gates.
This does not mean developers stop writing code. They still intervene where business logic, difficult debugging, performance, security, or novel architecture requires direct expertise. The shift is that code becomes one artifact inside a larger production system.
Strong engineers move between these modes. They do not delegate a poorly understood problem merely because an agent can attempt it, and they do not micromanage a well-specified repetitive task merely because they can.
| Responsibility | Why human judgment remains important |
|---|---|
| Problem framing | Organizations often state symptoms rather than the real problem |
| Architecture | Trade-offs span reliability, cost, latency, privacy, ownership, and future change |
| Domain translation | Business rules are incomplete, political, or context-dependent |
| Risk decisions | Someone must decide acceptable authority and failure impact |
| Verification design | Metrics and evals encode what the organization values |
| Accountability | Systems need owners who can explain, pause, repair, and improve them |
Ad hoc AI use has low setup cost: open a tool, describe a task, and iterate. A production harness has higher upfront cost because the team must build context pipelines, tool contracts, tests, eval datasets, permissions, and observability. The investment is justified when it lowers repeated review, failure recovery, token waste, and maintenance.
| Ad hoc use | Engineered system | |
|---|---|---|
| Upfront effort | Low | Higher |
| Repeatability | Depends on individual prompting | Encoded in reusable context, workflows, and tests |
| Failure diagnosis | Conversation history and guesswork | Traces, versions, error taxonomy, and reproducible evals |
| Marginal task cost | Can grow through retries and manual review | Can fall as routing, caching, and automation improve |
The most capable model is not always the best choice for every step. A mature system may use:
Model routing must be verified: a cheaper route that causes more retries may cost more overall. The useful unit is not price per token alone, but cost per successful, acceptable task. Chapter 5 will develop this production economics view.
Chapter 1 established the system-level mental model:
Chapter 2 now opens the harness and studies its reusable building blocks: models, prompts, context, retrieval, structured outputs, tools, APIs, MCP, state, identity, and basic permissions.