Orin

Inspiration

Every solo developer knows this day. You write the code — then comes the review, the security scan, the release, the 3 a.m. outage. All of it on you. The "Life After Code" theme asked what happens after the code is written, and our answer was radical: what if nothing after the code needed a person at all? Not the review, not the merge, not the deploy, not the pager. We didn't want to build another copilot that suggests lines in an editor. We wanted to build the engineer — an autonomous teammate that takes an issue and hands back a deployed, monitored release while you sleep.
What it does
Orin is an autonomous DevSecOps engineer living inside GitLab. You open an issue describing a feature and assign it to Orin. That is the last human click. From there:

1. Orin posts an implementation plan on the issue.
2. It creates a branch, writes the code and the tests, and opens a merge request.
3. The pipeline is the reviewer it can't cheat: a vitest suite with an 80% line-coverage gate, a SAST gate that blocks vulnerable merges, an idempotent DB migration, and a deploy of the prebuilt artifact to production.
4. GitLab Duo Code Review reviews Orin's MR — and in our flagship run it caught a real security flaw in Orin's own code, which Orin fixed with the suggested diff before merging.
5. A scoped auto-merge job merges the green MR; Orin watches the deploy pipeline, health-checks production, and only then reports completion on the issue.
6. When production broke in our rehearsal, nobody got paged: a scheduled watchdog job hit the health endpoint, its dead-man's switch fired, an alert issue was filed automatically, and the rollback pipeline restored the last good deployment — green, on its own. The incident closed itself.

All of it leaves one auditable trail: a single agent session with 11 linked items — the issue, both merge requests, every milestone comment,timestamped and reviewable. Nine GitLab lifecycle stages — plan, create, verify, package, secure, release, configure, monitor, govern — with zero human touches.

How we built it

Everything runs on the GitLab Duo Agent Platform:

• One custom agent — Orin, registered in the GitLab AI Catalog via aiCatalogAgentCreate. Its system prompt is a committed file, .gitlab/duo/orin-agent.md (https://gitlab.com/siddhant-group2925942/orin/-/blob/main/.gitlab/duo/orin-agent.md), treated as production config: versioned, diffable, and guarded by a parity test that keeps the catalog and the repo in sync.
  
• One orchestrator flow — Orin orchestrator, registered via aiCatalogFlowCreate from .gitlab/duo/flows/orin.yaml (https://gitlab.com/siddhant-group2925942/orin/-/blob/main/.gitlab/duo/flows/orin.yaml). It wires an AgentComponent with an ex (read/edit files, branch, commit, open and merge MRs, issue notes, pipeline polling) into an issue-to-production loop, triggered by nothing but the issue assignment.
  
• The product workload is a real full-stack app: a short-links service (Next.js, TypeScript, Vitest, Postgres) — deliberately small, so the autonomous loop has something concrete to ship, break, and heal.
  
• CI/CD as the trust boundary — stages test → sast → package → migrate → deploy; a scoped-token auto-merge job merges only green MRs; the scheduled uptime-watchdog job plus Healthchecks.io forms a dead-man's switch; a rollback job re-points production at the last good deplohealth.

Challenges we ran into

• The flow schema is discovered by failure. GraphQL introspection on gitlab.com returns a canned schema, so the only documentation was create-mutation validation errors. It took five rejected mutations — zero credits burned, zero runs started — to learn the YAML contract: prompts keyed by prompt_id, mandatory unit_principles/unit_primitives blocks, block-scalar indent rules, placeholder-declared inputs.

• The agent can't run tests locally. The sandbox has no npm registry access, so the pipeline is the only test runner. We made that a hard rule in the agent's prompt: poll pipelines, match SHAs (stale pipelines lie), retry failed jobs from their logs, stop after three fix cycles and escalate to a human. The scoped token can't merge — by design. Orin's own merge calls fail with 403 insufficient_scope. Instead of broadening permissions, we leaned into it: a CI job with exactly the right scope performs the merge only after every gate passes. Least privilege forced better architecture. The loop ate its own dog food. An early run changed the schema without a migration and took storage down — the fix became a mandatory in-pipeline migration stage, so agent-authored schema changes land without a human hand-applying them. The scariest moment was also the best proof. The security finding Duo raised on MR !12 — links with click limits and expiry leaking to unauthenticated callers — was on code Orin itself had written, merged, and deployed. The agent read the review, applied the suggested filter, and re-ran the loop. complishments that we're proud of

• A full issue → production loop with zero human touches, across nine GitLab lifecycle stages.

• An agent that fixed a security finding on its own code after being reviewed by GitLab Duo.

• An incident that filed, fixed, and closed itself — watchdog issue, rollback pipeline, green health check, no page.

• A complete, timestamped audit trail (11 linked items in one session) — governance isn't a slide, it's the session page.

• An agent that refuses to lie: its completion report requires a 200 from the health endpoint first.

What we learned

• Make the pipeline the constitution. An agent is only as trustworthy as the gates it can't bypass. Coverage thresholds and SAST enforcement stopped being "CI details" and became the core safety mechanism.
• Constraints breed reliability. Protected main, scoped tokens, and no local test runner each forced a pattern — auto-merge jobs, pipeline polling discipline, migration stages — that made the whole loop safer for humans.
• Prompts are configuration, not conversation. Committing the agent's system prompt and flow YAML, and testing their parity with the catalog, turned "prompt tweaking" into reviewed, revertible infrastructure change.
• Auditability is the product. The session page convinced us: for autonomous agents, the trail of linked evidence matters as much as the code produced.

What's next for Orin

• Multi-repo onboarding — point Orin at any GitLab project via a config file, no prompt surgery.
• Autonomy dial — first-class Assisted / Supervised / Hands-off modes, from "plan for my approval" to full hands-off.
• Proactive maintenance — scheduled issues Orin opens itself (dependency bumps, flaky tests, coverage drift) and works end-to-end.
• Agent-side test execution via a self-hosted runner, so fix cycles don't wait on CI round-trips.
• Smarter incident response — Orin triaging the watchdog's alert, choosing between hotfix-forward and rollback instead of always rolling back.

Built With

• ai-agent
• autonomous-agents
• ci/cd
• devsecops
• gitlab-duo
• gitlab-duo-agent-platform
• graphql
• healthchecks.io
• neon
• nextjs
• node.js
• postgresql
• sentry
• typescript
• vercel
• vitest