Skip to content
AI

The Next Languages Won't Be Written For Us

Andres Max Andres Max
·

Something changed in how I build and I only caught it looking backwards.

I used to have real opinions about frameworks. Which one I’d reach for, what its conventions got right, where it would start fighting me six months in. That was a genuine part of the job and I was good at it.

These days I spend most of my time describing what I want and checking whether I got it. I still read the code and I still make the calls that matter. But the shape of the work is goal driven now in a way it never used to be. I say what done looks like, the work comes back, I decide whether it’s right.

Somewhere in there I stopped caring much about the specifics. Not out of laziness. The nuance just stopped being load bearing. As long as the thing serves its purpose and I can verify it, the details of how it’s expressed matter a little less to me every month.

That’s a small personal change. Run it forward and it turns into something much bigger.

The question I keep seeing asked is whether AI will replace programming languages. I think that’s the wrong shape of question, and the more interesting one is sitting right next to it.

Every language was built for a human reader

Languages and frameworks carry a pile of decisions that were made for people. Readability. Ergonomics. How much you can hold in your head at once. Syntax that saves keystrokes, because keystrokes were expensive back when a person had to type every one of them.

None of that was arbitrary. Those were the right trade-offs for a world where the bottleneck was a human being writing and reading every line.

That bottleneck is moving. Not gone, moving. More of the writing is being done by something that doesn’t get tired, doesn’t lose its place, and doesn’t care how many characters anything takes. The further that goes, the more those old trade-offs look like they’re optimizing for a constraint that’s loosening.

Why AI won’t replace programming languages

Here’s where I think this lands, and I’ll say up front that it’s a bet and not a prediction with a date on it.

Languages don’t disappear and they don’t matter less. They get rebuilt for a different reader.

Terseness stops being a virtue. Clever syntax exists because a person had to type it and scan it, and neither of those is the binding constraint anymore. Explicitness wins instead, because ambiguity is the expensive thing now.

Structure a machine can check gets worth more than structure that reads nicely. Types, contracts, guarantees, anything that turns “is this correct” into a question something can answer without a human squinting at it. That used to be a matter of taste. It becomes the foundation.

And the intent moves up a level. If the thing I actually own is the goal, then the artifact that matters most is the description of that goal, precise enough to build from and to check against. The code underneath becomes an implementation detail, which is roughly how we already treat what the compiler spits out. Nobody reads that. It went machine-only a long time ago and we stopped thinking about it.

I think the layer above it is next.

The part that stays human

There’s a floor to this, and it’s the review.

The reason I read code now isn’t to learn how it works so I can extend it. It’s to decide whether it’s right, and that’s a different job with different muscles. Judgment didn’t move just because the typing did. Somebody still has to know what ought to be true and be able to check that it is.

So whatever that future layer looks like, something above it stays legible to a person. Maybe it’s a spec. Maybe it’s a set of guarantees the system can prove and then show you. It won’t be shaped like source code is today, but it will exist, because trusting output that nobody can inspect isn’t a place anyone gets to stand for long.

What I’d actually do about it

If you’re picking a stack this quarter, none of this changes your answer. Use what your team already knows and ship.

Where it does change things is what you put your own reps into. Getting sharper at describing outcomes precisely, at knowing what correct looks like before you see it, at reviewing work you didn’t write yourself. Those compound, and they transfer across every tool that comes next.

Deep fluency in one framework’s quirks was among the most valuable things an engineer could carry for about thirty years. I think it’s quietly turning into one of the least.

The thing being optimized for is changing. It’s been us for a long time, and I don’t think it will be for much longer.

// Newsletter

Get my ideas every Thursday

New posts, insights, and lessons on building products with AI. One email per week.