That only describes a happy path though -- I also had many instances where there's an issue and just describing it to an agent immediately identifies a fix and it all goes faster compared to me having to "load up" the flow of codebase into my brain first. But I also still have instances where it thinks it identifies an issue correctly, spits a fix which doesn't work and looks wrong. You point out that it does not make sense because of X, it agrees and spits out a new fix, which is also wrong and you start out on these back and forth wild goose chases, at this point I usually give up and do it the old fashioned way by understanding what is actually happening. If it is within an agent loop, there may be no back-and-forth to waste your time but then you pay with wasted tokens when it will eventually gives up or you stop it.

>I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)

I would question the last part. In my mind the more you let go of control over your codebase the more likely that it will drift way from a place where it is still comprehensible to you, and also your comprehension skills atrophy, and with that, your ability to ask good questions and to prod your agent in a correct directions weakens, leading to more wild goose chases and burned tokens. This is all keeping in mind that for throw away or small applications, maintainability is not that of important of a value so this doesn't affect all codebases.

:blinks: The architecture of your service relied on customer clocks being correct? That is, you built a distributed service without a clock synchronization primitive that relied on the clocks being sychronized?