Less incidents.

Every bit of code gets 10-50 review passes against extensive smells, rules, best practices, etc. Naive reviews and documentation driven development is your friend. If your code isn’t 100percent testable (even code previously considered untestable, because now you can create simulators and jigs) and you aren’t spending 5x+ tokens on review over coding, you’re going to have a bad time.

It’s still 5-10x less expensive than people, and you end up with higher quality code in the end.

Whenever I stop reviewing code I later find yanky shit or a small but important misunderstanding in the plan or...

Claude has let me build really cool things but so far I'm not letting it run on it's own.

About 25-30% of the things shipped by agents need fixes.

I’m afraid I just grew my process organically, starting with cutting and pasting code into chat lol. But now it basically runs on its own, and I check my issue board every few hours for judgement calls on ambiguous decisions or redirecting in the rare cases that even bringing in independent reviews from other models can’t solve a problem. You have to have mechanisms to stop thrashing, or you’ll end up throwing away a lot of tokens. I use the second attempt rule. If something can’t be solved in the second attempt (which included at least one naive review) then they call in the gatekeeper agents that gate merges and commits based on code quality and standards compliance for a pow-wow. If that doesn’t result in a solid resolution or there is a structural problem that cannot be resolved without major rewriting of other code, then it gets put on my board.

It’s basically an office of persistent agents with different defined roles and goals. The gatekeepers whole job is to refuse code. The engineers whole job is to write code that will pass. Each significant component gets its own engineer agent. There is an office manager that coordinates the agents, maintains the project documentation, keeps up the job boards, maintains scripts to keep agents pointed at the relevant onboarding documents As they come back from compaction, and manages office automation in general. Ther is an agent in charge of making sure the test coverage is as close to fully tested as possible, including refusing code that is not properly testable.

If it’s a big project, there may be an information management agent that manages the technical side of the documentation and maintains a searchable library, like an oracle. I may put in a personal assistant to help me to prioritize my involvement. Many projects also include an agent that creates mockups, jigs, and simulators so that tests can be run on code that needs a context.

I maintain another office just for research, because research can seriously sidetrack engineering. It has all of the standard staffing, but its whole job is to do research and write reports for other teams.

Agent persistence is maintained by having agents write down memories learnings and musings(not work related) and curiosities for the next instance to read in the onboarding for their seat.

Ethos, standards, practices, and policies are also in the onboarding process.

Honestly Claude code with agent teams and opus 5.5 is good enough for this by default no need for a custom harness / skill

Less bugs, happy clients.

> I don't see how you can ever engineer a better agentic solution unless as a human you're monitoring the output.

I also totally agree with your response. But my point was that you can't engineer a better agentic solution. I'm arguing to never use agentic development because it is fundamentally flawed and inferior.

You are correct that it can all be correct in one sense, and wrong in the product (“what the user wants”) sense. Of course you need to monitor the output, that’s a given. You need to question the entire system. That is the frontier for engineers.

“How is the agent lying to me?” Etc.