# Code Got Cheap. Judgment Didn't. > How software gets built when agents write the code: the harness, agents connected to the real work, backends built for agent traffic, agents that act before they're asked, and where people stay in the loop. Source: https://ahmedprime.dev/thesis # Code Got Cheap. Judgment Didn't. Notes on building software after the code started writing itself. And [3 long reads](#long-reads), each working one idea through on a real project. ## What's an engineer for, once anyone can generate code? For thirty years the constraint was throughput: how many lines a team could write, test and ship before the money ran out. That constraint is gone. Code has been commoditised. What's scarce now was always scarce. We just hid it behind the typing: knowing what to build, how the pieces fit, and when to say no. ## 1. The harness is the product Why do smart models still ship dumb software? Because a model is an engine, and nobody ships an engine. You ship a vehicle. The harness is the vehicle: the spec the agent reads, the tools it can reach, the permissions it runs under, the memory it keeps, the review it has to pass, and the loop that catches the mistake before it reaches main. A better model makes a good harness faster. It doesn't make a bad harness safe. ## 2. Agents need the whole picture Most harnesses stop at the repository. The work doesn't. The crash is in Sentry. The reason is in the analytics. The decision is in the tracker, and the argument about it is in Slack. An agent that can read all of those, through the connections the team already uses, knows what the colleague who was in the meeting knows. That's the bet behind [PRCHD's team lane](/projects/prchd#team-lane): no integrations of its own, just every tool the agent can already reach. ## 3. Agents are the new traffic Who's going to call your API next year? Not people clicking buttons. Agents: yours, your customers', and ones you haven't met yet. They don't need pretty screens. They need: - **Contracts.** Typed APIs and MCP servers, not a UI to scrape. - **Idempotency.** Agents retry. Your backend must not charge the card twice. - **Scoped identity.** Per agent, per tool, revocable. "The bot has admin" is not a security model. - **Budgets and rate limits.** An agent stuck in a loop is a denial-of-wallet attack you wrote yourself. - **Audit trails.** Who did what, on whose behalf, and who approved it. - **Errors a machine can read.** "Something went wrong" is useless to a person. To an agent, it's an invitation to try everything else. Frontends get thinner. Backends get heavier. A backend sized for two hundred people a minute will meet callers that run all night, retry on every error, and fan out in parallel. Most of what I've built this year has a door for agents. Snap Receipt's connector and FieldAudit Pro's MCP server use scoped, revocable credentials, and tools that can't destroy data, because the code that would do it isn't there to call. ## 4. From reactive to proactive An agent that only answers when prompted is a very expensive autocomplete. The next step is agents that notice. 1. **Notice.** An agent reads product analytics and crash reports, and finds a drop-off in onboarding nobody filed a ticket for. 2. **Propose.** It writes a feature proposal in the tracker, with the evidence attached. 3. **Share.** It posts the link in the team's Slack channel. 4. **Approve.** The product owner approves it, edits it, or kills it. One person, one decision. 5. **Plan.** An agent splits the approved feature into tasks. 6. **Build.** Coding agents take the tasks, each on its own branch, and open pull requests. 7. **Review.** A reviewer agent goes through each pull request alongside a senior engineer. The agent catches the boring mistakes. The engineer catches the wrong ones. 8. **Verify.** A QA loop runs the tests and the real app. Failures go back to step 6, not to a meeting. 9. **Ship.** The feature lands, the analytics agent starts watching it, and the loop begins again. *Diagram: The proactive loop in nine steps: agents notice, propose, share, plan, build and verify; people approve, review and ship. Failures at Verify go back to Build, and Ship starts the loop again.* Look where the people are: at the approval, at the review, at the ship button. Not at the keyboard. **How much of this runs today?** In PRCHD, four of those steps run with no glue at all, and most of the rest is one recipe away. The step-by-step table is on [PRCHD's page](/projects/prchd). ## 5. What happens to the team So who do you hire? People who can write a spec an agent can build from, and can tell when what comes back is wrong. The senior job becomes designing the harness: the specs, the skills, the gates, the trust boundaries and the review. Juniors don't disappear. They learn faster than we did, because their first reviewer never gets tired. But someone still has to decide what good looks like, write it down, and say no. That's the job now. ## 6. What doesn't change So is engineering over? No. Most of it matters more than it did: - Security still needs a mechanism, not a promise. - Somebody still owns the outcome. - Taste still matters. Agents will happily build the wrong thing, perfectly. - The boring disciplines matter more: tests, observability, rollbacks. There's far more code now, and most of it wasn't written by anyone who'll be there when it breaks. ## 7. What would change my mind Where could I be wrong? - **If models stop needing a harness.** If an agent can be trusted on a production branch with nothing but a prompt, the harness becomes a commodity too. I haven't seen it. My own projects show the opposite most weeks. - **If agent traffic stays a rounding error.** If agents are still a small share of the calls to the backends I build by the end of 2027, then "backends get heavier" was early. Early is a cost too. - **If proactive agents bring more noise than signal.** If teams start ignoring agent proposals the way they ignore alert storms, the loop needs a better filter before it needs more autonomy. That's the problem PRCHD's next desktop view is designed around. ## 8. Long reads Where's the long version? Here. Each one takes an idea and works it through on a real project. 1. [Write It Down First](/thesis/write-it-down-first) How I build with coding agents, spec first, and the remote teams that taught me the habit. 2 October 2026 · 8 min read 2. [Conductor vs PRCHD: Move the Agent, or Move the Desk?](/thesis/conductor-vs-prchd) Both run Claude Code and Codex in parallel worktrees. They split the moment you leave the desk. 21 September 2026 · 8 min read 3. [EntrenaPro — From Zero To Flutter](/thesis/entrenapro-from-zero-to-flutter) A 40-screen app for iPhone and Android in four months, on Flutter before 1.0, and what I learned on the way. 2 October 2018 · 9 min read · First published on [Medium](https://medium.com/@mahmed8003/entrenapro-from-zero-to-flutter-105151781fa6) I'll update this page when the evidence changes. [The Projects page](/projects) is where it shows up first. **Still have questions?** [Ask the agent about this page](/ask?about=thesis) Or [write to Ahmed](/contact)