ShipFromPhone

Inspiration

I'm 18 and I don't own a PC. Everything I build, I build on an Android tablet. I can write code on a tablet. What I can't do is everything after it: watch CI, read scan results, review, merge, deploy, and check production. That work normally needs a laptop and a person watching. "Life After Code" is exactly that work, so I handed it to GitLab Duo agents and asked one question: can a person with only a tablet file an issue and have it shipped, safely, with nobody touching it?

What it does

File an issue. Walk away. It ships.

On 15 Oct 2026 at 23:07 IST I filed issue #23 ("Follow the device's light/dark theme by default") from my tablet. The agents then did the rest:

1. A custom GitLab Duo flow, the Conductor, started on the work-item trigger and posted a plan with acceptance criteria.
2. It built the change and opened Draft MR !16 with tests and a CHANGELOG line.
3. CI ran unit tests, a changelog policy, SAST (Semgrep), Secret Detection, an SBOM, a container build and a staging smoke test. GitLab Duo Code Review reviewed the diff.
4. The Conductor's own reviewer approved the exact head commit. A CI release gate merged it.
5. Pages deployed it, verify-production confirmed the live site served that exact commit, and a GitLab Release was published.
6. The govern agent posted an evidence pack on the issue.

From issue to verified production took 13 minutes 21 seconds, with zero human touches.

How I built it

• Conductor: one custom GitLab Duo Agent Platform flow (.gitlab/duo/flows/conductor.yaml, generated by scripts/gen-conductor.py), triggered by "work item created". Since 17 Oct it has seven agent components in one session: plan, build, review, duo_fix, final_review, release and govern. (#23 ran on the earlier five-stage version.) It has one session because flow triggers ignore events from service accounts, so separate flows couldn't hand off to each other.
• Draft is the lock, CI holds the key. Agent MRs open as Draft, and only an APPROVED verdict on the exact head commit lifts it. The agents never merge. A CI release gate merges with a masked project variable that flows can't read.
• Guardrails: agent prompts may never push to main (#25, enforced by a test). .gitlab/duo is in Duo context exclusions, so agents can't rewrite their own instructions. Prompt changes are human-authored governance MRs (like !25) and are counted as human touches.
• Agents fix their own mistakes. On MR !26 the agent's first commit failed unit tests (pipeline 2956954051). Two minutes later the Conductor pushed one fix commit (85841c01) and the pipeline went green. A second commit answered GitLab Duo's review, Duo approved, and it merged with zero touches.
• Flight Recorder: a public evidence page, rebuilt from the GitLab API on every deploy: shipfromphone-d1d3e6.gitlab.io/flight (raw data.json). It applies a written human-touch rule to every MR and lists every touch.
• Stack: GitLab Duo Agent Platform, GitLab Duo Code Review, GitLab CI/CD, SAST, Secret Detection, CycloneDX SBOM, Container Registry, environments, GitLab Pages and GitLab Releases. The payload app is StudyDesk, a zero-dependency Node.js PWA. MIT licensed.

Numbers (live Flight Recorder, 23 Oct 2026)

• 35 Conductor runs: 25 shipped to verified production, and 8 failed or were abandoned.
• 23 of the 25 shipped runs had zero human touches. The median lead time from issue to verified production was 13.3 min (12.8 min for the zero-touch runs), and the fastest was 6.4 min.
• Human touches:
  • 3 on shipped runs: an early manual merge (#3), the governance MR !25, and #36, where my account resolved a Duo thread and re-requested review.
  • 5 on abandoned runs (housekeeping closes).
  • 5 runs were re-filed by a human after a dropped session.
• 227 pipelines and 23 GitLab Releases are in public history.

DevSecOps stages

Proven in pipeline history with no human touch: Plan, Create, Verify, Package, Secure, Release, Monitor (a post-deploy exact-commit check) and Govern.

Partial: Configure. There are CI-defined environments and a deploy resource group, but no infrastructure-as-code.

Challenges

• Flow triggers ignore service-account events, and flows can't read CI variables. I solved both by hand with an architecture change: one multi-agent flow, plus the Draft-lock release gate.
• Slow Pages publishing once caused a false production alarm, and an agent reverted a good merge (!11). The alarm window was fixed in #19, and the revert instruction was removed in #25.
• Conductor sessions sometimes drop mid-run. Five runs had to be re-filed by a human. The release gate now auto-re-files dropped sessions (#37), but no real dropped session has tested that yet.

Limitations, stated plainly

• Production is the static PWA on GitLab Pages. Server endpoints and security headers run only in the staging container. verify-production proves the exact commit is live, not that server-only features work in production.
• The release-gate token belongs to my account, so agent MRs show "Gaurang Kumar enabled an automatic merge". That line is CI, not me. Phone origin rests on my word: the API can't prove which device filed #23.
• One incident per failed commit is designed and tested in rehearsal, but no real production failure has exercised it yet.
• Agent-session pages are visible to project members only. Pipelines, MRs, notes and releases are public.

What's next

• Run real infrastructure-as-code for the Configure stage.
• Put a server deploy target behind the same gate.
• Keep the loop running through judging, so every new issue adds public evidence.

Who built what

The idea, design, guardrails and every decision are mine. The code was largely written by my AI assistant under my direction, and by the Conductor agents themselves.

Built With

• cyclonedx
• docker
• gitlab
• gitlab-ci
• gitlab-duo
• gitlab-duo-agent-platform
• gitlab-duo-code-review
• gitlab-pages
• javascript
• node.js
• semgrep