# Run AI4SE as a Business: Double Diamond, Specs, then Skills
Treat AI4SE as a business and the deliverable cannot stop at slides. Consulting engagements can run Spec-Driven: use Design Thinking / Double Diamond to move through pains, opportunities, and solutions; clarify IT4IT-related specifications; then agentify and skillify—atomic Skills first, Goal-driven Agents later, plus Commands, Hooks, and MCP. The hard part is defining the problem and converging on a solution.
Many peers who do not really do consulting — engineers by trade, or trainers by trade — treat some market “authoritative answer” as treasure: a hot open-source stack, a popular course, the Agent lineup from a flagship case study. A tiny team can sometimes copy-paste and still limp along. In a mid-sized organization, that cargo-cult almost always fails.
The reason is simple: every organization has its own logic, role boundaries, and collaboration inertia. Someone else’s answer solved someone else’s problem. AI4SE transformation has to rediscover a path that fits this organization — you cannot land with the answer already chosen, and you cannot treat “which Agent / which curriculum we adopted” as the deliverable. What clients buy is a verifiable change in how work gets done: which value stream runs cleaner, which human–AI handoff can be accepted, which assets are reusable next week. The three workshop failure modes on this site usually share the same root: after the excitement, what remains is someone else’s tool memory — not an operable path of your own.
Thesis: Operate a Spec Pipeline
Running AI4SE as a business means you need a value chain, specifications, and shippable assets — not a pile of demo scripts.
The Open Group positions IT4IT as managing the business of IT — a reference architecture and value streams for “IT as a business.” Consulting is the same shape: clarify the Specifications that describe R&D and delivery work, then talk automation and Agents. Otherwise an Agent is only executing the goal it invented.
One-line formula:
Double Diamond cadence × IT4IT Spec × assetization (Skill / Agent / …) = operable AI4SE consulting
That is Spec-Driven Development lifted from “write a Spec before code” to the consulting layer: the engagement itself can be Spec-Driven. Specs are the source of truth for ways of working and value streams; agentic / Skill packaging is the second half of delivery.
For the org-level pilot frame, see AI4SE Pilot Transformation for Mid-to-Large R&D Organizations. This piece is about how consulting operates that chain.
Three Frameworks, Three Layers
Do not mash Double Diamond, IT4IT, and SDD into one buzzword. They sit on different layers:
| Framework | Owns | Consulting artifact |
|---|---|---|
| Double Diamond | Diverge / converge cadence | Pain inventory → problem definition; opportunities → solution selection |
| IT4IT | Reference architecture and value streams for the “IT business” | End-to-end capability and data-object map (Spec skeleton) |
| SDD | Spec as source of truth and gate | Specs that can be reviewed, accepted, and handed to Agents |
The Design Council’s Double Diamond insists: understand the problem before answering it — diamond one is problem space, diamond two is solution space. Our piece on Design Thinking: cadence, templates, AI brainstorm already covers the three-layer stack; here we only borrow the cadence discipline.
On the SDD side, Thoughtworks / Fowler discussions often place practice on a spectrum: spec-first → spec-anchored → spec-as-source. Most consulting work is fine at spec-first / spec-anchored — Specs must be reviewable, editable, and usable as pilot gates. You do not need to fetishize spec-as-source (“humans never touch generated artifacts”).
Pipeline 1: Pain → Opportunity → Solution
Do not skip the order. Jumping to tool choice before problem definition is an empty second diamond.
| Phase | What you do | Typical output |
|---|---|---|
| Discover | Interviews, as-is value streams, friction (where IT4IT streams break) | Raw pains and evidence |
| Define | First hard converge: a debatable problem statement | Who, what pain, what evidence, what success, what we will not solve |
| Develop | Parallel opportunities: which handoffs to accelerate, what can become a Skill | Opportunity wall / elevator-pitch set |
| Deliver | Second hard converge: a pilotable solution slice | 1–2 bounded pilot slices + first Spec |
In practice, the workshop Pair → Group → Plenary funnel hardens both convergences: decisions must persist, not die on sticky notes. Elevator pitches and journey maps supply exit criteria — without shape, multi-round brainstorming never agrees on “done clarifying.”
Cadence rule: no vendor selection while diverging; no scope growth while converging.
Pipeline 2: Clarify the IT4IT Spec (Consulting SDD)
In code-side SDD, Specs are the truth of function and design. In consulting, Specs are the truth of ways of working and value streams.
A one-page consulting Spec should at least answer:
| Slot | Question |
|---|---|
| Value-stream segment | Which delivery slice? What are the upstream/downstream handoffs? |
| Roles and duties | What definition rights and vetoes stay with humans? |
| Inputs / outputs / gates | What must be true before work proceeds? |
| Human–AI boundary | What can be script / Skill / Agent; what must stay human judgment |
| Acceptance evidence | What counts as pilot success — reproducible and measurable |
“Change goes through the Spec” still applies: if pilot scope moves, edit the Spec before Skills or Agents, or demos will drive drift. A tool list without a Spec falls into the trap described in Humans define, machines execute — machines scale a process that was never made explicit.
Pipeline 3: Duty Transfer and Asset Evolution
Agentic / Skill packaging is transferring already bounded human duties to AI. The usual carriers are Skills and Agents; in coding-agent ecosystems you also accumulate Commands, Hooks, and MCP as connectivity assets.
| Stage | Carrier | When |
|---|---|---|
| Early | Skill (atomic capability pack) | Procedure is describable, trigger surface is narrow, verification is writable |
| Converge | Agent (Goal-driven) | Multi-step loops need planning autonomy, with humans still owning acceptance |
| Companion | Command / Hook | Deterministic gates and repeatable actions — things the model must not merely “remember” |
| Connect | MCP | Reach external systems (tools and data); not the methodology itself |
They compose; they are not mutually exclusive choices:
- Skill answers “how we do this the right way” — see Nine types of Claude Code Skills
- MCP answers “can we reach that system” — see MCP as a standard interface
- Hook answers “this must happen; the model cannot skip it”
- Agent answers “under a clear Goal, who runs the closed loop in an isolated context”
Start with Skills to keep blast radius small: atomic capabilities are reviewable, replaceable, and fail narrowly. Once Goals and acceptance are clear, converge Goal-driven into Agents — do not stack “universal collaborators” first; enlarge autonomy only after duties are sharp.
Where It Breaks: Two Convergences
The whole engagement diverges and converges, but most failures land on Define the problem and Deliver the solution.
| Signal | Usually means |
|---|---|
| Still comparing models / plugins, no “what we will not solve” | Define incomplete |
| Opportunity wall is full; no pilot slice with Spec and asset boundaries | Deliver incomplete |
| Skills proliferate without Goals or acceptance | Assetization spinning; never converging to Agents or operable capability |
| Treating MCP or an Agent product as the solution itself | Spec skipped; second diamond captured by tools |
Pin the cadence: no deep tool selection before the first diamond converges; on the second diamond, leave with 1–2 slices and park the rest in the backlog. Funnels and ORID-style process discipline exist so consensus lands in one Spec — not in meeting atmosphere.
Anti-Patterns and a Minimal Week
Anti-patterns
- Treating slides as the deliverable — no Spec, no assets, no acceptance evidence after the pilot
- Buying Agents / platforms first, hunting for pain later
- Skills only grow; never Goal-driven converge
- Encoding deterministic gates as “please remember to lint” Skills instead of Hooks
- Counting MCP connections or Agent headcount as success
Minimal actions this week
- Pick one friction point on a real value stream
- Write a one-page problem definition (including what you will not solve)
- Add a half-page consulting Spec (human–AI boundary + acceptance evidence)
- Run one Skill-level pilot (reproducible and reviewable)
- Decide next week whether to Goal-ify into an Agent — on evidence, not vibes
One-line close: Running AI4SE as a business means operating a Spec pipeline — Double Diamond to find the right problem, IT4IT Specs as truth, then transfer human duties onto Skills, Agents, and companion assets. Divergence is easy; the two convergences are the work.
References and further reading
- Design Council: The Double Diamond
- The Open Group: About IT4IT
- Thoughtworks: Spec-driven development; Martin Fowler site discussions of the SDD tooling spectrum
- AI4SE Pilot Transformation for Mid-to-Large R&D Organizations
- An AI4SE Workshop Is Not a Training Class
- Design Thinking in AI4SE
- Spec-Driven Development: Specs as the Source of Truth
- Humans Define, Machines Execute
- Nine Types of Claude Code Skills
- MCP: A Standard Interface