One of the first questions I ask devops organizations is to walk me through their development and operations standards. What are the non-negotiable devops practices? What are the data governance first principles? What observability standards are in place? How is security embedded in devops? This is the starting point. From there, we might review standards on how functional requirements are written. For businesses developing AI agents, I’ll ask about their non-functional requirements (NFRs) and how testing is performed.

Now that many devops organizations are using AI code generators, vibe coding, and applying spec-driven development practices, the questions increase. How does the AI know your organization’s standards? What processes monitor and enforce these standards? What are the developer responsibilities for owning the outcomes?

“Generative AI will happily hand you the movie set of an app with looks of a house from the street. The doors and windows open, and the demo runs clean,” says Mike Toole, director of security and IT at Blumira. “Behind the facade, there’s no plumbing and no wiring: no input validation, no auth boundaries, nothing actually holding it up. If your only gate is ‘does it run and look right,’ you’re shipping a set, not a building.”

One report shows that 92% of developers use AI coding tools daily in 2026 and that 41% of all global code is now AI-generated. Will all that code deliver value, operational issues, or mounting AI debt? I spoke to several experts about how to keep AI-generated code aligned with organizational standards and how to define an AI code generator’s context beyond just functional requirements.

Document like a construction specification

A general contractor in the construction industry will review building information models that provide a view of what they are developing. But many of the details are in the construction specifications, including component stipulations and performance requirements. Devops teams without equivalent documentation for their organization, architectures, and applications may have gotten away with this omission in the pre-AI era. But institutional knowledge and compliance requirements are the context AI code generators need before you share the first functional prompts with them. 

“AI-generated code stays aligned with engineering standards only when those standards are explicit, available, and difficult to bypass,” says Eddie Zhou, founding engineer at Glean. “Put architecture, approved libraries, data-handling rules, security controls, naming conventions, observability, test expectations, and non-functional requirements into specs and automated checks. Then, ensure you give the model that context but treat its output as untrusted until it passes the same reviews, tests, scans, and production monitoring as human-written code.”

Overcoming tribal knowledge was always challenging as devops teams had too much pressure to push features and little incentive to maintain documentation. Two of my top AI leadership skills are change management and agile collaborative leadership, because devops teams need practice alignment while introducing AI capabilities.  

Zhou adds, “AI amplifies ambiguity and weak governance as efficiently as good engineering. If standards live only in tribal knowledge, AI will expose that problem, not solve it.”

Encode non-functional requirements as automated tests

The problem with requirement documents and reference architectures is they aren’t directly enforceable with human or AI developers. Once a devops team agrees on standards and documents them, the next step is to develop approaches to encode them as automated acceptance criteria in CI/CD pipelines.

“AI code generators and human developers optimize for functional correctness—making the feature work—and quietly skip the non-functional requirements where most of your real standards live, including performance, security posture, error handling, observability, and auditability,” says Michael Bevilacqua, vice president of AI product management at Adeptia. “Encode your NFRs as executable acceptance criteria that generated code must pass before it merges, so ‘aligned with our standards’ becomes a gate the pipeline enforces on every change.”

An example: Performance requirements stating that all web pages should have a total page weight under 2MB can be validated during the pull request, and requiring the time to first byte (TTFB) to be under 800ms can be automated in CI/CD in a staging environment.

Requirements for stakeholders and AI

Architecture and automated non-functional requirements covering performance, security, and other organization-level compliance requirements should become the base-level context standards shared with AI-code generators. The next set of considerations for setting accurate contexts starts with application- and agent-specific requirements, their intended use cases, and specific compliance guardrails.

“CIOs are mandating AI to build apps faster, but many are realizing speed isn’t the bottleneck because more code doesn’t automatically create business value,” says Matt Healy, senior director of product strategy and marketing at Pegasystems. “Before developers write any code, organizations must understand customer needs, assess legacy systems, stay current with regulations and best practices, map enterprise architectures and integrations, and align business and IT.”

Consider three stages of understanding requirements. Once stakeholders set business value and intent, developers must first align on an implementation strategy and discuss performance, cost, and other trade-offs. Then, developers should reconvene with stakeholders and review implementation trade-offs. Healy adds, “On large projects, defining the solution and success metrics can take as much time as building it. Leaders aren’t just using AI to accelerate development, but to help executives, business analysts, product owners, and IT teams collaborate more effectively.”

The third stage is gathering the goals, user requirements, and implementation approach into a development-specific context. But we’re not done yet, because data requirements and operations considerations must also be included in the context fed to AI code generators. 

Build governance into the specs

How the application or AI agent being developed can use the data it has access to requires clear specifications. Data governance programs should have standards based on data sets, defined roles, entitlements, and usage specifications.

Kash Mehdi, vice president and field CTO at Reltio, says the teams that are pulling ahead treat data governance as an input to AI, not an audit after it. “They ground their tools in trusted, semantically consistent data models, approved specs, and security policies, so the AI inherits the organization’s standards instead of inventing its own. Without that governed context layer, you don’t scale from a handful of AI-assisted workflows to thousands; you just accumulate inconsistent code faster,” Mehdi says.

Here are two options to consider in creating standards: First, establish repurposable data sets as data products with defined integrations and usage rules. Organizations with many data sets and integration points should consider data fabrics. The second (and key requirement) is to standardize the format of data contracts, using human- and machine-readable formats so that data owners, users, and AI code generators operate from a consistent set of principles.  

“AI writes code that compiles and passes tests but quietly ignores your data contracts, so the failures show up in production as corrupted state, not build errors,” says Ed Huang, cofounder and CEO of TiDB. “The fix is to make governance machine-checkable, including schema constraints, access policies, and data-quality rules enforced at the database layer where the AI can’t route around them, not documented in a wiki the model never reads. Treat the database as the enforcement point for your standards, and it stops mattering whether a human or an agent wrote the query.”

Observability and testing first

When AI generates the code, a best practice is to use static application security testing (SAST) and other code analysis tools to perform automated code reviews. Another best practice is to put applications through penetration testing and other application security validations. But many of these tools are outside in view of what the AI developed. To get an inside view, observability and testing requirements must be included as a standard, with specific requirements around the key transactions you’re asking the AI to develop.

Sanjay Gidwani, CEO and founder at Kosmos, says, “More code volume just means more time spent investigating, and the fix isn’t reading the code more carefully before it ships. It’s connecting the observability signal, the thing that broke, back to the specific change that caused it. Without that link, you’re doing the same manual investigation as before, just with a bigger haystack.”

Testing requirements must go beyond generating automated tests, using synthetic data to expand the test patterns, and implementing continuous testing. “Instead of testing one input against one output, test whether an invariant holds across a wide range of generated inputs, which is a good fit for AI’s unbounded input space and non-deterministic outputs,” says Lior Gavish, cofounder and CTO at Monte Carlo. “I treat it as one layer in a stack with evals mapping the input space, property-based testing stress-testing it for edge cases and brittleness, and observability on live traffic checking whether production is drifting from the properties you defined as non-negotiable.”

Package and evolve the standards

Ed Frederici, CTO at Appfire, recommends codifying standards as machine-readable rules, including linters, formatters, and type checks. Merge the organizational and application standards into one context shared with the AI code-generating tool. His other recommendations:

• Enforce standards in continuous integration so violations block merges.
• Give the AI persistent context, such as CLAUDE.md, style guides, and architecture docs.
• Keep changes small and reviewable.
• Require human review of every pull request because AI-generated code must get the same scrutiny as any contributor’s. No exceptions.
• Back this approach with solid test coverage to catch regressions.
• Periodically audit for drift as your standards evolve.

It’s also important to remember that as code must be extended and maintained, so must the underlying development standards. “AI-generated code only stays aligned with your standards when it’s powered by a context engine that keeps learning, not a static snapshot of your rules,” says Itamar Friedman, CEO and cofounder at Qodo. “That means an engine that continuously adapts to your codebase’s evolving standards, your team’s PR history, and the prior decisions your engineers have already made, so the AI isn’t just following instructions but actually understands how your team works.”

As more devops organizations rely on AI code-generating tools, developers have an important opportunity to develop the standards and automated validations required to ensure what is built meets engineering and compliance requirements.

The newest member of the corporate workforce never sleeps, never asks for a raise, and can be cloned before lunch. It can also confidently make the wrong decision thousands of times before anyone notices.

That helps explain why some technology leaders have started talking about AI agents as employees, co-workers, or interns rather than software. Once an agent can update records, issue refunds, send communications, or act across multiple enterprise systems, deploying it no longer looks much like installing another application.

Recent Harvard Business Review articles have pushed that analogy further. One argues that agents should be treated like a new workforce, with defined roles, authority, sources of truth, supervision, and audit trails. Another recommends giving agents names and job descriptions, onboarding them, evaluating their performance, and increasing their responsibilities after they prove themselves.

But there is a catch: People may start believing the metaphor.

A separate HBR study of 1,261 managers found that when AI was framed as an employee rather than a tool, managers with experience working around AI agents took less personal responsibility for results and assigned more responsibility to the AI. They also escalated more problems and caught fewer errors. In the study, 31% of respondents said their companies already framed AI as a teammate or employee, while 23% said agents appeared on organizational or work charts.

For IT leaders, the answer may therefore be to borrow freely from the employee-management playbook — without extending the metaphor too far.

Don’t put software on the org chart

Amy Loomis, group vice president at IDC, draws a hard line around one word: responsibility.

Humans, she says, have obligations to their companies and to one another, and they bring an understanding of corporate culture and values that an agent can mimic linguistically without possessing.

That makes calling an agent a co-worker potentially more than harmless anthropomorphism. The label suggests a peer relationship and can encourage people to cede judgment to a system that’s very good at giving what was requested, Loomis says, but not necessarily at recognizing what was actually needed.

“Accountability is something that has qualities associated with it that are uniquely human,” she says. “Agents may be given permission to access data, but the accountability for what they do with that access lies with the person who gave the agent access, not the agent itself.”

That distinction still leaves plenty to borrow from employee management. It makes sense to give an agent traceable access and tightly scoped permissions — and to institute a kill switch to prevent the agent from having continued access. But Loomis finds it more effective to think in terms of giving an agent an operations charter rather than a human identity: define what the system does, what it may access, and what humans remain responsible for.

In other words, give the agent a security badge. Just don’t put its picture on it.

The employee metaphor has a job to do

Raja Iqbal, founder of agentic AI governance company Ejento AI and co-author of the HBR article “To Scale AI Agents Successfully, Think of Them Like Team Members,” is closer to Loomis than the headline suggests.

Iqbal says the metaphor is intended to put CIOs, CISOs, and other technology leaders into the right “cognitive posture.” Thinking about an agent as a team member, he argues, can remind an enterprise to impose familiar management disciplines: a unique identity, clear human oversight, defined authority, spending limits, approved information sources, and an audit trail.

If another term produces the same discipline, he’s fine with that too.

In fact, Iqbal explicitly rejects synthetic employees with human personas and seats on the org chart. That creates exactly the accountability problem critics worry about: “Bob did it” becomes an excuse even though Bob is software.

“The metaphor is dangerous when it’s decorative,” Iqbal says. By that, he means companies get into trouble when they adopt the human trappings — names, personas, or the language of colleagues — without also imposing the supervision, limits, and accountability that make the analogy useful.

His preferred distinction is simpler: the agent needs a technical identity so the enterprise can reconstruct what it did, while a human must remain responsible for those actions. “The identity is the audit primitive, and the human owner is the accountability primitive,” he says. Put more plainly, the agent identity answers what acted; the human owner answers who is accountable.

The employee analogy becomes more useful again when deciding how much freedom an agent should receive. Iqbal recommends graduated autonomy. An agent might begin with a human approving every action, progress to performing low-risk actions independently, and eventually receive bounded autonomy if its observed performance justifies it. A serious error can send it back down the ladder — or out the door entirely.

That sounds a lot like a probation period for a new employee. It’s also simply good software governance for a probabilistic system.

At DXC, professional agents are software

Russell Jukes has had plenty of opportunity to test that distinction. As chief digital and information officer at DXC Technology, he oversees AI in an IT services organization with roughly 115,000 employees.

“We think about [an AI agent] as a superpower, not as a person,” he says.

DXC separates agents into two categories. Personal agents work for individual employees and generally operate using the employee’s identity and access. Professional agents are enterprise systems built for broader workflows. On one of DXC’s major AI platforms, employees have so far created roughly 8,000 personal agents, compared with about 100 professional agents.

The professional variety receives much stricter oversight. It can have its own nonhuman identity, credentials, permissions, and authority boundaries. Activity passes through control planes that allow DXC to see what agents are doing and, when necessary, shut them down.

Jukes thinks many of these agents will eventually disappear from users’ view altogether. An agent might scan internal resource requirements overnight and recommend employees for projects. Nobody needs to greet it in the morning or consider it a colleague; they simply receive the result.

That’s where he parts company with the worker metaphor.

Jukes says he learned early on that AI cannot be deployed like conventional SaaS. His first attempt followed the familiar software model: make the application available, let employees use it within the prescribed workflow, and expect adoption to follow. “I did that, and nobody used it,” he says. The experience convinced him that AI requires a different approach, and he vowed to “never deploy AI like it’s SaaS again.”

Conventional SaaS is largely deterministic: the software constrains users to a defined workflow and produces predictable outputs. Agentic AI is different. It can interpret a goal, choose among tools and data sources, and decide how to get to an outcome. For Jukes, that means CIOs have to design the policies, permissions, data access, guardrails, and authority around the agent rather than simply deploy another application.

That also creates a clearer chain of responsibility. If a person approves the agent’s action, Jukes says that person owns the decision. If an autonomous agent behaves according to a business policy, accountability belongs with the people responsible for that policy. If the technology fails to operate as designed, responsibility moves to IT.

The agent itself never gets handed the blame.

Maybe treat it like an intern after all

Nina Tatsiy, global CIO of Quadient, an automation technology company, takes a position somewhere between Iqbal and Jukes. She calls agents interns, but deliberately uses the term as an analogy, not an organizational designation.

Agents must be managed as software, with security, governance, and technical controls, while recognizing that their probabilistic behavior requires additional supervision. “You have to do both,” Tatsiy says.

An intern does not receive every password and authorization on the first morning. Neither should an agent. It has to be onboarded, trained, watched, retrained when its environment changes, and eventually retired when it’s obsolete.

Quadient generally avoids giving agents human names. Tatsiy worries that doing so encourages people to see them as real colleagues capable of judgment.

“Overtrust is a problem,” she says, particularly because AI tends to state conclusions with such assurance. Tatsiy prefers using AI to challenge a hypothesis or surface questions people haven’t considered rather than allowing it to make the conclusion for them.

Yet the intern analogy has proved useful operationally.

In one accounts-payable deployment, Quadient had an agent effectively shadow human workers and learn from their feedback across different scenarios. Only after its performance had been tested across increasing levels of complexity did it begin providing recommendations. Humans still made the final decision.

The agent, in other words, earned more trust. It didn’t earn accountability.

Borrow from HR, but keep humans in charge

The emerging divide may therefore be less about whether agents are employees or software than about which parts of each management model IT leaders should retain.

Agents need individual technical identities, but not human identities. They need defined responsibilities, but not jobs in the human sense. They need monitoring and evaluation, but not annual performance reviews. They can receive progressively greater authority, but not progressively greater accountability.

And the stronger they become, the more important that distinction becomes.

Treating an autonomous agent like ordinary SaaS ignores the fact that it can interpret, choose, and act in ways conventional software cannot. Treating it like Steve from Accounting creates a different problem: sooner or later somebody may start assuming “Steve” knows what he’s doing.

IT leaders may indeed need to borrow heavily from HR as agentic AI spreads across the enterprise. They just shouldn’t start issuing employee badges.

Related reading:

• 6 ways to make AI accountability stick
• From chatbots to colleagues: How agentic AI is redefining enterprise automation
• Why AI adoption keeps outrunning governance — and what to do about it
• AI is spreading decision-making, but not accountability