Coding Agent
Set up so your developers go faster without shipping code nobody read.
What is coding agent?
A coding agent writes, edits and tests code alongside your developers inside your repositories, working from a task description and leaving every change to be reviewed by a person before it reaches production.
Coding assistants genuinely work now. They are fastest on the boring end of the job, which is where most development time actually goes: tests, boilerplate, migrations, moving a pattern across forty files.
They are least reliable exactly where a system is unusual, which tends to be the part of your codebase that matters most.
Deploying one well is mostly about boundaries. Which repositories it can touch, what it may never change without a human, and how you find out whether it sped anything up rather than just produced more code to review.
Why nothing merges without review
Duara sets up coding agents from Nairobi for development teams, and we use them ourselves daily, which is the only reason we have opinions worth anything on this.
We will not set one up to merge without review. Review is where the productivity claim survives or collapses, and a team that automates it has not become faster, it has moved the cost to whoever debugs production in six months.
Who this is for
- Developers spend time on boilerplate
- Test coverage is thin because writing tests is dull
- Your team is small relative to the backlog
- Assistants are already in use with no rules around them
Industries we serve
- Software companies
- Fintech engineering teams
- Internal IT departments
- Digital agencies
- Startups
- Banking technology
Problems this solves
These describe teams where the tooling exists but nobody has decided how it should be used.
- Time lost to boilerplate. Skilled developers spend their day on migrations, tests and repetitive edits rather than on the difficult parts.
- Assistants used without rules. Developers are already pasting code into public tools, and nobody has decided what may leave the building.
- Review becoming the bottleneck. More code is generated than the team can review, so review quality quietly drops.
- No idea whether it helps. Everybody believes the assistant makes them faster and nobody has measured anything.
What we deliver
Coding agents configured inside your repositories with explicit boundaries, review requirements that hold, protection for sensitive code, and measurement of whether delivery actually improved.
Coding agents configured for your repositories
Boundaries on what may be changed without a human
Review requirements that cannot be bypassed
Protection for credentials and sensitive code paths
Team practice and prompting conventions
Measurement of delivery before and after
Features
- Review is never automated away. A person approves every change. This is the constraint that keeps the productivity claim honest.
- Repository boundaries. Which code an agent may touch is explicit, and sensitive paths are excluded rather than trusted.
- Credentials kept out. Secrets and keys are structurally unavailable to the agent rather than protected by instruction.
- Measured, not assumed. We record delivery before and after, because the alternative is a team that feels faster with no evidence.
- Conventions the team agrees. How tasks are described to the agent is standardised, since inconsistent prompting produces inconsistent code.
Benefits
- The dull work goes faster. Tests, boilerplate and mechanical refactors are where these tools are genuinely strong.
- Test coverage improves. Tests get written when writing them stops being tedious, which is the most common real gain we see.
- Shadow usage stops. Developers using public tools with your code is replaced by a sanctioned route with actual boundaries.
- You find out the truth. Measurement tells you where it helped and where it did not, which is worth knowing either way.
Technologies we use
- Repository integration. Agents working inside your version control with branch and access rules enforced.
- Access scoping. Explicit limits on which repositories and paths an agent may read or modify.
- Secret exclusion. Credentials kept structurally out of reach rather than protected by instruction.
- Review gating. Pipeline rules ensuring no agent change merges without human approval.
- Delivery measurement. Recording throughput and defect rates before and after so the effect is known rather than believed.
The honest limitation is that these tools are weakest on unusual systems, and unusual is exactly what most established codebases are.
How the process works, step by step
Setting up coding agents properly takes three to five weeks, most of which is boundaries and team practice rather than installation.
-
Step 1
Free team review
We look at your stack, repository structure and where your developers actually lose time.
-
Step 2
Boundaries set
Repository access, excluded paths and review requirements are agreed and enforced technically.
-
Step 3
Baseline recorded
Current delivery and defect rates are measured, because without this no later claim means anything.
-
Step 4
Team practice
Developers work with the agent on real tasks, and conventions emerge from that rather than from a document.
-
Step 5
Measured review
We compare against the baseline and report honestly where it helped and where it did not.
Quality assurance and how we work
The commitments attached to putting an agent inside your codebase.
- We will not remove human review. A team that automates review has not become faster. It has moved the cost to whoever debugs production later.
- We measure before and after. A baseline is recorded first, because a team that feels faster without evidence is the normal outcome of these tools.
- Credentials are structurally excluded. Secrets are kept out of reach by configuration rather than by instructing the agent to avoid them.
- Your code does not train public models. Repository access is configured so your codebase is never used as training data.
- We report where it did not help. If the measurement shows no gain on part of your work, we say so rather than presenting the good half.
Frequently asked questions about coding agent
Will it replace our developers?
No. It is fastest on boilerplate and tests and least reliable where a system is unusual, which is the part that needs your developers most.
Can it merge code without review?
We will not set that up. Review is where the productivity claim survives or collapses.
Why refuse that so firmly?
Because a team that automates review has not become faster. It has moved the cost to whoever debugs production in six months.
Is our code sent anywhere?
Access is configured so your codebase is never used as training data, and enterprise arrangements keep it out of public model training.
What about our credentials?
Kept structurally out of reach by configuration rather than by instructing the agent to avoid them.
Does it work on legacy code?
Less well, and we say so. These tools are weakest on unusual systems, and established codebases are usually unusual.
Which languages does it handle?
The common ones well. We test on your actual repositories during the review rather than promising from a list.
How do we know it helped?
We record a baseline first and compare. Without that, the normal outcome is a team that feels faster with no evidence.
What if it did not help?
We report that. If the measurement shows no gain on part of your work, saying so is more useful than presenting the good half.
Will it increase technical debt?
It can. Generating code faster makes it easier to accumulate, which is one reason review stays mandatory.
Can it write tests?
Yes, and this is usually the largest real gain, because tests get written when writing them stops being tedious.
How long before our developers are working with it?
Three to five weeks, most of it boundaries and team practice rather than installation.
Our developers already use these tools.
Then the work is putting boundaries around what is already happening, which is the more urgent version of this.
Can it access production systems?
No. Agents work in repositories and development environments, never against production.
Does it work with our CI pipeline?
Yes, and review gating is enforced in the pipeline rather than left to convention.
Can juniors use it safely?
With review, yes, though we flag the risk that juniors accept generated code they could not have written and would not spot errors in.
Will it follow our coding standards?
Where they are documented and configured, largely. Undocumented standards are the first thing this exposes.
Can it handle large refactors?
Mechanical ones across many files, yes, and this is a genuine strength. Architectural change is not.
Do you use these yourselves?
Yes, daily, which is the only reason our opinions on the limits are worth anything.
What does a coding agent cost to run?
Developer seats and usage determine it, quoted against your team size before anything is agreed.
Glossary of terms
Terms used around coding agents.
- Code review
- A person reading a change before it is merged, which is the control this setup preserves.
- Boilerplate
- Repetitive code that must exist but requires little thought, where these tools are strongest.
- Repository scope
- The set of code an agent is permitted to read or modify.
- Merge gate
- A pipeline rule preventing a change from merging until conditions are met.
- Technical debt
- Shortcuts that make future change slower, which generating code faster can quietly increase.
- Baseline
- Delivery measured before a change, without which any later improvement claim is unverifiable.
Related services in AI Agents
Talk to us about coding agent
Ask your developers where their week actually goes. If the answer is tests and boilerplate, this is worth setting up properly.
Start your project