Software built with AI agents

I develop software and build infrastructure for clients, using a coordinated set of AI agents as my tools. I work out the architecture with you, write the specifications, steer the agents as they plan, code, test, and review, and check their work before passing it on. You stay in charge of the product: you set the priorities, decide who reviews and approves changes, accept the results, and run the system in production. Your IT governance applies throughout: your policies for security, data protection, architecture, and change management set the frame for my work.

The result is software delivered much faster and at lower cost than with a traditional team, and often of higher quality, because the thorough parts of engineering that usually get cut under deadline pressure have become cheap.

The practices on this page are options to consider, not a fixed package. Which of them a project needs depends on its risks, its budget, and your existing processes, and we decide that together at the start. I help you choose and implement the right measures, but no setup makes software, or a system of AI agents, safe in every circumstance.

What I build

Software engineering: applications and services, from web applications and APIs to data pipelines and AI features such as assistants and agents
Infrastructure: the environment the software runs in: cloud or on-premises servers, containers and Kubernetes, CI/CD pipelines, monitoring and backups, and GPU servers for self-hosted AI models. All of it is defined as code, so it can be reviewed, reproduced, and handed over.

How it works

A single AI assistant in an editor helps a developer type faster. A coordinated multi-agent system changes how a project runs:

Specialized roles: agents take on distinct tasks such as exploring the existing code, implementing features, writing tests, and reviewing changes. A reviewer starts with a fresh context and has no stake in the code it checks.
Parallel work: several independent work streams progress at the same time in isolated workspaces, instead of one after another.
The usual quality gates: changes go through version control, automated tests, static analysis, and code review, just like code written by people. Who reviews and merges follows your process: often someone on your team, otherwise me.
Human judgment where it counts: requirements, architecture, security design, and trade-offs are decided by people, not agents: by you, with my advice.

flowchart TD
    you["You<br/>goals and priorities"] --> spec["Specification and architecture<br/>worked out together"]
    spec --> a1["Agent<br/>feature A"]
    spec --> a2["Agent<br/>feature B"]
    spec --> a3["Agent<br/>tests"]
    a1 --> review["Review agent<br/>fresh context"]
    a2 --> review
    a3 --> review
    review --> ci["Automated checks<br/>tests, analysis, security scans"]
    ci --> mine["Human review<br/>your team or me"]
    mine -.->|"changes needed"| spec
    mine --> accept["Your acceptance testing"]
    accept --> prod["Production, run by you"]

My background matters here: three decades of software engineering and technology leadership mean I know what good systems look like, and I can tell when an agent is wrong.

A different development cycle

With AI agents, a working prototype takes days rather than weeks. That changes not only how fast a project runs, but how it runs:

Prototype before you specify: instead of writing requirements in the abstract, your users try a working prototype and react to it. The specification follows from what works, and misunderstandings surface in days rather than months.
Compare real alternatives: when several designs are plausible, I can build two or three of them, and you choose based on working software rather than slides.
Test risky assumptions first: whether a model is accurate enough, an interface fast enough, or a legacy system accessible is answered with a working experiment at the start, not discovered at the end.
Throw away and rebuild: once a prototype has answered its questions, it can be discarded. The production system is then built cleanly with what was learned, instead of growing out of an early experiment.

What you gain

Speed: prototypes in days, production systems in weeks rather than months. You see working software early and can steer by reacting to it rather than to documents.
Lower cost: one experienced engineer working with AI agents achieves what used to take a much larger team, with far less coordination overhead.
Quality: comprehensive tests, documentation, and multiple review passes are now affordable even on small projects. Refactoring early is cheap, so technical debt doesn’t have to pile up.
Consistency: conventions, logging, error handling, and documentation can follow the same standards across the whole code base.
No lock-in: you get ordinary code in your repository, a conventional technology stack, tests, and documentation. Any competent team can maintain it, with or without AI.

What to watch out for

AI-built software has its own failure modes, and a project plan should address them:

Plausible but wrong: agents produce code that looks right and isn’t. Review, tests, and a clear specification are what makes the approach work.
Gaming the tests: an agent told to make tests pass may weaken the tests. Tests need review as careful as the code they check.
Architecture drift: left alone, agents solve each task locally and the overall design erodes. Documenting the agreed architecture and checking against it in reviews counters that.
Clear requirements: agents build exactly what they are asked to build, quickly. Vague requirements produce the wrong system faster. That’s why each project starts with clarifying goals and constraints.
Understanding the result: software nobody understands is a liability. Documentation, architecture notes, and a handover to your team belong in the plan.
Rights to the code: purely machine-generated code may not be protected by copyright. The contract should therefore explicitly grant you all rights of use, and dependencies need checking for license compatibility.

Data sovereignty, privacy, and security

Building with AI means AI models see your requirements, your source code, and possibly your data. The measures below are the ones I typically discuss with clients; which of them a project needs is agreed at the start.

Who sees your code

Before a project starts, we agree in writing which models and providers may process your code and where:

Commercial models under business terms that exclude training on your data and limit retention, as the default for most projects
Your own accounts with the model providers, if you want contracts, billing, and logs in your hands
EU-hosted or self-hosted open-weight models for particularly sensitive code, accepting some loss of capability where that’s the right trade-off

Which option fits depends on your industry, your contracts, and your risk assessment. For more on the trade-offs, see AI for your organization.

Production data and systems

Agents rarely need real customer data to build good software:

flowchart TD
    models["Model provider<br/>agreed in writing"] <--> ws
    ws["Isolated workspace<br/>AI agents, project code,<br/>synthetic test data"]
    ws -->|"reviewed changes"| repo["Your repository"]
    ws -.-x|"no access by default"| prod["Your production<br/>systems and data"]

Development and testing usually use synthetic or anonymized data.
By default, agents have no access to production systems or real personal data.
Sometimes access to production makes sense, for example to diagnose an incident, analyze logs, or operate infrastructure. Then we agree on it explicitly, limit it to what the task needs, and log it, with your approval for consequential changes.
If real data is needed, for example to analyze a data quality issue, the work happens in your environment and under your rules, governed by a data processing agreement under Art. 28 GDPR.

Agents in a sandbox

A common starting point is to treat the agents themselves as untrusted:

They run in isolated environments, limited to the project they work on.
They get the credentials a task requires, and production secrets only where we have agreed on it.
Network access is restricted, and their actions are logged.
Changes are merged after human review, and deployments run through CI/CD or with explicit approval, following your process.
Infrastructure is described as code where possible, so changes can be reviewed before they are applied.

Secure code and dependencies

Depending on the project’s risks, measures can include:

Automated checks in CI: static analysis, secret scanning, and dependency audits on every change
Supply-chain discipline: AI models sometimes suggest packages that don’t exist, and attackers register those names. Dependencies can be verified, pinned, and scanned, and a software bill of materials (SBOM) can document them.
Extra care for critical code: where the risk justifies it, authentication, authorization, cryptography, and input handling get a threat model and a particularly thorough human review.

If the software you need has AI features of its own, such as an assistant or an agent, the security and privacy measures described in AI for your organization apply on top.

A typical project

Clarify: goals, users, constraints, the data and model policy, and which of the safeguards on this page the project needs.
Prototype: one or more working prototypes within days, to test ideas and assumptions with your users.
Specify: a concise specification and architecture, based on what the prototypes showed, that we both agree on.
Build: short iterations with regular demos, so you can steer early.
Accept: you test the results against your requirements and decide what goes live.
Hand over: documentation, tests, infrastructure code, and deployment support for your team, which runs the system, with continued development from me if you wish.

Contact

Have a project in mind? Write to .