The Future of Engineering:
when coding gets cheap, engineering gets harder
Introduction
Many software engineers have already experimented with agentic AI and AI-assisted software development, using tools like Claude Code and Codex to write code. They might rely on AI to generate a complex database query that would otherwise take time to get right, or to speed up specific parts of a problem once enough context is provided.
But for many teams, the productivity gains stop there. Switching to a newer or more capable model rarely leads to another significant leap in efficiency, and simply giving more people access to AI doesn’t solve the problem either. The model itself was never the real bottleneck. The missing piece is everything built around it.
So what does it actually take to move beyond isolated productivity gains and unlock the next level of AI-assisted engineering? And what does that investment really cost?
Agentic, or AI-augmented, engineering is the next step. AI is no longer just a tool you use, it becomes a system you build around. One with clear standards, well-defined prompts, and governance that ensures AI agents operate consistently. With that foundation in place, the engineering challenge shifts from simply building a solution to deciding what should be built in the first place.
Counterintuitively, in regulated environments, this shift from adopting AI tools to building AI systems is not optional. The organisations that invest in this discipline are the ones that ultimately move faster, not the ones that skip it.
Tool adoption is easy, systems engineering is hard
There are many more levels of adoption between tool adoption and a full AI system. Most maturity models for AI adoption in software engineering settle on around eight levels. When you use agents to solve isolated coding tasks, you are near the bottom of this ladder. The first steps in moving up involve building context for the agent: structured information about architectural decisions, coding conventions, and team standards. But at all times, the engineer is steering and determining what the agent is allowed to do.
The next step is making the agent more autonomous, and this is where most engineering teams plateau. To move further, you have to start building systems. The software development lifecycle is the same for all engineering teams at a high level, but the details differ between engineers, teams, organisations and technologies. In some cases quality checks can be tied to a programming language and IDE; in others, specific scripts and gates need to be created. Some teams want tight alignment between technical documentation and code, while others want the code to speak for itself.
Building an autonomous loop for the agent that does what matters for your team requires understanding your software development lifecycle in detail. It requires codifying the standards and knowledge that were tacit up until now. By doing so, you can create a system that prompts itself, what is called loop engineering.
Why regulated teams can’t take the fast path
At this point you have not reached the top levels of the agentic engineering maturity ladder. Up until now, everything is pretty much contained on a developer’s local machine. Moving beyond that, especially in a regulated market, requires complex system and platform engineering.
To illustrate this, consider the following example. Engineering teams always look to optimise themselves, so naturally they want to start connecting their AI agent to internal systems through the Model Context Protocol (MCP). For instance, connecting the agent to a logging and monitoring system so that when production issues are logged, the AI system can identify, debug, and resolve them: a self-healing system.
But this is where complexity often halts progress. Access to a logging and monitoring system is a standing privilege, and if your organisation follows ISO 27001, every use of privileged access needs to be properly logged and attributable. The natural response is to give the agent the developer’s account – their internal identity. But sharing a personal developer identity with an autonomous agent creates unmanaged risk against controls the standard explicitly expects you to manage: unique, attributable identities (A.5.16), authentication information that isn’t shared (A.5.17), and controlled privileged access (A.8.2).
There is a sharper problem underneath. The agent is reading the very logs whose integrity its own access model breaks: acting under the developer’s identity, its actions are recorded against the human, so the logging control meant to establish who did what (A.8.15) can no longer answer that question. Unattended autonomy of this kind also sits in tension with the EU AI Act, which requires human oversight for high-risk systems.
The better approach is to give each agent its own identity, but that is not possible when every developer controls which agents run on their local machine. The way forward is a centrally governed, sandboxed environment in which the organisation controls the boundaries and what agents operate within them. Getting to this stage in the maturity cannot be fast-tracked.
Skipping the system doesn’t make you faster. It just moves the bottleneck downstream.
The engineer becomes the operator, not the author
You might be wondering what the difference is for engineers between a local and a remote agent, and how that shapes the future of engineering. The truth is there is no one-size-fits-all coding agent. Different types of engineering teams, even within the same organisation, have different needs. A DevOps team delivering business applications has different needs from a platform team or a consumer-facing team. They all need their own variations of the AI system, and that can only happen if the engineers are part of building it.
The engineer becomes the designer and operator of the AI system. The system now authors the code being generated, but the engineer remains responsible. This is codified in the ISO 42001 standard as the human-in-the-loop. It means the engineer must be competent enough to catch any error the AI system produces. Be it on architecture, security, or even UI design. As decisions keep coming and standards keep evolving, the AI system keeps evolving as well.
This is where a serious risk emerges for engineering organisations: cognitive surrender.
As more code can be produced, engineers can drift into a mode where everything blends together and the agent simply moves forward unchallenged. The pull is real. Reviews feel like formalities. Architectural decisions get made by default rather than deliberately. The engineer stops questioning and starts approving.
The danger is not that the agent makes mistakes, all systems do. The danger is that when something goes wrong in a regulated environment, the question “why was this decision made?” must have a human answer. Cognitive surrender makes that answer impossible to give.
Preventing it requires more than guardrails. It requires deliberately designing where human judgment is mandatory, not just at the output, but at the decision points the agent moves through. Reviews should not only ask what the agent built, but why it was built that way. That distinction is what keeps engineers genuinely responsible rather than nominally accountable.
The agent inherits the engineer’s authprity, but not their judgment.
What can you do?
For the CIO
The temptation is to measure AI adoption by license utilisation or velocity metrics. Resist it. The right signal is whether value is moving faster from idea to production, end-to-end, not just at the coding stage. A team that generates code twice as fast but ships at the same speed has improved a metric, not the outcome. More on this here.
Governance infrastructure needs to come before scale, not after. Agent identity management, centralised sandboxes, and audit trails are not slowdowns, they are prerequisites. The organisations that skip them hit structural walls at exactly the moment they should be accelerating. Building that infrastructure is not a technical cost; it is the investment that makes the rest of the roadmap viable.
The investment case is not about tools. It is about building the system that makes tools useful at scale.
For the architect
Start with identity. Every agent that touches internal systems needs its own identity, not borrowed from a developer. If your IAM architecture does not support that today, it needs to before you scale. This is not a future problem. It is a present constraint that compounds as adoption grows.
Codify what is tacit. Your teams make thousands of implicit decisions about architecture, security, and standards every day. The agent can only reproduce what is explicit. That codification work is unglamorous, but it is the foundation the entire system rests on. Without it, the agent operates on assumptions. And in a regulated environment, assumptions are liabilities.
Design the centralised sandbox before you need it. Engineering teams will push for expanded agent access once they hit the regulated boundary. Having the environment ready is the difference between a controlled transition and weeks of blocked progress.
The underlying question in both cases is the same: where does your organisation actually sit on the adoption ladder today? The honest answer to that question shapes every decision that follows; what to invest in, what to defer, and where the next bottleneck will appear.
What can Finaps do for you?
That question is also where we start. With our AI Readiness Scan, we give you an honest read of your current maturity level across governance, delivery, data, and cost control, and a concrete plan for the steps that follow. Not a theoretical framework, but a prioritised path based on where you actually are.
Our AI-native engineers have built these systems from the ground up, in regulated environments, and know where the walls are before you hit them. If you want to move beyond experimentation and build something that scales, that is the work we do together.