Most conversations about AI coding tools are comparisons. Which agent writes better code, which one handles a large repository, which one is cheaper per seat, which one the team prefers. These are reasonable questions, and the answers change every few months as the products evolve.
The comparison also misses something. When teams switch tools and report that little improved, the reason is rarely that they picked the wrong one. It is that the tool was never the main variable. The outcome of agent-assisted delivery depends far more on the system around the tool: what the agent is told, what it may touch, what must pass before its work is accepted and who reviews it. That system is the same whichever agent sits in the middle.
This part explains how CloudNala thinks about coding tools, and why we treat them as interchangeable components inside a delivery system rather than as the delivery system itself.
This article describes CloudNala's approach. Tool names are examples of roles, not a ranking, and product capabilities change quickly.
The tools have converged on similar shapes
The main coding agents now share a broadly similar shape, even if they start from different places. Anthropic's Claude Code started in the terminal. OpenAI's Codex spans a command-line tool, editor integrations and cloud tasks. GitHub Copilot started in the editor and has grown into a repository-level agent; in early 2026 GitHub also made Claude and Codex available as coding agents inside Copilot, so a single team can now choose between agents from within one surface.
For a delivery team, that convergence is useful. It means the question "which agent?" is less consequential than it was, and the question "what happens around the agent?" becomes the one that differentiates teams.
We covered the earlier generation of tools in GitHub Copilot, Amazon Q and Kiro. This article deliberately avoids repeating a feature comparison, because any comparison written today will be out of date by the time most readers act on it.
The delivery system around the tool
A coding agent receives guidance, operates inside boundaries, and produces changes that are checked and reviewed. Each of those layers is independent of the agent.
Guides tell the agent what is wanted and how the codebase works: the specification or issue, repository instructions such as an AGENTS.md file, architecture decisions, coding standards and examples. A well-guided agent makes fewer avoidable mistakes.
Boundaries constrain what the agent may read, change and run: which repositories, which branches, which secrets are excluded, which commands are allowed, whether it may reach the network.
Checks test what the agent produced: build, tests, linters, security scanners, architecture rules.
Human review decides whether the change does what was intended, whether its trade-offs are acceptable and whether it should merge.
Production signals feed back into the guides, so that a mistake seen twice becomes a rule rather than a recurring review comment.
Swap the agent in the middle and the layers around it stay the same. If the layers do not exist, swapping agents will not fix the outcome. This is the practical version of the argument in our Coding Agent Harness series and in Harness engineering: the workshop around the agent.
Six questions that apply to every tool
When we set up agent-assisted work on a repository, whether our own or a client's, we answer six questions once, and the answers apply to whichever tool the team uses.
Where does work start? In the terminal, in the editor, or from an issue assigned to an agent. Each entry point has a different audit trail. Starting from a tracked issue gives the clearest record of why a change was made.
What may the agent read? The repository in scope, with secrets, credentials and unrelated client material excluded. If a tool cannot be scoped this way, it does not run on that repository.
What may it change? Branches, never the main branch directly. Infrastructure and production configuration only through the same pipeline as human changes.
What must pass? The same build, tests and scanners as any human change. Agent work gets no exemptions, and a failing check is never bypassed to save time.
Who approves? A named reviewer who understands the intent. AI review tools can help as a first pass; they do not replace the approval.
What is recorded? The prompt or issue, the diff, the check results and the approval. This record is what lets us answer, months later, why a change was made and who accepted it.
The answers in the diagram are our defaults, not universal rules. A client's policies may be stricter, and when they are, theirs apply.
Why we use more than one tool
We do not standardise on a single agent, for three reasons. First, the tools have different strengths for different tasks, such as long refactors in a terminal session, quick edits inside the editor, or issue-driven changes that run in the background. Second, client environments differ: some clients have approved one tool and not another, and we work within their approvals. Third, the market is moving quickly, and a delivery system that depends on one vendor's specific behaviour is fragile.
What we do standardise is the system: the repository instructions, the boundaries, the checks, the review and the record. That is what makes switching tools cheap and safe.
What this means for buying decisions
For organisations deciding which coding tools to license, the implication is to spend less time on the comparison and more time on the system.
- Write the repository instructions first. A team that cannot explain its own codebase conventions to a new human engineer will not explain them to an agent.
- Decide boundaries before rollout. Which repositories, which data, which actions. These decisions belong to the organisation, not the vendor.
- Make checks fast and local. Agents correct themselves well when a check fails clearly and quickly. Slow or vague checks waste both agent time and review time.
- Measure outcomes, not usage. Accepted changes, review time, escaped defects and rework tell you whether the system works. Seat utilisation tells you only that people opened the tool.
- Keep the option to switch. Avoid workflows that only one tool can run. The licence decision should be revisable every year.
We discuss the cost side of these decisions in AI coding costs are not just model prices.
The point of view
Coding agents are components, and increasingly interchangeable ones. The durable advantage lies in the delivery system around them: clear guides, enforced boundaries, fast checks, accountable review and a record of every change. Build that system once, and the choice of agent becomes a reversible, lower-stakes decision.
Next: Part 4, Turning research into a reusable advisory asset. All parts are on the series page.
Background reading: GitHub changelog, "Claude and Codex are now available in public preview on GitHub", 4 February 2026.
How CloudNala can help
We help engineering teams set up agent-assisted delivery that does not depend on a single tool: repository instructions, access boundaries, check pipelines, review rules and change records. The result is a short operating standard and a configured repository that any approved coding agent can work inside safely.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to CloudNala or write to us at consult@cloudnala.co.za