Operations | Monitoring | ITSM | DevOps | Cloud

Intent-driven development (IDD) is an approach to AI-assisted software development where teams make the desired behavior, constraints, and criteria for success explicit, then give an agent freedom to determine how to achieve the result. As agents take on larger and more autonomous development and maintenance tasks, the implementation itself becomes easier to replace. The important question is whether the software still behaves the way the team intended.

Improving agent experience (AX) is one thing. Keeping it good as your product changes is harder. A renamed field, different error response, or overlapping tool can turn a workflow that worked yesterday into extra retries, wasted tokens, or human intervention. CI gives teams a way to catch AX regressions as part of the development process. You can test the interfaces agents depend on, run representative agent workflows against product changes, and preserve fixed failures as regression cases.

A software factory is a system for turning engineering intent into production software through repeatable, increasingly automated workflows. It connects the tools, infrastructure, people, agents, validation, and delivery controls required to move work from an idea or issue into production. Coding agents have made the model newly relevant. Teams can now produce software changes much faster than traditional development processes were designed to evaluate and coordinate.

Language servers give editors structured, real-time feedback: diagnostics, hover docs, autocomplete, and other guidance that would otherwise surface later. Language servers already exist for many of the languages and tools developers use every day, but Claude Code doesn’t automatically receive their feedback.

Testing consumes up to 50% of CI/CD pipeline time. That’s the single most expensive place in your delivery pipeline, and a meaningful share of that time is often wasted running tests unaffected by the change. Every time a developer pushes a commit, the full test suite runs. A two-line bug fix in auth.py triggers 2,000 tests, including 1,900 that don’t touch anything near auth.py. Those unrelated tests are overwhelmingly likely to pass, but the pipeline still spends 20 minutes running them.

Summary: An API defines how software interacts with a service. MCP defines a standard way for AI applications to discover and invoke tools exposed by a service. They usually work together: an MCP server can sit in front of APIs you already run, turning low-level operations into capabilities an agent can find and use at runtime. Your API may already expose everything an AI agent needs. The harder problem is helping the agent figure out which operations matter for the task it has been given.

Every team adopting coding agents hits the same question early: where do you put the instructions that tell the agent how your codebase actually works? Two answers dominate the conversation right now. One is AGENTS.md, a plain markdown file at the root of your repo. The other is skills, packaged instruction sets an agent loads on demand. Most of the debate treats this as a formatting decision. It isn’t.

“We don’t need junior engineers anymore” has become one of those lines people repeat because it sounds obvious. The AI writes the code, so why pay someone to learn how to write it? On the latest Confident Commit podcast, Rob Zuber makes the case that this take is exactly backwards.

An AI sandbox is an isolated environment where code from an AI coding agent runs without direct access to your machine or your production systems. If the agent runs a destructive command or a mistaken script, the damage stays contained inside the sandbox. Developers use AI sandboxing to let agents execute code freely while keeping the host and its credentials out of reach.

As development shifts toward agentic workflows, an AI agent is only as capable as the systems it can reach. Local MCP servers allow desktop CLI and IDE agents to execute multi-step tasks on your machine. But remote MCP servers (also called hosted MCP servers) extend that reach to cloud-based and background agents, allowing an agent running in a web browser, a CI runner, or a backend service to access external tools over HTTP without needing a developer’s machine running local child processes.