Post

I'm beginning to suspect that a key skill in working effectively with coding agents is developing an intuition for when you don't need to closely review every line of code they produce. This feels deeply uncomfortable!

16 reposts229 likes

Let's ask the horses' mouth! :) Seriously I like seeing and hearing about coding workflows, I feel like my efficiency is 2 steps forward, 1.5 steps back, and I want to move to only 0.5 steps back

It's so much like being a high level manager. You need to let go and focus on the overall goal. I find it just as unsettling as when I tried to coach skills and got blank faces from half the juniors.

Agree, sometimes you get a vibe it’s understood and working the way you want. And some times the reply just smells funny and you have to restore to previous. A different sort of “Vibe” coding.

Our workflow now is that i’ll straight vibecode for like a full day to get to a polished prototype, not looking at the code at all. Then we’ll have an engineer do a refactor and cleanup pass, looking at overall structure rather than specifics. Only then will we do a detailed code review.

Agents basically make iteration (writing code) very fast and cheap, but quality (reviewed and optimized code) is still expensive. So it pays to delay quality investments (human reviews) until the iteration phase has been exhausted.

Fwiw: I don’t care if the code’s anywhere on the spectrum from an AI to Fabrice Bellard — if you don’t take the time to review and you own it, you’re gonna end up in a bad bad place later

working with proof assistants has gotten me used to this. they have had code search tools long before LLMs. but there i also don’t need to review the code because they’re automatically formally verified

I think the most value I get from coding agents (if I get any value at all - still making up my mind) is that it encourages me to get over my perfectionism. The code is often not beautiful, but if it works...

It has legitimately been a great "head of engineering simulator" for me. I get to be extremely picky about process and procedure. Occasionally it'll lie to me. I get LLMs to check each other's work. I get to say "this is not production ready" after being told something is production ready.

Cf. OpenAI “Why LMs Hallucinate.” 70%+ calibration error rates on code generation tasks. Any distributional “intuition” is bound to fail. If we could hone intuition to predict errors, so could the LLMs. If the code matters, you need to look at it carefully.

This is also a skill with people. It can be hard to delegate and trust the result. Incidentally, have you considered delegating the question of wether you need to look at a piece of code to an LLM?

I think you’ve written on this, but part of that intuition becomes knowing how to architect the framework and flow (and docs!) in a way agents can work with them at higher accuracy. While you can take this analogy too far, it’s not entirely unlike architecting app others can maintain, not just you

Finally, it’s not just intuition. If you spend some time going back-and-forth with an agent during the planning process, it usually becomes clear whether or not it has a grasp on what needs to happen next and how to accomplish it. If it can’t grok it, then you need to review more carefully.

It does, but I also think about how many people use Rails or Django that have never read the code to either framework In this way, coding agents can be thought of as a next level framework that does enormous scaffolding work for us Not as uncomfortable!

The difference though is that those frameworks do behave in pretty deterministic ways, and if they don't do what you want, you can dig into their code and either file a big report or figure out what you need to change in your code. LLM's are a black box on that front.

I trust those frameworks because their maintainers have earned that trust over many years, plus the code in the frameworks has been exercised by hundreds of thousands of other developers already

Indeed. And hopefully with time, LLM output will earn our trust too. Until then, and tomyour original point, knowing when we can / cant trust LLM output is a matter of skill.

this is a real challenge I have when trying to explain my workflow to others - it’s more intuition than anything. it also takes time to develop the intuition and update it when models/capabilities change.

a lot of people seem to want an instruction manual to follow but I think it’s important for people to develop the intuition. very “teach someone to fish” in that way.

LLMs in isolated usage do not adhere to prompts well enough for me to trust them to do tool calling in loops without testing and at least a cursory once-over to make sure they didn't do something careless.

If the loops had tight validation, verification & review steps builtin, I believe the output would get a lot better. Those steps could be LLM driven too, just different prompts and possibly even faster models.

it helps to do actual vibe coding on low value code, get a feel for when they’ll do well. and then build on that to higher value work i have a good sensitivity around what gpt-5 will do in Cursor vs codex-cli

It does, but I think it just indicates a bifurcation of the kinds of software LLM systems build vs humans; they write extremely convoluted, hyperdocumented, fairly badly designed code, but it often works. Whether that’s good or bad depends on the project, taste, workload of the future maintainers.

Do you think there’s a corollary element of management here where when you have a team working on say, a 10 year running codebase, that requires some management and balance while embracing this that might be difficult too? Sometimes it will miss subtle patterns with a lot of info baked in and

Comparison with human coworkers is hard because you can trust a human in a way you can't trust a non-deterministic LLM - humans have agency, can deliberately improve and can take accountability for their work But... you CAN improve LLMs by continually iterating on how you use them

but.youbut.you

It’s a hard comparison, BUT, I began trusting AI much more after AI caught more bugs in PR reviews than I did, and it did a better/faster job fixing them than the original dev. Maybe not without exception; but QA went up and my time went down.

It’s less about the machine understanding it and more making it still approachable quickly for the engineers used to a very codified way of working that’s treated them pretty well. I ask because this is my situation and I’ve been pondering about it a lot! Haha

In my experience the main problem I find with LLM driven coding is that you never get as deep into the problem space as you do when you write everything from scratch and it’s not possible to replicate that depth when just reviewing output 🤷🏻

I feel like in many cases I am getting deeper into the problem space with LLMs than without, because I can knock out half a dozen exploratory prototypes with them before I commit to a design

i do the same! but why do i read this all around? have we learned more about the dos and donts so we start going in this direction? a part of me is also drained by always thinking i might be doing it wrong and not catching up with the industry

and on the other hand even the „good“ results of that software engineering practice is nothing that changed my world. it’s the nice to have apps that i created not one must have. might be only me but every time i try to build must have parts it’s just not good

I’ve built a workflow that generates about 10,000 words of plan for a feature. All that gets reviewed carefully. Then I feel a lot more confident letting the agent break the plan down and churn through it.

Only use agents when the correctness of the resulting code is easily verifiable and short, like a small bash script or stuff. Otherwise use your thinking meat. Problem is, easily verifiable scripts are also written extremely fast without code agents. So code agents are probably a waste of money

I don't think that's true: even a small bash script can take me 10-30 minutes to write by hand, compared with 1-2m with an LLM Recent example, this uv-test script til.simonwillison.net/python/uv-te... - I actually had ChatGPT build that one on the spur of the moment while writing that article

til.simonwillison.netTesting different Python versions with uv with-editable and uv-testA quick uv recipe I figured out today, for running the tests for a project against multiple Python versions.