Last Friday I attended a presentation at The Learning Circle—a weekly knowledge-sharing session at Improving where we explore new tools, techniques, and ideas together. The focus was mastering AI development tools through a design kata. The exercise came with specific challenges and stretch goals. The twist? We’d iterate multiple times on the same problem, timing each attempt and refining our process to get faster.
The facilitator called for us to apply our normal workflows. For me, that usually means BDD-first, TDD when it makes sense. But here’s the thing—I didn’t do any of that.
When the Exercise Doesn’t Match Reality
At first glance, the challenge itself didn’t solve any real problem for me. But I took a step back and asked: who’s the stakeholder here? What do they value?
The answer: I am. I’m one of the stakeholders interested in boosting my productivity. The value wasn’t in solving the challenge itself—it was in the approach I took to solve it and what I learned from that process.
I also made a deliberate choice: go back to basics. I already have several tools and workflows that streamline my problem-solving, but I didn’t pull any of that into this exercise. I approached it from a blank slate—as if I had nothing—to work through the fundamentals.
So I opened Windsurf, kept the default model (Claude Sonnet 4.5), took a screenshot of the challenge—carefully cropping out the stretch goals rather than telling the AI what not to do—and let it run. Two minutes later, I had a working solution.
Did it work? Yes. Good enough.
Building the Workflow
For the second iteration, I decided to try something different: Creating a /plan workflow that generates an implementation plan with user stories and a test approach before diving into code.
This is one of the things I love about Improving’s culture: we’re encouraged to experiment, learn in public, and share what we discover. The Learning Circle gives us a safe space to try new approaches and refine our thinking together.
I created the workflow definition, started a new chat, invoked /plan with the same screenshot, and let it work. It came back with clarifying questions about scope, requirements, and context. Good questions. I answered them one by one, giving it the constraint and clarity it needed.
Then it generated a plan: user stories (not quite in my preferred “In order to / As a / I want to” format, but close enough), acceptance criteria, scenarios, and a test approach.
After that, I simply prompted “implement” with a reference to the plan it had just created.
The whole cycle—creating the workflow, generating the plan, and implementing the solution—took 12 minutes.
Was It Better?
I think so. Not because it was faster (it wasn’t), but because I now have a reusable workflow. Next time, I won’t need to build the planning step—I’ll already have it.
I also noticed the implementation didn’t include the tests, even though the plan called for them. That’s my next iteration: an /implement workflow that takes a plan, executes it, and if tests are part of the definition of done, actually runs them and ensures they pass.
The Real Question
Does this translate to business problems? To the work I do with clients?
The specific problem from the exercise doesn’t come up in my client work. But similar challenges do—like helping visualize general ledger entries in accounting systems or inventory levels in control systems. These are the kinds of real-world problems I tackle every day, and the lessons from experimenting in The Learning Circle directly inform how I approach them.
And for those problems, I’d take the same approach: What’s the simplest thing I can put on screen to continue the conversation?
I wouldn’t spend time selecting the perfect model. I wouldn’t overthink it. I’d get something in front of us—quickly—so we could refine the requirements together.
The Ballpark Answer
This morning I was reading a book where the author posed a problem: multiply 38 by 12.
I wouldn’t try to slowly calculate the precise answer. I’d round 38 up to 40, round 12 down to 10, and say, “About 400.” Is that exact? No. Is it enough to move forward? Usually, yes.
It reminded me of something from Don Norman’s The Design of Everyday Things—the rough conversion between Celsius and Fahrenheit: take Fahrenheit, subtract 30, divide by 2. Not precise, but good enough to know whether I need a jacket.
If someone says it’s 100°F, I can quickly think: 100 minus 30 is 70, divided by 2 is 35°C. That’s hot. I know what to wear. Done.
Good Enough Gets You to the Next Question
That’s where my mind goes with solving business problems and people’s problems: What’s the quickest way to come up with an answer—not the best answer, but an answer that lets me ask the next question and iterate?
The goal isn’t perfection on the first pass. It’s getting something real in front of us so we can learn what we actually need.
Good enough answers first. Then we refine.
Leave a Reply