AI is changing who can build software. Employees who have never written a line of code can now create applications, automate workflows, and build AI agents using natural language. A marketing professional can build an agent to monitor competitors. A sales operations analyst can automate lead qualification. A finance team can create workflows that reconcile data across systems.
This changes more than how software gets created. It changes who creates it, how it enters the enterprise, and who is responsible when something goes wrong.
Business users no longer need to wait for engineering teams to turn every idea into a working application. But the ability to create software doesn’t automatically come with the knowledge or infrastructure required to operate it reliably.
AI has dramatically lowered the barrier to creating software. It hasn’t lowered the responsibility that comes with running it.
For CIOs, CTOs, and security leaders, the challenge is to enable this new generation of builders without creating an entirely new category of unmanaged applications, privileged access, and operational risk.
Stop Teaching Everyone to Code. Teach Them How to Build With AI.
The mistake is assuming nontechnical employees need to learn a simplified version of software development before they can build with AI. They don’t. The real advantage of AI is that the people closest to a business problem can now build the software to solve it.
That changes what organizations should teach. Stop relying on prompt engineering workshops and generic AI literacy programs as the primary training strategy. Give employees real business problems, the tools to build working solutions, and the freedom to experiment within defined boundaries.
Employees need to understand how agents connect to enterprise systems, what permissions those connections require, and what happens when an agent takes action. A workflow that summarizes customer feedback is fundamentally different from one that modifies customer records or initiates transactions.
They also need to recognize that getting an agent to work once is not the same as building something that can operate reliably. Agents can produce convincing results while making incorrect decisions, misusing tools, or taking unintended actions. Testing, observability, and an understanding of operational boundaries need to become part of how people build.
The goal isn’t to turn business users into junior software engineers. It’s to make their domain expertise executable while giving them the tools and operating discipline to use it responsibly.
Also Read:ย CIO Influence Interview with Juraci Paixรฃo Krรถhling, CEO at OllyGarden
Give Employees an Environment Built for Execution
Training won’t get organizations very far if employees lack an appropriate environment to apply what they’ve learned.
There is a significant difference between experimenting with an AI chatbot and building an agent that executes code, connects to enterprise systems, or performs tasks autonomously. Yet many organizations are trying to support both activities with the same infrastructure and security assumptions.
Employees often face two choices: experiment with AI tools outside established enterprise controls or submit requests to already stretched IT and engineering teams.
Neither approach scales.
Organizations need environments where employees can build, test, and run AI applications with access to approved tools, appropriate compute resources, and clearly defined permissions. These environments should support experimentation without exposing production systems or sensitive data unnecessarily.
Isolation matters particularly for agents that generate and execute code. An agent should not automatically inherit every permission available to the employee who created it. Execution environments need boundaries around file systems, credentials, network access, and the resources an agent can use.
This is not simply a security requirement. It is an architectural requirement for scaling AI development beyond engineering.
The objective isn’t to eliminate experimentation. It’s to make experimentation practical without requiring organizations to choose between productivity and control.
Traditional Security Wasn’t Designed for Autonomous Execution
Most enterprise security models were designed around people accessing applications and applications accessing resources. Identity, permissions, network controls, and monitoring are built around those relationships.
AI agents introduce a different operating model.
An agent can reason through a task, select tools, execute code, retrieve information, and take actions across multiple systems. It may perform dozens of operations to complete a single request, making decisions dynamically along the way.
Traditional security controls remain essential, but knowing that an agent was authorized to access a system doesn’t establish whether every subsequent action was appropriate.
Consider an agent tasked with updating customer records. It may retrieve information from multiple sources, resolve conflicting data, and decide which records to modify. Even with legitimate access, the agent could overwrite valid information, expose sensitive data, or execute actions beyond the intended scope of the task.
A security team that sees only the initial request, authentication event, or final result is missing critical context.
Organizations need visibility into agent execution:
- Which tools were invoked, what resources were accessed, what actions were taken, and how those actions relate to the original task.
- The ability to enforce policies at the point of execution, before an inappropriate action is completed.
- Moving beyond controls that focus primarily on access and monitoring toward controls that understand and govern agent behavior.
The question is no longer just who has access to a system. It’s what an AI agent can do with that access.
Measure Production Outcomes, Not AI Participation
Many organizations still measure AI adoption through licenses issued, employees trained, or usage of approved tools.
Those metrics indicate participation. They don’t establish whether AI is creating business value or whether the resulting systems can be operated reliably.
CIOs and CTOs should measure what employees are building, how those systems perform, and whether they produce meaningful outcomes.
How many workflows have moved beyond experimentation? How much manual work has been eliminated? How often do agents complete tasks successfully? What do those tasks cost? Can the organization identify and control unexpected behavior?
Start with repeatable business processes where outcomes are measurable and the consequences of mistakes are understood.
A sales operations team, for example, might build an agent that identifies incomplete CRM records and recommends corrections. Initially, employees review proposed changes. As the system demonstrates reliability, certain low-risk updates can be automated while more consequential actions continue to require approval.
The point is not to maximize autonomy immediately. It’s to expand autonomy as organizations gain evidence that systems behave as intended and have the controls to manage exceptions.
An agent that works in a demonstration is not necessarily ready for production. Reliability, monitoring, cost management, and continuous improvement must become part of how success is measured.
The Next Generation of Enterprise Builders
AI is expanding software development beyond traditional engineering teams. That change is already underway, and attempting to contain it entirely within IT will limit its potential.
But giving employees access to AI tools is only the beginning.
Organizations need to equip business users with practical building skills while establishing the infrastructure, security, and operational controls required to support what they create.
For CIOs and CTOs, that means treating AI development by business teams as an enterprise architecture priority. For security leaders, it means extending visibility and control from users and applications to the actions AI agents take.
The companies that succeed won’t necessarily be the ones that train the most employees to use AI. They’ll be the ones that enable employees to build useful systems and have the operational foundation to run them reliably, securely, and at scale.
About Harold
Harold Byun is CEO of BlueRock, where he focuses on the emerging operational challenges created by AI-native and agentic systems. His work centers on helping organizations operationalize autonomous infrastructure by improving visibility, runtime understanding, and control across agents, MCP servers, orchestration layers, tools, and downstream execution environments.
About BlueRock
BlueRock delivers Agentic Security, helping teams see and secure autonomous agent actions before they run.
Catch more CIO Insights:ย Where Offensive Validation Is Headed
[To share your insights with us, please write toย psen@itechseries.comย ]
