Why AI needs a new playbook

AI needs a new software playbook because the dominant risk has shifted. Building a solution is becoming dramatically cheaper and faster. The harder work is establishing what the organization wants the AI to do and building a system people can rely on.

Performance-Driven Development, or PDD, is our beginning of that new playbook. It builds reliability into the system from the start, with performance measures and expert feedback directing the engineering.

The old playbook addressed expensive mistakes

For decades, the central risk in enterprise software was building the wrong product: something users would not use, customers would not buy or that misunderstood the business problem.

Software took months or years to build. A mistaken assumption could consume a large budget before anyone discovered that the result created little value. Product managers, customer development, Lean Startup, Agile and the product development lifecycle helped teams reduce that risk.

Before committing to a large build, teams investigated demand, tested assumptions and used prototypes and proofs of concept to learn whether the proposed product would matter. Those practices reflected the economics of construction. The more expensive the build, the more important it was to avoid the wrong investment.

Two forces are changing those economics

The first is AI coding. Engineers can produce and revise the surrounding software much faster with capable coding tools. Experiments that once required substantial implementation work become easier to try, inspect and change.

The larger force is using LLMs as reasoning engines inside a workflow. Instead of encoding every interpretation and branch of business logic, engineers can supply instructions, context and tools and let a model reason through the task. The model can generalize across variations that would otherwise require more custom logic.

Consider a document-review workflow. An engineer can give a model a source document, a review method and examples of the expected output. The team can begin inspecting results before building a large rules engine for every variation in the document's language.

We expect the cost and time required to build these systems to keep falling at an exponential pace as models improve. That expectation changes our investment advice: keep build-and-review cycles short, avoid elaborate machinery for temporary model limitations and build so better models can improve the system.

Reliability becomes the central risk

When a first implementation is inexpensive, the team can learn through building much earlier. The management problem moves toward the behavior of the resulting system. A working application shell and a convincing demonstration reveal little about whether employees can depend on it across their actual assignments.

The business still needs a worthwhile outcome. Faster construction makes it practical to investigate more possibilities and change direction sooner. It also makes reliable behavior the question teams must confront much earlier.

Why we build the workflow rather than a separate POC

Prototypes and proofs of concept helped justify an expensive build. As building becomes cheaper and faster, that separate demonstration addresses less of the risk. Showing that an LLM can perform a task on a few examples does not establish that the organization agrees on the right behavior or that the system will deliver it consistently.

We build the actual workflow and its evaluation framework together. Experts review representative work, resolve disagreements and guide improvements from the start. We begin small and move toward controlled production use, where feedback keeps improving reliability. This is how PDD addresses the risk that matters now.

Organizational agreement takes more work

An important part of reliability is getting people to agree on what they want the AI to do. A requirement such as prepare a good review or answer an employee's question contains judgment that a written specification rarely captures completely.

Business experts may interpret the same source differently. A manager may expect an answer where a specialist expects a clarifying question. Two departments may use different calculations. People can agree on a prototype's appearance while disagreeing about the decisions behind its outputs.

Non-deterministic behavior makes that agreement harder. The system may express an answer differently or take a different path through the task. Exact wording is often less important than whether it preserves the right meaning, evidence and decision.

Our advice is to work through concrete cases with the people responsible. Put the input, expected behavior and actual result in front of them. Ask what is acceptable, what changes the decision and who can resolve a disagreement. Those decisions become guidance and evaluation cases the engineers can use.

This is business work inside engineering. More code cannot settle a policy disagreement or supply expertise the organization has not made available.

PDD organizes the work around reliability

Our method explains the shift through four connected responsibilities: structure the project, build a reliable system, scale reliability in production and turn production feedback into improvements.

The PDD guide explains how expert feedback, evaluation and production review work together to build and maintain reliability.

Real production is part of reliability engineering. We launch when the system mostly works and improve rapidly, using human review and live feedback to expose problems development cannot anticipate.

AI is a capability to grow, not a project to finish

Software is becoming faster to build. Organizations are not becoming faster to change. A fixed project plan cannot anticipate every operating decision or the next model improvement. Build and operate creates useful capability while making room to learn.

Earlier software playbook	AI playbook
The challenge is building it	The challenge is reliable operation
Know what you need upfront	Learn what you need through use
Plan around today's technology	Adapt as AI advances
Finish the solution	Keep improving across the business
Choose a framework and architecture for scale first	Establish task definition and reliability, then scale

Buy a product, build internally or work with a partner: each path still needs reliable operation, adaptation, a useful first investment that compounds and people who can apply it.

Replacing SaaS is a business decision

Cheaper software makes more custom work practical. Cutting a subscription bill alone rarely explains the whole opportunity. Examine what the business could do differently, what the existing product contributes and who will operate its replacement. Recreating a familiar interface can preserve an old process when AI makes a better one possible.

How we learned this

Our company history describes the generative AI pivot, the engineering investment and enterprise work that led to PDD. We keep refining the methodology as AI and the work evolve.

Change what leaders ask to see

Ask the team to show the behavior it is trying to produce, the cases it handles, the important failures and the decisions blocking progress. Ask how experts contribute and how production findings become improvements. A polished demo leaves those questions unanswered.

The PDD guide describes the four checkpoints. Our principles explain the choices behind them. About Prolego explains where that point of view comes from.