AI skeptics, AI-driven:
why we test before we trust
A few years ago, teaching a computer to recognise a cat in a photo was still a research problem. Today it writes code. We have watched the AI hype cycle from the front row — mostly because we refuse to just watch it.
We recently ran a hands-on research sprint across the AI coding tools everyone is talking about: testing them ourselves, reading the industry data, and comparing notes with other engineering leaders about what is actually happening inside their teams versus what is happening on stage at AI conferences. This is the same lens we bring to every AI decision we make for our clients — and it is why clients bring us in when an AI-built product needs a second, harder look.
We were promised the end of programmers. That is not what happened.
The scare stories have been around for years: AI would replace developers outright, or let managers describe an app and skip engineers entirely. What is actually happening is more interesting than either the doom or the hype.
The job is not disappearing — it is shifting shape. Junior work is moving toward AI-assisted specification and AI-guided implementation. Senior and architect-level work is moving toward quality assurance, requirements review and business-process design. Anecdotally, the level feeling the most pressure is the middle: the ground is shifting fastest under the people who used to own "just write the feature".
One side effect we did not expect: the specific language or stack matters less than it used to, since AI absorbs a lot of that translation work. It is a fair question whether that is entirely a good thing — but it is the direction things are moving, and it is why we hire and structure teams around judgment, not just syntax.
What the industry is actually reporting — not what it is promoting
At a recent Google Cloud Forum in Hungary, several enterprise engineering leaders shared numbers worth taking seriously precisely because they are not marketing slides.
- 50–75% of code at some organisations is now AI-generated — an encouraging headline number, undercut by reports that AI also generates far more churn in the codebase than a human author would, which makes the raw percentage less useful than it looks.
- AI-based support tools mean more engineering work, not less, once you factor in the access-control and data-protection problems of letting a language model answer literally any question it is asked.
- AI-driven sales and decision support can sound confident and still be wrong, especially on narrow datasets — and verifying that it is right is often more expensive than the tool was supposed to save.
“AI is good because it lets you find out much sooner that a POC has no point.”
A lead developer, at the same forum. Fair — though we are still deciding whether that saves money or just changes where it gets spent. None of this reads like a reason to stop using AI. It reads like a reason to stay skeptical about how it gets used.
Why "just vibe code it" is a bad bet for anything real
Vibe coding — describing what you want in plain language and letting AI produce the code, iterating conversationally until it feels right — is genuinely useful for small, well-documented, low-stakes tasks. It is a bad foundation for anything that is going to run your business. Here is why we push back on it as a strategy rather than a shortcut.
- It has no memory of the whole system. Once a task outgrows the context window, the AI starts forgetting decisions it made a few steps earlier — including decisions other parts of the code now depend on. The result looks finished and is not.
- It writes tests that agree with itself. If the same AI wrote the feature and its tests, you get confident-looking coverage that never challenged the implementation. Bugs sail straight through a green test suite.
- It is non-deterministic. The same prompt can produce different results on different days, which makes "it worked when I built it" a much weaker guarantee than it sounds.
- It hallucinates business logic with total confidence. No flags, no warnings — just a plausible-looking edge case that is quietly wrong, sitting in production, waiting for the one customer who hits it.
- Nobody on the team can explain what is in there. When the person who vibe-coded the feature moves on — or the codebase has simply never been read end to end by a human — every future change becomes a guess.
None of that is a reason to avoid AI-assisted development. It is a reason to treat AI output the way you would treat any junior contributor’s first draft: useful, fast, and not yet trustworthy without review.
Where we have seen it go wrong — and where we come in
This is the pattern we keep running into with new clients: a product got vibe-coded to market fast, it worked well enough to launch, and then it started breaking in ways nobody on the team could fully explain — because nobody had fully reviewed what the AI actually built. By the time real users are hitting the edge cases, the cost of finding out is a lot higher than the cost of reviewing it up front would have been.
If that is where you are right now — a live product built quickly with AI assistance that is starting to show cracks — that is exactly the kind of fire we are built to put out. We audit the codebase, work out what is actually happening under the hood versus what the spec claims, stabilise what is live, and put the right human review points back into the process. We would rather be the team you call before launch. We are also the team you call after.
Where AI has genuinely earned a seat in our workflow
- Grunt work and code completion. Repetitive edits, moving logic between files, keeping translation keys and UI constants aligned — AI handles this well, and it frees up real hours that used to disappear into busywork.
- PR co-review. This one surprised us. Paired with the right MCP and Git setup, AI catches things a tired human eye misses, in seconds. It can be nitpicky, and it sometimes comments on code that is not even part of the PR — but on balance it adds value rather than noise.
- Specs and planning. AI is good at the parts developers are historically weak at: turning a one-line ticket into a properly structured one, cleaning up grammar and structure, keeping documents organised. The catch is that it still needs a careful human read-through — and if the plan is headed for an agent to implement rather than an experienced person, errors compound fast.
- Debugging, as a last resort. Sometimes it spots something a person would have missed. Sometimes it just suggests restarting the service and spins in circles. We treat it as a life preserver here, not a co-pilot.
- Communication. A decent editor for tone, phrasing and spelling. It gets genuinely strange when both sides of a conversation are quietly running everything through AI first. We still insist the last word is a human’s.
The risks we take seriously
Hallucination and data exposure are the two we watch closest. Context windows are finite, model memory is finite, and the more AI-generated content flows through an organisation, the harder it becomes to tell which parts are grounded in fact. On the data side, the question is not whether an AI tool could leak sensitive information — it is building the access controls so that it structurally cannot.
The one we think about most gets the least airtime: AI agents are tuned to agree with you. Flattering is addictive — and left unchecked, it is a quiet way to outsource critical thinking to a system that is not built to have any.
What we actually use, tool by tool
We tested these ourselves, and our take is a working opinion, not a verdict.
- GitHub Copilot — a daily driver for close to three years, and worth the price for code completion. It is a co-coder, not an autonomous agent, and it does better when you hand it the relevant files rather than trusting it to find them.
- Claude — our strongest results for AI-first, complex-task work. The CLI setup and MCP configuration take more effort than Copilot, but the output quality has been the most convincing of everything we tried.
- Atlassian Rovo — genuinely strong for Jira and Confluence content once you find the right skill for it. As a PR and code-review tool, we would look at SonarQube, Qodo or CodeRabbit first and compare before committing.
- Google Antigravity — promising on paper (Gemini, GPT and Claude in one environment), but our testing ran into frequent availability issues and token limits that made it hard to trust for daily work. We cannot recommend it yet for regular development.
- Devin — a strong pick for teams newer to AI-assisted coding: easy setup, good defaults, useful chat integrations.
- Cursor — high quality and deep integrations, but priced in a way that adds up fast; better suited to teams not yet optimising with custom skills and workflows.
- MCPs and local models — where we see the next real shift: running embedding models and vector databases locally while keeping an LLM in the loop, so sensitive data has a far smaller chance of leaving the building. A scoped, on-prem-friendly assistant with no live access to systems it does not need is one of the more practical near-term paths for organisations serious about AI without gambling on security.
Why we are telling you this
We are not chasing the AI hype cycle, and we are not ignoring it either. We are the team that tests the tool before we recommend it, questions the vendor slide before we buy the licence, and reviews the AI-generated code before it ever gets near your customers.
If you are building AI-assisted software and want a partner who treats "the AI said it works" as a starting point rather than an answer — or if you already have a vibe-coded product in the wild that is starting to creak — we would like to talk.
Contact us