Using AI in software delivery without lowering the quality bar
By Ampersand Lab · 3 November 2026 · 6 min read
AI can shorten the path from idea to production, but only if the engineering discipline around it stays intact. Where it helps, where it does not, and the guardrails we put in place.
Most teams are now using AI coding tools in some form. The interesting question is no longer whether to use them, but how to use them so that you ship faster without quietly shipping worse software. The difference comes down to what you ask AI to do, and what you refuse to hand over.
Short version: use AI to reduce the cost of drafts and options, and keep humans accountable for decisions, reviews and production.
Where AI genuinely helps
- Exploring options early: sketching alternative designs and approaches so a decision is made on something concrete rather than a blank page
- Prototyping: turning an idea into a working demo quickly enough to test the assumption before the real build
- Scaffolding and boilerplate: generating the repetitive parts of a feature, test setup and configuration
- Refactoring and test coverage: proposing changes and tests that an engineer then checks
- Reading unfamiliar code and drafting documentation, which is often where new team members lose the most time
Where it needs the most care
AI output is fluent and confident whether it is right or wrong. That makes it good at producing plausible code and poor at telling you when it has missed a requirement, an edge case or a security consideration. The risk is not that it writes obviously broken code, but that it writes code that looks fine in review.
- Security-sensitive code such as authentication, authorisation and handling of personal data
- Infrastructure changes, where a small misconfiguration can be expensive or hard to reverse
- Anything involving your business rules, which the tool cannot know unless you tell it, and cannot verify
- Dependencies and licences, which generated code can introduce without anyone noticing
Guardrails that keep quality intact
Every change has an owner
Code is reviewed and owned by an engineer who can explain it, no matter how it was produced. If nobody on the team can defend a change, it does not merge.
Tests and pipelines decide, not confidence
Automated tests, linting, type checks and security scanning run on every change. They do not care whether a human or a tool wrote the code, which is exactly why they are useful. The faster you generate code, the more important a solid pipeline becomes.
Keep changes small
Small, reviewable increments are easier to check than large generated diffs. We would rather review ten small changes than one sprawling one.
Be careful with what you share
Decide up front what data and code may be sent to AI tools, and use enterprise settings where client data is involved. Secrets and personal information should never be pasted into a prompt.
What this means for you as a client or a buyer
If you are working with a team that uses AI, the useful questions are practical ones. Who reviews and owns the code? What do the automated checks cover? How is client data handled? A good partner will have specific answers, and will be happy to share them.
How we approach it
We use AI throughout delivery to move faster on prototypes, scaffolding, tests and analysis, while experienced engineers stay accountable for every decision and every line that ships. If you would like to talk about how that could apply to your project, get in touch.