"The AI wrote it" is a poor answer when a client reports a bug. They hired your team. Your team shipped the code.
AI coding agents can produce a working demo in minutes. The temptation is to keep prompting until everything looks right, then call the job done. But a screen share tells you little about what happens when permissions fail or requirements change.
At Fireplace Digital, we use agents to write code, draft specifications, and help with review. We still have to explain the decisions and take responsibility for what reaches production.
The quick read
AI delivery key takeaways
- Approve a written specification and plan before agents start implementation.
- Keep pull requests small enough to review. Run tests before human review.
- Require human sign-off for authentication, payments, personal data, infrastructure, and migrations.
- Name the person responsible for the release.
What vibe-coding costs
Vibe-coding often means prompting until the demo works, without checking how the code works or whether it meets the brief. The first draft arrives quickly. Someone still has to check its assumptions.
An agent will fill gaps in a brief. Unless a person reviews those gaps, the agent's assumptions can become software behaviour that the client never agreed to. The team then has to find and undo decisions that nobody remembers making.
Large pull requests make that job harder. A reviewer faced with thousands of generated lines has to work out what changed, why it changed, and whether it belongs in the project. The time saved writing the code can disappear during review.
Keeping decisions only in chat creates a similar problem. When the conversation has scrolled away, the next engineer has code but little explanation. We need a written record that the team can return to.
Spec first, code second
Before implementation, we turn the brief into a specification that covers:
- Outcomes: what the user and the business need from the work.
- Scope: what we will build and what we have agreed to leave out.
- Constraints: the stack, compliance requirements, performance limits, and integrations we must work with.
- Prior decisions: architecture choices the team has already settled.
- Tasks: changes small enough for someone to review.
- Verification: the tests, acceptance checks, and manual checks needed to approve each task.
AI can help turn discovery notes into a first draft. It can suggest edge cases and rewrite vague requirements into statements we can test. The client and lead engineer approve the specification before implementation starts.
We keep the specification under version control so the team can see what changed and why. Recording it in a file also lets us use it with different coding agents. The process does not depend on a particular tool or model.
Telling an agent to ask before editing is only an instruction. We need an approval step that stops implementation until a person has agreed to the work.
The gates we run
1. Spec gate
We check that the outcomes, scope, and acceptance criteria are written and approved. If the brief is still unclear, we resolve it with the client before asking an agent to implement it. Otherwise, we are asking the agent to make product decisions on the client's behalf.
2. Plan gate
For non-trivial work, we require a short plan. It names the affected parts of the system, data changes, risks, and tasks in the order we expect to complete them.
An agent can propose architecture options. A senior engineer chooses the approach and checks it against the project's constraints. We need to understand decisions that will be expensive to reverse.
3. Implementation slices
Agents work against the approved specification in small pull requests, with one feature slice per request. We keep each pull request small enough to review in one sitting. Tests go in with the code, and automated checks must pass before human review.
The engineer who ran the agent is responsible for the code they submit. They need to understand the change well enough to explain it to the reviewer.
4. Review gate
We review AI-authored code to the same standard as code a person wrote. The following changes require human sign-off, even when automated review finds no problems:
- Authentication and authorisation
- Payments and billing
- Anything that uses personal data
- Infrastructure and deployment configuration
- Database migrations
AI can flag missing validation, risky queries, or changes that do not match the specification. A person must still decide whether to approve the work.
5. Release accountability
A named person is responsible for the release and decides whether the software is ready to ship. Models can draft changelogs, operating instructions, and client updates. The person responsible checks those documents and signs off on the release.
Where AI earns its keep in a studio
We use agents for work that would otherwise take up engineering time across a project:
- Turning discovery notes into draft specifications and lists of edge cases
- Writing routine code to create, read, update, and delete records against an agreed contract
- Drafting tests for expected behaviour
- Preparing migration notes, release summaries, and weekly client updates
- Checking for defects before a senior engineer reviews the code
An engineer still has to decide which tests matter, including the failures the team needs to check. Generated tests are useful only if they check the behaviour we agreed to build.
Product and architecture decisions, along with security approvals, require human judgement. So do conversations with clients about what is ready to ship this week and what needs more work.
What Fireplace Digital clients can expect
Our work covers technical strategy, design, and application development, including AI integrations and workflow automation. Clients can see what we agreed to build, how we will check it, and who is responsible.
When requirements change, we update the specification and identify the affected tasks. An agent can then revise those parts of the system, and the team reviews them again. We can trace the change back to an agreed requirement.
Clients also know who approved the plan and who signed off on the release. That responsibility stays with us regardless of how much code an agent wrote.
If a vendor offers to build a whole product without supervision, ask to see their approval and review process. Find out who will read the generated code and who will handle a problem after launch.
Before you give agents more control
Check that the team can meet each of these conditions:
- The specification is written, versioned, and approved by a person and, where needed, the client.
- The plan records stack constraints and decisions the agent must not reopen.
- Each pull request is small enough to review in one sitting.
- Automated tests run before human review.
- Authentication, payments, personal data, infrastructure, and migrations require human sign-off.
- A named person is responsible for approving the merge and release.
Resolve any missing steps before giving agents more control over the project.