The next hit: How LLMs change the way engineers work<br>Articles<br>Culture<br>Careers<br>Aha!'s GitHub organizationFind our posts on Hacker NewsAha! engineering blog RSS feed<br>Aha! Develop is the agile tool that links strategy to delivery.

Learn more

Chris Waters · 2026-06-15 · AI<br>The next hit: How LLMs change the way engineers work<br>Some people are drawn to software engineering, and not everyone is like that. But a common characteristic among engineers (myself included) is the thrill of building something and seeing it work. Maybe it is not the whole system, but some piece of it, some feature we implemented. It is a moment of accomplishment — a rush of excitement, adrenaline, maybe dopamine. Whatever you call it, that is what you do it for.

When you are writing code by hand, that comes in very small doses every hour or so as you achieve some milestone, but the really big hits may take days or weeks to get to. You are building big things. But that is part of the appeal — some of the thrill is the anticipation of completion.

One of the remarkable things about using LLMs for coding is how dramatically they compress the time to that sense of accomplishment. Something that might once have taken two days to type out can now appear in a matter of minutes. In 10 minutes, you have two days' worth of code. You run it, it works the first time, and you get that same thrill of accomplishment.

That can be addictive. And maybe "addictive" is not quite the right word, but the feeling is unmistakable: I want more of that. And the beauty of the LLM is that I am not tired. I did not spend two days writing that code. I spent 10 minutes, so I can go again.

But that can also be a problem, because thinking deeply about what you are doing, why you are doing it, and what the right approach is takes time. When something used to take two days, you were more likely to think carefully before you began, simply because you knew how much time you were about to invest. And as you worked, you had time to ask yourself: Am I on the right track? Do I need to course-correct? When code happens in 10 minutes, there is no space for that kind of reflection. The temptation is to do the opposite — to fire the shotgun again and hope one of the pellets hits something.

What makes this more striking is the speed of change. In the middle of last year, coding agents started getting better. Then November and December came, and they got significantly better. January rolled around, and now they are better again. We are in the vertical part of an exponential growth curve, and this phenomenon is accelerating so quickly that two things are happening at once. First, you look around and see colleagues overtaken by it as they discover it for themselves. Second, it is happening so quickly that we have not really had time to adjust or think through the downsides.

A different skill set

Many developers are concerned about what this means for the future, because it requires us to exercise a different part of our skill set. I am no longer writing individual lines of code. The ability to write individual lines of code correctly and quickly comes from years of practice. That skill may atrophy quickly, and many of us who have done this for a long time are uneasy about that. I spent decades developing it, and in months it may matter far less. Is that OK? I do not know. Part of me feels the loss of it.

The flip side is that I may not need that skill in the same way anymore given that the LLM can write those lines of code better and faster than I ever could. Even when I was at my best, I could not type as fast as an LLM can type, and I made lots of typos. The LLM does not make typos.

So yes, there is reason for concern. But it also means we have to think about problems differently. That is where we are right now. Many people — not just within our company, but across others as well — are working out a different way to operate. We are recognizing the danger of constantly chasing the next hit and realizing that we need to step back.

The skill we need to exercise now is, in some ways, closer to what a product manager does. We have to think more deeply about why we are doing something, what the goals are, and what trade-offs the implementation involves. In short, we need to be more "planful" before we start. This makes sure we are not doing things simply because we can, but because they are the right things to do.

Many of the most productive engineers I know have a strong bias to action. They are the ones most likely to think, "Let me start writing code so I can understand the problem better." And they are exactly the ones most vulnerable to this, because that technique no longer works the way it used to. As soon as you start writing code, the code is effectively already written before you have had time for the next thought. You do have to slow down a bit more than we ever had to slow down before, as that natural time is not built in.

You own the code

This is a radical...