We build software faster than we did two years ago, and we are more careful about it, not less. This page explains what AI assisted development actually is, why it is not the same as letting a chatbot write your system, where it goes wrong, and what we do to keep it honest.

No pitch. Bring the thing you are thinking of building and we will tell you whether it is a good candidate.

On this page: What it is · Why now · What you gain · Where it goes wrong · How we do it · Jargon buster

What AI assisted development is (and what it is not)

AI assisted development is professional software engineering with an AI agent doing a large share of the typing. The engineer still decides what gets built, how it fits the rest of your systems, and whether the result is good enough to ship. The AI drafts code, refactors it, writes tests, reads old systems and explains them. The person owns the outcome.

Vibe coding is the other thing. You describe what you want, accept whatever comes back, and keep prompting until it looks like it works. Nobody reads the code. Nobody knows why it works, or whether it still works in the cases you did not try. It is a brilliant way to knock up a prototype in an afternoon and a terrible way to build something your business will lean on for the next five years.

The difference is not the tool. Both use the same models. The difference is whether there is an engineer in the loop who understands the code and is accountable for it.

Vibe coding is fine for things you will throw away. Anything that touches your customers, your money or your data needs someone who has read every line and will put their name to it.

Why it exists

Two things changed. The models became good enough to write working code across a whole project rather than a single function, and the tooling grew up around them: agents that read your codebase, run your tests, and work from written standards instead of a chat window.

That collapses the cost of the tedious part of software work. Scaffolding, plumbing, boilerplate, tests, documentation, the third variation of the same form. Most of a developer’s week used to go on that. What is left is the part that always mattered: understanding the business problem, designing the data properly, making the trade offs, and checking the result.

This is not a fad, and it is not going back in the box. It is the same shift that happened when compilers replaced hand written assembly and when frameworks replaced hand rolled plumbing. Each time, the work moved up a level and the people who insisted nothing had changed were still around a decade later, but nobody was hiring them to build new things.

A developer who is not using these tools in 2026 is choosing to be slower, at your expense, for no benefit to you. A developer who is using them without any of the discipline described further down is choosing to be faster, at your expense, and you will find out later.

What it means for a business of your size

For a company of five to a hundred people, this changes the maths on bespoke software more than any development in the last twenty years.

Things that were not worth building now are. The stock control tweak, the quoting tool, the report that three people rebuild in Excel every Monday. Jobs that never justified a developer’s time at the old price now do. Bespoke stops being something only larger firms can afford and becomes the sensible option for problems that off the shelf products almost fit but not quite.

You see working software sooner, and you can change your mind. Iterative delivery has always been the right way to build for a business that does not have a fixed specification, which is nearly every business. Now the gap between “we discussed it” and “here it is, try it” is days, not weeks. That is how you find out what you actually needed.

Less of the system lives in one person’s head. Documentation and tests used to be the first things cut when the budget got tight, because they were expensive. They are cheap now, so they get written. Your software is no longer held hostage by whoever built it.

Legacy stops being frightening. Reading a fifteen year old Access database or a VB application nobody dares touch, explaining what it does, and working out what to keep is something these tools do unusually well. The thing you have been avoiding is now a much smaller job.

The gap between you and the enterprise narrows. Integration between your systems, proper reporting, a customer portal: the kind of work that used to need a platform vendor’s budget is now within reach for a firm your size, built to fit how you actually work.

Where it goes wrong

We would be doing you a disservice if this page were all upside. These are the failure modes we see, and they are common.

It writes plausible code with total confidence. The model does not know when it is wrong. It will produce something that reads well, compiles, passes the happy path, and quietly mishandles the leap year, the refund, or the customer with two addresses. Bugs that look right are harder to find than bugs that look wrong.

It does what you asked, not what you meant. If the requirement is muddled, you now get the muddle implemented quickly and at scale. Speed does not fix a bad brief. It makes a bad brief more expensive to unpick.

Nobody understands the system. This is the new bodge. Code that works, that nobody in the business or the supplier can explain, is a spreadsheet with extra steps. When it breaks, and it will, you are back to square one with a bigger mess. We wrote a book about this pattern before AI made it easier.

Your code and data go somewhere. Every AI tool sends what it sees to someone’s servers. Which provider, under what terms, retained for how long, and does your customer data go with it? Most people using these tools cannot answer that. If you are in a regulated sector, that is not a detail.

It sprawls. Left to itself an agent will cheerfully add a fourth way of doing something the system already does three ways. Without standards it enforces, you get a codebase that grows fast and rots faster.

Some suppliers are vibe coding and billing you senior rates. The tools make it easy to look productive. Ask any developer or agency you are talking to who reads the code before it ships, what standards it has to meet, and what happens to your data. If the answers are vague, so is the work.

How we do it

None of what follows is clever. It is the ordinary discipline of a software team that has been building for regulated businesses for years, applied to a new and much faster way of writing code. The tools changed. The standard did not.

The AI works from written rules, the same as a new developer would. Every project has a written brief for the agent: how the system is structured, the conventions it follows, what it must never do. We use Claude Code, and it works from that document, not from whatever someone typed into a chat window that morning. Consistent instructions produce consistent code.

AI output has to pass the same gates as human code. Our coding standards are enforced by tooling, not by hoping. If a change does not meet them it does not build, whoever or whatever wrote it. Explicit, readable code that the next person can debug beats terse, clever code every time, and we have configured the tools to produce the former.

Every change is reviewed twice. First by a separate AI reviewer whose only job is to find fault with what the first one wrote. Then by a senior developer, who reads it. Not skims it. Reads it. Nothing reaches your system that a person at Maly has not understood and is not prepared to defend.

Security is reviewed, not assumed. What we build gets a security review before it goes live, with particular attention to the things AI generated code is prone to get wrong: input handling, authentication, what gets logged, and what gets exposed.

Your code and data are handled under ISO 27001. We are certified, and that certification covers how we use AI tools. We can tell you exactly which tools see your code, which providers are involved, under what terms, and what never leaves our environment. Client data does not get pasted into a public chatbot to save ten minutes.

You own it, and you could take it elsewhere. The code is yours, it is documented, it is tested, and it is written to be read. That is the point of doing this properly. If we have done our job you should never need to move it, but you could.

The short version: we use the tools to go faster on the parts that do not need judgement, so we can spend more of your budget on the parts that do.

Jargon buster

What is AI assisted development?

AI assisted development is software engineering where an AI tool writes much of the code under the direction of a professional developer. The developer sets the standards, reviews every change and remains accountable for the result. It speeds up the routine parts of building software without removing human judgement from the parts that matter.

What is vibe coding?

Vibe coding is building software by describing what you want to an AI, accepting whatever it produces, and prompting again until it appears to work, without anyone reading or understanding the code. It is quick for prototypes and risky for anything a business depends on, because nobody can explain or safely change the result.

What is the difference between AI assisted development and vibe coding?

Both use the same AI models. The difference is whether a qualified engineer reads, tests and takes responsibility for the code. In AI assisted development the AI is a fast assistant working to written standards under review. In vibe coding the AI is the developer, and the output is trusted rather than checked.

What is an AI coding agent?

An AI coding agent is a tool that can read an existing codebase, make changes across many files, run tests and follow written project instructions, rather than answering one question at a time in a chat window. Claude Code is an example. Agents make AI assisted development practical on real systems rather than toy examples.

What is an AI hallucination in software?

A hallucination is when an AI produces something plausible but wrong: code that calls a function which does not exist, or handles an edge case incorrectly while looking correct. AI generated code is prone to this, which is why it must be reviewed and tested by a person rather than trusted because it compiles.

What does human in the loop mean?

Human in the loop means a person checks and approves what an automated system produces before it takes effect. In software development it means a developer reviews AI written code before it is merged or released. It is the single practice that separates responsible use of AI tools from hoping for the best.

Is AI generated code secure?

Not automatically. AI tools reproduce common patterns, including insecure ones, and can mishandle input validation, authentication and logging. AI generated code should get the same security review as any other code, with extra attention to those areas. Where your code and data are sent while using the tools also matters, especially in regulated sectors.

Who owns code written with AI?

In a normal bespoke software contract the client owns the code, however it was produced. The practical question is whether it is documented and readable enough for you to actually use that ownership. Ask your supplier whether another developer could take the code over, and what happens to your data when their AI tools process it.

Is AI assisted development cheaper?

Usually, for the routine share of the work: scaffolding, tests, documentation and standard features cost far less than they did. The judgement share, understanding the problem, designing the data and reviewing the result, costs about the same. The overall saving depends on how much of your project is routine, which is something a good supplier will tell you honestly.

Got something you have been putting off building?

Thirty minutes, no charge, no pitch. Tell us what the problem is and we will tell you honestly whether it is a good candidate for bespoke software, whether AI assisted development changes the answer, and roughly what it would take. If the right answer is a product you can buy, we will say so.

hello@maly.co.uk | 01473 934672 | Ipswich, Suffolk

Scroll to Top