AI writes the code. Someone has to own it.
AI can write almost all of your code. It still can't be accountable for it. How we build with AI at Oxbit — planned before anything is written, reviewed line by line, and never handed over as a black box.
AI has changed software development
AI is everywhere right now. It’s being jammed into our phones, our computers, every service or subscription we have whether we like it or not. You probably notice it most in your boss’s PowerPoint presentations, or in all your co-workers’ emails that have that slightly weird tone (can we seriously not write a message by ourselves anymore?). We’re constantly being bombarded about the latest AI advancements in the news, or hearing about another new data centre cropping up somewhere close by. There’s no escaping AI in some shape or form.
AI writes code. It doesn’t own it.
You’d expect software development to also be heavily impacted by AI, right? Well, yeah, you’d be correct. But like everything, there are levels to it. At a bare minimum you’ve most likely dabbled with ChatGPT or Claude to learn about a new topic, or get its opinion on how to tackle a problem you might be facing (I think it’s legit fantastic for this). But in terms of software development, it goes so much deeper than that.
AI is an absolute beast at writing code. You may have heard of agents and this term ‘agentic engineering’. This is how we write code now, for better or worse. The important distinction here however, is that while AI can certainly write code, it cannot own it. AI cannot be held accountable for the code it writes, and it cannot fully understand the context in which that code is being used. This is where human oversight comes in.
How we actually build at Oxbit
I came to software after a decade as an advanced life support paramedic. That job teaches you something that applies directly here: on the things that actually matter, you don’t improvise. You follow the protocol, you check your work, and afterwards someone’s name is on it. Nobody gets to say the machine did it.
So before any code gets written, I plan. I think through the main architecture decisions up front: the framework, the language, the database, and all the pieces that hang off it like email sending, contact forms, rate limiting etc. I want to know how the whole thing fits together before we start building it, not discover it as we go.
That planning habit runs right through to how I work with AI. I don’t routinely let agents run on autopilot. Every task starts in plan mode: the agent proposes how it intends to build something, and I read that plan and change it before a single line of code is written. Then the agent executes, I review the actual changes, and I commit them in steps, checking as I go that it’s done what I asked and not what it guessed. If something isn’t clear, I get the AI to explain what a piece of code does and why it built it that way, until I understand it. It’s a bit slower than just letting the machine run, but I prefer it that way, and so far it hasn’t let me down.
There are two things I never hand to AI unchecked: anything to do with security, and anything that touches the database structure. When it comes to authentication (are you who you say you are?) and authorization (are you allowed to access that?), I make sure I understand every line myself. Having blind faith in an AI to get this right every time is just not a risk I’m comfortable taking. Database changes get the same treatment, because a mistake there is one of the few things that’s genuinely expensive to fix later. Those are the parts where close enough isn’t good enough, so they don’t get delegated.
Here’s what this process buys you in practice. On a recent project, we’d built a lot of the website and were partway through when the client decided to switch designers and rebuild the entire look of it. This is the kind of mid-project U-turn that can potentially mean scrapping a lot of code and starting again. Thankfully this time it didn’t. Because of how it had been built from the start, the new design came down to adjusting pieces we already had: a big change to look at perhaps, but not a big change underneath. The client got the site they wanted without paying to build it twice.
And perhaps most importantly, before anything goes live, it gets checked (by a human). Our automated tests confirm a new feature hasn’t quietly broken something that was already working. We QA it by hand as well, both locally and on a private preview version that mirrors the live site exactly, so we see precisely what you’ll see before you (or anyone else) ever do. If something does slip through, we can roll it back in minutes, not days.
Vibe coding: it’s all about the vibes (not really)
You’ve probably seen the ads: cheap websites, built in days. Amazing, right? But look a little closer and something feels off. Why do they all look the same? The same black backgrounds, the same layouts, the same neon purple and green text. The answer is ✨vibe coding✨: directing an AI to write all of your code without understanding how any of it actually works. The bar has dropped so far that anyone with a $30 Claude or Codex subscription can do it.
It’s like getting a house built by someone who’s never learned construction but owns a very good set of power tools. The walls go up fast, it looks great in photos, and you move in happy. The problem shows up in winter, when you find there’s no insulation in the walls, the wiring isn’t to code, and nobody (including the builder) can tell you what’s behind the plasterboard. It’s not that they did nothing. It’s that no one understands what was built, so the moment something goes wrong, there’s no one who can safely open it up and fix it.
You can absolutely go this route — some businesses do. Just understand what you’re actually paying for, because eventually something does go wrong. What happens when it breaks, or when you want to add a feature, or a dependency needs updating to keep things running? Who fixes it then? The answer is: someone who understands the code. So the real question is whether you’d trust one of your most important business assets to a person who doesn’t actually understand how it works under the hood.
So what does this mean for you?
We know how the code works. We know how all the puzzle pieces fit together, and what to do when any of those pieces change shape (this is basically guaranteed). If you want to add a new feature, we can do it. If some dependency goes out of date and needs upgrading to keep things running, no problem. If you want to take your website to another developer who can pick it up and understand it, that’s simple (no hard feelings).
You don’t have to worry about your website being a black box that only the original developer can understand. We build with AI, but we own the code. We understand it, and we can maintain it for you. That leaves you free to get on with the part you’re actually good at: running your business.
If you’re weighing up a cheap AI-built site and wondering who fixes it when it breaks, we should talk.