AI and developer experience: when the agent is the user
AI changes developer experience because your tools have a new user: the AI agent. A CLI or API built for agents returns structured output, errors an agent can act on and explicit confirmation for anything destructive, while a person stays in charge of what’s sensitive. And what works for the agent works for your team too.
What is developer experience, and why does AI change it?
Developer experience (DX) is what it’s like to build on a tool: how long it takes to get a first result, how clear an error is, how easy it is to find the command you need and how far you can trust the documentation.
Until recently, there was always a person on the other side. A person who reads between the lines, notices a warning in red and asks a colleague when something doesn’t add up.
Now, more and more often, there’s an AI agent on the other side. It reads your documentation, calls your CLI, interprets your errors and decides the next step. It doesn’t ask anyone. What is ambiguous to a person is a gamble to an agent.
That doesn’t replace DX for people: it extends it. Your tool has to serve both, with the same guarantees.
What does an AI agent need to operate your tool?
We start from a principle we apply across our products: everything the interface does, an AI agent can do, and vice versa. AI is a first-class user, not an add-on. Seven rules follow from it.
- Parity between console, CLI and MCP. If an action only exists in the console, the agent can’t do it; if it only exists for the agent, your team can’t review it. MCP (Model Context Protocol) is the open standard AI agents use to call external tools.
- Structured, predictable output. The same fields, with the same names, every time. No decorative messages mixed in with the data. A change to the output format is a change to the contract.
- Explicit confirmation for anything destructive. An interactive “are you sure? [y/N]” won’t protect you from an agent that answers “y” to everything. Anything that deletes, or changes something with no way back, asks for explicit confirmation, separate from the command itself.
- Read-only toolsets. An agent that monitors doesn’t need to be able to change anything. A read-only profile lets you start using agents without putting operations at risk.
- Errors an agent can act on. What failed, why and what to do next, with a stable code.
“Internal error” forces the agent to guess; “missing parameter
device_id; expected a string” lets it correct itself. - Documentation an agent can read. The description of each tool and each parameter is documentation and prompt at the same time. It has to be precise, include examples and say what the tool does and doesn’t do.
- Idempotent operations. Agents retry. Repeating a command must not create a duplicate device, alarm or charge.
How do we apply it in our products?
In NovaeOps, our AIoT platform, whatever you do in the console can also be done through the command line and MCP: more than 180 operations your AI assistant can use to monitor and run the platform. The ones that delete anything ask for explicit confirmation.
In CogniX, our predictive AI, console, command line and MCP are kept in parity. There’s also a division of labour that matters for DX: CogniX answers in milliseconds on the data path, and your AI assistant queries it over MCP to explain what happened. Each piece does what it’s good at, at the speed its job requires.
How does DX for people differ from DX for agents?
| Aspect | DX for people | DX for agents |
|---|---|---|
| Discovering what’s possible | Menus, autocomplete and tutorials | A list of tools with precise descriptions of each tool and its parameters |
| Output | Readable tables, colours and summaries | Structured data with stable fields |
| Errors | A clear message for whoever reads it | A stable code, the cause and the next step |
| Destructive operations | A visible warning before confirming | Explicit confirmation, separate from the command, and human approval if it’s sensitive |
| Permissions | Those of the person’s role | One toolset per agent, read-only by default |
| Retries | The person can see something was already done | Idempotent operations: repeating doesn’t duplicate |
| Documentation | Guides and usage examples | Descriptions the agent reads as instructions, with no ambiguity |
These aren’t two products. It’s one product with two readers, and almost everything that improves the right-hand column improves the left-hand one too.
Who is in charge when an agent operates?
A person. Operable by AI doesn’t mean autonomous: everything can be automated and supervised with AI, and anything sensitive waits for a person. That has two parts.
Approving what’s sensitive
Explicit confirmation of destructive operations is the first barrier. The second is deciding which operations also need a person to approve them before they run. The agent proposes; the person decides. And there’s a record of who decided what.
Governing the tools
Once you have several agents and several MCP servers, the question is no longer “can the agent do this?” but “which agent can use which tool, with what identity and within what limits?”. Today each MCP server handles permissions its own way, or not at all.
There’s a less obvious risk too: if a tool’s description changes, what the agent does with it changes as well. The documentation the agent reads is part of its behaviour.
That’s the problem Praesidix, the control gate for your AI agents, sets out to solve. It’s in the lab: a gateway that will sit in front of your MCP servers, decide which agent can use which tool with what identity and limits, detect any change to a tool’s definition so you can approve it, and keep an audit log that can’t be tampered with. We go into more detail in AI agent governance.
What does your development team gain?
Designing for agents imposes a discipline your team will be grateful for:
- One surface to test and document, instead of a console on one side and a half-finished API on the other.
- What an agent did, a person can repeat with the same command, and vice versa: the procedure someone on your team runs today, an agent can run tomorrow without rewriting anything.
- Better errors for everyone. A message an agent can act on is also one the on-call engineer understands at three in the morning.
Where do you start?
Take the ten operations your team performs most often and check, for each one, whether an agent could do it unaided. Does it exist outside the console? Is its output stable? Does its error say what to do? Does it ask for confirmation if it deletes something? Whatever fails is your to-do list.
If you’d like to see a platform designed this way from the start, take a look at NovaeOps, the platform you can operate by prompt.