Does AI replace developers?

No. It replaces one narrow version of the job: typing code you already knew how to type. What remains was always the hardest part: knowing which problem is worth solving, knowing the domain, and seeing when an answer is subtly wrong. The engineer who understands the business becomes more valuable, not less.

Do you use AI to build our software?

Yes, where it genuinely helps: integrations, migrations, tests, first reviews, reading and summarising code. Everything AI writes is reviewed by an engineer who could have written it. What we deliver is ours, whoever typed the first version, and the source code is yours.

Is AI-written code secure?

Not by itself. Broken application code usually fails; broken infrastructure code keeps running, with permissions that are too wide or a port left open. So security and quality checks go into the CI/CD pipeline, and an engineer looks at every change to infrastructure, permissions and data.

Does AI make software cheaper?

More comes out of the same sprint. Our two-week sprints cost what they cost (small €4,000, medium €8,000, large €12,000, excluding VAT); work that used to be a sprint is now often a day. A small script that solves a problem is free. What does not get cheaper: deciding what to build, and the review.

What about the GDPR, NIS2 and DORA when AI writes our code?

The organisation stays responsible, not the model. We keep track of which code was written with AI, what was done with it and who reviewed it, so you can show that at an audit. Personal data does not go to a model without a data processing agreement, and not unless it is needed.

Can you help our team use AI well?

Yes, that is tech consultancy: first work out where it genuinely helps in your delivery pipeline, then set it up, measure what it changes, and take the team along. The tooling is rarely what is missing; the way of working around it is.

OpenAI: Advancing Artificial Intelligence for the Benefit of Humanity.

AI won't replace your developers. It will supercharge them.

Woordwolk met namen van AI-modellen: GPT, LLaMA, PaLM, BERT en meer

The pure coder is finished. The engineer is not.

AI-generated code has crossed a threshold. Engineers who spent years sceptical — Linus Torvalds and John Carmack among them — have publicly shifted toward acknowledging that what these models produce is now genuinely good. That is not a threat to developers. It is the end of one narrow version of the job.

What is left is the part that was always harder. Knowing which problem is worth solving. Understanding the domain well enough to spot when an answer is subtly wrong. You cannot build well for a travel company without understanding travel, or for a retailer without understanding retail. That judgement does not come out of a model.

So the work fuses. Engineering and domain expertise stop being separate roles. The developer who understands the business becomes more valuable, not less — and the one who only produced code has already been overtaken.

When code gets cheap, measurement gets expensive

This is the shift most teams have not priced in yet. When writing code was the constraint, output was a reasonable proxy for progress. Once code is cheap and abundant, that proxy breaks — and shipping more of it tells you nothing about whether you are better off.

The cost moves to the waiting. Thirty minutes a day per engineer lost to blocked builds, queued approvals and waiting on someone else works out at roughly €5,000 per engineer per year. Across a hundred engineers that is half a million euros a year — and it never shows up as a line in any P&L. Make code faster to write and you do not remove that cost, you concentrate it.

AI spend needs accounting for the way cloud spend did. Nobody sensible buys cloud capacity without knowing what it returns. AI tooling is heading the same way: the question moves from "are we using it" to "what did it actually change".

That is measurable, and we measure it. DX, DORA and SPACE give the frameworks; our Agile Analytics engine gives the data. And because code now arrives faster than anyone can review it by hand, CI/CD with AI-assisted quality and security checks stops being hygiene and becomes the control point that makes the speed safe.

WhereweuseAI,andwherewedonot

Our starting point is on the homepage and here once more: we use AI where it genuinely helps; accountability stays with people. Concretely:

Yes. Writing code we already knew how to write: integrations, migrations, tests, the tenth variant of a screen. Reading and summarising existing code before we touch it. A first review on pull requests, so the human review is about the design and not about a forgotten null check. Transcription and analysis in our own products, where it is the core of the product.

No. Deciding what should be built and why: that takes knowing the domain, and that does not come out of a model. Architecture and security without an engineer having looked at it. Infrastructure code that "works": broken application code usually fails, broken infrastructure code keeps running with permissions that are too wide, and you find out at an audit or an incident. And switching on AI as a substitute for a team that does not trust each other: the tooling is rarely what is missing.

The rule that follows is simple. Everything AI writes is reviewed by someone who could have written it. Faster, yes; unsupervised, never. That costs time, and it is exactly the time AI frees up elsewhere.

Vier treden onder elkaar — scan, sprint, project en doorlopend — met per tree de vraag die hij beantwoordt en wat hij oplevert.

Whatitchangesforyouasaclient

Three things, and the third matters most.

More software for the same money. Our two-week sprints cost what they cost (small €4,000, medium €8,000, large €12,000, excluding VAT); more comes out of them. Work that used to be a sprint (an integration, a boilerplate migration, a set of tests) is now a day. A small script that solves a problem is free: that is the kind of work AI turned from an afternoon into half an hour.

The same accountability. What we deliver is ours, whoever or whatever typed the first version. The law says so too: under the GDPR, NIS2 and DORA the organisation is responsible for the software, not the model. We keep track of which code was written with AI and what was done with it, so you can show that at an audit. How that works is in AI-assisted development under GDPR, NIS2 and DORA.

A different conversation about progress. When code is cheap, "how much was delivered" says nothing any more. The question becomes what is in production, whether it is used, and how fast a fault is fixed. We measure that, with the same numbers we hold ourselves to.

Twee ketens naast elkaar: wie uren verkoopt ziet de rekening kleiner worden als AI het werk versnelt, wie een uitkomst verkoopt levert met hetzelfde team meer.

Whatwebuildwithitourselves

We do not sell an AI strategy; we run products where AI does the work, and we pay their bills ourselves. That is where the opinions above come from.

CyberCloud CallController — Records, transcribes and makes phone calls searchable on what was said. Open source at its core, with retention rules for compliance.
Zenthropic — AI phone agents that answer 24/7, ask the right questions and leave a summary in Slack, email or the CRM. Response time under 800 milliseconds.
Agile Analytics — Measures where the time goes in software delivery: Git, CI/CD and Jira side by side, with DORA and SPACE as the frame. The instrument behind "when code gets cheap, measurement gets expensive".
ImageSenseAI — A plugin for WordPress and Strapi that describes images: alt texts for accessibility and findability, without the manual work.

Want to put AI to work in your own organisation? Tech consultancy is the service: work out together where it genuinely helps, then build it.

CyberCloud contactenscherm met per contact de naam en de gekoppelde vaste, mobiele en zakelijke nummers

What Agile Analytics looks like

A few screens from the product, as you see them in use.

Dashboard showing a total score of 88 out of 100 and five sub-scores — Delivery (DORA), Reliability (SLOs), Flow, Execution and Hours efficiency — each with a trend and a status. — Engineering Health Report
One number for the health of your engineering, built from five scores: delivery, reliability, flow, predictability and hours. One glance shows you where it hurts and which way it is moving.

Engineering Health Report
One number for the health of your engineering, built from five scores: delivery, reliability, flow, predictability and hours. One glance shows you where it hurts and which way it is moving.

DORA dashboard with four charts — deployment frequency, cycle time, MTTR and change failure rate — beside a repository filter list. — DORA metrics per repository
Deployment frequency, cycle time, time to restore and change failure rate, filterable per repository. The badges show whether you are performing at high or elite level.

DORA metrics per repository
Deployment frequency, cycle time, time to restore and change failure rate, filterable per repository. The badges show whether you are performing at high or elite level.

Sprint overview with transition and label filters, two distribution charts and a table of tickets moving from Review to Done, with assignee and confidence. — Sprint insights
Every status transition of every ticket, with timestamp, type, assignee and a confidence score. It shows where tickets get stuck instead of leaving you to guess.

Sprint insights
Every status transition of every ticket, with timestamp, type, assignee and a confidence score. It shows where tickets get stuck instead of leaving you to guess.

Service page with SLO cards for API availability and latency, each with a four-week history, above an error budget chart marked with deployments. — SLOs and error budget
Per service you see the current SLOs against their target and how much error budget is left, with deployments marked in the chart. So you know whether there is room left to release.

SLOs and error budget
Per service you see the current SLOs against their target and how much error budget is left, with deployments marked in the chart. So you know whether there is room left to release.

Team page with a kudos leaderboard of three members, DORA charts for deployment frequency and cycle time, and SLOs and error budget below. — Team overview
Everything for one team on a single page: kudos, DORA figures, SLOs and error budget, filterable by the current sprint. Usable in a standup without opening seven tabs first.

Team overview
Everything for one team on a single page: kudos, DORA figures, SLOs and error budget, filterable by the current sprint. Usable in a standup without opening seven tabs first.

Kudos page with the most recent praise, the total for this period, a leaderboard of five team members and a flow diagram of who gave kudos to whom. — Kudos
The praise team members give each other in their own channel, collected into a leaderboard and a who-thanked-whom overview. It shows how collaboration is going, not just how the numbers look.

Kudos
The praise team members give each other in their own channel, collected into a leaderboard and a who-thanked-whom overview. It shows how collaboration is going, not just how the numbers look.

Weekly timesheet for week 33 with the organisation projects Backend and Frontend below it, each with a description and an hours limit. — Time tracking
Log hours against organisation or personal projects, per week, right beside the numbers they feed. That turns hours efficiency into a score in the health report instead of separate admin.

Time tracking
Log hours against organisation or personal projects, per week, right beside the numbers they feed. That turns hours efficiency into a score in the health report instead of separate admin.

Whatwehavewrittenaboutit,bytheme

Our engineers write about what they run into. These are the pieces behind the position above.

Craft: what AI does to building itself

People: what it does to teams and the profession

Risk: security, compliance and what goes wrong

Dashboard met DORA-cijfers: deployfrequentie, doorlooptijd van wijzigingen en het percentage mislukte releases

Frequently asked questions about AI in software engineering

Does AI replace developers?
No. It replaces one narrow version of the job: typing code you already knew how to type. What remains was always the hardest part: knowing which problem is worth solving, knowing the domain, and seeing when an answer is subtly wrong. The engineer who understands the business becomes more valuable, not less.
Do you use AI to build our software?
+
Yes, where it genuinely helps: integrations, migrations, tests, first reviews, reading and summarising code. Everything AI writes is reviewed by an engineer who could have written it. What we deliver is ours, whoever typed the first version, and the source code is yours.
Is AI-written code secure?
+
Not by itself. Broken application code usually fails; broken infrastructure code keeps running, with permissions that are too wide or a port left open. So security and quality checks go into the CI/CD pipeline, and an engineer looks at every change to infrastructure, permissions and data.
Does AI make software cheaper?
+
More comes out of the same sprint. Our two-week sprints cost what they cost (small €4,000, medium €8,000, large €12,000, excluding VAT); work that used to be a sprint is now often a day. A small script that solves a problem is free. What does not get cheaper: deciding what to build, and the review.
What about the GDPR, NIS2 and DORA when AI writes our code?
+
The organisation stays responsible, not the model. We keep track of which code was written with AI, what was done with it and who reviewed it, so you can show that at an audit. Personal data does not go to a model without a data processing agreement, and not unless it is needed.
Can you help our team use AI well?
+
Yes, that is tech consultancy: first work out where it genuinely helps in your delivery pipeline, then set it up, measure what it changes, and take the team along. The tooling is rarely what is missing; the way of working around it is.