Technical design is now the biggest bottleneck in how fast engineering teams ship. AI coding agents compressed implementation from weeks to hours. AI code review agents improved merge quality and reduced regressions. The work that determines what gets built and how barely changed.
Stripe’s Developer Coefficient puts a number on this. Developers spend only 32% of their time writing new code. The remaining 68% goes to planning, understanding systems, debugging, and maintenance. AI made the 32% dramatically faster. The 68% still depends on tribal knowledge, the undocumented system understanding that a small number of senior engineers carry in their heads.
Every planning decision waits on them, and their calendars are already full. Specs move forward with gaps, risk surfaces late, and teams build the wrong thing.
Coding accelerated but the planning bottleneck got worse
A Hacker News thread titled “Writing Code Was Never the Bottleneck” surfaced a pattern that most engineering leaders will recognize. Junior developers using AI tools now produce in a day what used to take a week.
Senior engineers report spending more time reviewing, correcting, and re-scoping that output than they did before these tools existed.
The people who should be scoping the next feature are instead fixing the output of the last one because the technical design document that should have informed the implementation was skipped or rushed.
Teams skip technical design because waiting on the right person feels slower than starting the sprint. Three weeks later, the team discovers a missed cross-service dependency, and the rework costs more than the planning would have.
80% of developer time still goes to non-coding work
Atlassian’s Suzie Prince stated this during a recent industry panel. 80% of a developer’s time goes to planning, documentation, reviews, and maintenance.
The result is a speed mismatch across the development lifecycle.
- Code generation runs at machine speed.
- Technical design runs at the speed of the busiest architect’s calendar.
- That gap grows with every sprint as the volume of scoping work outpaces the people available to do it.
What tribal knowledge costs engineering teams
Tribal knowledge is the undocumented understanding about architecture decisions, system behaviors, and workarounds that exists only in engineers’ heads. Research from Glue quantifies what it costs.
- 23 hours per developer per month spent seeking knowledge that should be codified.
- 3 to 5 days of decision latency on architectural questions, versus 2 to 4 hours when the same knowledge is accessible.
- 12 to 16 weeks to onboard a senior engineer, versus 4 to 6 weeks when structured system context is available.
Why documentation has never solved this
Engineering teams have tried wikis, architecture decision records, and Confluence spaces. The knowledge decays because the codebase changes faster than anyone can document. The system-level context required for technical design is dynamic, spread across repositories, services, APIs, and operational history. A static document cannot keep pace with a living codebase.
A live knowledge graph captures what documentation cannot
A knowledge graph maps the relationships between services, dependencies, APIs, design patterns, and call flows across every repository in your system. It stays current because it reads the codebase itself, not a description of it from three months ago.
That same deep codebase context can power the planning phase directly.
- Feasibility analysis before the team commits engineering resources.
- Technical design documents grounded in service topology and existing patterns.
- Epic breakdowns with real dependency context per ticket.
- Risk flags based on codebase structure and past operational incidents.
What we are building at Bito
We recently extended AI Architect into the technical design phase with AI Architect in Jira, which generates grounded planning documents directly from epics and stories.
AI Architect builds a knowledge graph by indexing every repository in your system, mapping services, dependencies, APIs, design patterns, and call flows. It also draws on operational history from past Jira tickets, surfacing incident patterns, past architectural decisions, known failures, and recurring issues that the codebase structure alone would miss.
This is the same knowledge graph that already powers grounded code generation via MCP in Cursor, Claude Code, and Windsurf, and codebase-aware code reviews on every pull request.
On SWE-Bench Pro, that deep codebase context delivered a 39% improvement in task success, with the largest gains on large codebases and multi-file tasks.
What shifts when every engineer has the same system context
The architect’s role changes. Their time moves from context gathering to decision-making, which is the work that actually requires their expertise. They review a grounded first-pass document instead of building one from scratch.
New engineers benefit the most. Instead of spending 12 to 16 weeks absorbing tribal knowledge through conversations and code archaeology, they start with the same system context that a senior architect would bring to the table.
Onboarding becomes a function of the knowledge graph, not the availability of the right person.
The impact at scale
At scale, the numbers compound.
- 30 epics per month at 15 hours of senior engineering time each.
- Hundreds of stories at 2 hours each.
- Roughly 1,000 engineering hours per month spent on technical planning.
Deep codebase context generates a grounded first-pass planning document for each of those epics in minutes. Every engineer starts from the same system understanding, regardless of tenure.
Planning, technical design, and cross-service coordination remain essential. What changes is that these activities are grounded in the actual codebase instead of whatever the busiest architect remembers.
The next wave of engineering productivity starts before code
Technical design became the bottleneck the moment AI compressed the coding phase. The 80% of engineering time that goes to non-coding work is where the next wave of productivity gains will come from, and deep codebase context is how teams will unlock them.
The cost of waiting is already measurable. Every team that has watched a sprint produce rework because the technical design was incomplete knows the pattern.
The question for engineering leaders is whether to keep running technical design on tribal knowledge or to bring the same deep codebase context that powers code generation into the work that determines what gets built.
Connect AI Architect to your Jira workspace and see how it works at bito.ai.
