My comment is not directly responding to the essay, but it got me thinking about about how agentic programming is much more akin to management than it is to actual programming. Managers generally only have a high level idea of what ICs are working on and often don't have the time, bandwidth, and in some cases ability to understand everything the ICs they're supervising are doing. As more and more software gets written agentically the role of software engineer becomes less technical and more managerial.
back
3 comments
We can say that about programmers, most ICs don't understand what's going on in the layers beneath were they work. Most have no idea what's going on with libraries, frameworks, remote APIs, it's all abstractions. Most people can't tell you how system calls are implemented or function. They don't have the time, bandwidth to understand it all, they just operate at their own layer to get the job done.
It comes down to trust. I trust that the people who mede the low level stuff I'm using.
I don't feel the need to code review every single line of the edior I'm using. I trust it to work as promised. Same with all other tools.
It feels to me like I'm stuck doing code reviews for a junior dev all day so I use it as little as possible and mostly to look for things I may have missed.
It's great for "mechanical" changes.
For example, yesterday I came across some unit tests that didn't have error messages in their assertions. Normally, it takes me ~10 minutes to fix a handful of tests in this situation. In this case, I gave a 2-3 sentence prompt, went to the bathroom, and reviewed the result after I washed my hands. Saved me a bunch of time!
I encourage you to accept a feeling of "imposter syndrome" when using it, and keep trying new things with it. Don't feel like you have to be hands off, except when you're confident that you can be. (IE, if you think you need to spend 30+ minutes on mindless refactoring, see if you can explain it to an agent and then look at HN while it runs. You might get a good result, otherwise, it probably was time for a break anyway.)
BTW: It's important to try different models. The Claude 5.0 models are slow and give me bad results, so I'm sticking with 4.x for now.
Yes it's so useful for mechanical changes, refactors, and creating similar but slightly different components etc. It turns out that when you feed the word prediction machine a bunch of examples of what you want, and then some text that it can use to predict more text, it can do a good job!
The hard part is what text you feed it and how to judge the output.
Use the force Luke!
I finally learned to let go of the code. I dont even run my C++ editor anymore.
I run frequent code and architectural reviews. Its awesome.
While this is true to a point, the other factor is that developers are hired and tested for having certain skills and specializations. While I'm sure LLMs can be good at things, the question is whether their manager can accurately judge the output. I suppose this problem applies to developers too, but developers have peers and processes.
So as someone managing LLMs you need to put those processes in place too. The risk is that one tries to do too much and loses overview / insight. Focusing on getting the tower tall instead of sturdy, if you will.