Completely agreed. I’ve got about 20 years of professional software development experience. Tools like Claude Code let me build incredibly quickly when I use a stack I know intimately.
But when I try it with a stack I don’t know, I quickly find myself needing to learn the new stack to get anything done.
Extremely experienced engineers will be able to move quickly with these tools, but specialization will still exist, and I’m not clear on how juniors are going to ramp up on all of this.
It’s funny you should mention LISP macros. Five years ago, I’d have told you that the most efficient way to build something is to get an extremely experienced dev with mastery over a flexible language like LISP, and just let them go nuts. I constantly have to hold myself back from metaprogramming tricks because my coworkers won’t be able to maintain it. But on my personal projects, I really get to flex my muscles.
It occurred to me a few months ago that that’s exactly the same spot in my toolbox where Claude Code is. It’s a tool that allows one person with mastery of a tech stack to build things incredibly quickly. Look at Cursor where a tiny team has over $100M in annualized revenue.
Big companies often find themselves spreading ownership across too many hands. You know exactly how to build what you need, but you’re not allowed to touch 80% of the code involved because it belongs to a different team. But coordinating all of that is a massive amount of overhead that will derail most projects. This is why so little happens at big companies.
But these tools enable a smaller number of experts to do a job that used to take many. I expect the speed improvements to be super-linear as a result.
Of course, that brings concerns about what happens to the employment situation for devs if that happens. I hope it means that 10,000 new startups can build more ambitious products and absorb all the people who will probably be laid off by the huge corps in the next few years.