The 1950s already had a name for vibe coding

I came across a term this week that stopped me in my tracks: intelligence amplification. It sounds like something a startup coined last quarter. It's actually seventy years old.

In 1956, the British cybernetician W. Ross Ashby wrote about "amplifying intelligence" in An Introduction to Cybernetics. His argument was simple. We'd built machines to amplify muscle power for two centuries, so why not build machines to amplify thinking? Not replace it. Amplify it.

Four years later, J.C.R. Licklider published Man-Computer Symbiosis, a paper I'd encourage every developer to read, if only because it describes 2026 with unsettling accuracy from a desk in 1960. Licklider's vision was a partnership: humans set the goals, supply the judgement and the intuition, and machines do the routine, formulaic work that gets in the way of actual thinking. He wasn't interested in artificial intelligence as a replacement for people. He wanted a pairing that outperformed either party alone.

Then in 1962, Douglas Engelbart wrote Augmenting Human Intellect: A Conceptual Framework, and six years later gave the demonstration now known as the Mother of All Demos... the mouse, hypertext, screen sharing and collaborative editing, all shown live in 1968. Engelbart wasn't showing off gadgets. He was demonstrating a philosophy: that computing's highest purpose is to raise the ceiling on what a human mind can do.

So when Andrej Karpathy fired off his now-famous tweet in February 2025 about a new kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists", he wasn't starting something new. He was, whether he knew it or not, reviving the oldest ambition in computing. Collins Dictionary made "vibe coding" its word of the year for 2025. Ashby got there in 1956 without the branding.

Why experienced developers push back, and why they're not wrong

I talk to a lot of full stack developers, and a fair number of them are openly resistant to AI-assisted software engineering. I don't think that resistance deserves the eye-rolling it sometimes gets. Some of it is well founded.

Start with the evidence that cuts against the hype. In mid-2025, METR ran a randomised controlled trial with experienced open-source developers working on their own mature codebases. With AI tools, they completed tasks 19% slower. The kicker: afterwards, the same developers estimated the AI had made them 20% faster. That gap between perception and reality should give everyone pause, me included.

The 2025 Stack Overflow Developer Survey tells a similar story from a different angle. Adoption is enormous, with 84% of developers using or planning to use AI tools. But 46% actively distrust the accuracy of the output, and the single biggest frustration, cited by 66%, is AI answers that are "almost right, but not quite". Anyone who has debugged a plausible-looking function that quietly does the wrong thing knows exactly what that phrase means.

And that's the real hallucination problem. Simon Willison made this point well in early 2025: hallucinated code that calls a method which doesn't exist is actually the least dangerous mistake an LLM can make, because it fails the moment you run it. The dangerous errors are the ones that compile, run, pass a casual glance, and produce subtly wrong results. Those don't announce themselves.

So no, the sceptics aren't Luddites. They're pattern-matching on real failure modes. But I'd argue they're drawing the wrong conclusion from the right observations.

Amplifier, not autopilot

Here's where the intelligence amplification framing earns its keep. IA and AI describe two different projects. AI, in its classic sense, aims at autonomous systems that think for themselves. IA aims at symbiosis: machinery that makes a human sharper. The current generation of coding tools, for all the marketing, behaves far more like the second thing than the first.

The 2025 DORA report from Google, drawing on nearly 5,000 survey responses, landed on a finding I keep quoting to clients: AI doesn't fix a team, it amplifies what's already there. Strong teams with fast feedback loops and decent test coverage got faster. Teams with weak foundations found their problems arriving sooner and in greater volume. The report also found AI adoption correlated with higher throughput but lower delivery stability. An amplifier turns up whatever signal you feed it, including the noise.

Read that back against the METR result and the picture sharpens. The developers who slowed down were experts working on codebases they knew intimately, exactly the situation where their own amplifier gain was already high and the tool added review overhead. That result says less about AI coding failing and more about where amplification actually pays off, which is precisely what Licklider said sixty-five years ago: let the machine take the routine and formulaic, keep the judgement human.

Which is why I think the fear-for-my-career reading gets it backwards. If the tooling handles the boilerplate and the first draft, the scarce skills become the ones AI is worst at: threat modelling, security architecture, knowing which requirement is quietly wrong, judging what "done" actually means in a regulated environment. Those skills come from experience. The developers with three decades behind them aren't being devalued. Their judgement is becoming the bottleneck asset, and bottleneck assets get more valuable, not less.

Where this goes next

Karpathy himself has already moved on from his own term. In February 2026, a year after the original tweet, he proposed "agentic engineering" as a more honest description of professional practice, arguing that engineers, for the most part, no longer write code directly: they direct and oversee the agents that do, and there's "an art & science and expertise to it" worth naming properly. The vibe era, where you forget the code exists, was a snapshot of a moment. The direction of travel is towards developers as conductors... setting intent, defining constraints, reviewing output, owning the result.

That is Licklider's symbiosis with better hardware. The human provides initiative, direction and integration. The machine provides speed and breadth. Neither is much good alone.

My prediction, for what it's worth: within a few years "AI-assisted" will drop out of the phrase entirely, the way nobody says "compiler-assisted development" today. What will remain is the split Ashby and Engelbart saw coming, between people who use these tools to amplify genuine expertise and people who use them to disguise the absence of it. The first group will build careers. The second will build incidents.

The 1950s pioneers asked the right question: not "can machines think?" but "how much better can humans think with machines?" Seventy years on, for software engineering, we're finally in a position to answer it.

References

• W. Ross Ashby, An Introduction to Cybernetics (1956)
• J.C.R. Licklider, Man-Computer Symbiosis (1960)
• Douglas Engelbart, Augmenting Human Intellect: A Conceptual Framework (1962); "Mother of All Demos" (1968)
• Andrej Karpathy, vibe coding post (February 2025) and "agentic engineering" (February 2026)
• METR, randomised controlled trial on AI tools and experienced developers (July 2025)
• Stack Overflow Developer Survey 2025, AI section
• Google DORA, State of AI-Assisted Software Development report (September 2025)
• Simon Willison, "Hallucinations in code are the least dangerous form of LLM mistakes" (March 2025)
• Collins Dictionary, Word of the Year 2025: "vibe coding"

---

Want to talk about where AI genuinely earns its place in your development process, and where it doesn't? Contact our security-cleared team.