Inside Ambrook's software factory
A software factory where a homegrown triage agent (Amos) routes issues to a cloud coding agent (Niteshift), with an agentic risk check flagging sensitive changes, cutting median bug-fix time 80% and letting non-engineers ship fixes the same day.
Ambrook at a glance
The company
| Sector | "accounting tools to help businesses manage finances, improve margins, and stay independent" 5 |
|---|---|
| Employees | Not disclosed as a discrete count; the about page lists 50+ team members by name across all functions 5 |
| Customers | More than 8,000 independent businesses nationwide 4 |
| Revenue | $30M Series B led by Lachy Groom; no revenue disclosed 3 |
No source discloses an engineering-specific headcount separate from the company-wide team shown on the about page.
The engineering organisation
| Engineering size | Not disclosed; the Product Pod built the software factory, but no team size is given 1 |
|---|---|
| AI tooling since | Momentum Month launched in mid-2026, but engineers were experimenting with local agents before that 2,3 |
| Tool policy | Hybrid — Amos is built in-house; Niteshift is an external cloud coding agent chosen for model and agent independence 1,3 |
| Agents in the SDLC | A homegrown triage agent (Amos) that classifies issues, sizes work, and orchestrates the pipeline; Niteshift as the coding agent that opens PRs and iterates with automated reviewers; a home-grown agentic risk assessment that flags large diffs, sensitive systems, and undefined behavior 1 |
| Reported adoption | Over 50% of PRs made with Niteshift as of the case study; median bug-fix time down 80%; 1 in 4 bugs resolved in under 3 hours 1,3 |
| Published metrics | Bug time-to-fix drop, time-to-close, PR share via Niteshift, Momentum Month outcomes 1,2,3 |
The 80% drop is median time to completion for bugs, not time to first PR. The 50%+ PR share comes from a vendor case study and may measure differently from internal metrics.
People
What they set out to solve
Ambrook's Product Pod framed the problem as the pull between two kinds of work: the steady stream of fixes and quality improvements that keep a product polished, and the large features that open new business. The goal was to automate as much of the former as possible so engineering bandwidth could go to the latter — "increase the throughput of small and medium sized improvements without spending more time on them" 1.
The push came from growth. Coming out of the 2026 tax season, Ambrook saw a 4x year-over-year increase in signups, and made "everyone is a builder" a central thesis. That led to Momentum Month, a six-week company-wide sprint where everyone on the team — engineers and operators — learned to identify, build, run, and evaluate their own AI workflows 2,3.
Maturity level
Assigned by testing published facts against fixed criteria, and capped by what the sources state.
Code generation, triage, and review all run through agents: Amos classifies and sizes issues, Niteshift writes and iterates on fixes, and automated reviewers (Greptile, Claude, a home-grown risk check) do a first pass before human review. Nothing merges without a human looking at it, but "auto-approve for some PRs" has been introduced for certain categories 1,2. Non-engineers file bugs, test fixes on preview deployments, and have engineers merge — the same day 1.
How Ambrook's software factory works
The pipeline runs on four components: Linear holds the state, Zapier routes the webhooks, Amos triages and orchestrates, and Niteshift writes the code 1.
A ticket enters the loop when someone adds an Agent Triage label in Linear. That triggers a webhook through Zapier, which splits bugs from feature requests. Each path sends a request to Amos, Ambrook's homegrown background agent. Anyone at the company can interact with Amos in Slack or use it programmatically. Amos investigates the ticket, posts a comment with its findings, and labels the ticket with its classification 1.
Bugs get one of three labels: Agent Fixable for well-defined fixes like UI issues, caching bugs, or timezone-related off-by-one errors; Needs Engineer when the fix requires deeper knowledge; Not a Bug when the behavior was intended or the request is really a feature. Features get t-shirt sizing — large features exit the loop for an engineer to own 1.
Any Agent Fixable ticket triggers Niteshift, Ambrook's model-independent cloud coding agent. Once a PR is up, Niteshift iterates with several automated review agents to get the PR into a healthy shape. Ambrook uses Greptile, Claude code review, and a home-grown agentic risk assessment that flags large diffs, changes to sensitive systems like accounting or authentication, and anything with undefined behavior. When the process completes, Amos comments on the original ticket letting the owner know a PR is ready and requests them to preview the fix on staging 1.
The ticket creator shepherds the work through. An operator who files a bug is responsible for answering Amos when it comes back with "Needs Info" and for testing the fix on the preview link. Niteshift includes a short manual-testing path in every PR description to make that quick. If the fix is wrong, the operator iterates with Niteshift or pulls in an engineer 1.
Nothing ships through the loop without a human looking at it 1. But Momentum Month introduced auto-approve for some PRs, though what qualifies isn't specified 2.
Operating Ambrook's software factory: teams, roles, and skills
The software factory was built by Ambrook's Product Pod during Momentum Month, a six-week sprint where the entire company learned to build AI workflows. Rather than engineers building for everyone, everyone built for themselves 2.
Momentum Month restructured the team into small pods of 3–4 people. Non-engineering pods were paired with a "visiting engineer" embedded as a TA rather than a builder — explicitly not allowed to write the automations for their podmates 2.
The outcome was that everyone at Ambrook shipped at least a small feature or bug fix. Non-engineers authored skills pushed to a shared repo. The customer success team now ships small features themselves, identifying and fixing papercuts directly 2.
Implementation journey
- Early 2026Ambrook engineers experiment with local coding agents and local sandboxes for safe autonomous development; Amos exists but cannot write code 3.
- Mid-2026 (Momentum Month)A six-week company-wide sprint where everyone learns to build AI workflows; the declarative engineering pipeline is built with a single human code-review checkpoint 2.
- June 15, 2026Momentum Month curriculum open-sourced, documenting the sprint's structure and outcomes 2.
- July 5, 2026"Building Ambrook's Software Factory" publishes, describing Amos, Niteshift, the triage pipeline, and the agentic risk check 1.
- After Momentum MonthOver 50% of Ambrook's PRs are made with Niteshift; adoption went from 12% to 94% of the company in four weeks during the sprint 3.
Measuring Ambrook's software factory
The clearest figure is the 80% drop in median time to completion for bugs since the beginning of the year, with time to close under 24 hours and 1 in 4 bugs resolved in under three hours 1.
The 50%+ PR share via Niteshift comes from a vendor case study, which has an incentive to present the adoption favorably 3. No independent figure corroborates it, and no denominator is given for what counts as a Niteshift PR versus total PRs.
Momentum Month outcomes: support AI resolution rate improved from 20% to 50% (2.5x); 75th percentile time-to-resolution for bugs dropped 35%; everyone on the team shipped a small feature or bug fix 2.
Lessons learned
"We didn't build this to ship more code. We built it so the small fixes and improvements don't need to compete with our more ambitious work, because both are important" 1.
The risk check exists because accounting and payments data accuracy is paramount. Ambrook's complex software stack means getting a realistic-enough cloud environment for an agent to meaningfully test its work requires substantial effort. The home-grown agentic risk assessment flags large diffs, changes to sensitive systems like accounting or authentication, and anything with undefined behavior — but its implementation and success rate aren't disclosed 1,3.
The choice of Niteshift over extending Amos to code was a build-vs-buy tradeoff: "We estimated that we'd have needed at least a month of dedicated time to extend Amos not just to code but to give it the tools it would need to verify its work. Other cloud agents would've locked us into a single company's harness" 3.
What's next for Ambrook's software factory
Some kinds of changes can't yet be autonomously verified in Niteshift — third-party services like payment providers specializing in physical checks don't have robust test credentials for end-to-end testing. Niteshift is developing mocking for external services in the cloud environment 3.
Ambrook is also beta testing Niteshift's Android and iOS support to enable testing changes across mobile, web, and backend in a single cloud environment 3.
