back

by p4ul·1mo ago·view on hn ↗
> The work that’s left is more interesting and more valuable than the work that’s leaving.

I'm not sure I agree with that. Many (or most) of the software engineers I know find the heavy reliance on AI coding agents/assistants pretty soul-sucking and uninteresting. I feel the same, and I'm looking for some kind of middle ground. For example, I will only use agents when doing so would not deprive me of learning and discovery.

1 comments
Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a junior developer operating on directed work without clarity of purpose.

I've been explaining it like this:

Programming was 1% judgment and 99% effort, where lots of folks could carve out productive careers carrying that effort and receiving that judgment.

Agentic coding has cut that 99% down by at least a couple of orders of magnitude for some work. Well-judged and well-described systems can manifest quickly where effort alone would fail. The 1% is still there, but, by ratio after optimization of the sweaty part, it's at least half of where the value is.

I had an example of this this morning, where Claude Code left to run overnight on an open problem had made an absolute hash of multi-source grounded clustering. I course-corrected it with a rule (I don't like magic number tuning on small datasets) and a specific approach (use clustering with separating anchors/seeds), and it had the system working in 15 minutes (confirmed after a couple of hours of processing). These are the same techniques that we would use with junior engineers.

Along the way, it drafted reports and ran experiments that taught me about some of the limits of SOTA listening/characterization systems that I otherwise would have had to spend time researching.

Just make teaching you an explicit goal of the system, and you'll be able to swivel from opacity to illumination.

Thanks for your comments, @chaboud! I definitely agree that LLMs _can_ be an amazing tool for learning, but as you note, one must be intentional about using them that way. I feel like the messages being pushed down from leadership are NOT of the form "Use AI to learn topics deeply and discover new things." The leadership's perspective is more like "Use all the AI you can to ship as fast as you can."

Your comment about programming historically being 1% judgement and 99% effort is interesting. I'm not sure I agree with those exact percentages, but nonetheless, I think the more consequential part of your comment is that the 99% is being reduced by a couple of orders of magnitude. I think that's what ought to trouble us as software engineers. Expending effort is often how we learn and grow. This is true in the context of physical activity (e.g., going to the gym to strengthen muscles) as well as in the context of intellectual activity (e.g., struggling through a problem set). If I go to the gym with my forklift, I can lift things, but I'm not likely to get stronger. Similarly, if I have Claude write all my code, I'm probably not learning much.

The percentages, as with 91% of statistics, are made up, but that general asymmetry is why I think this is a perilous time for folks in the middle, still learning judgement and how to scale through others.

Experienced folks who know how to describe and articulate through others have a huge opportunity here. I have ultra-quick interns in my laptop, waiting to apply aggressive and slightly presumptuous energy to any and every problem. I also know how to pull them back in and get them to focus that energy (because junior devs were the same).

New folks will sink or swim quickly, but they're less expensive and more plastic on average. They're raised in this. We'll see what that does to quality.

Deeply technical managers, designers, scientists, program managers, and product managers are now in possession of an incredible power, to be able to craft existence proofs to counteract the couched recalcitrance that engineering orgs have held over their judgment for decades. There's a certain intellectual integrity in this, even if nobody can actually read the code at the rate it's being produced.