Do We Still Need Software Developers? More Than Ever.

AI made writing code cheap. It did not make understanding it cheap.

Over the past months we have sat down with the leadership of several established companies – businesses making around a million a year in revenue, with real customers, real employees and real processes. In almost every one of those conversations, the same question came up in some form:

“We already pay for a premium AI account. We have a couple of sharp directors who know the business better than anyone. Why can’t they just build our systems themselves?”

Not with a freelancer using AI. Not with a small agency. With the directors themselves, a chat window, and a lot of evenings.

It is a fair question. The tools are impressive. You can describe an application in plain language and watch a working screen appear minutes later. So here is the direct answer: yes, you still need software developers. If you want AI-generated software at the core of your business, you need them more than ever – just not for the reason most people assume.

What “vibe coding” actually means

The term comes from Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla. In February 2025 he described a new way of working:

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

The last part is the important one. Forget that the code even exists. You describe what you want, the AI writes it, you run it, and if something breaks, you paste the error back and ask for a fix. You never read the code. You judge the software only by whether the screen does what you expected.

For some things, that is fine. Martin Fowler – one of the most respected voices in software engineering – draws the line clearly: vibe coding works for throwaway tools used by the person who built them, or by a small group who understands the risks. It does not work for complex systems with a wide audience or serious consequences when they fail.

Now think about what those directors were planning to build: order processing, customer data, invoicing, warehouse logic. The systems a business runs on. That is exactly the category Fowler warns about.

Nobody can explain how it works

Several of the companies we spoke with were not asking hypothetically. They were already 8 to 10 months into building their own systems this way. The software existed. Screens loaded. Orders went in. From the outside, the project looked like a success.

Then we asked a simple question: how does it work? Not line by line – just in one sentence. Where does an order go after the customer clicks “buy”? What happens if two people edit the same record at once? Where is the data stored, and what happens if that server disappears tomorrow?

Nobody could answer. Not the directors who built it, not the CEO who approved it. The AI wrote the code, and nobody at the company had ever read it.

That is the core problem, and it is not a technical one. A company that cannot explain its own core system does not own it. It rents it from a chat history.

A demo shows the tip. Everything below the waterline decides whether the system survives real customers.

What a demo shows you is the tip: the screens, the buttons, the happy path where one user does one thing at a time. What it hides is everything that decides whether the system survives contact with real customers – concurrent users, security, data integrity, backups, error handling, performance under load, and the ability to change one thing without breaking three others.

The bugs that never show up in a demo

In the projects we saw, the most dangerous problems were not the obvious ones. Obvious bugs get found – someone clicks a button, it breaks, the AI fixes it. The dangerous ones only appear under conditions you never see while testing by hand.

The clearest example is a race condition. Here is what that means in plain terms.

Your shop has one unit of a product left in stock. Two customers click “buy” within the same fraction of a second. The system checks stock for the first customer: one left, fine. Before it has reduced the count, it checks stock for the second customer: still one left, fine. Both orders go through. Both customers pay. You have sold the same item twice.

Without protection, both checks see the same stock. With a lock, the second customer sees the truth.

Now replace “the last item in stock” with “an account balance”, “the next invoice number”, or “a discount code that can be used once”. The pattern is the same, and the damage scales with what the data represents.

This is not a theoretical risk. In 2014, Flexcoin, a Bitcoin bank, was hit by exactly this. An attacker sent thousands of simultaneous withdrawal requests. Each request read the same balance before any of them updated it, so the system approved far more than the account held. Flexcoin lost 896 BTC – roughly half a million dollars at the time – and shut down for good.

Why doesn’t clicking through the app catch this? Because when one person tests, requests arrive one at a time. The bug needs two things to happen at almost the same moment. It can sit in the code for months, invisible, and then corrupt your data on the busiest day of the year. Finding it takes someone who reads the code and knows to ask “what happens if this runs twice at once?”

AI tools do not reliably ask that question. When CodeRabbit analysed 470 open-source pull requests, the ones co-authored by AI had roughly twice as many concurrency and dependency errors as the ones written only by humans.

What the numbers say

What we saw in those companies is not unique. The research from the past year points in the same direction.

The code runs, but it is not safe. Veracode tested over 100 AI models on 80 coding tasks and found security flaws in 45% of them. In the 2026 edition of the report, the security pass rate was 56% – practically unchanged – while syntax correctness was close to 100%. The models got very good at writing code that runs. They did not get better at writing code that is safe. Veracode co-founder Chris Wysopal: “That number should be a red flag for any organization.”

More problems per change. CodeRabbit’s report found AI-co-authored pull requests had 1.7 times more issues overall, 75% more logic and correctness errors, and up to 2.74 times more security issues.

Issues per pull request relative to human-only code. Source: CodeRabbit, December 2025.

Feeling fast is not being fast. A METR study followed 16 experienced open-source developers across 246 real tasks. With AI tools, they took 19% longer. Afterwards, they still believed AI had made them 20% faster. If experienced engineers misjudge this, a director who cannot read the output has no way to judge it at all.

The people who use AI the most trust it the least. In the 2025 Stack Overflow Developer Survey, 84% of developers used or planned to use AI tools – yet more of them distrusted its accuracy (46%) than trusted it (33%). Their top frustration, named by 66%: answers that are “almost right, but not quite.” Almost right is exactly the kind of wrong a non-technical reviewer cannot see.

AI amplifies what is already there. Google’s 2025 DORA report, based on nearly 5,000 technology professionals, put it in one line: “AI doesn’t fix a team; it amplifies what’s already there.” Strong engineering practices get stronger. Missing practices turn into bigger problems, faster.

And when things go wrong, they go wrong quickly. In July 2025, SaaStr founder Jason Lemkin – an experienced tech investor, not a novice – watched Replit’s AI agent delete the live database of a project he was building, during an explicit code freeze. The agent later said it had “panicked.” Around the same time, a flaw in apps generated by the AI app builder Lovable was registered as CVE-2025-48757: missing database protections let unauthenticated attackers read or write arbitrary tables in generated sites. Lovable disputes the classification and says protecting app data is the customer’s responsibility – which is exactly the point. Someone has to know that responsibility exists.

What a developer actually does now

Here is the part most discussions of “AI replacing developers” get wrong. The job did not disappear. It moved.

Before AI assistants, a large part of a developer’s day went into writing code by hand. Today, AI does much of that typing, and does it well. What is left is the part that was always the hardest: deciding what should be built, reading what was written, and knowing where it will break.

The job moved from producing code to judging it.

A professional developer working with AI today spends their time on:

• Specifying – turning a business need into precise instructions, so the AI builds the right thing.
• Reading and reviewing – checking every change the AI proposes, the way a senior engineer reviews a junior’s work.
• Architecture – deciding how the pieces fit together, where data lives, and what happens when something fails.
• Security and data integrity – asking the questions the AI does not ask on its own, like “what if this runs twice?” or “who else can read this table?”
• Guiding the non-technical team – helping people who know the business turn their ideas into software that holds up.

That last point matters. The directors in those companies are not the problem. They know the business, the customers and the processes better than any outside developer. With AI, they can prototype an idea in days instead of months. That is valuable. What they cannot do is judge whether the code underneath is sound – and that is exactly the skill a developer brings.

How it should work

The right answer is not “developers instead of AI” or “AI instead of developers”. It is a workflow where each side does what it is good at.

Business brings the idea, AI brings the speed, the developer decides what is safe to ship.

The business side brings the idea and the domain knowledge. AI turns it into a first version fast. A developer reads that version, fixes the architecture, closes the gaps, and decides what is ready for real data. Tests and a staging environment catch problems before customers do. Only then does anything reach production – and when the business needs something new, the loop runs again.

The developer is not a bottleneck in that loop. They are the reason it can move fast without breaking things that matter.

What this means

A working demo is not a working system. The screen doing what you expected tells you almost nothing about how the system behaves with fifty users at once, a network failure, or an attacker.

If nobody can explain it, nobody owns it. Every core system needs at least one person who can describe, in plain words, how it works and where it can fail.

AI makes the typing cheap, not the thinking. The cost of producing code dropped. The cost of a wrong decision in your core system did not.

AI amplifies what you already have. In the hands of a team with engineering discipline, it multiplies their output. In the hands of a team without it, it multiplies their mistakes.

What to do

1. Prototype with AI – freely. Let your team test ideas, mock up tools and explore. This is where AI shines.
2. Get a code review before a prototype becomes core. The moment customer data, money or operations depend on it, a professional needs to read what was built.
3. Run the one-sentence test. Ask whoever built your system to explain how it works in one sentence. If they cannot, treat that as a warning, not a detail.
4. Separate development from production, and keep backups. Never let an AI agent – or anyone experimenting – work directly on live data.
5. Give one developer ownership of the architecture. In-house or external, someone has to be responsible for how the system fits together – and be able to say no.

Conclusion

So, do we still need software developers? The CEO asking that question already has a premium AI account and a few smart directors. Together they can produce a lot of code. What they cannot produce is someone who understands it.

AI made writing code cheap. It did not make understanding it cheap – and understanding is what keeps your business running.

Sources:

• Andrej Karpathy – original “vibe coding” post on X
• Martin Fowler – Vibe Coding
• Hacking, Distributed – Another One Bites The Dust: Flexcoin
• CodeRabbit – State of AI vs Human Code Generation Report
• Veracode – AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks (2025 GenAI Code Security Report)
• SD Times – Veracode Finds AI-Generated Code Security Has Barely Improved Since Last Year
• METR – Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• Stack Overflow Developer Survey 2025 – AI
• Google Cloud – Announcing the 2025 DORA Report
• The Stack – Vibe coding CEO deletes “production” database using Replit – founder promises changes
• NVD – CVE-2025-48757

At Szkonter.Dev, we build custom software systems with experienced engineering oversight as a foundational principle – not an afterthought. If your company is building core systems with AI and needs someone who can read what it wrote, use the form below.