If you have scrolled LinkedIn in the last six months, you have probably seen some version of the same headline: "I built a SaaS in a weekend without writing a single line of code." Cue the comment section — half ecstatic, the other half declaring that software developers are next on the chopping block, right after the cab drivers and the call centre agents.
This is what the industry has started calling vibe coding — describing what you want in plain English, letting an AI agent generate the code, the scaffolding, the deployment scripts, and sometimes even the database schema. It feels magical. It looks magical in demos. And like most magic, it falls apart the moment you ask it to do something real.
We work with enterprise clients across Dubai, Dublin and Pune, building systems that handle nuclear knowledge bases, parking authorisation for entire emirates, Oracle-to-Manhattan WMS middleware, and a long list of things where "it crashed in production" is not a punchline — it is a board-level incident. So when the question keeps coming up from our clients, our prospects, and frankly our own engineers — "is this going to replace us?" — we think it deserves an honest, non-clickbait answer.
Here is ours.
What vibe coding actually does well
Let us be fair before we are critical. Vibe coding tools — Cursor, Claude Code, Lovable, v0, Bolt, GitHub Copilot in agent mode, and whatever launches between us writing this and you reading it — are genuinely useful. They are not snake oil. They are good at a specific set of jobs:
- Rapid prototyping. Need to show a stakeholder what a screen could look like before the next steering committee? Two hours, done. A working clickable thing beats a forty-slide deck every time.
- Boilerplate and scaffolding. Setting up a new Express server, wiring up a basic CRUD UI, generating typed API clients, writing the obvious unit tests. The dull, repetitive part of any project.
- Throwaway internal tools. A quick dashboard for the ops team. A script that reconciles two CSV files. Things that need to work, not last.
- Learning and exploration. Engineers can prototype an idea in an unfamiliar stack and understand it faster than they would by reading documentation alone.
- Documentation, refactoring drafts, code explanation. The supporting work that good engineers used to do under sufferance.
Realistically, this is somewhere between 15% and 25% of the actual work involved in shipping enterprise software. It is a meaningful slice. It is not the whole pie. It is not even half.
15–25%
Of real engineering work AI can credibly do today
75%+
Still requires judgement, architecture & review
80/20
Easy prototype vs. production-ready system
Where the wheels come off
Now the part the demo videos do not show.
FAILURE MODE 01
The first 80% is easy. The last 20% is the job.
Anyone who has shipped software for more than a year knows the cruel arithmetic: the working prototype is 20% of the effort, and the production-ready system is the other 80%. Vibe coding is brilliant at the first part and almost completely useless at the second. Authentication that does not leak tokens. Database queries that do not collapse under load. Idempotent payment flows. Error states for the 47 ways a third-party API can fail. Audit logs that satisfy a compliance officer. Role-based access control that does not accidentally let the intern see the CEO's payroll. None of this shows up in a "build me a Twitter clone" demo. All of it shows up the moment a real business starts using your software.
FAILURE MODE 02
AI does not understand your business. It understands patterns.
We had a client recently — a manufacturer — whose "simple" invoicing logic had thirteen conditional branches based on country of dispatch, customer tier, contract vintage, and a regulatory exception from 2019 that nobody outside the finance team remembers. An LLM will happily generate beautiful, well-commented, completely wrong code for that scenario, because the actual rules live in a PDF that was never digitised and in the head of a controller who is two years from retirement. Software engineering is not typing. It never was. It is the translation of messy, contradictory, half-spoken human intent into a precise, deterministic system.
FAILURE MODE 03
The code looks right. That is its most dangerous feature.
A senior engineer reviewing AI-generated code is doing real work. A junior engineer accepting AI-generated code is generating a future incident report. The output is fluent, confident, and stylistically polished — which is precisely why subtle bugs slip past. Off-by-one errors, race conditions, SQL injection vectors disguised as parameterised queries, dependency choices that quietly introduce a GPL licence into your proprietary product. The code passes a lint. It passes a vibe check. It does not pass a security audit.
FAILURE MODE 04
Maintenance is where prototypes go to die.
Vibe-coded applications are often architectural Frankensteins — different files written in different styles, conflicting state management patterns, no consistent error handling, no test discipline, dependencies that nobody chose deliberately. They work on day one. By month six, every change breaks two other things. By year two, the team rewrites the whole thing — usually with engineers, the long way, because now it actually has to behave.
FAILURE MODE 05
The hard problems are not coding problems.
Designing a system that will serve ten million users in three regions with sub-200ms latency, comply with GDPR and DPDP, integrate with seven legacy systems your client acquired through three mergers, and survive a 10x traffic spike on Black Friday — that is not a prompt. That is architecture, judgement, trade-off analysis, and twenty conversations with stakeholders who do not know what they want until they see what they do not want. AI helps. AI does not lead.
Software engineering is not typing. It never was. It is the translation of messy, contradictory, half-spoken human intent into a precise, deterministic system. The typing was always the easy part.
So who actually loses work?
Let us not pretend nobody is affected. That would be dishonest in the other direction.
The roles most genuinely exposed are the ones built around redundant, pattern-based work — the body-shop model of ten people writing the same CRUD screen for the tenth client, the maintenance teams whose job is mostly running the same three runbooks in rotation, the agencies whose entire pitch was "we can build you a landing page cheap." That work is consolidating. It will keep consolidating.
But this is not new. This is the same pattern that came for typists, telephone operators, and frame-by-frame animators. The work did not disappear — the commodity version of it did. Demand for high-quality design, communication, and animation went up, not down. Software engineering is going through the same transition. The floor is rising. The ceiling is rising faster.
The Profecia view
Vibe coding does not replace developers. It exposes the ones who were never doing engineering in the first place.
Writing CRUD screens to a spec is not engineering. It is typing. The engineers being replaced are not being replaced by AI — they are being replaced by the realisation that what they did was always commodity work waiting for a faster way to be done.
The engineers who think, design, integrate, secure, and ship are about to have an extraordinarily good decade.
What competent engineers should actually do
If you are a working software engineer reading this and wondering what to do on Monday morning, here is what we tell our own people:
i.
Learn to lead AI, not race it
Treat AI like a fast, eager, slightly unreliable junior — give it scoped work, review its output like a code reviewer, and keep architecture, trade-offs and customer conversations for yourself.
ii.
Go deep on what AI cannot fake
System design. Performance. Security. Data modelling. Distributed-systems trade-offs. Reading legacy code and understanding why it is the way it is. These compound. They do not commoditise.
iii.
Fluent with tooling, not religious about it
Use Cursor, use Claude Code, use whichever assistant fits your flow. Measure honestly whether it makes you faster — or just feels like it does. Throw away the ones that do not earn their keep.
iv.
Specialise in something that has consequences
Healthcare, financial infrastructure, aviation, industrial control. Anywhere a bug is not embarrassing but expensive — or dangerous. The economics of "let the AI do it" do not survive a regulator's audit.
v.
Get better at writing & explaining
Half of senior engineering is now writing — design docs, post-mortems, prompts, code review comments. Clear thinking expressed in clear writing is the rarest skill in the industry and the one AI most amplifies.
vi.
Stay close to the business
Engineers who understand why the company makes money survive every restructuring, every tech shift, every hype cycle. AI does not threaten them. It makes them more valuable.
The honest bottom line
Vibe coding is real, it is useful, and it is overhyped. It does perhaps a fifth to a quarter of the work involved in building software — the visible, demo-friendly, easily-impressive part. The other three-quarters — the judgement, the design, the integration, the production hardening, the maintenance, the conversations with stakeholders, the architectural trade-offs, the responsibility — still belongs to engineers. Competent ones. The ones who can think.
The narrative that developers are about to be replaced makes for great headlines and terrible forecasting. What is actually happening is more interesting: the bar for entry is moving up, the bar for excellence is moving up faster, and the engineers in the middle who can adapt are going to have an extraordinarily good decade.
At Profecia Links, we use these tools every day. We also know what they cost when they go unsupervised. The clients who come to us after a vibe-coded MVP started melting in production — and there are more of them every quarter — are the clearest proof we have that the work is not going anywhere. It is just changing shape.
The future of software is not AI or engineers. It is engineers who know how to lead AI.
Top comments (0)