---
title: The Pace Of Feedback
teaser: The hurrier I go, the behinder I get.
tags: process,velocity,ai,artificial intelligence,technical debt
author: Richard Newman
published_on: 2026-05-11
---

If I'm measuring water into a marked cup, I slow down as I'm nearing the mark
because I don't want to overshoot it. I bet you do that too. I can pour quickly
at first, but as I near the line, I'll decide I need to be more precise. I slow
the rate so I can control it more. If I poured it all at full speed, I'd almost
certainly stop too early or too late. Even if it's okay to be a little off, I'd
still have to fix it.

In essence, I'm managing the pace I can handle. The pace at which I can perceive
what is happening, decide what to do about it, and act on that decision. We follow
a relentless perceive-decide-act flow in much of what we do every day. Driving a
car, sewing a hem, painting trim,
[having a conversation](https://thoughtbot.com/blog/a-conversation-with-the-situation).

We need a pace for perceiving that lets us have time to decide and then act. As
we become more familiar and skilled, we can reduce the time it takes, but it
always costs some time. We learn patterns and we learn what to watch for instead
of everything overwhelming us all at once. No matter how practiced we are, we can
only go so fast. I can responsibly drive faster than a new student, but I'm not
ready for the Grand Prix (vroom-vroom noises aside).

In fact, we depend on controlling the pace of feedback so much that we add controls
for it. Not only the brakes on our cars, but foot pedals on sewing machines,
speed controls on mixers, squeeze handles on sprayers. We know we'll make
mistakes. Without room to react, those mistakes can be damaging.

This isn't only when working with objects. We know all about rushing an arithmetic
problem or typing out an email too fast. The risk of errors and poorly considered
explanations is far higher. Being deliberate while working under pressure may feel
slower, but it generally meets the need better and faster.

## Of power tools and robots

The more manual our tools, the easier it is to handle the pace of feedback. If
I'm using a handsaw, it's unlikely that I'll injure myself or miss a cut going
crooked. The saw can't go far before I notice an issue and I can stop immediately.

Compared to a handsaw, a circular saw's blade rotation and cutting speed are
orders of magnitude faster. The feedback comes too fast for me to perceive every
moment of the cut. I can't track individual rotations or react to each instant.
To avoid mistakes, wasted material, and injury, I need to do more than just react
in the moment.

A crooked cut isn't just poor work—it can bind the blade and cause kickback. So I
manage the pace of feedback to preserve room for my perceive-decide-act cycle.
Before I even start, I set up the work to reduce risk. I can't always see the cut
going crooked in time, so during the cut I feel for binding and listen to the
motor. I compensate for the faster pace by predicting more and preparing more.

Imagine a more complete machine that automates more steps, like those in
mass-market cabinet shops. It might not only trim the wood, but also shape its
edges and corners with dedicated bits. Our machine follows a predetermined
combination of steps already well understood and tested. Now the machine's pace
far outstrips my perceive-decide-act cycle. By the time I perceive a problem and
decide what to do, the machine has already completed several steps. I can only
tell something went wrong after pieces have gone through or the machine jams or
breaks.

To be fair, the process is well understood and preprogrammed. While the cabinets
might lack artisan craftsmanship, they're good enough, sometimes excellent. As a
result, we accept less control for more speed and consistency. Our role shifts
from directly shaping the work to monitoring and feeding the machine. But in a
factory, this trade becomes stark. We cut, affix, trim, and package at breakneck
pace. Pieces get ruined, workers even injured, before anyone can perceive, decide,
and act to stop the line. We now program in acceptable error ranges and tolerances
for the machine to follow.

We can separate ourselves even further from the perceive-decide-act cycle. If we
add a robot with artificial intelligence, it will adapt as it works. Based on
what it senses, it adjusts its path and compensates for variations. Because it
adapts continuously, we can't predict or observe its decisions in real time. Any
one of those could be the start of a bad direction. By the time we realize a
problem, it's already made choices we never saw. We won't know what path it took
or why it chose its approach. By then it's far too late.

## Running blindfolded

Similarly, if an LLM is producing a lot of code for me without pausing, I can
think it's doing fine when it isn't. I may not always realize in time the pace was
too fast. Only upon closer examination will I find the code has become a mess.
I wouldn't easily know what changed or why. It can be like reviewing large,
unfamiliar PRs in unfamiliar codebases.

It's even worse than that. Because we imagine how good AI could be, we can imagine
not needing to be part of the process. We've read where machine learning has found
superior solutions experts can't explain.

We're tempted by a theoretical ideal:  we don't need to understand how something
works as long as it works better than we could. But that would mean I relax my
vigilance and abdicate my perceive-decide-act role. In other words, I not only
am unable to keep up with it, I don't even try.

AI coding tools aren't ready yet for us to step that far back. They can outrun
us and generate a tremendous amount of code quickly. That might be tolerable in
an exploratory effort like prototyping.

But in production, especially in regulated industries, security, safety, and
privacy are at stake. There we remain accountable for every line written and
every behavior introduced. LLMs can do a lot, but right now they're often better
as task tools, like a table saw we can control. They haven't proven themselves
to be wholly autonomous agents worthy of our trust.

We can't trust ourselves to catch the issues merely by
[reading the code later](https://thoughtbot.com/blog/illusion-of-fluency).
Even if it does work well, we may find what the AI comes up with to be opaque.
Although it's tempting to let the tool set the pace, losing control means working
blind and trusting blindly. To be responsible for our work means we
have to be able to engage with it. As with power tools, we need to own the
perceive-decide-act speed we can handle. Losing sight of that risks making mistakes
compound faster than we can recover from.

If you'd like to better manage your pace developing software with LLMs, take a
look at our
[rails-consultant open source project](https://github.com/thoughtbot/rails-consultant)
with skills for `/slice`, `/challenge`, `socratic-review`, and more. Or
[reach out to us](https://thoughtbot.com/hire-us) to discuss your project and
how we can help.