Siberta Software Factory
Siberta · Ankara · since 2023
People decide. AI agents build. Rules decide what merges.
The Siberta Software Factory is how we build software, for our clients and for ourselves. A request becomes a design, planned issues, written code, an independent review and a merged pull request. Our team sets the direction and approves what matters. AI agents do the rest, inside limits that GitHub itself enforces.
How a change flows
From one sentence of intent to a merged, reviewed pull request
Each step is a separate process with its own permissions. No agent can approve its own work, and no step depends on an agent remembering a rule.
- Team
States the work
A goal in plain language. It stays fixed until someone on the team changes it.
- Architect
Writes the design
Our representative agent clarifies the request and writes the ideal state, with numbered yes/no decisions, under its own identity.
- Team
Approves
Decisions are answered in one line. Nothing is built from an unapproved design.
- Planner
Splits into issues
Independent, testable issues with acceptance criteria. A script checks the plan against what the planner declared.
- Developer
Writes the code
In a fresh, disposable container. Runs the single test entry point and opens a pull request.
- Reviewer
Reviews independently
Sees only the diff, the description and the issue. Approves or blocks under a second identity.
- GitHub
Merges by rule
Green checks first, then rulesets and code owners. Critical paths wait for a person; the issue closes itself.
Inside the factory
The factory map
The same flow, one level deeper. Click a box to read what happens there; boxes with a thick blue edge open their own flow.
The approach
Tie correctness to mechanism, not intention. Build the mechanism only as far as it is needed.
Earlier internal platforms taught us what to avoid: they piled up policy engines, orchestrators and governance layers before shipping anything. The factory was designed the other way round. It was built in a day on five principles, then rebuilt from a single design document, and everything in it follows from them.
Assurance comes from structure, not interpretation
A language model interprets, and interpretation drifts. Hooks, rulesets and file permissions do not.
Test: if this rule is broken, does GitHub refuse it?
Define what is right, not what is wrong
Lists of forbidden things never end. Roles are written as "only does this", and permissions are allowlists.
Test: does the definition contain "except" or "don't"?
Every layer must pay for itself
A container, an extra agent, another document: each has to solve a concrete problem that exists today.
Test: does the argument for it say "someday" or "maybe"?
Put a limit on hardening the cage
Securing a system never ends on its own. "Last round" is part of the design, and the accepted residual risk is written down.
Test: is the same component being hardened a third time?
The record of the goal matters more than the goal
People and models both drift. What prevents it is a written goal and the habit of returning to it.
Test: is it written down how you will know you are done?
Guardrails
Limits enforced by the platform
Each guardrail is a mechanism that can be checked, and each exists because of a problem the factory actually hit.
Three agent identities
One identity writes and merges, one only reviews, and the Architect works under its own. GitHub does not let an author approve their own pull request, and people's accounts are kept for people's actions.
GitHub Apps · short-lived tokensNarrow roles, no prompts
Planner and reviewer run unattended with an allowlist. Anything not on it is refused without asking.
unattended · allowlist · no promptsA disposable workshop
The developer gets a fresh container for every turn, with limited outbound access and read-only inputs from the host.
container · egress allowlistPeople own the critical paths
Changes to roles, scripts, CI, templates and design documents wait for a code owner's approval. Ordinary work merges on review and green CI.
CODEOWNERS · rulesets · required ciThe reviewer checks the requirement
The reviewer reads the issue the pull request closes, so a missing acceptance criterion blocks the merge even when the description looks consistent.
diff + description + issueResumes from GitHub's state
A restarted run reads each issue's state from GitHub and runs only the missing step. Temporary errors are retried a few times; a permanent one stops the run with its reason.
state from GitHub · bounded retriesToday on Claude
Today, the factory runs on Claude
The method does not depend on a model: the roles, identities, rules and records stay the same whichever model fills a role. Today every role is filled by Claude, running in Claude Code.
Every plan runs several Claude sessions: a planner, one or more developer turns, an independent review for each turn, and the Architect working with our team throughout. The same pipeline builds our client projects and improves the factory itself, so our use of Claude grows with every project we take on.
Usage is measured per call. Models, retries and outcomes are recorded in one OpenTelemetry trace per plan, so we can see where tokens go and which steps need a stronger model.
Claude Code, unattendedEach role is its own process with a per-run agent definition. Nothing is installed on the machine.The right model for each roleEach role runs on the Claude model and effort level that suit its job. If one model is unavailable, the next continues with the same instructions, and the quality gate never lowers its bar.ArchitectA long-running Claude Code session that represents our team in the factory, works under its own GitHub identity and is reachable from a phone through Remote Control.OpenTelemetryClaude Code's own spans sit under each role's span, inside the plan's trace.
How the factory learns
Retrospectives that change the machine
Surprises become issues as they happen. At the end of a project they are grouped by root cause and decided: fixed now, or accepted as a known risk. Fixes go through the factory's own pipeline. One example:
Hundreds of non-blocking review notes were found in merged pull requests. Nearly half had never been tracked anywhere.
Review notes should reach the record by themselves, and the reviewer should see the requirement as well as the diff.
The factory planned, wrote, reviewed and merged both changes through its own pipeline.
The new reviewer cited the issue's acceptance criteria, and its notes opened a tracking issue without anyone filing it.
Siberta
Software and digital transformation, from process to product
Founded in Ankara in 2023, Siberta works with organisations on consulting, project management, software development and training. The factory is how we build.
Write to us:
siberta.com