September 9, 2026

Go Slower to Go Faster: What Transportation Engineering Can Teach Us About AI

Originally published in Chris Bosco’s LinkedIn newsletter, AI Signal, which features approachable AI education and practical ideas for daily work.

The Fastest Road Is Not Always the Fastest Trip

One of the most counterintuitive lessons in transportation engineering is that the fastest road isn’t always the one where people get through the fastest. For decades, the instinct was simple: wider roads, higher speeds and bigger intersections mean people arrive sooner.

But transportation systems do not work that way. The goal is not to maximize a vehicle’s speed between two points – it is to move people through an entire corridor safely, reliably and with minimal interruption.

This idea comes from transportation engineer Mike Brown, PE, AICP, who coined the phrase “move slower to go faster,” building on a movement represented by Charles Marohn, author of Confessions of a Recovering Engineer, that challenges the assumption that higher speeds produce better outcomes.

That distinction changes the design problem: engineers focus on reducing the number and severity of interruptions rather than the speed between them. Roundabouts, median U-turns and connected networks favor steady movement over repeated acceleration and stopping, and a driver at 30 mph can reach the destination sooner and more safely than one hitting 50 between red lights.

I keep returning to this idea as I develop AI applications and workflows.

In both, our instinct is to equate speed and activity with performance. But the real objective isn’t speed at one point in the system; it’s flow through the whole system.

The Illusion of Progress

People judge systems by what they can see and feel. Fifty miles per hour feels like progress, while 30 feels slow, even when the slower corridor is shorter and more reliable. Transportation engineers measure something different: total travel time, delay, reliability, safety and how the network performs overall.

AI creates a similar illusion. A model producing ten pages of analysis in 30 seconds feels astonishingly productive, but the work hasn’t disappeared. Someone still has to read it, decide what matters, verify the claims, resolve contradictions and decide what to do next. Like traffic stacking up at the next signal, the bottleneck has simply moved downstream.

We optimize the visible part of the process because that’s where AI looks fastest, but visible motion isn’t system performance.

The better question isn’t, “How quickly can AI generate an answer?” It’s, “How efficiently can the workflow move from question to trusted decision?”

When More Analysis Becomes More Congestion

Many AI tools now equate value with volume. Proposal-writing tools generate pages of strategy, research assistants create exhaustive reports and planning tools produce long lists of recommendations. The outputs can be impressive, but I keep coming back to a simple question: who is going to review all of this?

Deep research tools made this especially visible. Generating ten-page briefs from dozens of sources and sharing them in minutes became easy, but the time needed to absorb, verify and act on that material didn’t shrink to match. The same pattern shows up in AI-assisted software development — generating a working application fast is only part of the job, since the constraint shifts to testing and verifying it works. Development accelerates; review just moves downstream.

As generation becomes cheaper and faster, review becomes the scarce resource.

That doesn’t diminish the value of deep research or coding tools, it just means generation is one part of a larger system. If one side accelerates while review gridlocks, the workflow hasn’t improved nearly as much as it appears.

That leads to a second, closely related lesson: AI is exceptionally good at filling the gaps in our own understanding.

AI Will Fill the Gaps

AI systems can produce a coherent answer even when the user hasn’t fully defined the problem, which is what makes them both useful and risky. If we don’t clearly define the objective, constraints, inputs or expected output, the model fills those gaps with assumptions. The results may be polished and consistent while solving a slightly different problem than we actually have.

In a deterministic software workflow, missing logic often produces an error. In an AI workflow, missing logic still produces an answer. That difference matters.

It’s tempting to describe a poorly understood process broadly and let the model connect the dots. It’s useful for brainstorming but risky when building a repeatable tool or making a consequential decision, since invisible assumptions create review burden and rework later. AI is highlighting where our system was never fully specified, and that’s a design signal — it tells us where to slow down, clarify what’s known, identify what’s uncertain and decide what the AI should and shouldn’t infer.

Build Roundabouts, Not Giant Intersections

A signalized intersection is batch-oriented: traffic accumulates, stops, waits for permission, then moves in a large release. A roundabout works differently. Vehicles make small decisions, merge when there’s an opening and keep moving. The movement may be slower, but the system sees fewer complete stops.

The best AI workflows increasingly look more like roundabouts than signalized intersections. Instead of one giant prompt followed by one giant output and one giant review, break the work into smaller, checkable loops. Ask for the next useful step, review a concise output, correct the direction, if necessary, then continue.

This isn’t merely a prompting technique; it’s a workflow architecture.

Small loops surface assumptions earlier. They let the reviewer steer the work without rereading pages of material each time something changes and create natural checkpoints for deterministic rules, human judgment or additional data to enter the process. The goal isn’t to minimize interactions with AI, it’s to minimize wasted motion across the full workflow. Sometimes ten small exchanges are far faster than one giant prompt.

Optimize for Flow, Not Volume

Zoomed out, this is less about prompts than about design philosophy.

Good transportation design doesn’t maximize speed everywhere. Engineers decide where access should be controlled, where conflict points should be removed, where slower movement improves safety and where a network can distribute demand rather than forcing everything through one oversized corridor. Good AI design requires the same systems thinking:

• Where should a human define the problem more clearly?
• Where should sample data enter?
• Where should the AI stop rather than keep generating?
• Where should evaluation happen before the next step?

This changes how we measure value. A twenty-page report isn’t necessarily more powerful than five sentences; the better tool gives exactly enough information to make the next decision with confidence.

The objective is not maximum output. It is minimum friction between a question and a trusted action.

Go Slower at the Right Moment

We like the feeling of acceleration, whether we’re driving or watching AI generate a mountain of work in seconds. But the goal isn’t constant acceleration. It’s steady progress.

In both transportation and AI, the best-performing system may actually feel calmer: fewer stops, fewer rewrites, smaller queues, more clarity earlier, less material to review and more confidence in what remains.

That’s the counterintuitive opportunity with AI — before asking how to make the model do more, we should ask where greater clarity would let us ask it to do less.

Spend more time defining the problem. Understand the flow of data. Build against representative inputs. Decide how success will be evaluated. Use smaller, checkable loops. Generate only as much information as the next decision requires.

Go slower at the right moment, and the whole system moves faster.