Why Faster Coding Still Leads to Late Releases: A 90-Day Engineering Reset

Santhosh Murthy, in a GeekyAnts AI Thoughtmakers conversation, described a 90-day engineering reset for teams whose AI-accelerated coding produces more pull requests and healthy-looking dashboards but unpredictable releases. Murthy traced the problem to downstream bottlenecks, notably pull request reviews, after investigating six months of backlog history with AI-assisted analysis, and recommended mapping each priority to ownership, blockers, and delivery dates while having leadership explicitly trade off new work against existing commitments.

AI tools can help developers produce code faster. Yet a team can finish more pull requests, run successful demos, and still struggle to explain which features customers will receive next. That gap is the central topic of Faster Code, Late Releases: The 90-Day Engineering Reset https://www.youtube.com/watch?v=nFjQaEvOagI?utm source=dis2026 , an AI Thoughtmakers conversation published by GeekyAnts featuring Santhosh Murthy. The discussion examines a familiar engineering problem: visible activity looks healthy while delivery remains unpredictable. Its proposed response is a focused reset of priorities, ownership, and working processes. For developers and engineering leads, the useful starting point is understanding where work waits after the code has been written. In the conversation, Murthy describes a team whose sprint planning, demos, and dashboards appeared healthy. The problem became visible when leadership asked what customers would receive by the end of the quarter. The team could not give a clear answer. A dashboard showing completed tasks or increased pull request activity answers questions about individual stages of development. It may leave the larger delivery question unresolved. A feature can be implemented but still wait for review, integration, testing, or release coordination. Reporting the implementation as progress does not explain how much work remains before customers can use it. A useful delivery discussion therefore connects each priority to three things: Without that connection, teams can stay busy while commitments become increasingly difficult to predict. One of the clearest examples in the transcript concerns pull request reviews. Murthy explains that code creation previously consumed substantial time. As AI accelerated that stage, reviews became a more visible constraint. He investigated the problem through conversations with engineers and an AI-assisted examination of six months of backlog history. Tickets spending extended periods in review supported the concerns raised by the team. The lesson is specific: improving one stage does not establish that the entire delivery process has improved. A practical investigation could examine: | Delivery stage | Question worth investigating | |---|---| | Implementation | When did the change become ready for review? | | Review | How long did it wait before receiving useful feedback? | | Revision | What caused repeated review cycles? | | Release | What prevented an approved change from reaching production? | These questions help distinguish time spent actively progressing a change from time spent waiting. They also make a process discussion more concrete than a general request for developers to work faster. The transcript describes the first month as a period for understanding roadblocks while important delivery work continues. A reset does not require every project to stop. Existing customer commitments still need attention, and leadership must decide which work deserves protection. Murthy suggests asking engineers what repeatedly slows their work or wastes time each week. Answers might reveal delayed reviews, unclear release schedules, conflicting team priorities, or uncertainty about ownership. In the example discussed, both review delays and release coordination emerged as concerns. Those conversations should lead to a written account of the problem: The purpose is to establish a shared understanding of the delivery problem before introducing another process. Once blockers become visible, the reset needs decisions. One recommendation in the conversation is to stop automatically accepting new work. That requires leadership to make explicit trade-offs. For example, a team already handling four priorities cannot absorb a fifth without consequences. The decision should identify which existing commitment moves, which deadline changes, or which request waits. Otherwise, the original priorities remain on paper while attention shifts elsewhere. Ownership needs similar clarity. Each important feature should have someone accountable for coordinating its progress, dependencies, and unresolved decisions. This does not mean one person performs every task. It means the team knows who can explain the feature’s status and move a blocked decision forward. Murthy also emphasizes that disagreements deserve discussion, while an accountable product decision-maker must ultimately resolve competing priorities. A reset becomes useful when those decisions change how work moves. Priorities can become unstable when teams repeatedly revisit decisions without remembering why they were made. The conversation recommends keeping a decision log with a story or feature. It records what was prioritized or deferred, when the decision happened, and the reasoning behind it. A simple entry might look like this: Decision: Defer the reporting enhancement. Reason: The customer-facing release depends on completing the integration work first. Owner: Product lead. Revisit condition: Integration work reaches the agreed release milestone. This illustrative format gives future discussions a starting point. A changed priority can then be assessed against changed circumstances. The outcome described in the conversation is clarity. Team members should understand their responsibilities, the features they support, and what those features will deliver to customers. The habits that preserve that clarity include weekly priority checks, recorded decisions, and fewer meetings that interrupt focused work. The discussion also identifies an ownership warning sign for startups: the same two or three people appear in every incident or release conversation while others lack context. A useful reset distributes understanding as well as responsibility. Faster coding creates an opportunity to improve delivery. Realizing that opportunity requires attention to the reviews, decisions, and handoffs that follow implementation.