The programmers who want ai to take their jobs
While most of the tech industry ties itself in knots worrying about artificial intelligence killing software jobs, a vocal and growing faction of experienced developers is doing something that looks, from the outside, almost perverse: they are actively pushing AI to write more of their code, not less. Not as a reluctant concession. As a deliberate strategy.
The shift nobody saw coming
The standard narrative around AI and employment is grim and well-rehearsed. Reports stack up. Economists warn. White-collar workers brace. And programming, once considered a relatively safe harbor, has watched tools like GitHub Copilot and a wave of agentic coding assistants chip away at that sense of security. The fear is real, and for many developers it sits close to the surface.
But something else is happening in parallel, and it is being driven by some of the most experienced people in the room. These are not junior developers dazzled by a shiny tool. These are engineers who have spent years inside the sausage factory of software production and have arrived at a blunt conclusion: a significant chunk of what they do every day is mechanical, repetitive, and frankly beneath their actual skills. Translating specs into syntax. Patching legacy systems. Moving blocks of code between files. Fixing the same class of bug for the hundredth time.
Their argument is not that programming is dying. It is that the least interesting part of programming is finally eligible for automation, and they want to be first in line to hand it off.
Andrej karpathy names the thing everyone was already doing
The moment this current broke into mainstream tech conversation came in early 2025, when Andrej Karpathy, former director of AI at Tesla and one of the founding figures at OpenAI, posted a deceptively casual message on X. He called his approach vibe coding. The label stuck immediately, partly because it was honest about what it actually felt like.
Karpathy was not describing autocomplete on steroids. He was describing something closer to a full handoff: letting the model write and revise the code, accepting changes without auditing every line, and positioning the human as the one who holds the intent, not the implementation. The programmer becomes the director, not the typist.
Within months, vibe coding went from a tweet to a genre. Developers started writing about working this way full-time. Specialized publications ran analysis pieces. The word moved from ironic to operational faster than most tech coinages manage.
What they actually want to stop doing
The developers driving this shift are not asking to be made redundant. They are asking to be relieved of a specific category of labor that they argue has always been a tax on the real work. Repetitive pattern replication. Boilerplate integration. Syntax wrangling. Maintaining systems that should have been retired three years ago.
Strip that away, and what remains is the part they actually want: deciding which problem is worth solving, shaping how a product should behave, defining the user experience, drawing the ethical and architectural lines that a model cannot draw for itself. The AI, in their framing, is not a replacement. It is the layer that absorbs the mechanical so the human can operate at a higher altitude.
The practical upside is speed at a scale that changes how products get built. Instead of spending weeks on a first working version, teams using agentic tools can spin up multiple directions in days, test them against real conditions, and kill the ones that do not work before significant resources are committed. Iteration velocity becomes the competitive edge, not lines of code per hour.
Why this matters beyond the trend cycle
It would be easy to file vibe coding under "developer Twitter hype" and move on. The reason not to is that the people advocating for it are already shipping real software this way. This is not a theoretical workflow. It is running in production at companies that have quietly restructured how their engineering teams operate.
That raises questions that go well past the philosophical. If the premium skill shifts from writing clean code to directing systems that write code, the entire pipeline for producing developers needs to be rethought. What does computer science education look like when syntax fluency matters less than systems thinking? Who gets access to the tools that make this new model of work possible? And when an AI agent does the foundational build, how does value get distributed across a team?
The developers celebrating every new capability that lets them delegate further are not, in the end, designing their own obsolescence. They are sketching the job description of the engineer who comes after them. Whether the industry is ready to train that person is a separate, and considerably more uncomfortable, question to answer.