What the EU AI Act Means When You Build Software with AI

What engineering leaders need to know when coding agents become part of the software development process.

Coding agents are becoming part of everyday software engineering. They can inspect repositories, modify files, run tests, investigate failures, create pull requests, and increasingly operate with limited human intervention.

This changes how software is built. It also raises an obvious question for CTOs and engineering leaders in Europe:

What does the EU AI Act mean when coding agents become part of software development?

The answer is more focused than it may initially appear. The AI Act does not regulate "agentic engineering" as a separate category. Its relevance depends on the AI system being used, the role of the organisation, and the system being built.

There is one distinction that provides the foundation for the entire analysis.

The first distinction: deployer and provider

The AI Act distinguishes between deployer and provider.

Simply put:

• When you use a coding agent to develop your software, you are generally a deployer of the AI system you are using.
• When you build an AI system and place it on the market or put it into service under your own name, you may be its provider.

These are separate roles.

It does not matter whether you used a coding agent, conventional developers, or a combination of both to build the system. Using a coding agent does not change the regulatory status of the software you produce.

This distinction matters because the AI Act attaches different obligations to providers and deployers.

For a company using a third-party coding agent internally, the immediate concern is its role as a deployer of that coding agent. If the company subsequently develops and puts an AI system into service under its own name, it may also become the provider of that resulting AI system.

The regulatory analysis therefore happens at two levels:

The coding agent you use → What are your obligations as its deployer?

The system you build → What are your obligations as its provider or deployer?

This is the key connection between coding agents and the AI Act.

---

1. AI literacy is the most direct requirement

For organisations using coding agents, Article 4 on AI literacy is one of the most directly relevant provisions.

Providers and deployers must take measures to ensure a sufficient level of AI literacy among staff and other people dealing with the operation and use of AI systems on their behalf.

For software engineering teams, this needs to be understood in the context of how the coding agent is actually used.

An engineer using an agent for code suggestions has a different level of responsibility from an engineer supervising an agent that can modify repositories, execute commands, or access engineering infrastructure.

Relevant knowledge can include:

• which model or AI service the agent uses;
• what data and repository context it can access;
• what tools it can invoke;
• what permissions it has;
• how much autonomy it has;
• what information is sent to external services;
• how its output is validated; and
• which security and reliability risks apply.

The AI Act does not prescribe a specific training programme for software engineers. The important requirement is that the organisation takes the necessary measures to ensure appropriate AI literacy for the systems and circumstances in which people work.

For organisations adopting coding agents at scale, AI literacy therefore becomes part of engineering enablement and governance.

---

2. The regulatory status of what you build is separate

The most important second step is to look at the software being developed with the coding agent.

Consider two projects.

In the first, a team uses a coding agent to build an internal business application. The application does not fall within a regulated AI use case.

In the second, the team uses the same coding agent to develop an AI system used for recruitment, credit assessment, or another use case covered by the AI Act.

The coding workflow may be identical. The regulatory situation is not.

If the resulting system falls within a high-risk category, the organisation may have obligations concerning areas such as:

• risk management;
• technical documentation;
• logging and record keeping;
• human oversight;
• accuracy and robustness;
• cybersecurity; and
• post-market monitoring.

Those obligations apply because of the resulting AI system and its intended purpose.

They do not arise because a coding agent was used to implement it.

This is why engineering organisations should keep two assessments separate:

How are we using AI in software development?

and

What regulatory obligations apply to the system we are developing?

The first determines how the coding agent should be governed. The second determines whether the resulting system needs to meet requirements under the AI Act.

---

3. Agentic engineering makes the development process more consequential

Coding agents change the engineering process because they can do more than generate text or suggest code.

A typical agentic workflow can look like this:

Developer
    ↓
Coding agent
    ↓
Read repository
    ↓
Modify files
    ↓
Run tests
    ↓
Inspect failures
    ↓
Modify again
    ↓
Create pull request

The agent can therefore become an active participant in the development lifecycle.

For ordinary software, this is primarily an engineering and security concern.

For regulated AI systems, it also has implications for how the organisation develops and validates the system.

If the final system requires technical documentation, testing, logging, risk controls, human oversight, or other evidence, the development process needs to support those requirements even when parts of the implementation are performed by an agent.

The important shift is therefore not that the AI Act regulates autonomous coding. It is that agentic development changes how engineering teams produce a system that may itself be regulated.

---

4. Governance the coding agent as an engineering actor

The AI Act provides the regulatory context. Engineering teams still need to determine how a coding agent is allowed to operate.

The key issue is authority.

A coding agent that can only suggest code has a very different risk profile from one that can modify repositories, execute commands, merge pull requests, or deploy infrastructure.

A useful capability model is:

Read → Write → Execute → Merge → Deploy → Administer

Each step gives the agent more authority.

That authority should be explicit and limited to what the task requires.

This means engineering organisations should define:

• which repositories an agent can access;
• which files and resources it can modify;
• which tools it can invoke;
• which credentials it can use;
• which actions require human approval;
• which environments it can access; and
• how its actions can be observed and reversed.

These are engineering controls rather than AI Act requirements. They are nevertheless important when coding agents become part of the development infrastructure.

---

5. Regulated AI development needs stronger traceability

For a normal software project, knowing what an agent changed may primarily be useful for debugging and security investigations.

For a regulated AI system, the development history can become part of the broader evidence needed to demonstrate how the system was developed, tested, and controlled.

Agentic development makes this more important because an agent can perform many development actions without a developer manually carrying out each one.

A robust engineering environment should therefore make consequential actions attributable.

Depending on the system and its risk, this can include being able to determine:

• which agent made a change;
• under which identity it acted;
• which tools it invoked;
• which tests were run;
• which human reviewed the resulting change; and
• which version ultimately entered production.

The goal is not to log every interaction simply because AI was involved.

The goal is to have sufficient engineering evidence to understand and control the development process, particularly where the resulting system is subject to regulatory requirements.

---

6. What this means for CTOs

For organisations adopting coding agents, the practical approach can remain relatively simple.

Know your coding agents

Maintain an overview of which agents and AI services are used in engineering and what data and systems they can access.

Know your role

For each AI system, understand whether the organisation is acting as a deployer, provider, or potentially in another role defined by the AI Act.

Know what you are building

Identify which projects produce AI systems and assess whether those systems fall within the AI Act.

Match governance to authority

The more an agent can access and change, the stronger the controls around identity, permissions, supervision, testing, and recovery should be.

Build compliance into regulated development

When a project involves a regulated AI system, make sure the development process can support the documentation, testing, traceability, human oversight, cybersecurity, and other requirements applicable to that system.

This avoids turning every coding-agent deployment into a compliance project while still addressing the situations where the AI Act genuinely matters.

---

The practical conclusion

The EU AI Act does not create a separate regulatory framework for agentic software engineering.

For organisations using coding agents, the most important concepts are deployer, provider, AI literacy, and the regulatory status of the system being built.

The distinction is straightforward:

Using a coding agent to build software makes the organisation a deployer of the AI system it uses.

Building and putting an AI system into service under the organisation's own name can make the organisation its provider.

The fact that a coding agent was used to build that system does not change this classification.

What agentic engineering does change is the development process. Agents can access repositories, invoke tools, modify code, and perform increasingly consequential actions. Engineering organisations therefore need clear boundaries around their authority, appropriate AI literacy, and sufficient traceability.

When the resulting software is a regulated AI system, those engineering capabilities become part of the environment in which the organisation has to meet its AI Act obligations.

That is the real intersection between the EU AI Act and agentic software engineering.

The AI Act determines which systems and uses are regulated.

Engineering determines how safely and reliably coding agents operate within the development process.

The two meet when coding agents are used to build systems for which the AI Act imposes specific requirements.

This article is an engineering and regulatory analysis, not legal advice. It reflects the EU AI Act as consolidated on 27 July 2026, including the amendments introduced by Regulation (EU) 2026/1744. The application of the high-risk provisions has been deferred by the Digital Omnibus to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.