Making AI an engineering team practice, not a party trick.

Most teams meet AI coding tools the same way: everyone gets a license, results vary wildly by person, and six months later nobody can say what actually changed. The individual-productivity framing is the trap. An agent is only as good as the context it works in — and context is a team asset, not a personal one.

So the work I find interesting isn't prompting. It's engineering the environment agents operate in: encoding the team's architecture patterns so they're applied consistently, wiring guardrails so autonomy is safe, and measuring what helps so the practice improves like any other system.

A skills platform

At Rebtel I founded and maintain an internal skills platform for Claude Code: eighty-plus versioned, reviewed skills that encode how our backend is actually built — the architectural patterns, the error-handling conventions, the testing strategy, the delivery pipeline. An agent picking up a task loads the same knowledge a senior teammate would explain at the whiteboard. Skills are treated like code: proposed, reviewed, evaluated against real tasks before they ship, and corrected when the codebase moves on.

Workflow skills — a spine for the lifecycle

The newer layer is a set of orchestrator skills that map the development lifecycle phase by phase: planning a feature into small, AI-ready tickets (each with its test level decided up front), implementing a ticket from cold intake to an opened pull request, and a machine pre-review that runs before any human spends attention — tests green as a precondition, every acceptance criterion checked against evidence, scope and pattern adherence challenged by a deliberate skeptic pass. Each orchestrator owns its spine and explicitly delegates every "how" to the pattern skills, so a piece of knowledge lives in exactly one place.

Determinism where judgment adds nothing

Not everything deserves a model's creativity. The repeatable endpoints of the workflow — cutting a correctly named branch, moving the ticket through its lifecycle, scaffolding the pull-request body — are handled by committed scripts, slash commands, git hooks and templates. The principle: skills describe, scaffolding executes. There is a ladder of enforcement, from templates up through hooks to CI and branch protection, and we deliberately sit at the advisory end of it — tooling that warns gets adopted; tooling that blocks gets bypassed.

The improvement loop, sandboxing — and evals

Three things made the practice trustworthy. Skill improvement lives inside the work loop: when a skill proves wrong or unsatisfactory mid-task, the rule is to say so and draft the revision in that same session — never silently work around it — so the person (or agent) holding the full context proposes the fix and the skill's owner reviews instead of reconstructs. A strict OS-level sandbox standard for agent sessions means autonomy doesn't require faith: the blast radius is bounded by construction. And skills ship the way code does — evaluated red-to-green against real tasks before they land, with negative results respected. One experiment taught us that reformatting a workflow as a formal state table looked rigorous but changed nothing the evals could measure; what mattered was stating the guard conditions completely. Format is not behavior.

• Encode, don't repeat. Anything you'd explain twice to a new teammate belongs in a skill the agent loads every time.
• Agents amplify your engineering culture — including the bad parts. Codified conventions and clean seams pay off double.
• Review is the human's job. The goal is not unattended code; it's a higher-leverage engineer who owns judgment, direction and the merge button.
• Measure it. If you can't see usage and outcomes, you have a vibe, not a practice.
• Treat prompts and skills as artifacts. Versioned, reviewed, evaluated — the same discipline as production code.
• Advisory beats blocking. Guardrails that warn get adopted; gates that block get bypassed. Save the hard gates for CI and the merge button.

In August 2026 Anthropic published the AI-native SDLC playbook — six stages, from intent capture to autonomous maintenance. When it landed, I did the only honest thing you can do with a playbook: mapped our practice against it, item by item.

Most of it was already running here, built independently months earlier: CLAUDE.md as institutional memory (ours since May), skills as versioned policy (May, now eighty-plus of them in two tiers), planning that collapses requirements and design into a skill-constrained spec with ADRs (June), skills shipped eval-tested (June), an OS-level sandbox standard (June), machine review passes before any human spends attention (July), parallel worktrees with subagent fan-out throughout — and the lifecycle spine itself: this very page described the two-tier workflow model, including /start-ticket and /open-pr, five weeks before the playbook was published, and merged pull requests carry those annotations from spring onward. The receipts are public git timestamps, not memories. Converging on a vendor's conclusions before reading them is about the strongest external validation a practice can get.

One deliberate divergence survived contact with the article: the playbook leans on hooks that block; we run guardrails that warn (the ladder above) and keep the hard gates at CI and the merge button — in our experience, adoption dies at the first false-positive block.

And the honest open list, straight from the playbook's later stages: continuous evals in CI gating configuration changes (ours run when skills change, not yet on a schedule), agents as non-interactive pipeline steps, control-band monitoring that files its own findings, scheduled security scans with validated results. That's the next year of the practice, already written down.

None of the above is specific to one company. I've distilled the practice into a field kit — a six-phase playbook with templates and delivery formats — built so a skill system can be stood up from scratch in any engineering organization: assess where the real patterns live, lay the foundations (context files, permissions, tool access), encode the patterns and the workflows, roll out through pilot teams, and install the maintenance loop that keeps the encoding true as the codebase moves.

I'm beginning to take this beyond one company, in three shapes: a hands-on workshop day on your codebase (your tickets, your repo — by mid-afternoon your team has shipped agent-driven changes and knows what to encode next), a two-week agent-readiness assessment that maps your patterns and quotes the build, and the skill-layer build itself — four to six weeks to a running system your seniors actually trust. If that sounds like your team's missing layer, email me.

Extending the lifecycle spine toward release and operations, multi-agent orchestration for large migrations, usage telemetry so skill improvement is driven by data as well as in-session flags, and the question I keep coming back to: what does a software team look like when the bottleneck is review and intent, not typing? Happy to compare notes — email me.