Ten thousand dollars a week

In July 2026 a team of three senior engineers called Slopfix reached the front page of Hacker News with an unusual offer: "One week. Three senior engineers. $10,000." The job is not to write code. It is to delete it. They take codebases built with coding agents and cut them back to something a team can maintain, paid in proportion to how much of an agreed line-count reduction they deliver.

Their diagnosis fits in one sentence: "This happens to every vibecoded project past a certain size: the agent stops seeing the whole picture and starts duplicating code instead of finding it." Nobody deleted a database and nothing went rogue. The agent did what it was asked, one task at a time, until "adding a feature now takes days and breaks two other things." Their example of the cleanup: "the fourteen date formatters become one."

The twist is in their own FAQ: "Yes, we use Claude Code too. On a very short leash." The same kind of agent that produced the mess is the one removing it. What differs is the structure around it: a written list of what the app does, screen by screen, before anything is cut; senior engineers who decide what stays; and, among the deliverables, a CLAUDE.md, lint rules and CI checks. In their words, "the agent doesn't get a vote."

I use Slopfix as a public illustration of a failure pattern, not as an audited case study. The source and its limits are in Appendix C.

Why this keeps happening. A senior engineer tells me they tried Claude Code, or Codex, or another coding agent, and "it didn't work": the code looked right and was not, or something broke and nobody noticed for two weeks. Most failed adoptions are not explained by model weakness alone. They are failures of structure around the agent: missing context, constraints, process and review discipline.

You can pick up a hammer and use it. You cannot pick up a junior engineer and use them; you onboard them, give them context, set up review, build trust over time. Agents are closer to the junior engineer than to the hammer - a stance, not a claim about the agent's nature: the agent is software.

The thesis. Agentic software delivery is not primarily a tooling problem. It is a control problem. Control the context, the actions, the verification and the adoption surface, and the agent becomes useful; fail to, and it becomes expensive noise or operational risk. The three parts of this manual are three controls: Architecture is the control of capability (what the agent can know and do), Method is the control of workflow (how work is formulated, executed and verified), Reality is the control of adoption (where the method applies and where it should not).

By "agentic" I mean a system that takes a goal, decides which actions to perform, and executes them with some autonomy. You stop authoring keystrokes and start supervising work. What agents offer is not faster typing; it is the ability to delegate well-formed work. Understanding the problem, the idea on the cover, is the part that stays yours.

I will not tell you which agent to pick. The one you pick today will be deprecated, rebranded or absorbed within a procurement cycle. The way you think about the work survives the replacement.

Where I am coming from. I have written software professionally since 2000 and built AI systems for more than a decade. I have used every generation of coding assistant, from early IDE intelligence to Copilot to current agents, and for the last eighteen months I have watched production teams adopt agentic workflows well and badly. The manual is what survived repeated use across real teams. Full background: About the author.

Where this can be wrong.

• The tools will change. The products I name, the hook formats, the permission syntax and the prices will age. The primitives and the five-layer model are what I expect to hold.
• Regulated shops differ. I assume you can install hooks, configure AGENTS.md, set up sandboxes and run subagents. Where that needs a review board or months of procurement, the manual describes the destination, not the path.
• Process has a cost. Start with the native agent and the team's existing controls. Add planning, skills and reviewers where the task needs them; Chapter 4's six phases name functions, not six compulsory documents or approval stops.

Workflow advice was reviewed on October 23, 2026; other tool-specific claims retain their stated dates. The load-bearing claims and their limits are in Appendix C. Meaningful updates are in the changelog.

How to read it. It is written for the senior engineer, staff, principal or tech lead who will run this practice on a real team and defend it upward; anyone who ships software with AI can follow. Read sequentially for the full argument, or choose a route that ends in an inspectable result. Appendix D holds extended evidence and its limits.