4 min read

AI doesn't have a whiteboard, so you should bring one

AI doesn't have a whiteboard, so you should bring one

Picture a team. Modern stack, smart people, productive with Claude and Copilot. They ship constantly. But code reviews are taking longer and are more difficult. Regressions keep surfacing in places that should have been settled weeks ago. New features lean on the previous ones in shapes nobody quite predicted.

In a discussion with the team, we finally said it out loud: "Do we actually know how this thing fits together?"

Nobody does. At least not clearly.

Somewhere along the way, "I talked to the AI about it" had quietly replaced "we designed it." There was no moment of decision. No architecture review was skipped on purpose. The team just stopped doing one — because every time someone reached for a question, an answer was already waiting in a chat window.

This happened to a team I'm working with, and it could have happened to your team, too. I want to tell you what we did about it.

What AI doesn't do for you

AI is extraordinary at turning a description into plausible code. It is useless to tell you whether your description is correct.

This sounds obvious. It is obvious. And it's exactly the failure mode that every team I've worked with this year has stumbled into. You ask the model how to implement something, you get a confident answer, and you mistake the absence of pushback for a good idea.

Confusion in, plausible code out. We had outsourced typing. We hadn't realized we'd also outsourced thinking.

Back to the whiteboard

The fix was unglamorous. We blocked out an afternoon, booked a room, and brought markers and post-it notes.

We started with event storming. On a physical whiteboard. Without laptops. The goal wasn't to design software; it was to understand the process we were automating. We placed events in time order, argued over which ones actually existed, and found places where two of us had been carrying different mental models without noticing.

AI sat this part out. Not because it couldn't help, but because we needed to do it. The struggle in front of the wall is where shared understanding gets built. You can't import that from a chat log.

Then we sliced the flows into deployable chunks. Thin vertical slices, each one small enough that a user could see it, react to it, and tell us we'd misunderstood early, while changing course was still cheap.

Then we refined the slices. Aggregates, events, policies, commands. Classical tactical DDD. Nothing exotic, nothing recent. Here, AI started earning its keep as a sparring partner. We'd describe an aggregate and ask it to poke holes: missing events, fuzzy invariants, edge cases we hadn't named. It was becoming more useful because we already knew what we were looking at. The same prompts a week earlier would have produced confident nonsense.

Adding the foundational slice

This is the one we almost missed. Pure functional slicing left our coding agent without a good structure to start working with. We tried, but somehow the AI would duplicate logging code, validation logic, and other shared components.

So we made a deliberate foundational slice. Skeleton. Shared kernel. Logging and error handling. Persistence shape. Testing baseline. Not a feature — a seed. The thing AI would build on top of, not around.

Then we brought AI back to the code. With a shared model, sliced flows, and a seed structure, generation finally had something to grip.

What changed

The numbers told the story before we did.

Code generation got faster. The prompts were shorter because we weren't re-explaining the world every session. Token spend dropped — noticeably. Reviews became reviews again, not archaeology. Each unit had a known shape, so deviation was easy to spot. Users gave feedback on deployable slices instead of staring at half-finished abstractions. Bugs moved upstream into design conversations, where they cost a sticky note rather than a hotfix.

We spent 6 hours at the whiteboard, feeling like we weren't doing anything productive. However, thanks to these 6 hours, we spent dramatically less time and money getting working software out the door.

Attention is the scarce resource

Here is the thing I want you to take from this post.

The bottleneck in software was never typing speed. It was never even reading speed. It was attention — the cost of holding the right model of the right problem in enough heads at once. Every practice we call "software engineering" — modeling, slicing, layering, naming, documenting — is a tool for forcing attention onto the parts of a system that will hurt you later if you skip them.

AI removed a non-binding constraint. Typing was never the problem. And with the relief of typing getting cheaper, a lot of teams have quietly let go of the constraint that is binding. They've stopped paying attention to the shape of the problem because the code's shape arrives so quickly now that it feels like the work is being done.

The foundation slice we added is, in a way, the whole post in miniature. It is attention spent upfront, so AI doesn't spend your tokens — and your team's afternoons — guessing later. The whiteboard is the same thing on a larger scale. Event storming is the same thing for a process. Aggregates and bounded contexts are the same thing for a domain.

None of this is new. That's the point. The practices that worked before AI work even better with it, because AI multiplies whatever you bring to it — including your confusion.

Humans must lead

I don't want to leave you with "AI for code, humans for design." That framing is wrong, and it's the one that got us into trouble in the first place.

AI is a phenomenal participant at every stage. Sparring partner during modeling. Drafter during refinement. Accelerator during implementation. Critic during review. Use it everywhere. We do.

But it cannot lead. It does not know what matters in your domain, what your users will tolerate, what your team can operate, or what your business is for. It will happily generate plausible answers to questions you should not be asking. The work of deciding what matters — that work stays human. The whiteboard isn't a place AI can't go. It's a place humans must lead.

Bring the markers.