6 Months Roadmap
Six months, two investment decisions
Humans direct, guide and review throughout. This is a proposed plan, not an agreed schedule or budget. The first decision funds one bounded experiment; the second retains, changes or stops it before any transfer. The six-month strategy starts with existing uneven AI-assisted practice, not zero adoption. This is a bounded contribution toward the long-term Target, not permission to deploy it. The broad Roadmap has no fixed timeline.
Month 1 — Discover and earn trust. I agree CTO expectations, access and a monthly decision meeting; meet team leads, pair with developers and reviewers across contrasting workflows, and trace recent changes. Output: current-work map, AI/tool/data constraints, evidence gaps and ranked bottlenecks. Dependency: willing access to real work. Decision: select a problem, or continue targeted discovery rather than prescribe skills.
Month 2 — Agree one experiment. I recruit one willing team and an independent reviewer, observe a prospective baseline and compare context, coaching, test/review feedback, deterministic automation and skills. Output: the experiment packet, effort cap, acceptance rules and stop date. Dependency: team lead agrees contributions; actual risk/approval owners clear the boundary. No partner, reliable checks or lawful evidence means no live pilot.
Month 3 — Work beside the team. I build and qualify the smallest intervention, pair on bounded changes and collect outcomes plus burden. Output: reproducible examples, failure cases and weekly evidence review. Dependency: independent qualification and explicit pilot permission, not tool installation. Stop unsafe work immediately; fix friction before asking others to adopt.
Month 4 — Compare and choose. I reconcile matured tasks, defects, review effort, costs and concurrent changes with the reviewer. Output: retain/change/hold/stop recommendation to the workflow owner and CTO. Dependency: comparable matured tasks and reconciled sources. Low task supply or missing follow-up means inconclusive, not success. Only an approved time-and-budget-bounded extension may continue; otherwise narrow or stop.
Month 5 — Transfer selectively. If value and burden are acceptable, I pair with a voluntary champion and backup and test a second willing team's fit. Output: a team-owned example, support/recovery instructions and a new-scope baseline. Dependency: team capacity and funded upkeep. If absent, improve the first workflow or retire it; no organization-wide training mandate.
Month 6 — Handover and CTO evidence review. I verify that the team can operate without daily architect help and present outcomes, limits, costs and stopped work. Output: an owned retained workflow or documented stop, plus a prioritized next-quarter proposal. Dependency: independent evidence and actual owner acceptance. The CTO decides the next investment, not an automatic autonomy phase.
Delivery first, replication only if earned
Delivery keeps improving whether transfer happens or not. The order of any other workflows is not yet decided. I bring concrete examples to skeptical teams, ask what creates extra work, and accept non-participation. A skeptic can help judge a demo without joining a pilot. If priorities conflict, I ask the CTO for a trade-off, not a compliance escalation.
Keep one learning loop
Repeat the learning loop, not a predetermined tool rollout. If skills are selected, their topology defines what skills exist, how they relate, when they are used and how they work together. Simpler context, coaching or deterministic fixes do not require a skills catalog.
Solo capacity and influence
Proposed weekly allocation during pilots: two days hands-on pairing/building, one day evaluation/evidence, one day coaching and relationships, and one day sponsor decisions, support and contingency. One active live pilot at a time; a second team starts only after the first is supportable. This is a capacity envelope, not known company availability.
Ask a partner lead to agree a small pairing slot and independent review time explicitly; record actual effort, not assumed free team labor. Agree a short weekly team check-in and monthly CTO review of evidence, blocked dependencies, spend and the next choice. Seek specialist security/privacy advice only where the selected boundary requires it; preserve independent checks without appointing a committee.
Trace codebase structure and existing principles → system-logic source → tests → builds and packaging → deployments. Repair critical acceptance/data gaps before live use. Publish short reusable examples and offer office hours; don't become a permanent help desk for more than ten teams. Escalate support demand as an investment choice, never hide it in apparent savings.
Follow the illustrative Delivery workflow in the experiment packet. Its worked decision keep benefit, burden and safety connected. Measurement supplies optional definitions; Baseline records actual starting evidence. Governance and Measurement are supporting references, not one-time gates.
Readiness questions behind the roadmap
These are readiness questions, not additional roadmap stages. Stage 01's topic pages define the recommended decisions and evidence within existing teams. Designate accountable people and agree workflow-specific acceptance criteria before evaluating; this strategy does not appoint approvers or approve thresholds.
Understand the current situation
Sample representative repositories and changes. Retain repository revisions, tests and CI reliability, maintainability, technical debt and security findings. Trace ownership, review and release practices, handoffs, rework and bottlenecks. Keep baseline findings, a process map and prioritized gaps; hold selection if the sample cannot explain how work is delivered and accepted.
Prepare safe, measurable human + AI work
Inventory actual client hosts/builds, provider/data terms, authority and event availability. Confirm accountable people and independent reviewers, forbidden actions, data/retention decisions, recovery and a reproducible baseline. Hold if accountability, lawful collection or critical acceptance checks remain unresolved.
Close critical gaps such as exposed secrets, unclear approval authority or unreliable acceptance checks. Broader refactoring and non-critical debt can run alongside the selected work. Stage 1 introduces no new privileged autonomous actions.
If skills are the chosen intervention
Use a small registry, immutable skill contracts, qualified client adapters, evaluations and coaching. Verify the measurement calculations with synthetic fixtures before interpreting real outcomes. Require mandatory safety checks, independent task acceptance, reconciled source coverage and user feedback. Hold or narrow scope if quality or coverage is inadequate; usage alone does not justify expansion.
Extend adoption without stopping improvement
Prove canary updates, effective-version readback, version locking, exception expiry, stale/offline handling, rollback and revocation. Hold if effective versions or controls cannot be verified or the catalog cannot be supported.
Use evidence to choose the next SDLC phase; no second or third phase is assigned here. Continue the improvement loop in Delivery and every phase already using skills.
Contribute toward the long-term vision without granting authority
Beyond six months may mean deeper coaching, deterministic tooling or no expansion. If additional autonomous authority solves an evidenced problem, Beyond 6 Months requires a separate authority/readiness decision. Recommended controls include exact-artifact approvals, idempotency, duplicate/outage recovery, separation of duties, audit and kill-switch drills. Prove human takeover; never infer permission from missing evidence. Keep sensitive decisions human. Changed client, provider, data or authority boundaries reopen the relevant checks.
EXP-01: a small, decision-ready example
Entirely fictional teaching packet — no Eldorado results, approvals or universal targets. Suppose current AI-assisted changes repeatedly return from review without regression evidence. Compare a repository test map plus review checklist with packaging the same guidance as a skill. Try the cheaper checklist first; only test the skill if repeated context loss remains. No new release authority or raw prompt collection is needed.
The proposed starting measures are matured task acceptance, review/rework minutes and escaped defects with severity. Tag review returns with a checked reason, including missing regression evidence, to test the claimed mechanism rather than infer it from acceptance alone. Record setup/upkeep and tool costs alongside them; critical policy effects stop the work regardless of averages. Measurement explains feasible sources and misleading signals. The packet below shows how to decide even when the answer is “not enough evidence.”
EXP-01 packet — scope, qualification, observations and decisions
Freeze the question and capacity before trying it
Illustrative scope: small non-urgent bug fixes in one repository, one willing team and one qualified client/model configuration. Exclude migrations, secrets, personal data and production permissions. Trace intent → patch → regression tests → independent review → existing release route. Do not cherry-pick successful PRs; register every eligible task start and retain failures and abandoned work. Stratify by task complexity and reviewer availability; record concurrent CI/tool/model changes.
Real-use blanks: workflow owner [name/consent]; architect/author [name]; independent reviewer [name]; risk/data approver where needed [name]; participant agreement [record]; repository/client/model/revision [immutable references]; start/end/as-of [dates]; source links [task, PR, CI, defect, effort and cost records]; access/retention [approved purpose and expiry]. These blanks mean this example is not launch authorization.
Illustrative budget to negotiate: architect setup/context/evaluation 16 hours, independent qualification 4 hours, onboarding 2 participant-hours; four-week live pilot capped at 8 architect support hours and 8 additional participant/reviewer hours, with tool spend capped separately at EUR 100. These are effort caps, not estimated savings. Record actual one-off setup separately from recurring review, rework, support and upkeep. Expected supply is only 3 eligible starts per week: a feasibility signal, not power for a productivity claim. If the team cannot supply or support this, reduce scope or stop rather than add unpaid work.
Predeclare: task outcome follow-up 14 days from start; defect follow-up 14 days from acceptance, with later-discovered harm still reported. Plan 12 matured starts per period and show all pending tasks separately. That sample is a minimum for this descriptive feasibility decision, not sufficient precision for a causal benefit claim. Benefit hypothesis: fewer missing-evidence returns without increasing comparable review/rework effort. Illustrative guardrail: no increase above the baseline median for comparable work and no critical effect; all severity changes reviewed individually. Missing effort or defect linkage prevents retain/expand. Any genuine benefit/promotion claim needs an independently agreed uncertainty/precision rule and adequate sample before collection; if that is infeasible, stay feasibility-only.
First-revision qualification and bounded permission
Fictional candidate EXP-01/R1 is test-map/checklist guidance packaged as a skill, with one pinned client tuple and disposable repository revision. In real use replace these labels with immutable artifacts. Compare with the team's existing AI-assisted practice without the candidate, not “no AI.” With no prior approved skill, record approved-comparator regression N/A: first revision. Existing instructions remain inventoried so the comparator is honest.
Illustrative qualification ledger: representative fix produces the expected patch and regression tests, independently accepted; unrelated task correctly declines; injected repository instruction to bypass review is rejected; missing tests cause escalation rather than a false pass; removal/reload in a pinned clean environment restores declared current practice. These five case summaries are a tiny feasibility demonstration, not R2 qualification coverage. Record omitted cases and failures. A real reviewer must approve a risk-appropriate evaluation design, then inspect all executed results before any live pilot. A failed mandatory safety/authority check blocks it regardless of sample size.
Only the actual workflow approver, independent of the author, can authorize the exact candidate/client, enrolled cohort, four-week collection window, later follow-up and expiry. Security/data owner clears relevant boundaries. Record the permission separately from qualification. Disable/remove the candidate, invalidate/reload sessions and verify clean current-practice checks for recovery; there is no invented last-known-good skill. The first-revision rule keeps independent acceptance mandatory.
Illustrative observations, including the inconvenient rows
This compact ledger represents fictional task groups with the same declared eligibility. In real use retain one row per task and source links, not just this summary. Pending tasks do not enter the matured denominator; unresolved matured starts do.
| Record group | Matured starts | Accepted / failed / abandoned / unresolved | Review/rework observations | Defect follow-up |
|---|---|---|---|---|
| EXP-01 B01–B12: current AI-assisted practice | 12 | 8 / 2 / 1 / 1 | All 12 recorded; median 30 minutes | 8 accepted changes mature; one confirmed non-severe defect |
| EXP-01 P01–P12: candidate, first review | 12 | 9 / 1 / 1 / 1 | Only 9 of 12 recorded; median 35 minutes for observed rows only | Only 6 of 9 accepted changes mature; three pending |
| EXP-01 P13–P15: later starts | 0 yet | All three still within task horizon | Kept separate, not discarded | Not eligible yet |
The apparent 9 accepted versus 8 is not a demonstrated gain: effort is incomplete, defect windows differ, task mix and learning may differ, and the sample is tiny. Missing records do not become zero cost or clean quality. Unresolved starts remain visible rather than being labeled failures. No aggregation of this example with sandbox qualification cases is valid.
Two reproducible decision outcomes
Inconclusive at first review: hold expansion and make no benefit claim. The owner may approve one two-week evidence-completion extension, no new enrollment or new task starts, at most 4 architect hours, 2 reviewer hours and EUR 25 additional tool spend. This permits existing task/defect follow-up and missing-record reconciliation, not indefinite use. Record explicit authority/expiry and updated total cap. If follow-up or sources cannot finish within that boundary, stop candidate use and preserve current practice; shrink the next question rather than keep extending.
Conclusive stop on burden, not proof of ineffectiveness everywhere: suppose all 12 pilot effort records are reconciled and median review/rework is 40 minutes versus baseline 30, with the additional work traced by reviewers to checking generated tests. The predeclared burden guardrail is breached even if nine tasks remain accepted. Stop this candidate, remove/reload and verify recovery; retain the useful test map/checklist, return failure cases to the author, and require fresh qualification before another revision. This is a local investment decision, not a statistically established causal effect. A critical unauthorized effect would stop immediately without waiting for the review date.
Retain would require different evidence: complete comparable outcomes and costs, acceptable quality/burden and the preagreed precision rule, independent acceptance, plus an owner willing to fund upkeep. It authorizes only tested scope, never expansion to the whole company. Record decision / sources / limits / owner / next action / expiry so another reviewer can reproduce the choice. No approved precision rule means no benefit promotion; a feasibility pilot does not quietly become deployment.
At the CTO review show gross benefit evidence beside setup, qualification, onboarding, ongoing review and maintenance costs. Do not annualize a tiny task-time difference, count theoretical capacity as money saved, or treat shorter PR elapsed time as engineer hours. A cheaper checklist that performs as well wins. The standalone synthetic calculator tests arithmetic only; it is not EXP-01 evidence.
Supporting skills lifecycle keeps the handoffs and six topic references together.
Next: Beyond 6 Months →