AI is efficient. But does it make you effective?
Most engineering teams that have worked with AI assistants for a year report impressive measurable gains. A subsystem specification that used to take a week now gets drafted in an afternoon, and developers open three pull requests where they used to open one. Ask the same teams whether their last product release reached customers sooner than the one before, and the answers get vague.
Peter Drucker separated the two ideas decades ago, in the 1960s: Efficiency is doing things right, effectiveness is doing the right things. AI has made much of engineering more efficient. Whether an organization becomes more effective depends on context of the AI, and the AI has no view of the overall system.
Efficiency Is Not Effectiveness
Tasks can be more efficient. Whether they are effective is apparent only when a stakeholder benefits. Consider a team developing an electric braking system that uses AI to draft requirements. In two days it has 600 well-formed statements that pass every quality rule the team defined, work that used to take six weeks.
Then the requirements go to review. The functional safety engineer still reads at human speed, as is appropriate in a safety-critical domain, and a review queue that was two weeks deep is now two months deep. Even after review, a well-formed requirement for the wrong behavior stays wrong. The team has gained six hundred unvalidated decisions, and that is inventory.
Code generation is another good example. A software team triples its output with an AI assistant, but the code still runs on an embedded controller, and integration testing happens on two hardware-in-the-loop rigs that were where already overbooked before the use of AI. The new code waits in line for the rigs.
When I spoke with Marc Osofsky, CEO of Jama Software, about AI acceleration, he observed the same phenomenon in software companies. The extra output moves into testing and every stage after it, and in his words, “product velocity in companies has actually decreased.”
Tests are the subtlest case. When AI writes a feature and then derives the tests from the code it just produced, coverage increases and every test passes. Those tests confirm what the code does. If the code misread the intent, the tests misread it the same way, and the dashboard turns green although nothing has been verified. Marc Löffler calls this watermelon reporting, green outside and red inside, and AI produces it at scale.
Why Faster Stages Make Slower Products
All three examples show a common misconception: A product development organization produces validated decisions, and code or requirements count as progress once they have reduced uncertainty about what will work. Until then they are considered design in progress, work that sits in the system and stays invisible because it has no physical form. An AI assistant produces design in progress very quickly.
Donald Reinertsen wrote in The Principles of Product Development Flow that “few developers realize that queues are the single most important cause of poor product development performance.”
Little’s Law turns this into math: average cycle time equals design in progress divided by throughput. The slowest stage sets the throughput. If AI speeds up any other stage, throughput stays where it was, design in progress grows, and cycle time goes up. The Theory of Constraints arrives at the same conclusion, but from a different direction. I worked through the mechanism in more detail in (AI) Automation Without Acceleration.
Spec-Driven Development
Spec-Driven Development (SDD) makes the specification the source of truth and treats code as a derived artifact. This is the idea behind model-driven development and MBSE, which is 25 years old. Those approaches struggled because maintaining the models cost more than writing the code, and AI has reversed that cost. Jama Software applies SDD in its own engineering and measures the outcome as shipped features minus defects, a metric that counts delivered value.
In SDD, humans review and revise the specification before AI generates code, and generated tests stay linked to the requirement they verify. That solves the test problem above, because verification now refers to intent. It also moves human attention to where it is costs-effective: a flaw found in a specification takes a sentence to fix, while the same flaw in generated code takes a sprint. Marc went further: “The specific artifacts become almost disposable in an AI world.” When generation is cheap, the lasting asset is the knowledge of what to generate and how to judge the result.
Productivity Is Local, Velocity Is Systemic
Productivity is confined to a stage or process step, and measured in output, e.g. requirements per hour. Velocity is a systemic property: it is the rate at which relevant uncertainty falls and validated capability reaches customers. Velocity lives in the handoffs between teams and in queues that nobody owns, so a measurement inside one team’s boundary cannot capture it.
This explains why the fastest product developers got fast before generative AI existed. SpaceX started trying to land Falcon 9 boosters in 2013, and it did so without a separate test program. Customer launches carried landing hardware and attempted a controlled descent after delivering their payload, and engineers used the telemetry from each flight to refine guidance and control. Early attempts ended in explosions. In December 2015, about two years after the first try, a booster landed. The speed came from turning every delivery into feedback for engineering, which is a property of the organization. This was not due to better tools, and certainly not due to AI.
AI works in any environment. In an organization with fast feedback and clean interfaces, it amplifies both. In one with long queues, it makes the queues longer. That’s why the real question is where to apply AI, and answering it requires a map of the whole system.
The Velocity Loop
The Velocity Loop is such a map. It builds on the DevOps loop that Gene Kim and his coauthors describe in The DevOps Handbook and adapts it to cyberphysical products, where hardware and software change at different speeds. The loop connects four practices. Business decides what the product should be and what comes first, defining just enough for a viable first version and adjusting it based on feedback from real-world use. Engineering designs and verifies. Delivery builds the product and operates it in the field. System Stewardship sits at the hub, turning business intent into something engineering can build against and feeding field evidence back into the architecture.
The loop makes the handoffs between these practices explicit. Six kinds of things move around it: intent, decisions, artifacts, instances, feedback, and knowledge. Each must be picked up downstream and contribute to value, or the loop stays open. Most AI tooling today works inside Engineering and produces artifacts. The constraints usually sit in structuring intent before engineering starts, in verification against physical reality, in delivery, or in field feedback that rots, unused.
The loop also shows why SDD works. System Stewardship can establish a commitment once, such as an interface or a specification, and the fast loop then reuses it for many cycles without returning to the hub. A reviewed specification is such a commitment, and AI can regenerate code against it as often as needed. The Velocity Loop calls the opposite an Unanchored Bypass. This happens when work moves directly between practices without the necessary translation, or continues based on commitments that are no longer valid. Every exchange seems fast while architectural assumptions drift apart. Asking an AI for code without a reviewed specification behind it is a classic example.
Where AI Adds Velocity
AI helps the product when it shortens a delay the customer feels. ZF Friedrichshafen cut validation time for high-power electronic components from twelve months to two. The team built a model-based environment that generates digital twins of the components’ thermal behavior, with product requirements linked to the simulation models. The full twin took too long to simulate, so the team used AI to find the critical regions and simplify the rest. AI wrote no requirements here. It removed a constraint in verification, inside a system that took several years of deliberate work to build.
Marc described a semiconductor example in which AI triggers simulations through CI/CD pipelines, so nobody operates each tool by hand. “The humans are up front and on the back end and they’re guiding and they’re governing. But they don’t have to be artisans at each step.” This removes a handover along with the queue that used to form in front of each specialist. The design question changes from how AI can help one engineer to which steps still need a human at all.
Change impact analysis works on the edges of the loop. When a requirement changes late, finding every affected test and design element often takes longer than the change itself, so organizations avoid late changes instead of evaluating them. With live traceability, AI-assisted impact analysis lists the affected elements while the change is still a proposal, and Business can decide on evidence. In the other direction, AI can consolidate scattered field data and incident reports into evidence that System Stewardship weighs before Business sets priorities. In each of these cases, linked requirements and automated pipelines existed first, and AI made a working system faster.
A Diagnostic for Your Next AI Initiative
Before funding an AI initiative, ask one question:
If this AI works exactly as promised, which end-to-end delay becomes shorter?
If the answer names a delay your customer feels, such as a validation cycle or a release, the initiative generates velocity. If the answer is that engineers will produce more, it generates productivity. Both might be useful, but be sure you know which is which.
To find the delay that makes a difference in your organization, map the value stream backward from the customer and look for where work waits. The stage with the longest queue in front of it sets the pace, and it is rarely the one that looks busiest. Then track features delivered and adopted over time, as Jama Connect® does, rather than requirements generated per hour.
Effectiveness Is a System Property
AI is extremely efficient; nobody doubts that today. Effectiveness depends on the system around the tool. Point AI at a stage that was already fast and you get longer queues, with green dashboards over a product that ships on the old schedule. Map the loop first, find the constraint, aim AI there, and the bottleneck moves.
AI will move the bottleneck either way. Engineering leaders can move it deliberately toward the customer, or discover later where it piled up. Productivity is local, velocity is systemic, and an AI strategy has to be built on the second.
