The next hit: How LLMs change the way engineers work
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 transition for almost everyone. For some people, it is an emotional journey. We have spent years working on something we pride ourselves on, and suddenly it does not matter in quite the same way anymore.
At Aha! it is important to us that everyone move through that journey at their own pace and understand it in their own way. We are not terribly prescriptive about exactly how people should work.
But one thing we are clear about is this: You own the code you commit. Maybe you used AI as a tool to write that code, but it is still your code. Just as my keyboard did not write the code, neither did Claude. I may have used Claude to help write it, but it is still my code, and I own it. That mindset matters in practice. It is not enough to say, "Claude wrote this." That is the wrong way to think about authorship and responsibility.
That forces you to slow down and ask: Have I actually read all the code Claude produced? Am I willing to stand behind it and be responsible for committing it? That mentality sets the framework through which other things naturally follow — being more planful, making sure you review the outputs, and so on.
Making junk fast
One of the big negative consequences of being able to move so fast is that you can make junk fast. And making junk fast — what is the point? Maybe it gives you that hit quickly, but are you really accomplishing anything?
I went through that cycle myself: fast, fast, fast, fast, fast. And then: Hold on. What am I actually accomplishing? If I slowed down, thought a little more, and was more planful at the start, I would probably accomplish more (even if the hit came a little later) and be more satisfied in the end. There is nothing satisfying about throwing something away. I want to take satisfaction from knowing that I did something that mattered.
Ready to build with intention? Learn more about Aha! Builder and sign up for a free trial.
