Allstacks tells LDS what AI misses before a coding agent starts

Allstacks CEO Hersh Tapadia told Let's Data Science that an AI planning agent wrongly excluded payment collection from a specification after seeing an old payment processor removed from the code, an error a product manager caught before the plan reached a coding tool. Allstacks' September 16 Product Studio update expanded planning integrations that assemble specifications from customer signals — Tapadia cites a session holding 113 evidence items, ten Gong calls and nine research-note summaries — and hands them to Cursor via deep link and to Lovable over Model Context Protocol. Tapadia recommends teams measure revisions and rework alongside planning speed, and says the company's 75% inference-cost claim excludes some costs.

Allstacks tells LDS what AI misses before a coding agent starts In written answers to LDS, Allstacks CEO Hersh Tapadia describes a planning agent that incorrectly excluded payment collection and another specification that needed Jira/Azure DevOps parity criteria. He explains how Product Studio hands plans to coding tools, where human approval remains, and what its 75% inference-cost claim excludes. His suggested test measures revisions and rework alongside planning speed, and keeps the existing workflow if the new one adds no value. An AI planning agent saw that an old payment processor had been removed from the code. It concluded that payment processing was outside the project's scope. The product manager reading the resulting specification noticed the missing requirement: the product still needed to collect money. The old processor had been removed to make room for a replacement, rather than to abandon payments. Hersh Tapadia, co-founder and CEO of Allstacks, describes that internal mistake in six written answers to Let's Data Science. It is a useful example of the problem the company is trying to address with Product Studio: giving a coding agent a plan that reflects the business, rather than simply generating more code from an incomplete request. Even with access to implementation history, the agent made the wrong inference. Tapadia says "nothing in the spec now said how payment would be collected." The fix required someone who understood the intended change. That is the practical question running through this interview: what should a team verify before passing an AI-written specification to Cursor, Claude or another development tool? A plan assembled from customer signals and code Allstacks' September 16 announcement expanded Product Studio's planning integrations, collaboration and operational context. Its product page https://www.allstacks.com/product/product-studio describes a workspace for researching, defining and reviewing requirements, then exporting them into existing development workflows. Tapadia's shareable example starts with an internal competitive analysis of Allstacks' software engineering intelligence product. Product Studio retrieved customer signals from Gong calls, Jira requests, Slack and Pendo. He says the session ultimately held 113 evidence items, ten Gong calls and nine research-note summaries. People selected a feature from that analysis: a revised team activity report organized around sprints and agile ceremonies. The agent then queried ACE, the Allstacks Code Engine, for existing API contracts and the frontend design system, aiming to avoid unnecessary backend work and fit the existing interface. The volume of retrieved material was not itself proof of a complete specification. A subsequent QA review found that the plan did not define which behaviors had to match for customers using Jira and those using Azure DevOps. The proposed correction included shared snapshot-day logic, explicit treatment of tracker-specific differences and test data covering completed sprints, a scope change and a sprint with no committed items. The team accepted it. Tapadia says the agent added parity criteria to the three affected stories and left the other four unchanged. This is a concrete way to assess context quality: ask whether it produced the requirements and test cases needed to build the feature. Counting retrieved documents does not answer that question. A specification and prototype are not a shipped feature The output was a ProductSpec, which Tapadia describes as a product-level specification upstream of engineering-specification tools. The team handed it to Cursor through a deep link as a plan for the coding agent to implement. They also sent it to Lovable over Model Context Protocol, or MCP, along with the extracted design system. MCP gives an AI tool a defined way to interact with another system. Tapadia says Lovable produced a clickable prototype respecting the existing API contracts and styling. These are distinct deliverables: an analyzed feature, a reviewed specification, a coding-agent handoff and a prototype. The answer does not establish that this feature was fully implemented, tested or deployed in production. For a data or engineering team, that distinction matters when evaluating a planning product. A good-looking prototype may help people agree on a requirement, but the team still needs evidence about error handling, permissions, data behavior and the implementation that will actually run. What the 75% figure pays for Allstacks promotes 75% lower token spending and four-times-faster planning. Tapadia explains that the figures come from internal comparisons and customer observations. The explicit comparison covered tens of runs producing the same planning artifact from the same source systems: once in Product Studio and once in Cursor Auto mode connected through MCP. Spend came from Cursor usage data and Allstacks' Langfuse traces. Cursor Auto selected the model, so the systems did not use identical models. Tapadia says Cursor's inference spending was about four times Product Studio's in that comparison. That is the basis for the 75% reduction. Quality was judged qualitatively against the goal of substantially similar artifacts, without a formal scoring rubric. | What Allstacks measured or compared | What it did not include | |---|---| | Model inference spending on the two workflows | Continuous preparation of the context graph | | Time to a finished plan in internal comparisons and customer observations | Allstacks and Cursor subscription fees | | Qualitative comparison of the resulting artifacts | Human review time and a formal quality score | Tapadia also reports average in-session inference spending below $1 across roughly 4,000 Product Studio sessions, excluding context-graph preparation. Neither number is a complete cost per delivered feature. The company attributes the advantage to preparing and retaining structured context before a planning session. The fair purchasing question is whether that preparation, the product fee and review effort produce enough useful improvement for a particular team. A smaller inference bill alone cannot establish the answer. Where people approve changes According to Tapadia, Product Studio can create and update Jira and Azure DevOps work items and Confluence pages. It does not delete or close tracker items. Slack is read-only in the workflow he describes. "Every write from a session stops for approval." The approval can allow one operation, allow that kind of write for the remainder of the session, or decline it. Updates can show a diff, the proposed change alongside the current content. Approval therefore includes a session-level permission option, rather than necessarily requiring a new click for every subsequent operation. Tapadia says writes use the user's own connection and permissions in the destination system. Before updating a ticket, the product compares its current version with the version it previously saw. If someone edited it in the meantime, the proposed write is blocked and must be redone against the current version. He describes similar version checks for Confluence and operation tracking to prevent repeated updates. Rollback occurs through the ordinary history in the tracker. These are company-described controls; LDS did not independently test their behavior. A team evaluating them should deliberately edit a ticket between proposal and approval, then inspect the resulting permissions, conflict handling and history. Tapadia identifies the described functionality as generally available, while a remote MCP server enabling other tools to pull from Product Studio remains in development. An outbound handoff does not establish that this separate inbound integration is already available. Shared context needs its own access review Tapadia says administrators control the scope of source-system tokens and which sources Allstacks processes. Ingested information resides in an Allstacks tenant, prompts go to the configured model provider, and documents handed off to coding tools leave for those tools. Collaborators see the material brought into a shared session. Tapadia says sessions do not expose raw code, but can include tickets. That makes session membership and document exports part of the information boundary a team must review, alongside the permissions on the original systems. Revocation also has two different consequences in his account. Disconnecting a user's MCP connection removes the stored credential and tool access on the next turn. Revoking a source-system token stops new ingestion; already ingested data is deleted under Allstacks' policies within 30 days. Stopping access does not mean every existing copy disappears immediately. These explanations help define a technical review, rather than proving that every organization's confidentiality requirements are met. The team should verify its chosen hosting, provider terms, session visibility and deletion process against the data it intends to connect. What to measure over the next two sprints Tapadia proposes a small comparison using eight to twelve genuinely similar upcoming work items over one or two sprints. Plan one group through the normal process and the other with Product Studio, while keeping the people and reviewers consistent. He recommends measuring time to a ready-to-build specification, clarifying questions and revisions after implementation starts, reopened or substantially rewritten stories, time from start to merge, and specification quality against a rubric. Those measures connect faster drafting with the work that follows. A specification produced sooner offers limited value if it causes more clarification, omits a payment flow or sends an engineer down the wrong path. The small comparison is a practical starting point, not a controlled demonstration that one product will improve every team's delivery. Scope and complexity must be comparable, and teams should record total cost as well as the inference portion. If planning time, revisions, rework and cycle time do not improve, and the existing specifications already score well, Tapadia's advice is direct: "Keep it." That is a useful condition to carry into adoption. The product's value has to appear in requirements people can use and outcomes they can check, not simply in the speed or polish of the initial plan. Reporting note This LDS Exclusive is based on six written answers attributed to Hersh Tapadia, co-founder and CEO of Allstacks, supplied directly through Joshua Milne PR, and the original September 16 announcement. Public Allstacks material provides supporting context. The internal examples, cost figures, product availability and control descriptions are attributed to Allstacks. LDS did not operate Product Studio, rerun the comparisons or independently verify security controls. The additional evaluation questions are LDS's interpretation of the interview. Key Points - 1An internal billing specification wrongly excluded payment collection. A product manager corrected the agent's interpretation of why an old processor was removed. - 2Allstacks'75% figure compares inference spending, uses different models and excludes context preparation, subscription fees and human review. It is not total feature-delivery cost. - 3The interview distinguishes specifications and prototypes from shipped code, describes session-level write approval and proposes comparing revisions and rework over one or two sprints. Scoring Rationale Original named interview gives practitioners concrete failure examples, a clear evidence boundary and practical checks for adopting AI in their work. Sources Original reporting, with the public references used alongside it. LDS Exclusive Reporting based on written answers given directly to Let's Data Science by Hersh Tapadia, Co-founder and CEO, Allstacks . Practice interview problems based on real data 1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with. Try 250 free problems https://letsdatascience.com/problems