Predictions about AI 🔮

Looking at where we are, computing the trajectory, and thinking about the future of software development

Over the past month I wrote a lot of code.

This alone is a surprise, given my current heightened status as a full-time newsletter writer.

The second surprise though, is that I actually wrote very little code myself, and intentionally let AI do 90% of the work. I forced myself to do so, by picking a language (Swift) I don’t even know the syntax of.

But why is that?

One month ago I watched this video of an 8-year-old girl coding a Harry Potter chatbot from scratch. The girl uses Cursor and completely trusts the AI to do the job — she gives incremental instructions in chat, and the AI updates the code every time.

I had used AI for coding in the past, but not that way. What I had done up to that point was AI-assisted development, while the girl was doing AI-driven development:

• AI-assisted development — means that, by default, I write the code myself. AI jumps in when I need help or to do obvious chores.

• AI-driven development — means that, by default, AI writes the code. I jump in to correct the issues.

Should we switch to AI-driven? Does AI-driven even work?

I can’t say for sure, because a lot depends on your codebase and what you need to do with it, but I can tell you there is a lot you can accomplish by just trusting AI to write all the code.

Modern models (e.g. Claude 3.5) are able to incorporate a ton of context, and they rarely make mistakes. When they do, it is most often not on pure logic: they get confused on API versions, or they default to build instead of buy even when the latter is obvious.

All in all this is forgivable, and especially after a while that you work with them, you start smelling situations where they can do wrong, and easily intervene.

Of course my experience is limited: these days I am only a writer and I don’t have a giant, grizzled codebase anymore on which to do deep testing, so in the past two weeks I also talked with as many managers and engineers as I could, to figure out how they are using AI on their teams.

I think our respective experiences complement each other well, and so do our biases:

• I may be eager to try new things, but can only do so on little more than toy projects.

• They may have full, multi-year projects to try on, but more inertia towards changing how people work.

So, this article contains my full thoughts about using AI for coding, and a list of ten predictions about where AI will take us.

I will spoiler the conclusion and say that I am an AI-optimist. There is a future where AI 1) improves how we write code (more on that later), and 2) improves the quality of our jobs, taking away most chores and letting us focus on the more creative and rewarding parts.

But I also believe this will not happen automagically — in other words, it’s not the only possible future. We will need to be intentional in creating workflows that leverage the best of AI + the best of humans, sometimes at the expense of some short-term gains.

So here is the agenda for today:

1. 🔮 Predictions — my 10 best predictions about how AI is going to change software engineering. Mostly good, and a few bad:

   1. Most engineers will become full-stack

   2. Product engineers will become mainstream

   3. Niche languages will become more popular

   4. We will write code with fewer dependencies

   5. AI-generated code is going to be tracked

   6. We will write more docs

   7. Static analysis is going to be huge

   8. AI will successfully scale to large codebases

   9. Software innovation will slow down

   10. It will be hard for junior developers

2. 🤖 How to leverage AI as an engineer — what’s the right way to approach this tech in a way that your skills and your career benefit from it, instead of the opposite!

3. 🔧 The best tools right now — my favorite AI tools as of today. Spoiler: copilot is not there!

Let’s dive in, starting with predictions!

---

1) Most engineers will become full-stack

Over the past 15 years, web technology has become more complex, instead of the opposite.

DHH’s thesis—which I largely agree with—is that this happened because we brought in a lot of layering from big tech. In fact, a lot of the most relevant open source work of recent years comes from there.

Tech layering led to job layering, especially creating a big divide between backend and frontend engineering.

I believe we will spend the next decade undoing this. Signs were already there, with the surprising resurgence of Ruby on Rails, and JS frameworks becoming increasingly full-stack.

AI will only accelerate this trend because, if anything, it gives developers basic proficiency in any language/piece of tech. Think of all those features that are, like, 80% frontend + 20% backend — or vice versa. In many cases, these can now be easily owned by a single guy.

And the trend will only accelerate, rewarding engineers who can own features from top to bottom. In other words, product engineers 👇

2) Product engineers will become mainstream

As we discussed in recent articles, this doesn’t only apply to code.

AI + good tooling reduces engineers’ cognitive load, opening up avenues for taking on more responsibilities. One angle is, of course, more coding (== full-stack), and another one is going after product.

This is probably going to take more time than the full-stack prediction, but to me product engineering convincingly looks like the future of software engineering 👇

How to Become a Product Engineer 🎨

3) Niche languages will become more popular

Another byproduct of this universal basic proficiency, is that niche languages and tech stacks become easier to pick up.

This is important because, instead, we spent the last decade consolidating most web dev around very few choices, making suboptimal calls to prioritize reusing the same skills, vs picking the right tool for the job.

Nobody thinks Electron apps feel or work better than native ones, but Electron still dominates because 1) you can write once and run everywhere, and 2) people prefer to write (e.g.) React instead of Swift.

Or, Rust is widely admired for its performance, memory safety, and concurrency. But even when these features matter, how many teams are actually learning Rust vs lazily creating yet another Node service?

AI drastically reduces the barrier to entry for any language and tech. This can do wonders to the diversity of our stacks, which, in turn, would improve the quality of our apps.

4) Fewer dependencies

You may have noticed that AI tends to write simple things from scratch, as opposed to looking for a package.

I don’t know you, but it is so refreshing to cut out a lot of trivial packages and partially undo the node_modules memes 👇

In many cases, AI even exaggerates, and it’s up to humans to make good buy-vs-build calls, but that’s fine.

Dependencies are important but there is always a sneaky tradeoff in terms of maintenance, vulnerabilities, and tech debt. AI makes it easier to roll your own things when you can’t find something that fits, or it is simply not worth it — and that’s precious.

5) AI-generated code is going to be tracked