AI coding agents can inspect a repository, propose changes, run tools and prepare a pull request. For a business commissioning custom software, the useful question is whether that work survives review, testing and use in the real workflow.
Custom software development with AI coding agents still needs a developer who owns the result. A faster first draft has little value if it creates more review work, breaks an integration or leaves the next maintainer unable to explain the change.
This guide focuses on the delivery process: which tasks to delegate, what evidence to ask for and how to decide whether AI assistance is helping. For application permissions and oversight, see the separate agentic AI governance checklist.
What changes when an agent can work in a codebase?
An assistant that suggests a function is different from an agent that can inspect files, edit several modules and run commands. The latter needs an environment, instructions, tool permissions and a stopping point. OpenAI’s Agents API announcement describes this surrounding harness for multi-step work; it does not remove the need to decide what the agent should be allowed to do.
The same assignment should be understandable to a human engineer. “Improve the application” is too broad. “Add a date filter to the existing report, preserve the current export format and demonstrate that permissions still apply” gives a reviewer something concrete to accept or reject.
Choose a small task with an observable result
Good starting points include explaining an unfamiliar module, drafting tests for an agreed behaviour, updating documentation or preparing a small change in an isolated branch. A task becomes harder to supervise when it combines unclear requirements, sensitive data, a schema migration and a production release.
Before work starts, record:
- The user outcome: who needs the change and which task it should improve.
- Existing behaviour to preserve: permissions, exports, integrations, error handling and business rules.
- Allowed scope: files, dependencies and systems the agent may touch.
- Acceptance examples: an ordinary case, an invalid input and a case the user must not be allowed to access.
- Completion evidence: a reviewable diff, relevant checks and a working demonstration.
A practical example: extending a supplier catalogue
Kitek provides ongoing engineering for Metal100’s catalogue, search, supplier enquiry and tender workflows. This is established software work; it is not a claim that Metal100 uses AI coding agents.
Consider a proposed change to that kind of system: adding a supplier filter. An agent could draft the query and interface changes, but acceptance would depend on details beyond whether a dropdown appears. Does the filter respect the selected region? Does pagination preserve it? Do search results and supplier enquiries still point to the correct records? Does the query remain usable with a realistic catalogue?
Those questions are the engineering context a business must retain. They also make a useful bounded pilot: one change, known acceptance examples and a developer who understands the existing workflow.
Review the behaviour as well as the generated code
A test suite can pass while a requirement is misunderstood. Tests proposed by the same agent may repeat its assumptions, so the reviewer should compare them with the original acceptance examples and inspect the running application.
Review should cover the requirement, affected data, permissions, dependency changes and operational impact. A migration needs a migration and recovery plan. A new integration needs failure handling. A new package needs a reason to be introduced and a check of its suitability and licence.
First-hand observation
Our own website keeps managed content and custom code in Git. The release process validates the committed source, backs up production, checks the published pages and enquiry flow, and supports rollback if release checks fail. That gives us concrete evidence to inspect before accepting a change. AI assistance should feed into that review process rather than become a separate route around it.
Measure the whole change, not the drafting speed
Compare similar tasks using the total effort from an agreed requirement to an accepted release. Include implementation, review, corrections, testing and follow-up defects. Keep the task size and reviewer experience in view; one unusually easy ticket is not a reliable productivity benchmark.
- How much reviewer time did the change require?
- How many assumptions had to be corrected?
- Did the checks exercise the business behaviour, including failures?
- Was additional maintenance work created after release?
- Can another engineer explain and support the result?
Expand agent access only when the evidence supports it. If the review burden rises, narrow the task or improve the context before adding more automation. Australia’s software development guidance includes AI-assisted work within the software development lifecycle: normal engineering accountability still applies.
What to ask a software partner
Ask who reviews agent-assisted changes, which data and credentials the tools can access, how the work is tested and who maintains it after launch. Ask to see the acceptance evidence for a representative change. An answer about a model or subscription alone does not describe a delivery process.
Kitek’s custom software development service starts with the workflow, users and constraints. If the application already needs intervention, begin with software rescue and takeover so that access, release controls and the existing behaviour are understood before development accelerates.