Vibecoding Won. What's Next?

\ As you read this, someone, somewhere is having a debate about whether vibe coding is net positive or negative. The argument is over. Vibe coding isn't going anywhere. Pandora's box has been opened and we're not going back. How did this happen so quickly? It's all about capability. In just a few short years, AI coding assistants have become insanely good. Yes, purely AI-generated code is often sub-optimally architected and has many inefficiencies. But this doesn't matter. Consider cybersecurity. AI models like the upcoming Mythos have the ability to chain together distinct vulnerabilities in code to exploit previously secure systems. The code does not have to be perfect. It just has to work. Take the experience of the Firefox team, which used Claude Mythos Preview and other AI models to help identify and fix newly discovered, but long-standing software bugs. They developed a harness and subsystems that help them use AI effectively for software hardening activities. Now, the Firefox team isn't vibe coding security fixes. But the techniques they've developed will help others secure their code more rapidly. And, given the speed that AI can find software vulnerabilities, and the urgent need to fix these bugs, I'm sure that we'll soon see completely human-free 'vibe secured' software in the near future. The consequences of slow security patches due to human bottlenecks will be too high. It's not just about security. Companies are mandating that the majority of code shipped to production has to be AI-generated (but at a cost). Solo builders are charging up to $8,000 per engineering project and not writing a single function from scratch . The CEO at a 200-person agency embarked on a " SaaS ditching program " after employees vibe coded replacements for every software tool the company pays for. Yes, vibe coding has won. What happens next? The adoption curve is one story. What's happening to the people doing the shipping is a different one. The Brain Drain Do you remember the great calculator debate? If you went to elementary school in the 1980s, you might. The Christian Science Monitor covered this topic in May 1986: \ Should children use calculators in elementary school? Or should they learn their arithmetic the old-fashioned way? … This issue has been simmering ever since pocket calculators became less expensive than textbooks. To date, math teachers have resisted the trend. Less than half use calculators in teaching -- and then, often only for checking answers -- even though the NCTM leadership has been advocating them since at least 1980 … This is alarming talk to people like John Saxon … A frequent critic of the NCTM, Saxon thinks that the organization's leaders have their heads in the sand on the calculator issue. 'There is a tremendous potential for destruction' of student math skills, he says. \n We all know who won this debate, but the arguments against calculator use sound very familiar. Using AI can lead to the atrophy of hard-won writing, coding and other skills. One engineer, after relying on AI for routine work, reported that they'd forgotten how to implement a Laravel API. It felt, they said, like being "back before I ever wrote a single line of code." Another documented a decline in their decision-making and cognitive skills: "It's making me dumber for sure. Mentally outsourcing 'thinking' in general.” This problem is personal, and it scales. The Talent Gap The rapid rise of AI has led to a real debate about what to do about juniors in coding, consulting, science, and other fields. AI can do many of the tasks that people used to rely on entry-level employees to complete. As a result, juniors and people across all career levels are learning how to prompt, review and orchestrate. These are valuable skills. But, it's not the same as writing and revising an analyst report, learning an API framework from scratch, or gaining the ability to organize functions and classes for readability and maintainability after much trial and error. In five years, what will the world look like? Will there be a large class of people who don't have a good mental understanding of what an effective software system looks like? Will they not know how to gather data and construct a financial model? If AI spits everything out in 5 minutes, why bother? Someone thought through this scenario a long time ago. Multivac: A Cautionary Tale Back in 1956, the late science fiction writer Isaac Asimov published a short story called " The Last Question ." In the story, an all-seeing, all-knowing artificial intelligence called Multivac is invented. Asimov wrote: \ Alexander Adell and Bertram Lupov were two of the faithful attendants of Multivac. As well as any human beings could … They had at least a vague notion of the general plan of relays and circuits that had long since grown past the point where any single human could possibly have a firm grasp of the whole. Multivac was self-adjusting and self-correcting. It had to be, for nothing human could adjust and correct it quickly enough or even adequately enough. So Adell and Lupov attended the monstrous giant only lightly and superficially, yet as well as any men could. \n Multivac is so complex and capablen that humans have no understanding of how it works, or its purpose. There's a lot more that happens in the story, but the point is that humans created an intelligence, but lost the ability to govern it. \n This, once fantastical idea, of an all-seeing, all-knowing computer system that had far outstripped its creators, is the current reality. This could be the 'what's next' of vibe coding. Systems created by AI, maintained by AI and controlled by AI. Humans, out of the loop. That's the pessimistic read. Here's a more optimistic one. A Framework for Working Differently At the heart of many of Isaac Asimov's works and the great calculator debate is the concept of human autonomy. Can human tendencies, habits, and emotions be boiled down to a set of equations, which can be used to control the masses? Will people be more helpless if they can't mentally solve calculations because machines handed them the answer? \n History teaches us that the answer to these questions is no. To master technology (and not be mastered by it), we have always built new skills, habits, and ways of thinking. Circling back to vibe coding. For some, prompting an AI until something works, often without much understanding of what's happening underneath, is enough. I don't think this is a great idea. A better approach is to move toward 'agentic engineering.' This isn't clearly defined yet, but at its core, for me, it's about having a deliberate relationship with AI that's slower paced and better considered. A strategy for agentic engineering that has yielded good results for me is what I call the SARD framework. This stands for Slow Down, Ask, Read, Document . This approach is summarized below. If there's interest I can go deeper into the framework in the future. Slow Down : AI can spit out a large volume of code very rapidly. Having agents spinning away for hours on a task sounds tempting, but it leads to problems down the road. Agents can go off-task, or develop code that requires a lot of remediation in the future. Slowing things down to keep a handle on what's being developed has many benefits. The biggest is having a good mental model of the codebase. At the most basic level, this enables pointing agents toward specific parts of the code to work on, which consumes fewer tokens (saves money), and aids with debugging and code analysis. Ask : With AI there are no dumb questions. Many times, during a project an agent will propose a solution that makes sense on the surface, but could lead to problems in the future. Or, the implementation being suggested isn't one that you're familiar with. When this happens, the best response is to ask the agent to clarify or explain its decision-making. Sometimes the agent will rethink its approach, or you gain a better understanding of a technique you're unfamiliar with. Asking questions aids learning and keeps you mentally engaged with the work. Read : This is related to the slow down part of the framework. With AI-assisted coding it's easy to get burned by decisions agents make in-flight. They tend to repeat themselves, don't have a good sense of functionality that's not in their context. This leads to things like repeated features across files, functions that do too much, etc. These may sound like small things, but they can lead to a codebase that's harder to understand in the future. This is why not auto-accepting changes can be a good idea. Catching a bad architectural decision mid-build can save hours of time. Document : Agents are amnesic, and so are people. Agents forget what they were working on across prompts. People forget within days. Taking time to document modules and methods well at the beginning is another time saver. Better documentation means agents take less time to understand a codebase (fewer tokens, save money). It can also help people reason about and understand the code, even if they're less technical. A docstring that's written in plain English, along with information about what's being returned by a function, is excellent information that helps with debugging and understanding. The SARD framework isn't for everyone. It takes more time upfront. But considering that organizations using AI coding agents don't report tremendous productivity gains by moving fast, taking the slow path has the potential to yield good results. Not everyone is going to slow down. Which is where the second part of the story starts. The Cleanup Crew Remember Mythos? It doesn't need the code to be perfect. It just needs a gap. There's a lot of code being rapidly developed that's insecure and non-optimized. The question is: who is going to maintain this code, ensure it is secure and performing optimally? Some might point to AI. While AI will play a role here, I think this could lead to more demand for engineers, not less. I recently released a report, Shipping the Future , which features insights about how builder communities on Reddit are talking about developing products and services with AI assistance. The research reveals that a lot of builders aren't thinking about issues like security. However, over the last year, discussions featuring terms like threat model and security audits have been on the rise . The best people to advise builders on these topics, if they don't have the knowledge themselves, are people with hard-earned experience who can help to optimize, remediate and maintain an ever-growing pool of software applications. The Calculator Debate of Our Time The vibe coding debate is similar to the circa 1980s argument about calculators, but with bigger stakes. Calculators undoubtedly led to cognitive outsourcing. AI is doing the same. Asimov was prescient in so many ways. He realized that it is important to grapple with the idea that powerful, inscrutable machines that have outstripped their creators, might emerge one day. \n Asimov's Multivacs are all around us. In the self-improving AI system that writes its own guiding parameters. In the software that's shipped with functionality only the AI understands. Human autonomy doesn't disappear by default. It can only be given away. Slowing down, questioning what's given, documenting for our future selves is one path toward mastering AI, rather than being mastered. The rewards are potentially great for people who master these skills. They'll be the cleanup crew. Valuable, in-demand and in control.