The reason nobody had built a good open version of it is that the work spans biology, finance, regulatory mechanics, and software, and very few people sit across all four. So I first brainstormed and consolidated datasets using Perplexity, created POC Excel workbooks to generalize the approach and math.

The result is BioValue. Open source rNPV calculator, seven validated single-asset deals as presets, a four-post analytical series sitting next to it (posted at the BioValue substack), code is live at nealvybe.github.io/biovalue.

The problem

A risk-adjusted NPV for a drug asset is the standard tool BD analysts use to value a transaction. Take peak revenue, run it through a probability-of-success curve by development stage, discount at the acquirer’s WACC, subtract R&D cost PV. Compare against the deal terms. Decide if the buyer overpaid.

Every BD shop has their own Excel template for this. They are mostly inconsistent. They mostly use stale PoS benchmarks (BIO/Informa 2014 is still in circulation despite better data being available). They mostly bake in assumptions the analyst doesn’t actively own. The output looks rigorous, but the input quality varies wildly between firms.

The version most analysts learn from looks something like: clinical stage on one axis, therapeutic area on the other, lookup a table, multiply. The version that produces useful outputs is more involved.

What I wanted to build

A single-file web app, no backend, no install. Open source. Sensible defaults but everything editable. PoS data from a current source. A few validated deals built in as presets so the user can sanity check the model against real transactions. A Deal Analysis tab that shows three things explicitly: standalone Asset rNPV, a commercial-adjusted lower bound, and the actual Deal PV implied by the deal structure. Where Deal PV sits in that range tells you something specific.

No registration. No paywall. No dashboard SaaS layer. Just the tool.

The data

I pulled phase-transition PoS from MIT Project ALPHA, the most current public-good PoS database. ALPHA is industry-sponsored, biomarker-stratified, and updated quarterly. It replaces the older BIO/Informa numbers and produces meaningfully different results in some TAs.

Phase durations from Sertkaya et al. (JAMA Network Open 2024). R&D cost benchmarks from Chandra & Mazumdar (Analysis Group / Journal of Investment Management 2024). Indication library across 39 conditions from CDC, SEER, NCCN, ADA, AHA, primary literature, each with a source citation in the data file. Deal data from press releases and analyst coverage, normalized to a common structure.

All public, all citeable. None of it was the hard part.

The build

Single HTML file, vanilla JavaScript, Chart.js for the one chart, localStorage for input persistence. No build step. No framework. No bundler. The whole engine is in the page.

I worked with Claude on the engineering. Most of the actual building was conversational: lay out a tab, wire up a calculation, validate against a known result, iterate. The Cowork workflow let me jump between editing the engine, running validation scripts in Node, regenerating chart images in Python, and pushing to GitHub Pages, all in the same session.

The pattern that worked: I’d describe what the tab needs to do, Claude would generate the HTML and JS, I’d point out where the math was wrong or the UX was off, we’d fix it. When I needed to pressure-test the rNPV engine against real deals, I had Claude write a Node script that ran each preset through the engine standalone, which let me catch a couple of bugs that wouldn’t have shown up just by clicking around in the UI.

The hardest decisions weren’t code. They were methodology. Where to draw the line between standalone Asset rNPV and a more conservative BD-realistic lower bound. How to model royalty in licensing deals vs acquisitions. Whether to include a biomarker premium and how to compute it. Whether platform deals and CGT deals fit the same framework as chronic single-asset deals (they don’t, and that took most of a week to figure out).

Each of those decisions has a defense and a counter-argument. The tool exposes the choice rather than hiding it, which is the only honest way to handle methodology disagreements.

The validation

I started with eleven recent transacted deals. I wanted to know if the framework produced Asset rNPVs that lined up with deal economics. Seven of them did. Their Deal PV landed between 30 and 65 percent of standalone Asset rNPV, median 55 percent.

The other four broke. UCB/Neurona at 180 percent of standalone. Lilly/Verve at 525 percent. AbbVie/ImmunoGen at over 300. Merck/Prometheus similarly. The numbers were too high to be deal premia.

That turned out to be the interesting part. Two of the four were cell-and-gene-therapy deals where the chronic-drug rNPV shape doesn’t describe how the asset actually generates cash (one-time treatment, no LoE, manufacturing-constrained launch). The other two were platform deals where the lead asset only captured 30 to 50 percent of what the acquirer was buying. The framework wasn’t wrong about those deals. It was wrong to apply it to them.

That breakdown became the four-post analytical series on the publication side, at biovalue.substack.com.

What got built

A working rNPV engine with seven validated presets. Five HTML pages covering the tool, About, Tutorial, Market Report, and License. Eighty pages of internal docs (methodology, deal validation, post drafts). Four analytical posts ready to publish. Three validation scripts (Node and Python). Live at a custom GitHub Pages site.

The whole thing is one repository. No backend. No database. No login. The repo: github.com/nealvybe/biovalue. Everything reproducible.

What required real judgment

A few places where the AI couldn’t help and the work was mine:

Which PoS dataset to use. ALPHA, BIO/Informa, Wong-Siah-Lo, and proprietary firm-specific databases all produce different numbers. Choosing ALPHA was a judgment call about credibility and currency. I read the methodology paper, checked the sample sizes, and accepted the tradeoffs.

The three-value framework. Standalone Asset rNPV at the acquirer’s WACC is one number. Commercial-adjusted rNPV (BD-realistic haircut: 14 percent WACC, peak times 0.60, commercial PoS times 0.85) is a second. Deal PV (upfront plus risk-adjusted milestone PV plus royalty stream PV) is the third. The decision to surface all three rather than collapse to one number was the most important methodology call. It changes what the tool tells you.

Dropping deals from validation. Neurona at 180 percent looks like a deal premium until you realize the cash-flow shape is wrong. Knowing when to drop a comp rather than rationalize the result is the difference between a model and a fitting exercise.

The biomarker decomposition. The conventional “+20 percent for biomarker selection” rule turns out to be four different things wearing the same name. Working through which one applies in which context took several iterations.

None of that was a coding problem. It was a thinking problem that the tool made visible.

The numbers

One repository. Around 180KB of HTML/JS for the tool. 39 indications in the library. 19 differentiation flags. 7 validated deals with deal economics reconciled to within 5 percent of analyst consensus peak forecasts. 4 analytical posts. 1 live URL with HTTPS via GitHub Pages and Cloudflare. Built incrementally over a few weeks, in parallel with other work.

The tool is at nealvybe.github.io/biovalue. The analytical writing is at biovalue.substack.com. Both are free.

Going from idea to live tool to validated framework to publishable analytical series is the loop AI tooling now makes possible. It still requires domain background, methodology judgment, and willingness to throw out the things that don’t fit. But the bottleneck has moved off the code.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

The previous post argued that AI flipped the bottleneck in software development. Writing code used to be the constraint. Now it is the fastest step in the cycle. The slow parts are upstream (defining what to build) and downstream (validating that it worked). The teams moving fastest organized around blast radius, scoped regression to the change surface, and converged roles so one person could hold more of the loop.

This post is about the tools. Specifically, what happens when you apply a Six Sigma lens to the development process and realize that the tooling was optimized for a bottleneck that no longer exists.

Where the time goes now

In a traditional development workflow, a Six Sigma analysis would show the constraint at the coding step. Work piled up waiting for developers. The entire tool ecosystem evolved to manage that queue. Jira managed the backlog. Code reviews ensured quality before the expensive deployment. QA (Quality Assurance) caught bugs before they reached customers. Regression suites protected against regressions in a slow, manual change process.

AI compressed the coding step. In some cases, by an order of magnitude. But the steps before and after it did not compress. So the constraint moved.

Upstream, the constraint is definition. A product person deciding what the zone should become, interpreting user feedback, articulating what correct looks like. That step is still happening at human speed because it requires human judgment.

Downstream, the constraint is validation. Not “did the tests pass” but “did the user’s experience actually improve.” That step is also at human speed because it requires watching real behavior, interpreting metrics, and making a judgment call about whether to iterate or ship.

The middle of the process, where the code gets written and tested, is now fast. The tools that manage that middle (ticketing systems, pull request workflows, manual QA pipelines) are adding overhead to the step that no longer needs it. The process caught up to the code. The tools have not.

What the tools were built for

Jira was built for a world where multiple humans needed to hand work to each other and track who was doing what. Developer A finishes a feature, moves the ticket to code review, Developer B picks it up, moves it to QA, Tester C verifies it, moves it to done. Each transition represents a handoff between humans, and each handoff needs tracking because humans forget, get busy, and lose context.

When AI agents are doing the coding and testing, those handoffs shrink. The product person describes what the zone should become. The agent writes the code, generates tests, runs them, and commits with notes. The product person reviews the outcome. That is two humans in the loop at most, and often one. The 47 status transitions and custom fields in the middle are tracking handoffs that no longer happen.

This does not mean Jira is useless. It means the value shifts. The ticket is no longer instructions for a developer. It is a record that a human made a decision. The board is no longer a queue of work waiting for developers. It is a dashboard showing which zones are active and what state they are in. The audit trail is no longer for daily standup. It is for the “what happened six months ago” moments.What the tools need to become

If you redesign the tooling around the new bottlenecks, three things change.

The upstream tool needs to be an observatory, not a backlog. The slowest part of the new process is figuring out what to build. That means the tool needs to surface problems faster. If Atlassian integrated observability (the kind of data you get from Splunk, Mixpanel, or Datadog) directly into the product planning layer, the feedback loop from “something broke” to “someone knows about it” would tighten from days to minutes. Right now, a tester finds a crash, writes it up in Jira, someone triages it, and eventually it reaches the person who can act on it. If the crash data surfaced automatically in the zone dashboard, the product person running that zone would see it in real time and direct an agent to investigate before a ticket ever gets written.

The midstream tool needs to be an orchestration layer, not a project manager. Atlassian’s recent launch of agents in Jira (February 2026, now in open beta) points in this direction. You can assign tickets to AI agents the same way you assign them to humans. The agent shows up as a team member. You can mention it in comments, track its progress, and review its output. But the interface is still ticket-shaped. The evolution would be zone-shaped. Instead of assigning individual tickets to agents, the product person would describe what the zone should become, and the agents would break that down, execute, and report back. The human reviews the outcome, not the individual steps. Epics or stories scoped to zones, not granular tasks scoped to individual changes.

The downstream tool needs to close the loop automatically. After the agents make changes and tests pass, the question is whether the user’s experience improved. That requires connecting the deployment to the metrics. Did registration errors drop after the zone sprint? Did page load times improve? Did the user behavior change? Right now, that validation is manual. Someone checks a dashboard, compares before and after, and makes a call. If the tooling connected the deployment event to the observability data automatically, validation could happen in minutes instead of days.

What others are building

Atlassian is not the only company rethinking this space.

Anthropic published how their internal teams use Claude Code, and the pattern is revealing. Their security engineering team described their old workflow as “design doc, write janky code, refactor, give up on tests.” Now they give Claude pseudocode, guide it through test-driven development, and check in periodically. The key phrase is “check in periodically.” The human is not in the loop on every step. They set direction and audit outcomes. Between February and August 2025, the share of Claude Code usage dedicated to implementing new features jumped from 14% to 37%. The tool shifted from helping write code to being the thing that writes the code while the human focuses elsewhere.

Cursor shipped Automations in March 2026. An always-on agent that watches for triggers. A bug report lands in Slack. The automation checks for duplicates, creates a Linear issue, investigates root cause in the codebase, attempts a fix, and posts a summary back in the thread. No human context-switched. The entire upstream-to-midstream flow happened without a human deciding anything. The human’s role was to set up the automation and review the output.

Devin takes full task delegation further. You hand it a problem, it works asynchronously, and reports back with a pull request. The developer is not co-editing. They are reviewing outcomes.

The pattern across all of them: the human is moving further from the individual steps and closer to setting direction and reviewing results. The question that none of these tools has fully answered is how far you can push the “check in periodically” model before you lose control. That is the frontier.Rovo and the platform bet

Atlassian is making a bet with Rovo Dev that is worth watching. Their agent takes a Jira ticket, breaks it into a technical plan, generates code and tests, and auto-reviews pull requests against the acceptance criteria in the ticket. It pulls context from across the Atlassian ecosystem: Confluence docs, Jira history, Bitbucket repos.

The interesting thing about this is not the code generation. Every AI coding tool does that. The interesting thing is the integration surface. The agent has access to the documentation, the ticket history, and the codebase in one context. That means the quality of its output depends heavily on the quality of those inputs. Well-maintained Confluence pages, well-written Jira tickets, and clean Bitbucket repos produce better agent output. Neglected documentation and vague tickets produce vague code.

This is the “ticket as prompt” idea from the previous post, built into a product. The ticket is literally the prompt. If it is well-written, the agent can execute. If it is vague, the output is vague. Atlassian is betting that this will push teams to write better tickets, which in turn makes the agents more useful, which makes the platform more valuable. It is a flywheel, but only if teams change how they write issues.

What this looks like in practice

At SportChartz, the product is made up of independent services with clear API (Application Programming Interface) boundaries. The development cycle for a zone sprint looks roughly like this:

1. User feedback and error data accumulate for a zone (upstream)

2. The product person reviews all of it, decides what the zone should become (human judgment)

3. Agents execute: code changes, test generation, test execution, commits with notes (fast)

4. Product person reviews the outcome, not the individual commits (human judgment)

5. Deploy to staging, check metrics, iterate or ship (downstream)

Steps 1 and 5 are where better tooling would help the most. Step 1 is still mostly manual (reading bug reports, checking dashboards, talking to users). Step 5 is still mostly manual (comparing metrics before and after). Steps 2 and 4 are human judgment and will stay that way. Step 3 is already fast.

Atlassian’s current tools handle step 3 well. Jira tracks the work. Bitbucket holds the code. Confluence holds the context. Rovo connects them. But steps 1 and 5 require data that Atlassian does not own yet. Error rates, user behavior, performance metrics. That is Datadog and Mixpanel territory.

The DevOps extension

This is really a DevOps evolution. Traditional DevOps connected development to operations: CI/CD (Continuous Integration / Continuous Deployment) pipelines, automated deployments, monitoring, alerting. The tools (Jenkins, GitHub Actions, Datadog, PagerDuty) bridged the gap between “code is written” and “code is running in production.”

The new gap is between “a problem is detected” and “a human decides what to do about it.” And between “a change ships” and “someone confirms it actually helped.” DevOps solved the deployment gap. The next evolution solves the decision gap.

The development tools (Jira, Bitbucket, Confluence) need to extend into operations territory. Not to replace Datadog or Splunk, but to bring that signal into the same interface where product people are making decisions. The agent that fixes the code is only as fast as the human who tells it what to fix. If that human has to switch between four dashboards to understand what went wrong, the bottleneck is the tool, not the person.

The platform that connects all five steps of the zone sprint, from problem detection through definition through execution through validation and back to monitoring, is the one that closes the loop. Right now, no single tool does that. Atlassian is closer than most because they already own steps 2 through 4. The question is whether they move fast enough to own the edges before someone else builds the full loop from scratch.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

Every company that scales past a handful of people hits the same wall. The people who built the thing have to stop building and start explaining.

This has always been the bottleneck. Not hiring. Not fundraising. Not product-market fit. The bottleneck is the transfer of context from the people who have it to the people who need it. And for most of the history of building companies, the answer has been some version of: hire smart people, pair them with experienced people, and wait.

AI is about to break this model. Not by solving the training problem - by making it worse in ways that aren’t obvious yet.

How training actually works

The official version is onboarding docs, wiki pages, recorded walkthroughs, maybe a buddy system. The real version is someone sitting next to someone else for a few weeks and absorbing how decisions get made. What to prioritize. What to ignore. Which shortcuts are fine and which ones create problems downstream.

This works because the new person makes small mistakes, gets corrected in context, and builds a mental model of how the organization thinks. The feedback loop is tight. The cost of mistakes is low because the scope starts small.

The whole thing depends on experienced people having time to do the correcting. And it depends on mistakes being visible enough to catch.

What AI changes

When someone uses AI to produce work - code, documents, analyses, designs - the output looks finished. It’s syntactically correct. It follows conventions. It reads like someone who knows what they’re doing wrote it.

This is the problem. A junior person producing work with AI assistance looks a lot like a mid-level person producing work without it. The visible quality gap that used to signal “this person needs more guidance” has compressed. The work looks right even when the person producing it doesn’t fully understand why it’s right.

In a code review, the difference between code written by someone who understands the system and code written by someone who prompted their way to a working solution used to be obvious. Variable naming, edge case handling, architectural choices - these things revealed how deeply someone understood what they were building. Now the AI handles all of that. The code looks clean. It passes tests. But the person who submitted it might not be able to explain why this approach was chosen over an alternative, or what breaks if the assumptions change.

The review bottleneck

Code review has always been the last line of defense. Someone experienced reads the work, spots the gaps, and either fixes them or sends it back. This worked when the volume was manageable and the patterns were recognizable.

AI-assisted development changes the math. A developer using AI tools can produce three to five times the volume of code in the same time. The reviewer’s job just got three to five times harder, and the mistakes are three to five times harder to spot because the surface-level quality is high.

The reviewer used to scan for obvious problems - style issues, missing error handling, inefficient patterns. Those are gone now. The AI handles them. What’s left are the subtle problems: wrong abstractions, misunderstood requirements, solutions that work for the current case but create tech debt for the next three cases. These take real expertise to spot, and they take time to explain.

So the people with the most context are now spending more time reviewing more output that’s harder to review. The training bottleneck didn’t get better. It got worse.

The delegation paradox

Here’s where it gets counterintuitive. AI makes individuals more productive, which should mean you can do more with fewer people. And in the short term, that’s true. A small team with AI tools can ship at a pace that would have required a much larger team three years ago.

But you still need to grow the team eventually. Markets move, products expand, and the people who built the first version can’t do everything forever. When it’s time to scale, you discover that the training infrastructure has atrophied. The experienced people have been heads-down shipping. The documentation reflects what the AI generated, not the reasoning behind it. The institutional knowledge is concentrated in fewer heads than ever.

This is the paradox: the same tools that let you move fast with a small team make it harder to grow that team later. The speed advantage creates a training debt that compounds over time.

It’s not just engineering

This pattern shows up everywhere AI touches knowledge work. A junior analyst using AI to produce financial models creates output that looks polished but might not reflect a deep understanding of the assumptions. A junior marketer using AI to write campaigns creates copy that reads well but might miss the strategic positioning that an experienced person would catch.

In each case, the visible output improves while the invisible understanding stays the same. And the experienced people who could close that gap are busier than ever because the volume of output to review has exploded.

Product management hits this too. An AI can generate a reasonable-looking PRD from a prompt. But a PRD that covers the right features, has the right scope, and makes the right tradeoffs requires understanding the customer, the market, and the technical constraints in a way that doesn’t transfer through prompting.

What I’m watching for

There’s no clean answer to this yet. The training problem has been hard for as long as companies have existed. AI is reshaping it, not solving it.

The companies that figure this out will probably find ways to make the reasoning visible, not just the output. Some version of showing your work that scales beyond “explain your code in a pull request description.” Something that captures why decisions were made, not just what was decided.

The ones that don’t figure it out will build fast, ship fast, and then stall when the original team burns out and no one else can pick up where they left off. The training debt comes due the same way tech debt does - gradually, then suddenly.

I think about this a lot because I’m building a company right now where the AI-to-human ratio in the development process is high. The leverage is real. But so is the risk that the knowledge stays in too few heads for too long.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

My father was a carpenter. He had a rule: measure twice, cut once. It made perfect sense. Wood costs money. A bad cut wastes material. You cannot un-cut a board. So you invest the time upfront to make sure the cut is right.

I used to flip it on him just to hear the lecture. Measure once, cut twice. He would shake his head every time.

His rule assumed that measuring was cheap and cutting was expensive. In his world, that was true. In software development, it used to be true too. Writing code was the hard part. A bad deployment could take down production for hours. Rolling back was painful. A bug that made it to customers meant going through the entire fix cycle again. So teams invested heavily in requirements documents, design reviews, test plans, staging environments. Measure twice, cut once.

The economics have changed. In cloud systems with CI/CD1, a bad cut is cheap. Deploy, see it break, roll back in seconds, fix, deploy again. And now, with AI writing the code, the cut itself takes minutes instead of days. The ratio flipped. Measuring is now the expensive part.

Measure once, cut twice is not reckless. It is rational when cutting is fast and cheap and measuring is slow and expensive. A detailed requirements document in Jira takes longer to write than just building the thing, seeing if it works, and iterating. The prototype becomes the spec.

The new bottleneck

The traditional development cycle had a clear bottleneck: writing code. The process around it (requirements, ticketing, reviews, testing) existed to make sure the expensive part went smoothly. Testers filed bugs. Product managers triaged them. Developers picked them up, understood the context, wrote the fix, wrote tests, opened a pull request. Someone reviewed it. Quality assurance verified it. Everything waited on the code.

Now the code part takes minutes. An AI assistant can write the fix and the tests in one shot. But everything around it moves at the same speed it always did. Someone still has to decide if the bug matters. Someone still has to describe it well enough that the fix is correct. Someone still has to verify the fix actually addresses the real problem. Those are all judgment calls, and judgment does not speed up just because code generation did.

If coding used to be 70% of the cycle and coordination was 30%, the proportions are closer to reversed now. The process that was designed to manage the slow part is now adding friction to the fast part.

Two functions that stay human

As AI compresses the middle of the development cycle, two distinct human functions emerge on either side. They are separate for good reason, primarily skill.

The first is product. This is the technical development side. The person who understands the system, makes architectural decisions, orchestrates AI agents across zones, and judges whether the output is correct. They need product sense to know what to build and technical depth to know if it was built right. The old titles do not map cleanly. This is not a traditional developer waiting for a spec. It is not a traditional product manager who cannot read the code. It is someone who can hold the full loop: understand the problem, decide the solution, direct the agents, evaluate the output, and iterate. A technical product manager. A lead developer with product instincts. The title matters less than the ability to run the whole cycle.

The second is marketing, in the broadest sense. Customer-facing. Support. The person who understands users, talks to them, interprets their feedback, and translates what they are experiencing into something actionable. They are the source of truth for what the customer actually needs, which is often different from what the customer says they want. Their output feeds the product side. If it is vague, the product person builds the wrong thing faster than ever.

AI can write code, generate tests, draft documentation, even summarize user feedback. But it cannot decide what the product should become. And it cannot understand what a frustrated user is really telling you. Those two judgment functions stay human. Everything in between is compressing.

Where roles converge

The most valuable person on a team right now is the one who can look at a batch of user feedback, understand the product implications, make a judgment call about what the area should become, and then directly orchestrate the AI agents to build it. That person does not need a separate developer to translate their vision into code. And a developer who cannot make product decisions is stuck waiting for someone to tell them what to build, which is the new bottleneck.

Testing follows the same pattern. The hard part of testing was never running the tests. It was knowing what to test. Edge cases that matter. Scenarios that reflect real user behavior. The judgment about which failures are acceptable and which are not. That is the same “defining correct” problem, just applied to quality instead of features. If the product person is running a zone, they already know what correct looks like. They are the best person to define the test criteria. AI generates and runs the tests. The separate QA2 team as a handoff point becomes unnecessary when one person holds the full context.

This is a convergence. The line between developer, product manager, and tester is dissolving. Not because the skills are less important, but because one person with AI support can now hold more of the loop than was previously possible.

The new baseline

Some of what follows is already happening at well-run engineering organizations. These are not new ideas. But they used to be what separated great teams from good ones. They are becoming what separates functional teams from dysfunctional ones. The bar moved.

Playing zone. The best teams are organizing work by blast radius, not ticket priority. They group issues by what part of the system they touch, not by who reported them or how urgent they sound. At SportChartz, the product is made up of multiple running services with clear API3 boundaries between them. When we see crash bugs in registration, and registration touches the subscriber database, we look at all the pending issues that also touch the subscriber database. Feature requests, bugs, performance complaints. We group them together, assign one person to that zone, and do a focused sprint where that person absorbs all the feedback at once. The output is not “12 bugs fixed.” It is “this area of the app is significantly better.” The bug reports are not a to-do list. They are research input for rethinking the section.

Scoping regression to the change surface. If you change 12 things scattered across the product, you need to regression test the whole product. If you change 12 things all within one contained area behind a clear API boundary, you regression test that area thoroughly and do a light smoke test on the rest. Change a lot in a smaller area, run full regression on that area, then rotate to the next zone. Each zone ships independently. The whole product moves forward without any single release touching everything at once.

Treating AI as a participant, not a helper. This means more than giving developers access to Copilot or Claude Code. It means structuring your workflow so AI agents can consume the same inputs your developers consume. If your bug reports are only understandable by a human who already knows the codebase, you have a bottleneck that AI cannot help with.

Accepting that iteration is cheaper than specification. The 2025 DORA4 report found that AI does not automatically improve software delivery. It amplifies existing conditions. Good teams get faster. Teams with heavy process and fragmented workflows get more mess, faster. The teams that benefit most are the ones that already had short iteration cycles and were willing to ship, observe, and adjust.

Not everything changed

Some things still need the measure-twice treatment. Data migrations. Security. Anything touching money. Regulatory compliance. Infrastructure that, once deployed, is hard to undo. These are still wood. A bad cut is still expensive and sometimes irreversible.

The mistake most teams are making is treating everything like wood because that is what the process was built for. And the mistake some AI-first teams are making is treating everything like cloud because the tools make it feel that way. The reality is that every codebase has both. Knowing which parts are wood and which are cloud is itself a skill.

A note on scale

Everything above describes how small, product-led teams are running today. The pattern changes at enterprise scale. At 300 engineers across multiple product lines, horizontal concerns don’t fit inside a zone. Platform architecture, security, reliability, data governance. And the softer things: how junior engineers learn the codebase, how designs stay coherent across teams. They all span zones, and they need people and structures dedicated to them. The zone model is a local pattern, not an organizational one, and scaling it requires a different set of decisions about where zones end and shared platforms begin.

The frontier

The table stakes get you to functional. The next set of problems is harder, and not solved yet.

Bug reports as prompts. If every issue in your tracking system was written well enough to be directly actionable by both a human and an AI agent, the entire cycle from report to fix to test gets faster. The bug report becomes the prompt. That requires a different way of writing issues than what most teams are used to.

Test case generation from requirements. If the requirement is clear enough to be a prompt, then generating test cases from it is almost mechanical. “Given this input, expect this output. Given this edge case, expect this error.” The test cases are implicit in a well-written requirement. AI can extract them. But it only works if the requirement is well-written, which brings us back to the two human functions.

Automated regression scoped by dependency graph. Right now, deciding what to regression test after a change is a human judgment call. If your system has a clear dependency map, that decision can be automated. Change the subscriber database layer, automatically run every test that touches subscriber data, skip the rest. The architecture has to support it, but the tooling is getting close.

The workforce question. Companies are cutting 10-20% of engineering headcount and pointing to AI as the reason. Some of them restructured how they work first and then realized they needed fewer people per zone because each person is more productive. Some just cut headcount without changing the process and are now wondering why the remaining team cannot absorb the work. The difference is whether the cuts followed a real change in how work gets done, or whether “AI” was just the justification for a cost reduction. At scale, you might have five product people each running zones with AI agents, and two or three marketing people feeding them user signal. That is a team of eight doing what used to take thirty. Not because anyone was unnecessary, but because the coordination overhead between roles disappeared when one person could hold more of the loop.

In practice

I spent decades building software in both embedded and cloud environments. In embedded systems, you still measure twice. The hardware is real. A bad cut means a physical product recall. In cloud systems, the cost of a failed cut dropped so far that the old process creates more drag than it prevents.

The teams that are moving fastest right now are playing zone. They organize by blast radius, scope their regression to the change surface, and treat bug reports as research input for area-level redesigns rather than individual tickets. The people running those zones are a new kind of role, part developer, part product manager, part tester. They hold the full loop, and AI handles the parts that used to require separate people with separate handoffs.

The practical side of this is in how you structure the inputs. Jira issues written as prompts. Test cases generated from well-defined requirements. Workflows where AI agents participate in the development cycle alongside humans. That is where the zone model pays off.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

Product development has always had a cost problem.

Not the cost of building. The cost of being wrong. A wrong build used to mean months of wasted engineering, a missed quarter, a planning cycle spent undoing what the previous one created. So the frameworks that survived were the ones that invested heavily upstream. Understand the market. Define the buyer. Write the requirements. Get it right on paper before you touch the code, because touching the code is expensive.

That logic was sound. It’s just no longer the constraint.

The cost of being wrong

When building takes days instead of months, the cost of being wrong collapses. You can build the wrong thing, show it to a real user, learn exactly why it’s wrong, and rebuild it in the time it used to take to write the requirements document for the first version.

This doesn’t mean the upstream work stops mattering. Market problems don’t change faster just because you can build faster. Knowing who you’re for, what you do for them, why you’re different: that’s strategy, not implementation. If anything, the speed of AI-assisted building makes positioning more important, because you can build so many things that the discipline of choosing what not to build becomes the real constraint.

What changes is everything between the insight and the market.

The spec is the build

The long requirements document was a technology for managing expensive uncertainty. Specify every interaction, every edge case, every acceptance criterion before development starts, because development is the expensive part and you need to get it right on paper first.

When building is cheap, the prototype is the spec. You build it, react to it, adjust. The document that used to justify the build is now the build itself. A rough sketch and a conversation replace twenty pages nobody finishes reading anyway.

Roadmaps longer than a quarter become fiction. If you can build and validate a feature in two weeks, a twelve-month roadmap is six learning cycles out of date before you’re halfway through it.

What the product actually is

But the deeper shift isn’t about speed. It’s about what the product actually is.

In the traditional model, the product is what you ship. The feedback loop is how you improve it. They’re sequential. You build, you launch, you learn, you plan, you build again. The learning informs the next cycle.

In an AI-accelerated model, the feedback loop is the product. The thing you ship on day one is a hypothesis. The thing you ship on day thirty, after four or five iterations shaped by real usage, is the product. The learning process and the building process aren’t sequential anymore. They’re the same activity.

The skill that matters now

This changes what skill matters most. It isn’t requirements writing. It isn’t even building. It’s pattern recognition across fast feedback.

Can you watch five users interact with something you shipped three days ago and identify the common thread? Can you tell the difference between “this is confusing because we implemented it poorly” and “this is confusing because the concept is wrong”? Can you distinguish a user struggling with the interface from a user who doesn’t actually have the problem you thought they had?

These are judgment calls that require deep market understanding. The understanding doesn’t change. The speed at which you have to apply it does.

The frameworks aren't wrong

The frameworks built for the old cost structure aren’t wrong. The market orientation is right. The buyer focus is right. Pragmatic Marketing got the important things correct.

What they couldn’t anticipate is a world where the build is no longer the expensive part. Where the cost of correcting is lower than the cost of planning. Where the thing you learn by shipping in week one is worth more than anything you could have specified in the months before it.

The feedback loop was always how products got better.

Now it’s how products get made.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

SportChartz started as a spread reversion model. A way to predict the probability of reaching the closing spread within a certain number of drives. The charting came later, once we transformed the data and realized the patterns that CMTs use in equities were showing up in the game signal. That’s when it became a charting platform, modeled after TradeStation and StockCharts.com. The path from there to an agent platform was a series of problems we didn’t see coming until we were standing in front of them.

The charting tool

Once the charting system was in place, the platform gave users Bollinger Bands, RSI, MACD, and Spread Deviation, all working on data that’s been reindexed by game events and transformed into a proper signal.

The first version supported up to ten simultaneous games. That felt like plenty. We’d pick the marquee matchups (prime-time NFL, nationally televised NBA games) and provide charts for the games people were already watching.

The selection problem

Then we started learning from the CMTs using the platform. Some of them weren’t interested in the marquee games. They were trading mid-week college basketball. Tuesday night MAC conference games. The kind of games most people don’t even know are happening.

The less prominent games were sometimes better trading games. Less efficient markets. Fewer sharp bettors watching. The prediction market prices reflected less information, which meant the technical signals were often more actionable. A divergence in a prime-time game might get corrected quickly because thousands of people are watching. The same divergence in a Tuesday night game might persist longer because nobody’s paying attention.

We’d spent time trying to figure out which games and leagues to support. The answer turned out to be all of them. All power conferences for NCAA, all pro games. On a day when multiple sports overlap (pro and college football, NBA, college basketball) that can be 40 to 50 games.

So we rebuilt the architecture to support all of them.

The consumption problem

Supporting 50 games created a new problem. Nobody can read 50 charts. The charting tool was excellent for a user focused on one or two games. But the whole point of covering everything was that the opportunities could be anywhere. A CMT watching the Celtics game might be missing a better setup in a college game they didn’t know was happening.

We opened a Discord and encouraged users to share what they were trading. The idea was community intelligence, CMTs spotting signals in different games and surfacing them for each other.

This didn’t work the way we hoped. What we got was after-the-fact reporting. “I caught this divergence in the second half and it played out.” That’s interesting for learning, but useless for acting in the moment. By the time someone posted about a signal, the window had closed.

Alerts

The fix was to take the human out of the communication loop. Instead of waiting for a user to spot something and post about it, we built alerts. The platform monitors the charts and pushes notifications when specific conditions are met. A MACD crossover in the Memphis-Houston game hits your phone whether you’re watching that game or not.

This solved the timing problem. The signal reached the user while it was still actionable.

The complexity wall

We started showing the platform to people outside the CMT community. Handicappers with deep knowledge of teams and matchups. Sports fans who traded prediction markets casually. They saw the alerts, understood that something was happening, but couldn’t act on them.

The alerts said things like “bearish RSI divergence” and “Bollinger squeeze breakout.” For someone who speaks that language, these are clear and specific. For someone who doesn’t, they’re noise. Even when we simplified the language, the underlying issue remained. Acting on a technical signal requires understanding what it means in context, and that understanding takes time to develop.

These users didn’t want to become chartists. They had their own frameworks for thinking about games. They wanted the information the charts were producing, translated into terms they could use without leaving their existing workflow.

The agent decision

Instead of trying to teach everyone technical analysis, we built agents that watch the charts, interpret the signals, and communicate them in plain terms. The agent does the chart reading. The user gets the insight.

For CMTs, the agents became something more. A way to encode their strategies and run them at scale across every live game. A technician who developed a multi-indicator strategy for identifying momentum shifts could program it into an agent and have it monitor 50 games simultaneously. The strategy runs everywhere at once. The CMT’s expertise scales beyond what they could do watching charts manually.

The app we didn’t build

There was a point where we discussed building separate apps. A pro version for CMTs with full charting tools and strategy builders. A simple version for casual users with just the agent notifications and plain-language summaries.

Separate apps would have missed the point. The value isn’t in the tool. It’s in the network. CMTs and casual users on the same platform create something that separate apps can’t. A CMT builds a strategy. The agent runs it. A handicapper uses the output. They’re on the same platform, benefiting from each other’s presence, even though they’re using it in completely different ways. Split them into separate apps and you lose that connection.

Where this may be going

Every step in this build, from charting tool to alerts to agents, was a response to a real problem we discovered by putting the product in front of users. That's still the only method we trust.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

I had a working R Shiny prototype for football spread reversion predictions. A handful of users, no security, R doesn’t scale. The goal was to port the whole thing to a real platform and allow Chartered Market Technicians to use it across multiple live games.

I turned to Claude Code. Within a couple of days we had the AWS scaffolding together: front end, containers, deployment pipelines, documentation. It filled in gaps in my understanding of CloudWatch monitoring, DNS, VPC networking.

Then we ported the R data feed and analysis modules to Python, built test scripts, and got the spread reversion model running on the new infrastructure. The main issues were anomalous data events from the sport feed: timeouts, referee administration events, edge cases that the R prototype had papered over.

Auth was next. Multiple users means login. I partnered with Okta and Claude implemented the integration. Then caching, so every game analysis wasn’t re-transforming the data for every user.

The caching architecture was where the prompting workflow started to take shape. I’d pass the design and requirements to Claude, which generated ideas and questions. I’d add my thinking, then pass the whole thread to ChatGPT for a different perspective, then back again. It was conversational, the same kind of iteration you’d get from a whiteboard session with senior engineers. The difference was no scheduling, no Confluence write-up, no follow-up meeting. If I wanted additional insight, I opened a new session. The rigor was the same. The coordination overhead disappeared.

By the end of football season, we had a working multi-user app. Then I described what I really wanted to build: a charting platform modeled after TradeStation and StockCharts.com, using the enriched data feed, with tools for users to annotate the charts. We had a working model shortly after.

The backlog problem

Development capacity had outpaced every other part of the operation. CMT associates providing product feedback generated a backlog longer than I have ever seen. More sports, more indicators, additional analysis modules, charting tools, sharing, social features, communities. The list kept growing.

And the capacity to build it was there. Functionality that would take a traditional team several months was getting done in weeks.

I refactored the services with Claude so they could deploy independently, aligned to functional areas that matched the backlog feedback. Terraform infrastructure scripts, database changes, all part of the same refactor.

Then I opened a Claude coding session for each microservice, with a shared markdown library for documentation. I ran the backlog in parallel. Instead of treating it as a list of issues to resolve, I started asking a simple question for each service: “how can we make this awesome?” I’d go into planning mode with that service’s Claude session, implement not just the fixes but the features to make it great. While one agent was running, I switched to the next.

At Dell, VMware, and Comcast, this scope of work would have been an epic with stories broken across multiple sprints. Each story groomed, estimated, assigned, reviewed. Sprint planning, standups, retros, cross-team dependencies managed through program increments. The agile framework exists to coordinate people across functional areas. When the development capacity changes this dramatically, that coordination model starts working against you. The ceremonies become the bottleneck.

The ratio problem

Then reality stepped in. The app had a lot of functionality, well beyond MVP scope. And the process around it hadn’t kept up.

Telling users what should happen in each release, having tests we could execute before deployment, those became luxuries. We were changing so much that even with a few users, I couldn’t align a bug report to know which release it was filed against.

The core problem was a ratio. Traditional dev cycles have a rough balance: a week of development matched to a week of testing. AI compressed the development side to almost nothing, but the testing cycle stayed the same. We couldn’t reduce the testing. So we had to increase the development work per release.

But we couldn’t just pull more Jira issues by priority. If we did, we’d be changing too many areas of the app at once. The increased surface area meant more regression testing, which made the problem worse, not better.

Making it awesome by service

We changed the goal. Instead of taking Jira issues from a priority perspective across the whole app, we looked at a single service with high-priority bugs. Then we brainstormed on how to make that service awesome.

The bugs were the entry point, but the scope expanded to include features and improvements for that service. A week of focused development on one service matched the test cycle. The regression surface stayed contained because we were only changing one functional area. The ratio balanced out.

This is the approach now. Pick a service, go deep, make it great, test it properly, deploy it. Then move to the next service. The speed is still there, it just runs within a structure that keeps quality connected to it.

Where we are now

The current focus is scaling the development process. The system works. The methodology works. It lives in markdown documentation and in practice — architecture decisions, service boundaries, deployment procedures, development history, post-mortems, each service with its own complete record. Confluence got replaced by Obsidian and a searchable index across all of it. Claude’s context window means every coding session starts from scratch, so the docs became the continuity layer.

The AI compressed the development cycle, but it didn’t compress the thinking, the testing, or the process around it. The speed is transformative, but only if the rest of the operation can keep up with it.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.