Why the Right Development Model and Paradigm Still Matter in the Vibe-Coding Era!

TL;DRA powerful tool has arrived in the workshop. Vibe coding lets you describe what you want in plain English and have a large language model cut the timber for you, and it is fast. But a faster chisel was never what decided whether a project lived or died. What decided it, and still decides it, is whether you matched the right people and the right paradigm to the work's complexity class. The tool does not repeal that rule; it sharpens it.

My argument runs in three parts: vibe coding is superb where the requirements are known, and the stakes are low; dangerous the moment a weekend prototype quietly becomes a production system; and slow poison to your talent pipeline if you let the machine do so much of the apprentice's work that you stop minting masters. The Luddites took hammers to the looms and Ford's line drew pickets from men certain the machine had come for them; refusing the tool is a losing hand every time. Refusing to think about how you wire it into your organisation is the more expensive mistake, and it is the one being made right now.

Enterprise CTOs have asked me many times at the start of a project which development model, platform, or language they should adopt to give the implementation its best shot in the cloud. There are several factors I weigh, and they have not really changed with the arrival of AI; they have simply grown louder:

1. Project Complexity Class: how much of the problem is actually unknown.
2. Availability of the programming talent pool: and now, what “talent” even means once the machine writes the first draft.
3. Existing libraries and support tools: into which the LLM has quietly installed itself as the biggest library of them all.
4. Programming paradigm and the language’s efficiency: vibe coding being the newest paradigm your craftsmen must assimilate, not the last one they ever will.

Let me take them in turn, because the answer to “do we still need junior developers?” falls straight out of the first two, and it is a more uncomfortable answer than the industry wants to hear.

How complex is the work, really?

The cloud era handed developers an enormous resource to ply their trade. Gone are the days of waiting eight weeks for a development environment to be provisioned; with the ease of an API call, developers tap into as much compute and as many cloud-native services as they need. With that capability came the monolith-versus-microservice debate, and now a second one stacked on top: how much of this do we let the AI write?

There is nothing wrong with a monolith, provided the project is simple, and the deliverable is deterministic. And there is nothing wrong with vibe coding, provided you are honest about which quadrant you are standing in. So how do you tell whether your project is simple or complex, and thus which developers (and tools) to assign to it? Too many rockstar developers on a simple job is not cost-efficient; too few experienced hands on a hard one, and the team fumbles over basic obstacles.

To classify the work, I use the Cynefin sense-making domains, dressed in the known/unknowns language Rumsfeld made famous:

Simple (known knowns). You have all the specifications and requirements, your developers understand them, and they have fair skill in building the solution. Most of the time, these are extensions to existing deployments: a new field in a database, a new report schema. Nobody is inventing an architecture; they are following an existing one under some form of development governance. Simple projects can be staffed with junior developers, led by more experienced ones to keep them on the path. This is exactly where vibe coding shines. When the pattern is known, and the blast radius is small, letting the model rough out the code and having a human dress the edges is a real win. Karpathy himself framed it as “throwaway weekend projects,” and that framing has done a lot of honest work that the hype has since thrown away.

Complicated (known unknowns). You recognise the risks upfront, but the team does not yet have the skill or knowledge to deal with them; an unfamiliar technology, a domain that is not yet common knowledge. This is the realm of hypothesis testing, tinkering and prototyping to learn as you go. I would love to say prototypes stay prototypes. But I have seen too many test prototypes become critical enterprise systems, because no one believes in throwing away working code and starting again. The prototype gets patched, and patched, and that is the technical debt we all end up paying. For this class, we use rapid application development (RAD), with quick, iterative deliverables, and, crucially, a proper Design, Construction, and Testing phase once the prototype has met its objective, so the patching is designed out rather than lived with. RAD is intensive and wants a broad range of engineering skill; junior developers are usually not seasoned enough for it. Over time, as the team gains exposure, frameworks and helper libraries emerge, the unknowns become knowns, and a Complicated project gracefully decays into a Simple one.

And here the new tooling earns its most important warning. Vibe coding is a prototype-manufacturing machine of extraordinary speed, and that is precisely the danger. If the industry could not resist promoting hand-built prototypes into production before, what happens now that a prototype can be conjured in an afternoon by someone who, in Karpathy’s own words, has stopped reading the diffs? GitClear’s 2025 study of 211 million changed lines tells the story we should have seen coming; the share of refactored, reused (“moved”) code slid from roughly a quarter in 2021 to under a tenth in 2024, cloned code roughly quadrupled, and for the first time copy-pasted lines overtook moved ones. By September 2025, Fast Company was calling it the vibe-coding hangover, with senior engineers describing the “development hell” of maintaining code the machine wrote, and they did not. None of that is a failure of the tool. It is the old prototype-to-production sin, committed faster.

Vibe coding does not change which quadrant a project lives in; it only changes how quickly you can fool yourself about which one you are in.

Complex (unknown knowns). Here, the unknown elements exist, and the team senses something is missing, but the knowledge sits outside the team, or within one quiet member who never brought it to a consensus. As a group, the team may well have the skills; the trouble is that if nobody knows the risk exists, it never makes it into the design. You mitigate this early with role-playing, storytelling and brainstorming, the group activities that surface tacit knowledge, and you need strong leadership to build a safe-haven culture where speaking up carries no penalty, however far-fetched the concern. Notice that no amount of code generation helps you here. The bottleneck is human, social, and about judgement; the very things a language model does not possess.

Chaotic (unknown unknowns). The riskiest work an organisation takes on, with little guarantee it will bear fruit: discovery, R&D, exploratory work (quantum computing, say). Few organisations have the appetite, but the rewards, when they land, are first-mover advantage over the competition. Staffing depends on the flavour of the unknown, but these tend to be the scientist types with a healthy respect for engineering solutions.

Now, the honest truth about enterprise software: roughly 80% of it is data and information retrieval, some reshaping of that data into a different structure, and storing it in a file or database with a little processing along the way. That is an oversimplification of what we used to unglamorously call data processing rather than software development, but step back and look at the ERPs, the CRMs, the e-commerce platforms, and that is essentially what they do. Which means enterprise software tends to be Simple or Complicated, and seldom Chaotic. It also tends to have a very long life and demands constant maintenance to keep pace with the business. Hard-to-change software accretes technical debt through patchwork until it becomes a ticking time bomb, and (we are humans after all) we rarely defuse it before it goes off.

If 80% of enterprise work is Simple-to-Complicated data plumbing, then 80% of it is exactly where vibe coding both helps most and tempts you most. Treat that as a reason for discipline, not a licence for abandon.

Programming is a craft, and craftsmen are grown, not summoned

The enterprise needs different skill sets across development, security and operations. And programming, whatever the tooling, stays a craft. As with any craft, there are levels of maturity to climb; the novices fresh from school, the journeymen learning the trade from their own mistakes, and the master guild members whose decades of scars produce the architectures the rest of us build on.

Now the blunt question every CTO has put to me this year: if the machine does the heavy lifting, do we still need juniors at all? Can we not run a thin bench of seniors who write the specifications and check the outputs, and let the AI be the workforce?

I will plant my flag. The executives quietly deciding to stop hiring juniors because “the AI does that now” are not trimming fat. They are eating their seed corn. A thin bench of seniors checking machine output is not a workforce strategy; it is a wealth transfer from the profession’s future into this quarter’s margin, and the invoice arrives on the day the last of today’s masters retires, with no one trained to take the bench.

Here is the analogy I keep coming back to. Picture a cabinetmaker’s shop the year the power tools arrive. The router and the CNC machine now do in minutes the rough cutting an apprentice used to spend months learning by hand. Two things are true at once, and you have to hold both without flinching.

First, refusing the power tool is foolish. This is the Luddite’s error, and Ford’s picketing unions after him; the tool is not going back in the box, and the shop that swears off it gets underbid by the shop that takes it up. Any developer worth their salt can assimilate a new paradigm and be productive after a short ramp-up, and vibe coding is simply the newest paradigm to assimilate. The craftsman takes up the tool; the tool does not take the place of the craftsman.

But second, and this is what the “just keep the seniors” crowd waves away: where do the next masters come from? The apprentice never did the rough cutting because it was the valuable work. The apprentice did it because that was how the hand learned the grain of the wood, how judgement was built in the fingers long before it reached the head. Let the machine make every rough cut and the apprentice never builds that judgement, and twenty years on you own a workshop full of expensive machines and not one person who can tell when the router has wandered into a knot.

So let me take the specific claim apart, because it hides a sleight of hand. “Seniors write specs and check outputs” sounds like vibe coding, but it is the opposite of it. As Simon Willison put it, if you have reviewed, tested and understood every line the model wrote, you were not vibe coding at all; you were using an LLM as a very fast typing assistant. Competent review of AI output is a senior skill, and arguably a harder one than writing the code yourself, because you are reverse-engineering intent from unfamiliar code under a clock. Which is the contradiction, stated plainly: the “just seniors” model burns senior judgement faster than any tool before it, while quietly demolishing the apprenticeship that was the only thing producing that judgement. It is a machine for consuming a resource it has stopped manufacturing.

You cannot run a workshop of masters-and-machines with no apprentices. Not because apprentices are cheap hands, but because they are the only supply of future masters you will ever have.

What actually changes, then, is not whether you need juniors but what a junior does on day one. The grunt work that once filled an apprentice’s first two years, the boilerplate and the CRUD scaffolding and the glue code, is exactly what the machine now cuts. Fine; so move the apprentice up the bench rather than out the door. Put them on reading and tearing apart generated code early, on writing the tests the model skipped, on the “why is this wrong?” arguments that build the judgement muscle. The barrier to entry has dropped, and some of the people who vibe code their first weekend app will be bitten by the craft and become real engineers. That is a gift. But it is a gift you have to catch on purpose, and an industry busy congratulating itself on headcount savings is not reaching for the catch.

I sort the unknowns on any project into two kinds, because AI moves one and leaves the other exactly where it was:

• Requirements and specification unknowns. The unquantified non-functional requirements; “the platform should be responsive”. The model will cheerfully generate code against a woolly spec and hand you something that runs. It cannot tell you the spec was wrong. That judgement is human and requires senior experience.
• Developer skill in a new paradigm. This one AI genuinely compresses; ramp-up is quicker when you can ask the machine to show you the idiom. But shortening the ramp is not the same as removing the need to understand where you have ended up standing.

Fundamentally, it comes back to your model for code development. If your business lives on inventing new designs each time, you want a SWAT team of strong engineers (pun intended) who can match the software solution to the right infrastructure, cloud resources and all; you are betting on innovation, and vibe coding is a force-multiplier for people who already know what good looks like. If your business instead sustains a large estate of enterprise platforms and fields change requests against them, the model is different; here the machine’s speed is seductive, and the discipline of review is the only thing keeping the estate from quietly rotting. Whether you want one large SWAT team or several is a question of what earns the business its income, not of what is fashionable this season.

The best library you now have is the one that writes libraries

The existence of useful libraries and support tools has always been one of the most important factors in choosing a language. If your team has poured effort into classes and libraries that integrate with your enterprise systems and have been tested and trusted across teams, it would be foolish to throw them away on the next project. Enterprise Java has long been the favourite here, with most shops having built their own JVM libraries to meet their domain. And when you step into a new domain (big-data processing, computer vision, AI/ML), it is often easier to reach for Python and the open-source ecosystem than to reinvent the wheel.

The LLM has now installed itself as the largest helper library in the building; ask, and it produces the wheel on demand. But a borrowed wheel you do not understand is the reinvented-wheel problem wearing a disguise. The point of a trusted library was never that it saved keystrokes; it was that it was tested and understood by your people. Generated code that no one on the team can comprehend fails that test, even when it compiles. Use the model to draft, by all means; then fold what survives review into the same trusted, governed asset base you already keep. (IBM’s public cloud, for what it is worth, ships SDKs for Go, Java, Python, Node.js and Swift, and if your language can call a REST API, or even just curl from a shell script, you can reach the services directly.)

A library earns its place by being understood, not by being fast to summon. That was true of your JVM classes; it is true of everything the model hands you.

Are your developers productive, or just busy?

The ready availability of developers who can assimilate your chosen language and paradigm is the next hurdle, and I am in two camps here. Yes, you need skilled talent. But coding output is not manual labour, and a developer’s productivity was never lines of code per hour; it was a poor measure before AI, and it is a comic one now, when the machine can emit a thousand lines that a senior then spends a day deleting. My own view has not shifted: any developer worth their salt can pick up a new paradigm and be productive after a short ramp-up, and the good ones treat vibe coding as one more instrument to master, not a reason to stop understanding the notes.

And if you want the discomfiting evidence, METR ran the experiment the rest of us only argued about. Sixteen seasoned open-source developers took on 246 real tasks in their own repositories, with AI allowed on some and barred on others. Beforehand they forecast the tools would make them about a quarter faster; afterwards they reckoned they had been a fifth faster; the stopwatch said they were 19% slower. Sit with that gap for a moment. The busy feeling of shipping was real; the shipping was not. Which is the whole point of the heading above: velocity you can feel is not the same as work that is done, and only one of the two shows up in the business’s numbers.

The choice of paradigm still shapes how productive people are. I like how OOP languages let you abstract and model a domain in terms a business person can almost read, and how functional styles make whole classes of bugs structurally impossible; the paradigm is not decoration, it changes which mistakes you can even make. Vibe coding is a paradigm too, with its own signature failure mode: code that looks plausible, runs, and hides its defects behind confidence. Adopting it is therefore not a yes-or-no; it is a where and a how much, calibrated to the complexity class in front of you.

And as professional developers, we too often forget that we work for a business, and that the business's prerogative is profit. So the right development model has to be judged from that seat. When you weigh a paradigm, this shiny new one included, the question is not “is it exciting?” but “will the team ship sustainable, good code the business can live with for a decade?” Vibe coding can lower cost and raise speed in the Simple and Complicated quadrants. It can also bill you later, with interest, when the unreviewed prototype becomes the system of record. Both invoices are real. Your job is to know which one you are signing.

Summary

The right development model and paradigm mattered in the client-server era, mattered in the cloud era, and matter now that a language model writes your first draft. None of the fundamentals moved. You still classify the work by how much of it is truly unknown; you still match talent to complexity; you still guard against the prototype that sneaks into production and turns into a time bomb; and you still grow craftsmen the only way craftsmen have ever been grown, by letting apprentices do real work under a master’s eye.

Vibe coding is a superb power tool, and the Luddite reflex to reject it is the wrong lesson to draw from Ford’s picket lines. So embrace it where the requirements are known, and the stakes are low; be ruthless about review where they are not; and do not, in the name of a lean senior bench, take an axe to the apprenticeship that supplies your future seniors. Do we still need junior developers? More than ever, though what we ask of them on their first morning has changed for good. Do we just need seniors to write specs and check outputs? Only if you are content to run your masters down and mint no new ones, which is a fine plan right up until the last of them clears out their desk.

Weigh the pros and the cons, as I always tell the CTOs who ask. The tool is remarkable, and I reach for it daily; the democratisation is real, and I would not put it back if I could. But a workshop is not its machines. It is the people who know when the machine is wrong, and (we are humans, after all) it will eventually be. Keep the workshop.