> A trading floor is a bad place for unreviewed code written by people who can't read it, and the information barrier problem would be reason enough on its own. Requiring that agent-written code come from people trained to review it is a sensible rule for a regulated business.
Jokes on them: devs are also losing the capacity to read the code. Can't mix move fast, high volume with "read code".Agentic engineering needs to be "all in".
To deal with the volume, the system needs more checks than humans can handle. Additionally, the humans no longer understand the details at the low level of implementation at scale. Therefore, the system only needs to assert that it is following agreed patterns.
So the initial scaffolding needs to be agent friendly. The processes need to be aligned to agents. The tooling needs to be agent operable and put on rails. The patterns need to be documented to be enforced.
Otherwise, teams get volume that cannot be handled by humans. So full speed agentic engineering requires teams to be all-in.
A piece of this is to leverage the harness to normalize or standardize output. Standard patterns, standard architecture, standard UI libraries. These are all much easier to enforce with agents than with humans, but requires extensive platform and harness engineering.
Teams do not really understand this yet. Engineering teams still think their job is to build product faster. By the 10th time you tell an agent "implement issue #15639", you realize anyone could have done that. Engineering's job now is to own the enterprise harness (context layer, ephemeral agent env, ingress channels, auth proxies, MCP servers, quality gates, agent ops, etc) so anyone can build the product. That's what "all-in" means.
Once this system is set up and well executed, it really doesn't matter who writes the initial prompt. An enterprise harness designed to enforce safety, security, and best practices applies to a senior dev or a junior dev or a product owner all the same. All-in on engineering the enterprise harness, not the product.
You have to go all in on agentic engineering. And if you're all in on agentic engineering and doing it well, then anyone should be able to build safely and no one needs to look at code. The code should look highly consistent and agents should be enforcing best practices, approved architecture, running security scanning, etc.
The gains at the middleground compromise are not really significant and, IMO, creates frustration and friction.
Works best to go all in. GS should let everyone have CC and GH and focus on making their enterprise harness safer for everyone.
And, no, it doesn't actually work. Agentic engineering is a myth by people who got high on their own farts.
Key is to get folks to unload their heuristics and rules they use for their daily workflow and judgement.
What does good code look like? What are you looking for when reviewing code? What anti-patterns are your senior devs looking for? How can you see the evidence of agent adherence?
Some of it comes down to system architecture and essentially creating rails. Agents are very good at following patterns and copying existing code (it's all just text). Establishing strong patterns, documenting them, and creating deterministic checks (linters, analyzers) helps unlock broader audience of builders.
There's nothing that fundamentally cannot be written down as a set of heuristics and given to agents to enforce except that most folks in software are very bad at writing.
This is just adding wishful thinking to the pile of trash.
In a single session? Agree. The agent is bad at enforcing rules against itself. In a multi-agent, disconnected session setup? You'll see that this works very well.
Rules and code are both just text, after all.