An AI Workflow Design,
in full.
Not consultancy to redo every time, but a reusable playbook. This is the Software Development department example, open and free: what to really automate across the lifecycle, with which tools, in which phases and with which controls when it's AI writing the code but the merge stays your responsibility. It's also the department we live in: this site and our products are built this way, every day. The exact shape of what we graft into your business.
What to really automate
The pattern here isn't repetitive volume as it is in support: it's the stage. The most common misreading is to reduce AI for developers to autocomplete in the editor — in reality it touches the whole cycle, from architecture to code, review, tests, CI/CD and on to operations. But maturity changes drastically from one stage to the next: some markets are real and crowded, others have a single serious vendor, others aren't even a product category yet. You automate where the independent evidence holds up, and you leave the judgement on the merge to a person.
- Assisted code writing (completion and chat in the editor) al posto di: Typing repetitive code and boilerplate by hand
- A first automated review pass on pull requests al posto di: Waiting for a human reviewer's first comment
- Test generation as scaffolding al posto di: Writing the test skeleton by hand and maintaining selectors
- Automated diagnosis of pipeline failures al posto di: Reading build logs by hand to find the cause
- Incident summaries and root-cause assistance al posto di: Reconstructing the timeline by hand during an incident
In 2025 a controlled study of sixteen experienced open-source developers measured them 19% slower with AI tools on code they knew well — even though they had expected a speed-up and came away convinced they had gone faster; METR itself then walked that headline back in early 2026 (the control group had probably self-selected, leaving out the people who benefit most). The DORA 2025 report records adoption at 90% and individual output rising, but flat team delivery metrics and growing instability: "AI amplifies existing practices, it doesn't fix dysfunction". These are indications of direction, not promises of results. The number that matters for an SME is a different one: perceived speed is not speed — it has to be measured on your own work, not taken from the brochure.
Two models, not a shopping list
The 2026 market for AI development tools splits into two models useful to an SME. The right choice doesn't depend on the most-cited tool, but on how much test and review discipline you already have in house. The platforms promising full autonomy remain a reference ceiling, not a starting point.
Editor assistant + a first review pass
The pairing that covers the most mature stages, the ones with the most solid evidence: a writing assistant inside the editor and an agent that takes the first pass on the pull request, leaving approval and the merge to a person. It's the right cut for the SME tier because it's exactly what the most rigorous independent study recommends: review agents augment human review, they don't replace it. The concrete gain is removing the wait for the first comment, not removing the reviewer.
An autonomous agent that writes and approves
An agent that takes a task and carries it all the way to the pull request — and, in the extreme cases, all the way to self-approval. There is a real, documented counter-example (a company that self-approves more than 19% of its own pull requests, with AI code regressing less than hand-written code), but with a large asterisk: a bespoke control architecture, explicit exclusions for the high-risk paths, a full audit trail. An SME adopting an off-the-shelf tool doesn't inherit those safeguards: it's a later stage of maturity, not a day-one choice.
Our default choice for an SME is to start from the augmented level — AI that makes a person faster while they stay responsible for the merge — because it's the only level where the independent evidence holds up. Autonomy is earned later, once solid tests and excluded sensitive paths already exist and can be verified. Picking the exact vendor, the due diligence on its code-handling terms and on where your sources end up are part of the graft.
The phases of the graft
Every item in the playbook carries a phase, so halfway through you filter by "what comes next" instead of re-reading the pilots you've already closed. In development the order is set by the maturity of the stages, not by wishful thinking: you start from the stage with the most solid evidence and the lowest risk, and you widen only where the review gate has already proven it holds.
-
1
Pilot
First 30 daysA single stage, not the whole cycle — usually assisted writing or the first review pass. A named owner, the usage policy written (what may leave the company perimeter and end up in a third-party model), the merge always in a person's hands, and the success criterion defined before the tool: a number measured on your own work, not perceived speed. That's the direct lesson of the METR study.
-
2
Scale
First 90 daysWhat worked extends to the adjacent stages: test generation as scaffolding and automated diagnosis of pipeline failures — the most mature CI/CD stage and already today the most widespread use case. It widens only where tests and review already hold up: sensitive paths stay excluded, they aren't forced into the agent. Automatic writing of pipeline configuration doesn't belong here: it isn't a product category yet, and it's a documented attack surface.
-
3
Ongoing
Steady stateContinuous monitoring on a measured number, not a perceived one — and on the debt: churn, duplication, share of refactored code. Discipline is the multiplier: AI amplifies what you already have, so the control isn't the tool, it's the gate around it. The playbook gets updated at every change of stack or policy, not archived.
The compliance overlay, and who governs it
Generated code brings ownership and secrets questions
It's the control most specific to this department, and it didn't exist before AI. Two questions, both open: who owns the code the assistant generated, and what exposure the material it was trained on creates; and where your sources end up — an assistant that sends proprietary code to a third-party model is a secrets-leakage channel, distinct from the privacy questions in the rest of the playbook. Reading the EU AI Act for development tools most likely lands on a minimal-risk, general-purpose profile rather than high-risk: but that has to be verified vendor by vendor before advising a client on it, not assumed.
Review discipline cannot be delegated
Generated code is not secure by default. A by-now classic piece of academic research found vulnerabilities in around 40% of the programs an assistant generated across 89 scenarios; 2026 research measured AI-generated C++ as roughly twice as likely to produce a runtime violation as human-written code — and found that static analysis alone makes the two look equally safe, which is misleading. On the pipeline side, a 2026 study of more than 13,000 "agentic" workflows found hundreds of confirmed injection vulnerabilities, many of them zero-days. That's why the human gate before the merge isn't bureaucracy: it's the control that counts, exactly as source grounding is in support.
Compliance overlay
Repositories contain secrets, credentials and sometimes personal data inside tests and fixtures: it raises the same GDPR questions as the rest of the playbook, plus the ones specific to this department. What leaves the perimeter towards a third-party model, minimisation of what you pass to the model, retention of prompts and logs, licence and provenance of the generated code. Due diligence on the vendor and its code-handling terms is a non-negotiable part of the software choice.
The AI owner
No big-enterprise Center of Excellence: one or two people named as AI owner are enough. Five responsibilities stay with them — setting priorities, who approves what (which paths the agent never touches, first of all), enabling the team, reusable standards and monitoring on measured numbers. It's the owner who keeps the control gate alive: when test and review discipline frays, AI accelerates the debt instead of preventing it. We're not saying it from the outside: this gate is the same one we keep shut on our own products, every day.
The same pattern, other departments.
-
Sales
Lead scoring, automated follow-ups, CRM hygiene.
See the full example -
Marketing
Campaign optimisation and copy with brand oversight.
See the full example -
Operations
Process automation, reporting and anomaly detection.
See the full example -
Finance & Administration
Accounts payable, month-end close and cash forecasting, with a human on the money.
See the full example -
HR & People
Screening, onboarding and an internal knowledge base, with high-risk hiring kept under oversight.
See the full example -
Customer support
Ticket deflection, triage and agent-assist, with answers anchored to sources — no hallucinations.
See the full example
This is the example. We graft yours.
The other departments follow the same pattern. Start from the free assessment to find out where it makes sense to begin, or let's talk directly.
Example for guidance only: it does not constitute legal or tax advice or a compliance assessment.