Which coding agents, for whom, with what access. Tools such as Claude Code, Codex or Copilot, and MCP where it fits.
Three ways I can help.
I am a software architect: thirteen years in software, the last three on AI in production, agents, retrieval, code automation, evals. Same three offers, in your vocabulary.
For software teams
For your businessNot a software company? Read the version for your business.
AI consulting
Make AI easy
AI consulting
The AI plan: two to three weeks, a plan, an architecture and a spec your team can build from.
My knowledge and my time, for the team and the product. Calls and emails with your leads and engineers until I know the codebase, the delivery flow and the product. Then a plan, an architecture and a spec your team can build from.
What you get
- A plan: where AI belongs in the product and the workflow, and where it does not.
- An architecture and an implementation spec: interfaces, data flow, failure modes, evals.
- A read on your setup: which agents, which access, who runs what.
- Hands-on setup with the team: rules files per repo, review gates, checks in CI.
How it goes
Read the ground.
A free intro call, then calls with leads and engineers, a look at the repo and the pipeline.
Rank the bets.
Candidates ordered by value and by risk, the weak ones cut.
Plan and spec.
Two to three weeks in: the plan, the architecture, how it gets evaluated.
Set up and advise.
I set the tooling up with your team and stay reachable.
For example
Whether the AI feature everyone asks for is worth building.
Why the assistant works in a demo and not in production.
What belongs in CI and what stays with a human reviewer.
Whether your docs and data can carry a knowledge assistant at all, RAG done properly.
How to tell a feature has got worse before a customer does.
An app built with AI that nobody can maintain or trust any more.
How to bring a sceptical team along without a mandate.
It can end with: buy the tool, or do nothing yet. Consulting stops at the plan. If you want it built, that is the next service.
AI implementation, end to end
Built, then kept running
AI implementation, end to end
Same start, then I build it. A first working version in weeks, not months, an MVP if you prefer the word, improved while it is used, then hardened and handed over.
What you get
- A working system in production, on your cloud and your accounts.
- Code in your repositories, reviewed the way you review your own.
- Evals, traces and dashboards, so you see what it does unattended.
- A handover session and documentation, then kept up to date as your product moves.
How it goes
Understand first.
The codebase, the flows, the constraints, the first thing worth doing.
Scope and design.
Interfaces, data, permissions, failure modes, what done means.
Ship a version.
Weeks, not months, behind a flag, measured.
Harden and hand over.
Evals, observability, documentation, then your team runs it.
For example
TodayReviews wait a day for a senior.
InsteadA first pass in minutes; the senior reads the rest.
TodayThe same class of bug ships every quarter.
InsteadChecks in CI that know your rules.
TodayOnboarding is weeks of asking the person who knows.
InsteadAn agent over the codebase, answering with the file.
TodayUsers click through ten screens to do one thing.
InsteadThey ask; an assistant does it inside your product, and remembers how they like it.
TodayAnalysts queue for the data team.
InsteadA data agent running read-only queries in a sandbox.
TodayDocs and tests lag the release.
InsteadBoth generated with the change, and reviewed.
TodayA feature shipped with no way to tell if it degrades.
InsteadAn eval suite and a dashboard.
TodayAI is a better autocomplete on a codebase it does not know.
InsteadAssistant, then implementer, then agents that finish the ticket under your rules.
Data residency and privacy, by design
- Your cloud, your accounts, your repositories. Least privilege per component.
- No training on your data, and residency in Europe when it is a requirement: regions, models or your own servers.
- What the model does not need, the model never sees.
- Human approval on anything irreversible; sandboxes for generated code; evals in CI, traces in production.
- GDPR written into the spec, not bolted on.
Websites, end to end
Found by people and by AI
Websites, end to end
Less common for a software company, but it comes up: a marketing site, a docs site, a launch page. End to end, while your team ships product.
What you get
- A static, fast site on your domain, in a repository you own.
- Content marketing can change without a ticket to engineering.
- Technical SEO and GEO, visibility in AI search, monthly care.
How it goes
Scope and look.
What the site has to say, and to whom.
Build and launch.
Static build, your domain, your hosting. A few weeks.
Monthly care.
Content, fixes and small changes.
For example
A marketing site the product team never has time for.
A docs site engines and assistants can actually read.
A launch page live this month, not next quarter.
A site rebuilt static, off a CMS nobody logs into.
Being cited when someone asks an assistant about your category.
Core Web Vitals that stopped being green.
Analytics without cookies and without a consent banner.
A second language, with hreflang, done properly.
You own all of it: the code, the accounts, the domain, the content and the documentation.