We use AI coding tools on the projects we build. That includes the client work on Mandizo and our own internal product ManOps. The shorter answer to the question clients ask is: AI assists, humans direct and review. No change goes out without a developer reading it. This post explains what that means concretely, not in principle.
Why We Use AI Tools and What We Use Them For
AI coding tools are useful for specific tasks: drafting boilerplate, tracing data flow through a large codebase, generating test cases for known inputs, and identifying patterns in code that look like a known bug class. They are fast at those tasks and they make mistakes at those tasks. The speed is only worth something if a competent developer reviews the output before it becomes part of a codebase.
We do not use AI tools to generate a feature from a description and ship it unchanged. We use them as a faster first pass - a draft that a developer then reads, corrects, tests, and signs off. The developer is responsible for the output. The tool does not have context about the rest of the system, the security requirements, or what the user actually needs. The developer does.
What This Looks Like on Mandizo
Mandizo is a GST-ready invoice generator we built for a client, published with their permission. The product handles guest invoice editing, Firebase Auth for signed-in users, Supabase Postgres with row-level security on six tables, and automated security tests that run in CI on every change.
During the Mandizo build, AI tools helped draft migration SQL and the structure of RLS policies, and developers reviewed the SQL. That review was not perfect: a later audit found issues that needed emergency hotfixes on 28 September 2026, which is why the database attack tests below exist. The Firebase Auth to Supabase integration involved careful attention to identity types across the stack - the kind of edge case that a developer must trace manually rather than accept from an AI suggestion.
The 37 automated checks in CI (lint, typecheck, build and database attack tests) that run on every push and pull request to the Mandizo repository were written to verify the behaviour the developer expected, not the behaviour the AI assumed. That distinction matters: a test that passes because the AI wrote code and tests to agree with each other is not a security test. A test that checks whether a user can read another user's records via the Supabase anon key is.
What This Looks Like on ManOps
ManOps is our own internal product: a web app plus native iOS and Android apps on a shared versioned API. The build involved approximately 130 automated security-review runs and 52 sub-agent runs using AI coding tools, under human direction. Those runs were uneven: about 40% of one batch produced no usable verdict (rate limits, schema errors, empty output), and reviewers sometimes dismissed reachable issues as pre-existing, so we treat their output as leads for a developer to check, not as a verdict.
The test suite on ManOps covers 3,298 vitest tests on the web app and 2,266 Flutter tests on the native apps, verified on 9 October 2026. Those tests were not generated wholesale by AI and accepted. They were written to test specific behaviour, with AI assistance on the boilerplate and human review on the assertions. A test that checks the wrong thing is worse than no test.
The versioned REST API - 135 paths documented in OpenAPI - was designed by a developer who knew what the web app and the native apps needed. AI tools helped with drafting route handlers and reviewing request validation. The architecture decisions - which resources to version, how to handle auth tokens across platforms, how to structure the calls and push subsystem - were made by people.
Where Human Review Is Non-Negotiable
There are five points in our process where a human must review before anything proceeds.
- Security-affecting code. Any change that touches auth, RLS policies, API authorisation, secrets handling, or data access patterns is read by a developer end-to-end, not just at the changed line.
- Database migrations. Migrations that change the live database must be read by a developer before they are applied. ManOps has 44 migration files in the repository.
- Third-party integrations. Auth providers, payment hooks, push services and messaging platforms have their own failure modes that AI tools do not reliably surface. The Firebase Auth migration on Mandizo is the clearest example of why this matters.
- Test assertions. A test that asserts the wrong thing gives false confidence. Assertions on security-critical behaviour - can this user read that record? - are written and read by a developer.
- Shipping to production. Changes reach production through CI (type-check, lint, tests, build), and a post-deploy smoke check probes the live API after every production deployment.
What AI Tools Do Not Replace
AI tools do not replace understanding the system. A developer who does not understand how Supabase RLS interacts with a service-role client, or how Firebase Auth tokens reach the database, will not catch the class of error that matters most. The tool can point at a line. It cannot tell you whether the architecture around that line is sound.
AI tools do not replace accountability. When a client's data is exposed because of a bad security decision, the explanation cannot be "the AI wrote that." The developer who shipped it is responsible. That responsibility is what forces the review step to be real rather than ceremonial.
AI tools also do not replace real-device testing. We documented explicitly in ManOps which behaviours had been verified in tests and which had not been verified on a real phone: FCM ring behaviour under Android battery optimisation, APNs VoIP delivery from a serverless function, lock-screen answer behaviour. Those are runtime questions that code review - AI or human - cannot answer.
What Clients Should Ask Any Agency
If you are hiring a team to build your product, the question is not whether they use AI tools. Most do. The questions that matter are: who reviews the AI output before it becomes your codebase? What do the security checks cover? Where does human sign-off happen? And what is the process when something turns out to be wrong?
Vague answers to those questions - "we have a review process" without being able to describe it - are a warning sign. The how we work page describes our process in more detail. If you have a project in mind and want to understand how we would approach it, get in touch.
The Bigger Picture
AI-assisted engineering is not a risk to be avoided. It is a tool that changes the economics of building software: some things that took a day now take hours. The risk is treating that speed as a replacement for competence rather than a multiplier on it.
The products we point to - Mandizo and ManOps - show what the guardrails look like when the approach is working. Security tests that run on every commit. Migrations that have been read before they are applied. A test suite built on real assertions. And a clear record of what was and was not verified, so the next developer who works on the codebase knows exactly where the limits are.
Common questions
Do agencies that use AI coding tools still review the code?
At Zovintra, AI assists and humans direct and review: no change goes out without a developer reading it. Security-affecting code, database migrations, third-party integrations, test assertions and shipping to production all require human review before anything proceeds.
What should I ask an agency that uses AI coding tools?
Ask who reviews the AI output before it becomes your codebase, what the security checks cover, where human sign-off happens, and what the process is when something turns out to be wrong. Vague answers such as 'we have a review process' without detail are a warning sign.
How can I find out whether a team really reviews AI-written code?
Ask them to describe where sign-off happens and expect specifics rather than a general claim. Zovintra's how we work page describes its process in more detail, and you can get in touch to discuss how it would approach your project.
Sources
- Mandizo - Zovintra case page - Zovintra, accessed 19 Oct 2026
- ManOps - Zovintra case page - Zovintra, accessed 19 Oct 2026
