For decades, software development followed a relatively clear division of labour. The business defined requirements, IT translated them into systems, developers wrote the code, testers tested it, security reviewed it and operations deployed it.
Agentic AI is beginning to change this model fundamentally.
Modern AI coding agents can analyse requirements, design architectures, write application code, generate and execute tests, identify failures and refine the implementation. What previously required several specialised roles and multiple handovers can increasingly happen within one continuous AI-supported process.
The important change is therefore not simply that software can be produced faster. The distance between a business idea and executable software is collapsing.
And that makes governance more important, not less.
Business moves closer to software development
Traditional development typically follows a chain such as:
Business need → Requirements → Architecture → Development → Testing → Security → Release → Production
These steps create friction, but they also create control. Different people review decisions, responsibilities are separated and software passes through several organisational and technical gates.
Agentic development can dramatically shorten this chain.
A business expert does not necessarily have to write code or even understand the programming language. They might describe a business problem, discuss requirements with an AI agent, review proposed functionality, test results and refine the solution.
The agent handles much of the translation between business intent and technical implementation.
This creates something organisations have wanted for decades: much closer collaboration between business and technology.
But it also removes some of the organisational boundaries through which IT governance traditionally operated.
Business involvement is not uncontrolled citizen development
Allowing business units to participate in agentic development does not mean that hundreds of employees should independently generate applications and deploy them into production.
A more realistic model is controlled collaboration.
A business specialist can define processes, data requirements, business rules and expected outcomes. AI agents can translate these into specifications and implementations. Professional developers and technology teams remain responsible for architecture, repositories, integrations and production environments.
The business therefore moves much closer to software creation without necessarily becoming responsible for software engineering.
This can eliminate significant translation losses. The person who understands a lending process, investment workflow or regulatory reporting requirement no longer has to explain everything through several layers before seeing a working result.
But organisations must clearly define where business participation ends and engineering authority begins.
Governance has to move upstream
Traditional IT governance often controls the development process. With agentic development, organisations increasingly need to govern the environment in which development happens.
If an AI agent can modify hundreds of files, introduce dependencies, change database structures, create APIs and generate tests within minutes, reviewing every individual action manually is neither realistic nor useful.
Governance therefore has to focus on questions such as:
Who can use development agents? What can they access? What can they change? Which standards must they follow? And under which conditions can their output reach production?
The objective should not be to slow agents down. It should be to create a controlled corridor within which they can move extremely quickly.
What this governance model needs
The first element is identity and accountability. Every development initiative must ultimately have accountable human owners. An AI agent cannot own an application, accept business risk or become responsible for a production deployment.
Second, agents should operate within controlled development environments. Access to repositories, databases, cloud environments, APIs and secrets should follow least-privilege principles. This becomes even more important when an agent can execute hundreds of actions much faster than a human developer.
Third, organisations need architecture guardrails. Approved technology stacks, authentication mechanisms, API standards, logging requirements, encryption rules and external dependencies should be defined centrally. Wherever possible, these rules should become machine-readable and automatically enforceable.
Fourth, security must move into the development pipeline. Secure coding rules, dependency scanning, secret detection, static analysis and vulnerability checks cannot remain activities performed shortly before production.
A simple principle follows:
The faster software can be generated, the more controls must be automated.
Fifth, organisations need clear testing and quality gates. AI agents are excellent at generating tests, but having the same agent create both an implementation and its tests is not necessarily independent assurance. Minimum standards for unit, integration, end-to-end, security and acceptance testing should therefore depend on the application's risk.
The business has an important role here: validating whether the resulting software actually implements the intended processes and business rules.
Data may be the bigger risk
One of the largest risks may not be generated code at all. It may be the information available to the agent.
Organisations need explicit rules defining which source code, internal documents, customer information, production data, credentials and confidential information can be exposed to which models and tools.
Agentic software development therefore cannot be governed by IT alone. It connects software engineering with information security, data governance, procurement, risk management and AI governance.
Keep production as a controlled boundary
Perhaps the most important distinction is between creating software and putting software into production.
Agentic AI makes experimentation dramatically cheaper. Organisations should exploit that.
Business teams and developers should be able to prototype ideas, test alternatives and discard unsuccessful approaches quickly. Trying to apply full production governance to every experiment would destroy much of the benefit.
Production is different.
Software interacting with customers, sensitive data, financial transactions or critical processes should pass clearly defined production gates.
Governance should therefore be risk-based. An internal productivity tool used by five employees should not face the same controls as software supporting payments, lending or regulatory reporting.
Business criticality, data sensitivity, customer impact, financial impact, regulatory relevance and degree of automation can determine which controls are required.
IT becomes the platform and guardrail provider
Agentic development does not make central IT less important. It changes its role.
Instead of being the organisation's software-production bottleneck, IT increasingly provides the platform, architecture, tools, guardrails and production infrastructure within which software can safely be created.
There is a useful parallel with cloud computing.
The mature organisational response to cloud was not simply to prohibit business units from using it. Organisations established approved platforms, identity management, security standards, landing zones and governance.
Agentic development will require a similar evolution.
From written policies to executable governance
Perhaps the biggest opportunity is to rethink governance itself.
A 60-page software-development policy that nobody reads will not effectively govern an AI agent.
Many governance requirements can instead become part of the engineering environment:
Policy → Guardrail → Automated Check → Evidence
Required tests can be enforced through CI/CD. Approved dependencies can be checked automatically. Security scans can block releases. Architecture rules can be tested. Agent activities and code changes can be logged. Production deployments can require defined approvals.
Governance becomes less about documenting compliance after development and more about embedding organisational rules directly into the development platform.
A new operating model for software development
Agentic development should not be understood simply as another developer-productivity tool. Its larger potential is to change how business and technology work together.
The future model could look like this:
- Business defines intent and validates outcomes.
- AI agents translate intent into working software.
- Engineering defines architecture and technical guardrails.
- Security and compliance define machine-enforceable controls.
- Automated pipelines continuously verify those controls.
- Humans remain accountable for critical decisions and production releases.
That is not uncontrolled AI-generated software.
It is a new model of software engineering.
The central governance question is therefore not how organisations can prevent business users and AI agents from getting too close to software development.
It is how they can allow that collaboration while keeping architecture, security, quality and accountability under control.
And because agentic development operates at machine speed, governance increasingly has to do the same.