← All conversations Sunday Meditations / Sep 20, 2026
Why agent engineering is harder than it looks Armin Ronacher · 6:14 · English audio
The video could not load. Open the original video or the X post using the links above.
Transcript EN 0:00 Hello, today it's just me. I want to talk with you a little bit about what's hard about AI software engineering. 0:08 And this is in part because I got some really lovely emails recently where people shared their experiences, 0:13 but also because I asked on Twitter and I actually got a ton of responses. 0:19 And really the question that I have sometimes is, 0:22 how is it that after 18 months of using agentic software engineering tools like Claude Code, 0:28 nothing really improved. 0:32 And I know this is a little bit not true because clearly the models are way more capable, 0:38 but it didn't really feel like the hard problems are solved. 0:46 And in some ways things got worse. 0:48 And I think most consistently the problem that I 0:54 see that we have working ourselves with agentic tools, 1:00 as well as what I see other people report is really that because we haven't solved some of those fundamental problems. 1:07 Speed is now becoming 1:08 a new problem. 1:10 It generates so many more pieces of code that our capacity to keeping up is going down and down. 1:18 And it wouldn't be so 1:24 bad if we just were willing to slow down, but we're not. 1:30 We're committing ourselves to being faster and faster. 1:34 And that's because we're no longer doing this alone. 1:36 We're doing this in teams. 1:37 And I can't tell you how many of you have expressed 1:43 frustration about the fact that other people are sending you slop and other people are sending you 1:49 pull requests at their volume they just can't keep up with. 1:51 And so we have this unfortunate situation where the models are both 1:56 getting really, really good, but not good enough that we still can't trust them. 2:04 And this gap doesn't seem to be improving meaningfully. 2:10 And it's actually for me a huge problem right now on a very personal level, because I mean, I wrote about this before. 2:17 I don't trust Astra and increasingly I don't trust Fable to be 2:23 good software engineers, because what's happening in their training processes is that these models are 2:29 rewarded for succeeding, but not for writing code that I like. 2:34 And in many ways, some of the behaviors you get out of these models now are counterproductive. 2:39 They are, 2:42 for instance, no longer willing to use edit tools as much as they used to, which means that as I'm watching the edits fly by in 2:49 Pi, very often I can't even understand what the model is doing, 2:52 let alone which tools it's invoking. 2:54 And so as all of this is going on and on, we're shipping faster. 2:58 The quality of the code is deteriorating very quickly. 3:01 And our 3:06 tenacity and energy is just not there anymore to 3:12 apply the same kind of rigor and quality standards to it as we used to have. 3:17 And then we're increasingly losing understanding. 3:21 And I think one of the more devious parts about this is 3:27 that in situations where my understanding is really, 3:30 really necessary, there are too many cases where seemingly nobody has it anymore. 3:35 And I heard this story from friends I used to work with. 3:40 I had heard stories like this from people talking about it on Twitter that 3:45 you can now end up in an incident where a bunch of people 3:52 are huddling in a Slack room trying to figure out what's going on. 3:54 And it's just all talking with the machines because nobody actually really wants to understand anymore, let alone understand the code that was committed. 4:01 And that's not a situation that I think we should be encouraging. 4:07 But I do want to let you know, 4:13 a lot of us are feeling like this right now. 4:15 And I think we owe it to us and our industry 4:20 to find solutions to this problem and not just 4:24 let it happen and not push back against this. 4:31 This is a very shared experience. 4:34 And don't get me wrong. 4:38 I love those tools. 4:39 I think they're absolutely fascinating. 4:42 And it is so many times just such a magical experience to work with them. 4:49 But they are also deeply frustrating. 4:53 They're little machines where sometimes they produce an amazing result. 5:00 And then you're spending two weeks trying to massage one pull request into a shape that you like 5:05 with no feeling of forward progress. 5:09 And it seems to be random. 5:14 I don't know if it's just if me and my little community around us are just not the best 5:20 prompters because I've heard that some people express that we're all just prompting wrong. 5:25 But I think it's just hard. 5:27 And I just really felt like because 5:33 we're all, maybe not all of us, but because I think a lot of us struggling with this, 5:38 I think it's just good to let you know that you're not alone. 5:42 And I think we probably need to do some changes here in how we approach certain 5:48 problems and how we engineer to actually really get to the bottom of it. 5:52 Because better models and more capable models, 5:56 if anything, right now are making it a little bit worse by writing code that 6:03 is a lot less pleasant to look at and a lot harder to understand. 6:08 So that's it for today. Have a nice weekend.
Download captions .vtt ↓
AI summary Reading notes Based on this transcript. Use timestamps to check the original discussion.
0:19 ↗ Stronger models have not removed the hard parts Armin reflects on eighteen months of agent tools: model capabilities have improved, while trust, quality and understanding remain difficult engineering problems.
1:07 ↗ Generation outpaces review Growing volumes of code and pull requests strain a team’s ability to review. Armin worries that pressure to ship faster drains the energy needed to maintain standards.
2:10 ↗ Task success is not the same as good code He argues that training rewards successful outcomes without necessarily rewarding readable, reviewable implementations. Some editing and tool-use patterns also make changes harder to follow.
3:17 ↗ Lost understanding becomes an incident risk He describes teams responding to incidents by repeatedly consulting machines while lacking direct understanding of the committed code, and calls for taking that loss of knowledge seriously.
4:07 ↗ The frustration is shared He expresses both enthusiasm and frustration, and calls for changes in engineering practice. Occasional impressive results do not erase prolonged rework or prove that every difficulty is a prompting failure.