Everyone wants to talk about what AI made faster. We should also talk about what it made harder.
Over the past several months, the team at Juno built something that hasn't existed in the tax software industry: a complete automation workflow for business returns (Forms 1065, 1120, and 1120-S). The market has been focused almost entirely on individual 1040 workflows, and because of that, business returns have been left to a worksheet-heavy, document-intensive process that honestly hasn't changed much, and CPAs have had to absorb that cost in time and complexity on every engagement. That's the gap we decided to close.
What we delivered would have taken 10 months by any traditional measure. We delivered it in 10 weeks.
That headline is real and I'm not going to undersell it, but if you stop the story there you miss the more important part, and the part that anyone building at this pace right now actually needs to hear.
The speed was real. So was everything it exposed.
AI-assisted development didn't just accelerate our output. It compressed an entire product cycle into a timeframe that revealed, very quickly, which parts of our operation were built for normal velocity and which ones weren't, and the distance between those two things turned out to matter a great deal.
Tokens consumed, lines of code written. Those numbers are large and they're not the point, because a large codebase isn't a badge so much as it's a footprint that has to be managed, maintained, and understood by human beings. The capability was real, and the question was whether the rest of our process could keep up with it. In some places it could, and in others it couldn't, and the gaps showed up fast.
The gaps are worth examining.
Where the bottlenecks actually appeared
Here is what we observed, directly from inside this build:
Ticket writing became a constraint. The time required to write a detailed, well-scoped engineering ticket was greater than the time it took an engineer to build off of it, and that's a new problem that didn't exist at previous development speeds. When one person is translating user feedback into actionable technical work and consuming that work faster than it can be written, you have a bottleneck that has nothing to do with engineering capability and everything to do with the pace at which humans communicate and translate intent.
Testing volume exceeded human capacity. An enormous amount of work was built in a compressed timeframe, and testing it required human judgment, not just automation, and when you compress the volume of work we were validating into a timeline that development could handle but humans could not sustain, burnout happened. That's not a failure of the team so much as it's an honest consequence of applying AI speed to a process that still requires people to validate correctness, edge cases, and real-world tax scenarios, because you cannot automate the judgment out of quality.
Tax industry validation came too late. We made a deliberate call early on to emphasize engineering speed and bring the full team in later, because we didn't yet know how things would turn out and we wanted to see what was possible before we widened the circle. That decision made sense at the time, and it created consequences anyway. Domain expertise, in our case tax knowledge, inserted later in the process surfaced design calls that had they been made earlier, the AI could have handled from the start, and that means the sequence matters more than we anticipated. When tax industry validation is upstream it governs what gets built, and when it's downstream it becomes a correction loop, and those are structurally different outcomes that flow from where you place a single decision in the process.
User feedback volume scaled with feature volume. When you ship 10 times the features in a compressed cycle you should expect 10 times the feedback, and we did, but what we underestimated was that the systems around that feedback, triaging it, prioritizing it, getting it into the hands of the right people, weren't scaled to match, and so development velocity outran the feedback loop infrastructure in ways that created real pressure on product and QA.
What this is really about
The bottlenecks didn't appear where AI was working. They appeared everywhere AI wasn't.
The pattern is worth understanding, because AI accelerates the parts of your workflow it touches and in doing so puts pressure on everything adjacent that it doesn't touch, and those adjacent functions, ticket writing, domain validation, quality review, user feedback synthesis, go-to-market alignment, are human functions that didn't get faster just because the code did.
There's also something worth naming about the engineers themselves. When capability expands that quickly the challenge isn't motivation, it's focus, and engineers can be overwhelmed by what's now possible in ways that produce a wide footprint rather than a precise one. Keeping the team oriented to product intent and not just technical possibility became active work, and that work has to be owned by someone or it doesn't happen.
The outcome, honestly
The product shipped, and CPAs are using it during extension season right now, expanding which return types they're processing, providing direct feedback, doing real work on a platform that didn't exist three months ago. That is genuinely invigorating.
It was also genuinely exhausting, not because the team wasn't capable, but because the pace of AI-enabled development creates a new kind of demand on the humans around it, and rest matters more now than it did. The pressure that accumulates at the end of a compressed cycle, when human elements control the final mile, is real and has to be planned for and not just endured.
Would we do it again? Yes. Would we do it the same way? No. That's good and humbling. It means we have grown and learned something about ourselves along the way.
What we're taking forward
A few things are clear coming out of this.
Tax knowledge and domain expertise need to be in the room earlier, not as a review gate but as a governing input to what gets built and how the AI is directed from the start, because the earlier that knowledge shapes the work the less correction happens downstream.
Feedback infrastructure needs to scale with feature scope, and a large release requires a larger capacity to receive, triage, and act on what comes back, because that's a product and operations question and not just a development one.
The human elements of a development cycle, the communication, the judgment, the validation, the synthesis, don't accelerate because the code does, and building at AI speed means investing in those functions proportionally or they become the ceiling on what you can actually deliver.
Speed is available. The question is whether your team and your process are built to receive it.
We're building toward that, and this was a real step in that direction and an honest look at how much further there is to go.
P.S. Want to see what we've built? Start a free trial. Want to help build what's next? See open roles at Juno.
