AI governance in software development: autonomy limits and who approves

Published 9 October 2026 · updated 12 October 2026

AI governance in software development is the set of rules that defines what coding agents may do without prior approval, what needs a person's sign-off first, and who answers for the code that goes to production.

This page is a practical guide. How Ithaca applies it, with human supervision and every session logged, is on the page about the agentic development platform.

Who this page is for

For CTOs, CIOs and CISOs who have already approved coding assistants in a pilot and now need AI governance that holds up in an audit, and not only on a slide. It also works as a starting point for anyone who needs a short set of practices for agents that write and change code.

What AI governance means in software development

In software development, AI governance does not start with a generic "responsible use" policy. It starts with four questions an auditor asks in concrete terms:

• Which coding agents exist, and which systems do they work on?
• How far does each one go on its own, and what needs human approval?
• What is recorded from each session: the request, the steps, the model, the cost, the result and the authorship?
• Who reads the code before it goes into production?

If the answer to any of them is "we don't know," the organization has the intent but not yet operational governance for coding agents. A policy without a record rarely holds up in an audit.

Coding agent governance: what changes when agents write code

A code-completion assistant speeds up the person who is already typing. A coding agent takes over parts of the execution: it reads the repository, proposes changes, opens pull requests and runs tests. The question is no longer only "is the suggestion good?" but also "who asked, what did the agent do, with which model, at what cost, and who approved it?"

Without answers, a company piles up autonomy without limits, sessions without a trail and speed without measurement. Without measurement, the gain has no number and model spend stays off the books. Governance for coding agents treats these effects as engineering problems: the goal is to scale use with control and to measure what improved.

Dan Shapiro's scale of coding autonomy, in "The Five Levels: from Spicy Autocomplete to the Dark Factory" (23 January 2026), puts the dark factory at level 5, "a black box that turns specs into software." Ithaca operates at level 4, with people reading what goes to production. The argument is on What a dark factory is, and why the platform is not one.

A practical implementation checklist

Use this as a starting point. It does not need to be complete on day one; it needs to exist and to evolve with real data from a pilot.

1. Autonomy limits

For each type of system and level of criticality, define what the agent does without prior approval and what needs a person's sign-off before it runs. Reading what goes to production applies to everything. Generating a test in a low-risk repository is not the same as changing a payment service. Write the limit down and revisit it after the pilot, widening autonomy by documented decision, based on the pilot's data.

For how the industry labels this lifecycle, see AI-native SDLC vs. agentic SDLC vs. AWS AI-DLC.

2. Session record

Every coding-agent session has to leave a trail. These are the minimum fields, and the reason an auditor asks for each one:

• Request: what was asked, and by whom (reconstructs the intent).
• Steps: what the agent did, in order (shows the path, not only the outcome).
• Model: which model ran each step (ties the decision to the provider policy).
• Cost: what the session cost (lets you weigh the gain against the spend).
• Result: what came out, whether a diff, a pull request or a rejection (closes the loop).
• Authorship: who asked, who executed, who supervised (answers "who is accountable?").

Fictitious example. Request: fix the CPF (Brazilian taxpayer ID) check on the sign-up form, requested by Ana, tech lead. Steps: read the sign-up service, propose a patch to the tests, open PR #4821. Model: the provider set in the client's policy. Cost: R$4.20 for the session. Result: PR approved after review. Authorship: Ana asked; the agent executed; Bruno supervised and approved.

Without these fields, the risk committee asks and the team answers from memory. With them, the answer is a trail. The technical detail is in Observability for coding agents.

3. Human reading before production

Without human reading, nobody on the team knows the code when it needs maintenance. Require a person to read what goes to production. How deep the review goes depends on criticality; the reading itself stays. That is what keeps the operation at level 4 and out of the dark factory.

4. Model policy

Put in writing the provider, region and contract for the models, and what may be sent to the provider during inference. That policy belongs to the company, not to the tool vendor.

5. Cost and measurement

Without cost per session, there is no way to know whether the delivery gain pays for the model usage. Record tokens or cost per session, per model and per type of task.

6. Authorship and accountability

Every change needs an identifiable human author: who asked, who supervised, who approved it for production. In regulated sectors, that chain tends to be among the first things an audit asks for.

Suggested order

Start by mapping where AI is already in use in engineering. Then put the session record and human reading in place for the pilot. Only after that, widen autonomy and scope. The reverse path, broad autonomy with no trail, is what tends to stall the conversation with risk and compliance.

How this maps to market frameworks

These are the references the market uses to organize AI governance. Compliance with each one belongs to the organization that adopts it. The agentic development platform helps produce the record and the supervision these frameworks describe.

• NIST AI Risk Management Framework (AI RMF 1.0). A voluntary US framework (January 2023), organized into four functions: Govern, Map, Measure and Manage. Its generative AI profile (NIST AI 600-1, July 2024) proposes governance, documentation and monitoring actions for generative AI risks, which are easier to evidence when every session leaves a trail.
• ISO/IEC 42001:2023. The international standard for AI management systems (December 2023), certifiable by accredited bodies: policies, responsibilities, life cycle and continual improvement. Certification, when a company seeks it, belongs to the organization that runs the management system.
• EU AI Act (Regulation (EU) 2024/1689). In force since 1 August 2024, with staggered application. Article 14 requires high-risk systems to allow effective human oversight: understanding the system's capabilities and limits and monitoring it, staying aware of automation bias, interpreting its output, deciding not to use or to reverse that output, and stopping the system. Under Regulation (EU) 2026/1744, these obligations apply from 2 December 2027 or 2 August 2028, depending on the category. Coding assistants, as such, are not among the high-risk use cases listed in Annex III. The article serves here as a reference for what effective human oversight means, not as an obligation on your engineering tool. If the system your company builds is high risk, the assessment belongs to your legal and compliance team.
• Brazil. The Brazilian AI Strategy (EBIA, from the Ministry of Science, Technology and Innovation) has a governance axis. Bill PL 2338/2023 passed the Senate in December 2024 and, as of October 2026, awaits the rapporteur's report in a special committee of the Chamber of Deputies. It is not yet law. In the financial and capital markets, ANBIMA has published AI good-practice guides (2024 and 2025) that recommend governance throughout the life cycle, with human participation among the topics.

For this checklist, what these frameworks have in common is the weight they give to records and to human oversight.

Where the agentic development platform fits in this checklist

The agentic development platform applies this checklist to the way coding agents operate:

• Level 4 autonomy. Coding agents execute; humans supervise and read what goes to production. The platform stops before the dark factory.
• A traceable session. The request, the steps, the model, the cost, the result and the authorship are recorded.
• Knowledge base first. Codebase, documentation and anonymized data go in before any new line is written.
• Then build and refactor, observability and sustainment. On a legacy system, the modernization reads what still serves, builds the replacement beside it and switches piece by piece. The method is in Legacy modernization without stopping the business.
• Built alongside your team. It is not self-service. Validating the environment is up to the client's security team.

The Dr. Consulta case study shows the platform on a system in production.

The platform does not guarantee zero risk. A failure is still possible; the operation aims to limit how far it reaches and to make its cause easy to find.

Frequently asked questions

Book a demo

If your company's question has moved from "does AI write good code?" to "who answers for what the AI wrote?", the next step is to apply this checklist to a pilot with a session record and human supervision.

Book a demo →

Read also

• Agentic engineering vs. vibe coding: what changes when the code goes to production
• What an agentic development platform is
• What a dark factory is, and why the platform is not one
• Observability for coding agents
• Legacy modernization without stopping the business
• Harness engineering for enterprise coding agents