msabir.dev

People + agents / one engineering practice

The team behind the work.

One human. A team of agents. A software factory built around clear specifications, independent review, and evidence.

Muhammad Sabir smiling, wearing a dark jacket and a light shirt.

The human in the loop

Muhammad Sabir

Engineer, architect & platform builder

I set the direction, decide the scope, and own the outcome. My agents bring implementation and review capacity; the engineering decisions remain mine.

More about my background

The agent team

Different models. Shared standards.

These are the names in my working team. Assignments can change with the task; the specification and review standards travel with the role.

  • Fable

    Claude

    Planning & orchestration

    The default conductor in my factory roster: keeping the specification, questions, and next steps connected.

  • Opus

    Claude

    Implementation

    One of the implementers assigned a bounded brief, an isolated worktree, and a clear verification contract.

  • Sonnet

    Claude

    Task-based collaboration

    Part of my agent roster, with the role and scope chosen for the work at hand.

  • Astra

    Codex

    Review & integration

    The default reviewer and lander in the factory roster: examining specifications and checking implementations against their briefs.

  • Sol

    Codex

    Implementation

    Works from the same briefs and acceptance criteria, returning code and a handback for independent review.

  • GLM

    OpenCode

    Implementation

    A member of the configurable implementation roster, using the same worktree and handback conventions.

  • Kimi

    AI teammate

    Review & development

    Works with me on reviews and development. I’m now bringing Kimi into the Software Factory workflow as well.

  • DeepSeek

    OpenCode

    Implementation

    Another implementation option in the roster, held to the same brief, checks, and review process.

These agents are my team. We work through requirements, challenge specifications, write implementations, and examine the results together. I bring the product direction, engineering judgment, and responsibility for what ships.

“Built with AI assistance” only tells a small part of that story. The interesting part is how we organize the work.

My Software Factory #

I built Software Factory to give that collaboration a repeatable structure. It is a collection of role-specific skills, a small runner called Baton, and conventions for files and Git. It coordinates Claude Code, Codex, and OpenCode without requiring its own application server or database.

I think of this as an agent-driven development lifecycle—ADLC—with agents participating in planning, review, implementation, and verification. It fits the broader AI-driven development lifecycle, or AI-DLC, which puts AI execution and human oversight throughout the lifecycle. My factory turns that approach into two concrete loops: review the specification, then develop against it.

Roles and models are separate. Rondo, Refrain, Maestro, Virtuoso, and Cadence describe responsibilities. Fable, Astra, Opus, Sol, and the others are the agents that can fill them. A configurable roster determines who takes each job.

Two loops. Clear handoffs.

Specification → evidence

01 / SPEC REVIEW

Make the specification hold up.

Rondo coordinates the review. Refrain is the reviewer that keeps its context across rounds.

  1. Write the intent

    A requirement, specification, design record, or brief gets a template and a version in Git.

  2. Review against the contract

    The reviewer checks completeness, contradictions, feasibility, and testable acceptance criteria. Findings get stable identifiers.

  3. Resolve with the owner

    I see the findings at the default checkpoint. The writing agent resolves what it can; decisions about scope and behavior come back to me.

  4. Return to the same reviewer

    The next round revisits earlier findings before adding new ones. The review does not start from scratch.

  5. Record the verdict

    Approval names the reviewed document revision. The loop also has a round cap and can stop for a decision.

Findings → corrections → review again

02 / SPEC DEVELOPMENT

Turn the specification into evidence.

Maestro coordinates the work. Virtuoso implements each brief. Cadence reviews and integrates the result.

  1. Prepare bounded briefs

    Issues and reviewed briefs define scope, dependencies, acceptance criteria, security, and the checks each implementation must pass.

  2. Dispatch ready work

    Each implementer gets an isolated worktree and a fresh context. Dependencies determine which briefs can run concurrently.

  3. Hand back code and evidence

    A handback identifies the branch, commit, checks, and remaining questions. An unresolved product decision is returned instead of guessed.

  4. Review, then integrate

    Cadence checks the source against the brief. Accepted work lands on the spec branch; refused work gets a correction round.

  5. Gate the combined result

    The final pass syncs main, reviews security, and runs the full gate. Maestro stops at a passing spec branch; landing on main and publishing are separate steps.

Refusal or failed gate → correction → verify

What keeps it grounded

The work leaves a trail.

Context where it matters
The document reviewer stays with the conversation. Implementers start with focused briefs and fresh contexts.
Evidence before acceptance
A successful agent exit is not proof of a finished feature. Source review, acceptance checks, and the full gate each answer a different question.
Records that survive a session
Review files, handbacks, and a manifest preserve decisions and progress. Baton records each run and can resume the appropriate vendor session.
Lessons become checks
A recurring mistake should lead to a stronger convention or a guard that can fail, so the next agent does not have to rediscover it.

A factory still evolving. Both the spec-review loop and Maestro’s development cycle have now run end to end. I keep refining the skills, runner, and verification rules as the team works.