Zakodiac

This is real and I deal with it constantly in consulting. When you're running teams of teams you physically can't see every mistake or learn every minor implementation detail - that's just the reality of scaling yourself. Doesn't matter if it's humans or agents doing the work.

The way I handle it is the same either way: trust but verify, delegate appropriately, set up checkpoints, and provide architecture and design direction up front so they don't spin their wheels going the wrong direction. The more context you give before they start, the less likely you end up reviewing something that went completely sideways.

It's kind of funny honestly - we talk about agents making "wrong design decisions" and missing context like it's a new problem, but this is literally what happens with human teams too. We trained these models on human output including all the human failure modes, so of course they reproduce them. The difference is just speed and scale.

Yeah we've seen the same thing with a few smaller Rust tools I've built with agents. The strictness definitely helps - when it compiles you can be pretty confident there aren't weird runtime surprises lurking. So the fewer functional bugs theory checks out from what we've seen too.

The tradeoff is LLMs still struggle to produce good idiomatic Rust consistently so it takes more iteration cycles to get there (good agent tooling helps, linting/checks/etc.) The compile times on those iterations can be brutal sometimes depending on the project size which adds up for sure. The crafty agents can still find ways to satisfy the compiler without actually solving the problem correctly too, so the cheating risk of course doesn't fully go away.

Using SDK client libraries as the compatibility target is the right call - it keeps the whole AI-assisted development loop honest instead of just generating code that fakes happy paths.

Slack being harder than G-Suite tracks. The real-time stuff (websockets, event subscriptions, rate limiting quirks) is a completely different problem than REST APIs with predictable request/response flows.

I've been building something adjacent to this actually - a multi-protocol mock server called mockd (https://github.com/getmockd/mockd). Different angle than DTU - instead of cloning specific services, it runs real protocol servers (gRPC, REST, websockets, MQTT, etc.) that return controlled responses. The idea is you define your mocks across protocols and it serves them with state support, so you can build up a comprehensive mock of something like Slack's API surface from one tool. Longer term the plan is community templates so people can share and build on each other's setups. Still cleaning things up but would be curious what you think if you get a chance to look.

The Go to Rust rewrite is interesting - was that driven by performance or more about the ecosystem/tooling for this kind of work?

This matches my experience. The agents are useful for cranking through implementation once you already know what the architecture should look like. But that "knowing what it should look like" part - understanding the client's constraints, the failure modes, what needs to be bulletproof vs what can be eventually consistent - that's still completely a human job. And it probably will be for a while.

This is the part that worries me the most. I work as a Principal in consulting and finding people with real technical depth is already hard. If the next generation of engineers learns to lean on agents instead of actually understanding what's going on, that gets worse. You need people who can look at agent output and know if it's right, and that skill only comes from years of doing the work yourself - or perhaps in the new era at least understanding everything that the agent is doing and why. The crutch risk is real.

The Digital Twin Universe is the most interesting thing in this article and the part most people are glossing over. The real question Simon nails is: how do you prove software works when both the implementation and the tests are written by agents? Because agents will absolutely game your test suite - return true, rewrite assertions to match broken output, whatever gets them to green.

Their answer of keeping scenarios external to the codebase like a holdout set is smart. And building full behavioral clones of services like Okta, Jira, Slack so you can run thousands of end to end scenarios without hitting rate limits or production - that's where the actual hard engineering work is. Not the code generation, the validation infrastructure.

Most teams trying this will skip that part because it's expensive and unglamorous. They'll let agents write code and tests together and wonder why things break in production. The "factory" part isn't the agents writing code. It's having robust enough external proof that the code does what it's supposed to.

I agree agents can break flow but I think the bigger issue is they hide too much, not that they're too intrusive.

Most agent tools right now don't give you good visibility into what sub-agents are doing or what decisions they're making. You zoom out, let it run, come back to a mess. Tools like OpenCode and Amazon's CLI Agent Orchestrator are trying to fix this - letting you watch what each agent is actually doing and step in to correct or redirect.

OpenCode actually removed the ability to message sub-agents directly. I get why - people would message one after it finished, the conversation would fork off, and the main orchestrator lost track. But I don't love that fix because being able to correct or pivot a sub-agent before it finishes was genuinely useful. They bandaided a real problem by removing a good feature.

Honestly the model that works best for me is treating agents like junior devs working under a senior lead. The expert already knows the architecture and what they want. The agents help crank through the implementation but you're reviewing everything and holding them to passing tests. That's where the productivity gain actually is. When non-developers try to use agents to produce entire systems with no oversight that's where things fall apart.

So I wouldn't want agent tools to be "calm" and fade into the background. I want full transparency into what they're doing at all times because that's how you catch wrong turns early. The tooling is still early and rough but it keeps getting better at supporting experts rather than trying to replace them.

The framing of "code's audience is shifting from humans to agents" feels premature. AI agents often don't have the full context needed to make good architectural decisions - they don't understand the client's constraints, the timeline, the maintenance burden, or the tradeoffs that led to a particular design. A human still needs to be the architect, and that means humans still need to be able to read and understand the code.

The real risk isn't that agents can't read messy code - it's that without humans deeply understanding the codebase, you lose the ability to catch when an agent has missed edge cases, taken a shortcut, or produced something that technically passes but doesn't actually solve the right problem. We've all seen agents "cheat" their way through tasks in ways that look correct on the surface.

So the question isn't whether good code matters less now - it arguably matters more. Clean architecture, clear documentation, and well-understood code are what let you verify that an agent did the right thing. And testing remains as useful as it's always been, not because the agent needs it, but because humans need proof that the system actually works. Tests are a spec, a review mechanism, and a safety net all in one.

We're a long way from truly hands-off AI development. Until then, writing good code is how you stay in control.