I was nineteen, sitting in a university computer lab that smelled of instant coffee and warm plastic, and I had broken the universe.
Not metaphorically. I’d written a C program that allocated a pointer, freed it, then touched it again. The machine didn’t crash gracefully. It just… stopped. The cursor blinked at me like it was judging me. I stared at line 47 for forty minutes. I was pretty sure I’d offended the hardware.
That was the deal back then. You thought like the machine. Registers, opcodes, memory addresses. The computer was a temperamental landlord and you were the tenant who’d better keep the pipes quiet. Every generation of developers I’ve worked with since still has a scar from that era. A story about the night the pointer bit them. A grudge against a segfault that never fully healed.
And the learning curve wasn’t just technical. It was cultural. You learned to think in the machine’s language before you were allowed to think in your own. You spent your first two years translating yourself into something the computer could parse. The ideas were there. The expression was the bottleneck.
Fast-forward a decade. I’m writing PHP at my kitchen table. My daughter is doing homework on the other side of the laptop. A football match is on the TV, muted. I’m shipping a feature in an afternoon that would have taken me a week in C.
And I feel like I’m cheating.
Not because the code is bad. It’s fine. It’s readable. I can look at if ($user->is_logged_in()) { show_dashboard(); } and think, “Yes, that’s what I meant.” The syntax finally sounds like a person. Like me.
I remember thinking: this is what it was supposed to feel like all along.
The best part wasn’t speed. It was flow. I could stay in the problem. I wasn’t context-switching between “what do I want this to do” and “how does the machine want me to say it.” Those two questions were finally the same question. I could think about the user, the edge case, the weird thing the customer in Bristol does with the form, and the code just… followed.
Nobody called it a revolution. It was just the next tool. The next small mercy. You stopped managing the machine and started managing the problem.
Last Tuesday I sat down, had a coffee, and typed a sentence into an AI agent. Not a prompt. Not a spec. A sentence. “Build me a script that pulls the last 90 days of invoices, flags the ones over budget, and drops a summary in my inbox every Monday.”
Four minutes later it was done. Tested. Working.
I reviewed it. It was… fine. Actually better than I would have written it in a hurry. I made one small edit. Shipped it.
And I sat there for a moment, feeling something I couldn’t quite name.
Not awe. Not fear. Just… oh. There we go.
Because that’s the thing nobody in the “AI will destroy programming” debate seems to notice. It’s not a new category. It’s the same line, extended one more step.
Punch cards. Terminals. IDEs. Scripting languages that sound like English. And now: you say what you want, and something builds it.
Each step closed the gap between the thought in your head and the thing on the screen. A little more each time. Nobody stood up and applauded when Python came along. It was just obvious. The next logical place to be.
I keep waiting for the “but this time it’s different” feeling. The sense that the ground has shifted under my feet. It never comes. Just a smaller gap. A quieter evening. Less 11pm staring at a blinking cursor, more 6pm closing the laptop and going to pick up my kids.
The person who can’t code
Here’s where it gets interesting to me, and where I think most of the conversation is missing the point.
For most of my career, there’s been a wall between the people who have the idea and the people who can make the thing. Product managers, founders, designers, operations leads. They had the vision, the user insight, the “what if we just…” And then they had to write a ticket. Wait three sprints. Hope the developer understood the same thing they meant. Watch a 45-minute demo that was 80% right and 20% “well, actually, the requirement was…”
I’ve been on both sides of that wall. And I’ll tell you: it was fine. It worked. But it was slow, lossy, and it meant that most ideas died in the gap between “I think this would be great” and “here’s a working prototype I can show someone.”
The cost of being wrong was too high. So people got cautious. They optimised for the safe idea, the incremental improvement, the thing that fit neatly into a sprint. The weird, half-formed, “what if we tried it this way” idea? That stayed in the back of the mind. Because turning it into something you could feel required a developer, a timeline, and a budget.
Last month a product manager on my team had one of those ideas. A small workflow change. Nothing architectural. But it was the kind of idea that’s hard to explain in a ticket because the value is in the feel, the sequence, the little interaction.
She didn’t write a ticket. She opened an AI agent, described the flow in plain English, and had a rough working prototype by lunch. Not production code. Not something she’d deploy. But something she could click through. Something she could put in front of three users and watch their faces.
She validated the idea in an afternoon. The version that survived user feedback went into the backlog as a proper spec. The version that didn’t? Died quietly, cheaply, and without a three-week build cycle.
That’s the part that gets me. It’s not that the AI wrote the code. It’s that the feedback loop got ten times shorter. The distance between “hypothesis” and “evidence” collapsed from weeks to hours.
And that changes what people are willing to try.
What actually changes
I don’t think the team structure changes overnight. I don’t think every PM is going to start shipping production code, and I don’t think that’s the point.
What changes is the cost of exploration. When a rough prototype is an afternoon instead of a sprint, you try more things. You kill more bad ideas early. You find the good ones faster. The conversation between “what should we build” and “here, touch this” stops being a formal handoff and starts being a conversation.
The developer’s job doesn’t disappear. It shifts. Less “translate this ticket into code.” More “here’s the shape the prototype gave us — now make it real, make it safe, make it scale.” The craft moves upstream. The thinking gets more room.
And for the people who’ve never written a line of code in their life? The wall gets a door in it. Not a demolition. A door. You can still not code. But you can feel the thing before you ask someone else to build it. And that changes the quality of the conversation.
The sentence
People ask me if I’m worried about AI and software development. And I think about that nineteen-year-old in the coffee-stinking lab, convinced he’d broken reality with a single free().
I’m not worried. I’m just glad the gap is finally small enough that I can think about the problem instead of the plumbing. That the product manager can feel the idea before it’s a ticket. That the weird, half-formed “what if” gets a chance to become a thing you can click, before it gets polished into a committee decision.
That’s all any of us ever wanted. We just had to wait for the tools to catch up to the sentence we already knew how to say.
And the sentence was always: I want it to work like this.
We just finally have something that hears us.