Something happened with AI in the last three months that has completely changed coding. Over the past few years, AI for coding has improved dramatically, and I have been picking up parts of it. However, only recently did it get past the threshold from useful to essential.
This is by far the biggest change in coding and software engineering in the two decades I have been at it. And we are never going back to writing any significant portion code by hand.
At work, we picked up a Claude Code subscription and had broad adoption within two weeks, and total adoption within a month. My peers at other companies are also all-in, and in my corner of the internet, I’m probably a late adopter.
Still, I have no idea how obvious or widespread this is. I could absolutely be in an echo chamber, so don’t take my word for it. This post blew up a few months ago, and the New York Times had perhaps the best, general audience writeup I have come across.
This post, however, isn’t about the big picture. I want to talk specifically about how AI has impacted the code I produce, which I will bucket into a few categories.
Worse Code or Slower Coding
When it’s an easy, obvious, small change, it is faster to just do it rather than trying to prompt through it.
I have also been led on wild goose chases with the AI on some particular approach to fixing a bug that was wrong. Had I not turned off my brain, I would have gotten there faster.
So AI isn’t always better than doing it the old-fashioned way, but it usually is.
Slightly Faster Coding
For now, I think it’s still important that software engineers have a good idea of what the final code needs to be. This is a matter of understanding the task at hand and having a good mental model of the solution.
Previously, the next task from there would be to actually tap the keys to write the code. Now, engineers can prompt AI to write the code, which is almost always faster.
“Slightly” is kind of a misnomer here. There isn’t a specific absolute or relative time saving that I’m referring to here. When I say slight, I just mean that it isn’t affecting the trajectory of the project or task. Perhaps using AI fixed a bug in ten minutes that would have taken me an hour. That is a huge improvement, but on its own, it probably doesn’t do much in the grand scheme of things.
In another universe, I might have gone out for lunch with a friend and taken an extra hour, and we would have been even. Being faster maybe makes my better as I spend more time on Board Game Arena, but I’m still delivering roughly the same product as I was before.
Better Code
Sometimes, AI just comes up with something better than I would have myself.
I said above that it’s important that engineers need to have a good idea of what the solution is. That doesn’t preclude better solutions from existing. In the process of prompting AI and putting together a spec, AI might come up with a different, better approach than the engineer.
That’s a pretty clean win.
I don’t want to get into the question of whether AI is truly “creative” in these moments by coming up with novel solutions. The baseline here is not the universe of all possible solutions, but just what the prompter would have done otherwise.
In that case, I think AI is generally smarter than most engineers out there.
Justifying the Fifth Case
For awhile, I thought that there were two primary dimensions on evaluating the impact of AI on code:
- Speed: faster or slower
- Quality: better or worse
Above, I grouped slower and worse into one, and made exceptions for faster and better.
However, having gotten further along with coding with AI, I think there’s actually a distinction between slightly faster and much faster.
In the slightly faster case, we can get to the same or better outcome in a time that doesn’t significantly impact trajectory. Frankly, in the world of professional software engineering, there are so many other factors in market conditions, product decisions, etc. that matter a lot more to a business’s success than shipping code faster.
However, I think something special happens in the much faster case.
Much Faster Coding
Discounting whether AI is coming up with better code, I think there’s a point where AI adds significant value by writing code faster that coders know how to do as well.
And it really comes down to laziness.
Except for some truly virtuous software engineers out there, coders hate writing tests. We know how to do it, but it’s so boring and laborious that we just pretend it isn’t part of our job.
But AI doesn’t get bored. Tell it to write tests, and it will bust out any sort of test you want in seconds.
Writing tests isn’t a matter of ingenuity: the tests are of roughly the same quality as a human would write. AI also isn’t just slightly faster, because if we didn’t have AI, we wouldn’t have written those tests at all. Suddenly, our codebase is better because it was done.
Other examples? It’s all code cleanup and tech debt: documentation, code formatting, refactoring, etc. There are so many things that coders know are important but never get around to because there are more pressing, business-facing tasks at hand. However, doing these not only makes engineers more effective, but also AI more effective working in a clean codebase.
And there’s actual functionality that benefits from being much faster as well that tips from unfeasible to doable. For example, I personally hate using python to read Excel spreadsheets. I find it annoying and error-prone. I don’t like the documentation. Doing it makes me realize that I don’t really understand Excel in the first place.
Because of that, I frankly had written off any Excel parsing tasks as impossible because I was never going to bang my head against the wall to get it done.
But AI is great at reading Excel spreadsheets. In fact, spreadsheets are actually structured data, which AI is very friendly with.
Again, the point is not that I don’t know how to parse spreadsheets or that AI would do a better job. And it’s not that it just can do it faster. The point is that without AI, I would never even attempt it. With AI, the task goes from Herculean to actually feasible, and that’s a game changer.
Final Thoughts
Last week, I posted an unpublished blog post from last summer about using AI for coding. It’s still astonishing to me how much things have changed in such a short amount of time.
Right now, the world feels chaotic. Of course I’m talking about AI now, but there’s also geopolitics. The world is changing rapidly, and no one really knows what’s going to happen. By chance, of course, some people have made correct predictions that they will explain as foresight. However, a wide variety of things could have pushed us off that path.
We’re not going back. Politics and society are fundamentally different from ten years ago, and it could have been very different. AI has a lot of risks, and we don’t really know what the best processes are, but we are never going back to mostly writing code by hand.
However, I’m trying to take a positive perspective in all of this. When the world was coherent, tractable, and understandable, it was also somewhat fatalistic. We felt like we knew where the world was going, and we were just along for the ride, better or worse.
When the world is chaotic, I actually feel more optimistic. Nothing is guaranteed, and that means that our choices now can affect what happens. And that’s a great opportunity to make a difference.