Amar Goel, Bito’s CEO, sent one Slack message on a Thursday evening asking Bito’s AI Architect to add Linear ticket support to the platform. Six hours later, five workstreams across five repositories and four tech stacks were implemented, pushed to GitLab, and ready for review. The same scope had been estimated at 3 to 4 weeks for a senior engineer working traditionally.
Total human time across four people: under two hours. This is how Bito’s own engineering team builds Bito. AI Architect, the same system intelligence platform Bito ships to customers, runs as part of the team’s daily workflow. When a feature needs to span multiple services and repositories, AI Architect provides the cross-repo architectural context that makes the work possible in hours instead of weeks.
This post walks through the full implementation, from the initial message to review-ready code, and shows what happens when a coding agent has a knowledge graph of the entire codebase.
Key results
| Metric | Value |
| Wall-clock time | Under 6 hours |
| Traditional estimate | 3 to 4 weeks |
| Total human time | Under 2 hours |
| Repositories touched | 5 |
| Workstreams completed | 5 |
| Architectural approaches evaluated | 4 |
| Slack messages to kick it off | 1 |
The scope of the feature
Bito’s platform already had deep Jira integration. When an engineer tagged @bito on an epic or story, a four-service pipeline analyzed the ticket, built a plan, and posted it back as a comment. That pipeline ran across four repositories: the tool layer, the webhook registration service, the webhook receiver and Kafka producer, and the intelligence service that consumed events and generated plans.
Customers using Linear instead of Jira had been asking for the same capability. Adding it required tool parity in the agent layer, a new webhook receiver with signature validation, webhook registration with secret storage, event pipeline routing through a provider abstraction layer, and a frontend OAuth integration in Bito’s Angular SPA.
The work spanned five workstreams across five repositories and four tech stacks, the kind of cross-service feature that, even on a codebase the team knows well, normally takes a senior engineer 3 to 4 weeks of focused work.
“We’d been shipping @bito for Jira to customers, and Linear support was a gap. I knew what the feature had to do, but I didn’t want to spend a month of a good engineer’s time watching them read Jira pipeline code to figure out how to extend it. So I wrote one Slack message and sent it to our own AI Architect.”
– Amar Goel, Co-founder and CEO, Bito
How AI Architect approached the problem
AI Architect had already indexed Bito’s full codebase, every repository across the platform, plus Jira, Confluence, commit history, and observability data. When Amar’s message came in, AI Architect had the full topology of the Jira integration pipeline already mapped. Which services called which, where the skill resolution logic lived, how events flowed end to end.
Four architectural approaches, delivered in minutes
AI Architect produced four candidate architectures: a mirror architecture that forked the Jira service, a unified intelligence service that refactored it into a provider-agnostic service, a serverless rebuild, and a lightweight Slack-bot orchestrator.
Each came with effort estimates, risk assessments, and a clear recommendation. Amar discussed briefly with Anand and selected the unified service approach.
Deeper analysis the team didn’t ask for
After the selection, AI Architect went back and analyzed the existing Jira service in detail. The finding was specific: roughly 60 to 70% of the service was already provider-agnostic. The executor, skill resolution, dedup logic, S3 logging, and worker pool had no dependency on Jira at all. The refactor was smaller than it looked.
AI Architect produced a list of exact file changes, a provider interface signature, the three surgical edits needed to the processor, and a rollout sequence.
Agent specs with senior-engineer-level detail
Before writing code, AI Architect produced four detailed agent specs, one per workstream, covering token expiry, race conditions, partial failure rollback, idempotent webhook registration, and backward compatibility.
Several details surfaced on their own, without being asked for:
- Linear webhooks don’t expire: Unlike Jira, no auto-renewal code was needed. The spec removed an entire workstream of scaffolding the team would have written by default.
- Backward-compatible event schema: Events without a “provider” field default to “jira” so existing Kafka producers keep working during rollout.
- Provider-isolated worker lanes: 70% of the worker pool dedicated to Jira, 30% to Linear, so a Linear bug could never starve Jira processing.
- Feature flag plus separate Kafka topics: Deploy the renamed service with Linear processing flagged off. Validate Jira for a week. Flip the flag. Keep topics separate for independent monitoring and pause capability.
These are the details a senior engineer adds to a design doc after two rounds of review. AI Architect produced them on the first pass.
Parallel execution across five repositories
Once Amar said “implement,” AI Architect worked across four repositories in parallel: tool parity in the agent layer, the webhook endpoint, webhook registration, and the provider abstraction. Each workstream pushed a feature branch to GitLab with a merge request link and verification gates, ready for review. A fifth workstream for the Angular OAuth integration was added as a follow-up the same evening.
“I reviewed the code expecting to find the usual gaps. Missing error cases, race conditions, hardcoded assumptions. Instead, I found HMAC signature validation with payload size limits, idempotent registration with DB unique constraints and rollback on partial failure, and a clean provider abstraction that didn’t touch the Jira code path until the feature flag flipped. It read like a senior engineer wrote it. One who knew our system.”
– Anand Das, Co-founder and CTO, Bito
Results
- Under 6 hours wall-clock, 5 workstreams ready for review: From Amar’s initial Slack message to the final workstream ready for review, AI Architect delivered design, specs, and implementation across five repositories in one evening.
- 3-to-4-week scope compressed to a single evening: AI Architect’s own sizing estimated this at 3 to 4 weeks for a senior engineer working traditionally. The team’s gut check matched.
- Under two hours of human time across four people: Amar wrote the initial message, picked the approach, and approved execution. Anand and two engineers reviewed the design via Slack and the code in GitLab.
- Review-ready code on first pass: Anand approved the backend workstreams after the initial push. The only change required was a semantic correction: Linear does not have a concept of an epic, while Jira does.
- Senior-engineer-level judgment surfaced unprompted: Backward-compatible event schemas, provider-isolated worker lanes, feature-flagged rollout sequencing, and the recognition that Linear webhooks don’t expire all appeared in the specs without being asked for.
Why this matters
Every engineering leader has run the same calculation: a feature that spans multiple services, estimated in weeks, blocked on the senior engineers who hold the system context in their heads. AI Architect removes that bottleneck by giving every engineer and every coding agent that system context, grounded in the full codebase plus Jira, Confluence, and PR history.
The same capability Bito ships to customers is what Bito runs on internally. Every branch, merge request, and verification gate from this evening is real and reviewable in Bito’s own repositories.
“AI Architect takes a sentence of intent and figures out the system-level design, the rollout strategy, the backward-compatibility risks, and the right sequence of commits, across services it was never explicitly told about. In one evening we had an evening’s worth of human time produce what would have been weeks of traditional work, ready for review and testing, because the graph knew our system as well as we do.”
– Amar Goel, Co-founder and CEO, Bito