← Writing

Industry · Opinion

The state of software, and where it's going

I've been writing code for about six years, two and a half of them professionally — which means my whole working career has happened inside this AI shift. This is my honest read from that vantage: what has actually changed, what hasn't, and the bets I'm making.

Where I'm writing this from

A quick disclaimer so you can weigh what follows: I'm not a twenty-year veteran with grand hindsight. I've been coding for around six years and working in the industry for about two and a half. But that turns out to be an oddly useful seat — I learned my craft the old way (reading code, breaking things, slow understanding) and then started my professional career right as AI rewrote how the work gets done. I've felt the shift land on me personally, not observed it from a corner office. Take this as a practitioner's field notes, not a prophecy.

The thing that actually changed

When I started out, the bottleneck in building software was mostlytyping it— knowing the syntax, the framework, the exact incantation. In just a couple of years that bottleneck has largely dissolved. AI can now produce a working first draft of almost any well-trodden piece of code faster than you can describe it. That's not hype; it's my daily experience.

But here's what I keep telling people: the typing was never the hard part. The hard part was always decidingwhatto build, why, and how the pieces should fit — and then being on the hook when it breaks at 2 a.m. Those parts didn't get automated. If anything, they got more important, because everything around them sped up.

Before — the bottleneck was typing

Idea
Type the codethe slow part
Ship

Now — the bottleneck moved to the ends

Decide what & whyjudgment · scarce
AI writes the draftnearly free now
Review & verifythe new core skill
Ship

AI didn't remove the bottleneck — it moved it from your keyboard to your judgment at both ends.

What got cheaper, what got precious

A useful way to think about it: AI made a whole category of work nearly free, and in doing so made a different category more valuable.

  • Cheaper:boilerplate, glue code, first drafts, one-off scripts, looking up how an API works, translating between languages. The "I know this is possible, I just have to type it out" tier.
  • More precious:judgment, system design, knowing which problem is worth solving, reading a codebase you didn't write, catching the subtle bug the AI confidently introduced, and owning the result. Taste, basically.
AI turned code into a commodity and made judgment the scarce resource. The engineers who thrive are the ones who were already more than typists.

The uncomfortable middle (where I actually sit)

I won't pretend this is all rosy — and this is the part I feel most directly, because I'm early enough in my career to still be climbing it. The path from junior to senior used to runthroughall that now-automated grunt work; grinding out the boilerplate is how you accidentally built intuition. If AI does all the easy parts, the ladder loses its bottom rungs. Where does the next generation of seniors come from?

I don't have a clean answer, only a working theory I'm living out: the job of a developer at my stage is being redefined in real time towardreviewing, directing, and verifyingAI output. That's a harder skill to learn early, not an easier one — you have to be good enough to catch what the machine got subtly wrong before you've earned the scars that make catching it instinctive. So I've made a deliberate choice to keep doing some things the slow way, precisely so the intuition still forms.

There's also a quality reckoning coming. It has never been easier to produce a large amount of code thatworks in the demo. The amount of software in the world is about to balloon, and a lot of it will be under-understood by the people nominally responsible for it. Maintenance, security, and "why does this actually do what it does" become the defining problems of the next decade.

My bets on the next few years

  1. The unit of work shifts from "write code" to "specify and verify."Increasingly you'll describe intent and review outcomes. The people who can write a precise spec and a sharp test will outperform the people who can write a clever loop.
  2. Small teams do what big teams used to.A tiny, high-taste team with good tooling can now ship what needed a department five years ago. This is the part I find genuinely exciting — it's why I'm building things solo with a very small footprint.
  3. Fundamentals come roaring back.When anyone can generate code, understanding what the machine is doing — data structures, systems, networks, how the OS actually behaves — becomes the differentiator, not a relic. You can't review what you don't understand.
  4. Software gets more personal.When building is cheap, more software gets built for an audience of one, or ten, or a single team — bespoke tools that were never worth a company's time before. I think that's a quietly beautiful shift.

How I'm playing it

I'm leaning into the parts AI doesn't touch: understanding systems deeply, having opinions about how things should be built, and staying close to the metal (which is half of why I still runArchand read the code I ship). I use AI heavily — it's a fantastic collaborator — but I try never to ship something I couldn't explain line by line. That's the line I'd offer anyone right now: let the machine do the typing, but never outsource the understanding.

This is the most leverage individual engineers have ever had. It's also the easiest it's ever been to build a mess. Both are true. The craft, honestly, is learning to hold both at once.