Software Engineering with Claude Code in 4 Weeks
A dedicated Base/labs architect for 4 weeks, taking your team to build software with AI the spec-driven way, with the right harness around the agent and governance from day one.
4 weeks full-time, or spread proportionally · 1 dedicated Base/labs architect · 1 client team of up to 10 people
Engineering companies that want to use Claude Code as a way of working, not just a souped-up autocomplete, starting with one team of up to 10 people: shipping real features and refactors faster, without losing control of quality, security and cost.
Claude Code without a method becomes "vibe coding": a vague request, the model guesses the requirements nobody stated, and the result is scope that grows mid-task, half-finished implementations and code that ignores the project's patterns. The bigger the change, the bigger the damage. The answer is not a better prompt but process and environment: first decide what to build, then how, and only then write code, inside a harness that limits and verifies what the agent does.
The spec-driven process, in practice
Instead of a loose prompt, every change goes through three documents and four review gates. Spec and plan are files in the repository: they survive between sessions, go into the pull request and can be read by anyone on the team.
1. Spec: what and why
The agent runs design questions (shape, data sources, edge cases, what stays out of scope) and writes the specification. Someone on the team reviews and approves it before any plan exists.
2. Plan: in which steps
From the approved spec, the plan defines what "done" means, which files change and an ordered list of tasks, each with the test that validates it. Human review catches tasks that are too coarse or out of order.
3. Code: task by task
For each task: a failing test, the code that makes it pass, refactoring and a review by a subagent that reads the change without the context of whoever wrote it. If a task contradicts the spec, work stops and goes back to the spec.
4. Final review: against the spec
An independent reviewer checks the whole change against the spec and the plan before merge, and a person approves.
The harness: the environment that controls the agent
The quality of what the agent delivers depends on the environment it works in, not just the model. Harness engineering is designing that environment. The most important deliverable of the 4 weeks is the first version of your company's harness, with a short tutorial on how to use it. The architect builds it together with the pilot team, and it lives in the repository.
Context
What the agent needs to know about the project: architecture, code standards, build and test commands and decisions already made, in a lean CLAUDE.md.
Memory
What must survive between sessions: specs, plans and conventions versioned in the repository, instead of depending on a conversation history.
Skills
Repeatable team procedures (opening a spec, reviewing a PR, generating a report), with deterministic steps where the result cannot vary.
Tools
What the agent can use: approved MCP servers, integration with CI, the task tracker and the repository, each with minimum permissions.
Constraints
Guardrails and a permissions policy that define what the agent does not do, with hooks for rules that admit no exceptions and clear autonomy limits.
Verification
Tests, automated checks and independent review that prove the change does what the spec asks before it reaches merge.
What we deliver
- The first version of your company's harness, in the repository: CLAUDE.md, skills, hooks, permissions and spec, plan and task templates. It is the most important deliverable of the engagement.
- A short tutorial on how to use the harness day to day, for the team and for whoever joins later.
- A Base/labs architect dedicated to the engagement for the whole period, leading it hands-on.
- A hands-on AI engineering course for the team, in 3 half-day sessions, using your code and your backlog.
- A complete development flow with agents: task and spec, implementation (feature, fix and hotfix), PR review, CI/CD, QA validation, bug identification and monitoring.
- Bug, vulnerability and performance detection with AI support, and software reports generated by skills.
- Model choice per task, context window and usage cost estimation.
- A permissions policy, approved MCP servers, telemetry and spend limits, defined with your security team.
- A runbook to take the process to other teams in the company.
How it works
Before we start
Together with platform, security, identity and network teams, we settle the decisions that must exist before anyone installs the tool. We choose the team (up to 10 people), the repository and the real features for the engagement, and capture the baseline from Git history: cycle time, review time and rework.
Week 1: harness v1 and first spec
The architect runs a repository diagnosis and builds the first version of the harness. The team takes the hands-on course, in three half-day sessions, and ends the week with the approved spec of a real feature.
Week 2: from spec to PR
Plan and tasks with tests, implementation with TDD, skills with deterministic steps and subagent review, pairing with the architect. Features, fixes and hotfixes go through the normal pull request flow, and the first changes reach merge. The harness is adjusted with every lesson learned.
Week 3: from PR to production
CI/CD, QA validation, bug, vulnerability and performance detection with AI, and long-running agents for specific events. MCP integrations, model choice and cost come in, along with a second cycle of bigger changes that touch many files. We start writing the tutorial from real usage.
Week 4: autonomy and handover
The team runs the full cycle on its own and the architect only reviews. Together we define the agents' autonomy limits. Your team takes over the harness, the policy, the MCP list and the spend report, and receives the final tutorial and the runbook for other teams. A readout with the numbers.
- The first version of your company's harness, versioned in the repository, with a short usage tutorial.
- A team of up to 10 people that runs the spec, plan, code and review cycle on its own code.
- Real features, fixes and refactors delivered during the 4 weeks, through the normal pull request flow.
- Templates and policy versioned in the repository.
- A runbook to extend the process to other teams.
- Engagement numbers against the baseline, for the readout.
We measure cycle time, PR throughput and review time against the baseline captured from Git history before the work, plus weekly usage and spend. We also track review rework and change failures, to know whether speed is costing quality.
- One team of up to 10 people, and a backlog of real features, fixes and refactors for it.
- Team members available for the three course sessions and for pairing with the architect.
- Engineering leadership defining which repository is in and what is off limits.
- Security, identity and network teams available for the initial decisions.
- One admin per area of responsibility to receive the handover.
Frequently asked questions
How does the architect's dedication work?
A Base/labs architect is dedicated to your team. The reference format is 4 weeks full-time. If the 4 weeks are spread over a longer calendar, the architect's dedication is proportional: the total effort is the same, distributed over more time. We agree on that when designing the engagement.
Can I hire the architect after the engagement ends?
Yes. After the handover, the company can hire ad hoc hours of the architect for follow-up, for example to review the harness, answer questions or support the arrival of other teams.
What is the harness?
It is the environment around the coding agent: project context, memory between sessions, skills, tools, constraints and verification. Instead of relying on a perfect prompt, the team designs that environment once and reuses it on every task. The first version of your company's harness, with a short usage tutorial, is the main deliverable of the engagement.
Why a single team of up to 10 people?
Because a dedicated architect can closely follow a team of that size, on real work, during the 4 weeks. The harness and the runbook left behind are the basis for taking the process to other teams afterwards.
Is this just training?
No. The course is one part of the first week. The rest is engineering: the team delivers real changes from your backlog, through the normal pull request flow, with the architect alongside.
How is this different from Claude Code's plan mode?
Plan mode produces a plan inside the session itself. In the spec-driven process, spec and plan are files in the repository, reviewed by people and reused across sessions and teams.
Do you use Spec Kit, Superpowers or BMAD?
We choose the flow based on your context. Open frameworks like these help structure the process, and what matters is that spec and plan live in the repository and go through review. For small changes, like a style tweak, the full process is overkill, and we teach the team to tell the difference.
Is our code exposed?
The permissions policy defines what Claude Code accesses and which commands it runs, and is designed with your security team. The model access route (Claude Enterprise, Console or a cloud such as Bedrock, Google Cloud or Foundry) is one of the first decisions, and the data terms of your agreement continue to apply.
Want to talk about this offering?
We start with a conversation to understand your scope. Each offering has a closed scope and price per phase.