You don't know what to build

AI has everyone talking about code. You hear "we don't need that many engineers anymore," or "everyone is an engineer now". We started to act as if the limit on progress is how much code we can produce, and now that we wave our magic wand chant the words "claudius maximus!", it can feel like there's no limit at all.

Yes, THE right word is "feel." Teams feel faster than ever 😏. Whether they are faster is a different question, and in my experience the answer can be daunting. AI feels so fast that we can put a date on something we don't understand yet, and the date doesn't feel absurd, because "the code part will be quick". The code part was always going to be quick, cough cough JBoss AS 6.0.

In my experience, code is rarely what slows us down.

Writing code is one step in solving a problem, and usually the cheapest one. The expensive steps come before it. You have to understand the situation you're in. You have to understand your customer, and what your customer is trying to do, which is not the same as what they ask for. Only then can you think about a solution, and a solution is not one thing: it has phases and versions that change as you learn. And before you build any of it, you need evidence that people want it. A few ideas come with evidence attached, because customers keep asking for them. Most don't, and gathering the evidence is real work.

Say you've done all that. You know people want the thing. You still have to decide how much of it to build first, what the risks are, and which parts you have to get right. A payments product has to get the money right. A medical product has to get the records right. Deciding what you must nail is itself a decision.

Data wrangling did get faster, coalescing information from completely unrelated sources, did get faster, typing got faster. Taking time to actually understand what needs to be built and why did not. These decision are the most important in the process of creating solutions. The steps before it got faster, and the ones after it too. It feels like this one got too, naaaaahhhhhhh.

Understanding still moves at the speed of conversations with customers, and thinking still moves at the speed of thinking. The bottleneck didn't move. It just got easier to ignore, because the visible part, the code, now appears instantly.

Here's what happens when you ignore it. You commit early. The date goes on the roadmap, the deal closes, the product shows up in the billing system before anyone knows how it should work. Before you commit, "we don't know how this works yet" is a reason to pause. After you commit, the same sentence is a reason to be hasty. Every unknown you find makes stopping more expensive, so the more reasons you have to stop, the faster you go. I've been in those rooms, and nobody in them is being stupid. Each call is reasonable on its own. The trap is the order: the commitment came before the understanding, so understanding turned from a guide into a cost.

The second thing that happens is quieter. Software built this fast feels like it is working fine. It answers. A system designed only for the happy path has no way to say "I can't answer this," so when reality leaves the path it returns something plausible instead: a date, a balance, a green status. A wrong answer looks exactly like a right one, and nothing pages anyone. This is why the speed feels free. The demo works, the dashboards stay green, and the errors don't show up as errors. They show up weeks later, somewhere else, usually as a wrong number in front of a customer.

And when they show up, someone absorbs them. This is the cost I think we undercount most. Every gap in a system gets paid for by a person, and it's almost never a person who can fix the system. It's the support rep restoring accounts one at a time after a bad import wiped them. The ops person running a manual step every month because the job can't handle the edge case. The reviewer catching the same bug in every pull request because nobody wrote the test. The customer fronting money the system forgot it owed them. The bug is free to the people who could fix it and expensive to the people who can't.

Being quick does not mean hurrying, rushing, or otherwise moving so fast that you are out of control. And let me repeat: being quick does not mean being agile. […] it also requires ease and grace or being adaptable and resourceful.— Joshua Kerievsky, Joy of Agility: How to Solve Problems and Succeed Sooner (BenBella Books, 2023)

That's why everything feels fine. The cost is real, but it lands on a ledger we never read. Hand work doesn't show up on a dashboard. Apologies don't show up in velocity. The gap survives, month after month, paid in hours of someone's life. The people who pay most are the ones keeping the wheel turning. The careful ones. I see you there. They burn out first, because absorbing is invisible, and invisible work gets neither help nor thanks.

When a team says it's moving fast, sometimes the truth is that someone else is doing the slow part by hand. Maybe AI will speed up the understanding steps too someday. I don't know. So far it has mostly sped up the step that was already fast, which makes the imbalance worse, not better.

The strange part is that your company already tells you when this is happening. It doesn't tell you in metrics. It tells you in language. A stuck ticket finally moves and the update contains the word "finally." A friends starts typing in caps. Someone apologizes, in writing, for work that should never have been assigned. The template your process says is required sits empty, while the real decision lives in some Granola nobody will open again. These are confessions. They have dates on them. They were written by the people inside the problem, which is exactly why nobody reads them as signal. The authors are too close to it, and the readers are the authors.

So if you want to know whether you're fast or just feel fast, don't count the code. Read the exhaust. Listen for the jokes in your meeting titles, and find out who in your company does something by hand every week that a system was supposed to do. I'd like to say I learned this early. I didn't. Some of those joke titles were mine.

Yeah, you need to go figure out what to build.