Giant Robots Smashing Into Other Giant Robots

Illusions Of Fluency

2026-05-12T00:00:00+00:00

I didn’t realize it had a name until I looked it up, but a Rubin vase is a famous optical illusion. It’s the one where you first see two faces looking at one another, and then realize it can instead be seen as a vase. You might have had it the other way around.

That one is well known enough that you probably already know to look for its “second” image. There are many other examples where another view isn’t obvious until it’s pointed out. Even then it’s sometimes hard to see right away.

That is, I’m viewing something, certain I’ve taken it all in, thinking it’s unremarkable. Nothing suggests I’ve missed anything or should give it a second look. Once it’s pointed out, I finally see it. How did I miss that? It was right there the whole time.

Fluency illusion is like that and far more common than we’d hope.

It happens when you realize a detail you missed. You thought you understood, but you hadn’t. That confidence, never noticing what you missed, is the illusion of fluency.

Seduction

This illusion, that we understood what we read when indeed we hadn’t, is insidious. It draws us in without any sense of risk, without skepticism. For if we felt we might be misreading something, we’d look for it. But since we don’t, we move on, accepting our reading as an accurate one.

This isn’t about humility. Not a choice or a failure of attention. The process is automatic. We’re trying to get something done and nothing triggers us to look closer.

Our practice, experience, even education, has made us capable of reading quickly. Of following what may even be complex content and still picking up key elements. That very capability tricks us into thinking we’ve fully understood.

We’re shown a solution to a math problem on a whiteboard. We find out later we’re far from being able to solve it on our own.

And so we can’t just read text once and absorb it all. We have to re-read, study, wrestle with it. It’s why we take a risk when we skim contracts and fine print.

Or source code.

Desirable difficulties

We’re well acquainted with this phenomenon even if we didn’t have a name for it before. In pedagogical settings, we counter fluency illusions with desirable difficulties. The instructor intentionally forces the student to contend with what they read (discussions, exercises, exams, etc.). It helps internalize what they’re reading. It better ensures they’ve discovered what it might yield for them.

As with students, we can’t trust ourselves to capture enough detail merely from reading it. So we must admit we don’t know what we think we know. We need to find ways to illuminate details, most especially when we’re the only ones that may be in a position to do so.

We can create friction to supply that illumination. We want pull requests small enough to read in pieces. We do this not only to limit the scope of a change but to make it tractable to review without merely skimming. We write automated tests not only to verify correctness but to think through what must be considered. We write them to help us engage with the problem at hand. We deliberately create desirable difficulties by forcing a conversation with the situation.

I can lose the illumination I desire when I inadvertently abdicate my role. When I let an LLM produce code I haven’t sufficiently participated in. If an AI tool generates too much code at once, I can be seduced to think it’s doing fine when it isn’t. The pace at which an LLM can produce code can quickly overwhelm the pace of feedback I can handle. In trying to read through it I can easily fall victim to fluency illusion. It may be only later when it becomes plain how much I missed.

We can’t trust ourselves to catch the issues merely by reading the code later. What the AI comes up with might be opaque to us, even when it works well. Our illusion of fluency will tempt us to nod along either way.

Promises, promises

That sounds dire, but it isn’t really. We’re actually used to this. We start new fields of research from threads pulled on older questions. We come up with novel solutions and ways of doing what’s not been seen before. We’ve figured out how to fly.

Cranberries and nightshade may look alike, but one of those is poison. We figured it out not by merely looking at them more closely, but empirically. We tested and watched other animals for clues. We rely on checks and balances and processes, all to limit the cost of being wrong.

Here too we have an opportunity. An obligation really. To stay engaged, to understand in the moment what we’re trying to build. To recognize the success, or failures, of what we write.

Someday we won’t care what the AI explicitly wrote any more than we care about the ones and zeros in our code most days. We can instead focus on the pace of feedback so we can correct issues in time. We can find new ways to converse with the situations at hand. And we’ll want checks and processes to limit the impact of any mistakes along the way.

Someday AI will be good enough to let it do more on its own in writing code. But it still needs us heavily engaged and skeptical for it to become what we hope for.

And we still need everyone else to keep us honest about that.

The Pace Of Feedback

2026-05-11T00:00:00+00:00

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.

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. 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 with skills for /slice, /challenge, socratic-review, and more. Or reach out to us to discuss your project and how we can help.

A Conversation With The Situation

2026-05-08T00:00:00+00:00

I was planning to build a tiny storage shed for my small backyard. Part of me wanted to jump in and start framing right away, but lumber is expensive and I could imagine wasting it.

Being wood, the structure could easily become too heavy to move. I might need access to the wall behind it, so I wanted to keep the framing minimal. But then it also needed to support the roof load from snowfall.

Drafting plans revealed other unexpected details. How much space 2x4 studs would make the shed take up. How to have enough roof overhang without adding too much weight. If I’d done much construction before, these likely would have been trivial details, but I hadn’t.

As much as I could measure over and over, getting into the drafts exposed key details I’d otherwise miss. Working with it revealed what I needed to know but couldn’t see before.

Back to the future

This is not at all a new insight for any of us. Donald Schön wrote about this more than 40 years ago in The Reflective Practitioner. In one chapter, he takes us through a conversation between an architectural design instructor and a student planning an elementary school. Schön depicts dialog and sketches as they work through the challenge. They use phrasing and vocabulary specific to their discipline, loading terms with meaning relevant to the problem at hand. The student, Petra, identifies the choices and constraints she finds most troublesome.

Quist, her mentor, is wrestling too with the problem. He tries and abandons more typical techniques for less conventional ones, devising metaphors for them to explore. They relax architectural prescriptions to fit a situation best practices didn’t foresee. As they talk, Petra finds she can’t quite express the conceptual challenges she perceives designing for the site terrain. As they go, it becomes clear they’re iterating through different framings. They “begin with a discipline” and then “break it open” to find more fitting solutions.

They highlight different aspects and consequences, common vocabulary emerging throughout the conversation. They play with tradeoffs, abandoning some as interesting but flawed. They discover how those impact the hoped for functionality of the school building. Exploring the building site, choice by choice.

Thus the designer evaluates his moves in a threefold way: in terms of… consequences judged…from the normative design domains, in terms of their conformity to or violation of implications set up by earlier moves, and in terms of [their] appreciation of the new problems or potentials they have created.

A conversation arises between the original challenge, options tried, and the outcomes proven to be important. The situation talks to them, they talk back, and so forth. It proceeds until the situation and a solution find common ground with one another.

Schön also points out that an experienced professional like Quist can’t capture everything they know into words. They have to demonstrate it to help lift out the tacit knowledge and intuition. It’s like breathing: it’s easy until you focus on it (great, now I’m suffocating). It’s not his thinking lacks rigor as much as he’s so practiced that nuance is now implicit. It wasn’t for him when he started and it isn’t yet for Petra.

Chatterbox or black box

As professionals who create software, we too work through this with each other and with our tools. We often recognize patterns we can apply and tradeoffs from our choices, but encounter details that demand more from us.

We regularly hold conversations with the situations we’re asked to develop software for. We struggle to articulate to those who weren’t there with us how we found it. We collaborate to load terms with our colleagues, stakeholders, and users. Those not present may miss language we shared and details we discovered.

It’s why we follow agile processes. Being agile isn’t necessarily faster, it’s not necessarily cheaper, but it reduces risk. We learn or confirm in each iteration what will help us be successful going forward. We engage with the details, letting them influence and inform us as we mold and shape them.

As software professionals, we’re first and foremost conversationalists with situations. We must engage with the problems we face to see how choices can fit together. Our solutions don’t need to be perfect. They need to reflect the tradeoffs accepted for the obstacles exposed. And we need to bring along those who weren’t part of our conversation to appreciate our choices.