> prompting just isn't able to get AI's code quality within 90% of what I'd write by hand

Tale as old as time. The expert gets promoted to manager, and the replacement worker can’t deliver even 90% of what the manager used to. Often more like 30% at first, because even if they’re good, they lack years of context.

AI doesn’t change that. You still have to figure out how to get 5 workers who can do 30-70% of what you can do, to get more than 100% of your output.

There are two paths:

1. Externalized speed: be a great manager, accept a surface level understanding, delegate aggressively, optimize for output

2. Internalized speed: be a great individual contributor, build a deep, precise mental model, build correct guardrails and convention (because you understand the problem) and protect those boundaries ruthlessly, optimize for future change, move fast because there are fewer surprises

Only 1 is well suited for agent-like AI building. If 2 is you, you’re probably better off chatting to understand and build it yourself (mostly).

At least early on. Later, if you nail 2 and have a strong convention for AI to follow, I suspect you may be able to go faster. But it’s like building the railroad tracks before other people can use them to transport more efficiently.

Django itself is a great example of building a good convention. It’s just Python but it’s a set of rules everyone can follow. Even then, path 2 looks more like you building out the skeleton and scaffolding. You define how you structure Django apps in the project, how you handle cross-app concerns, like are you going to allow cross-app foreign keys in your models? Are you going to use newer features like generated fields (that tend to cause more obscure error messages in my experience)?

Here’s how I think of it. If I’m building a Django project, the settings.py file is going to be a clean masterpiece. There are specific reasons I’m going to put things in the same app, or separate apps. As soon as someone submits a PR that craps all over the convention I’ve laid out, I’m rejecting aggressively. If we’ve built the railroad tracks, and the next person decides the next set of tracks can use balsa wood for the railroad ties, you can’t accept that.

But generally people let their agent make whatever change it makes and then wonder why trains are flying off the tracks.

>2. Internalized speed: be a great individual contributor, build a deep, precise mental model, build correct guardrails and convention (because you understand the problem) and protect those boundaries ruthlessly, optimize for future change, move fast because there are fewer surprises

I think the issue here is, to become a great individual contributor one needs to spent time on the saddle, polishing their skills. And with mandatory AI delegation this polishing stage will take more time than ever before.

> But generally people let their agent make whatever change it makes and then wonder why trains are flying off the tracks.

IMO, this is the biggest issue. Well, along with just straight up ignoring what you tell it and doing whatever it thinks should be done.

But, to answer the actual thread question: Make it work (all the tests pass) then make it right is the way I'm getting quality work out of the robots. As long as you watch them to make sure they don't either change the tests to pass on buggy code or change the code to pass on buggy tests (yes, Claude is quite proficient and eager to do both) then the code gets better and better as new stuff is added and the 'flow of computation' is worked out.

Oh, and have an actual plan to follow so they don't get distracted at the first issue and say they're finished because they fixed some random unrelated bug. I've also found it helpful to have them draft up such a plan while they're knee deep in that section of the code for related work so they don't have to figure it all out again from scratch and try to add a few extra levels of abstraction just because.