You Can't Outsource the Thinking
I spent four hours this morning designing a workflow engine.
Not building one. Thinking through one.
At 8am I started where most people start. Complex regex parsing for node connections. Multiple execution modes with intricate state machines. Database schemas for tracking execution state. Type definitions spanning hundreds of lines. The kind of architecture that looks impressive in a design doc.
By noon I’d distilled the whole thing down to three sentences:
- Prompts do the work
- Files are the interface
- The system orchestrates, not executes
That’s the entire architecture now. Simple enough to prototype in an afternoon.
Those four hours were the work. Not wasted time. Not a detour. The actual work.
I wrote code. Little scripts to test ideas. I sent out multiple AI agents to research how other workflow engines handle orchestration. I had Claude poke holes in my assumptions. I iterated through several different approaches before landing on the simple one.
The journey from complex to simple—that’s where the insight lives. And you can’t skip it.
The question I keep getting
I run workshops. I do one-on-ones with engineers adopting AI tools. I talk to builders at every level. Beginners who’ve never shipped anything, seniors with fifteen years of production code behind them.
The question that comes up constantly, in different forms:
“How do I pick the right tech stack?”
“What architecture should I use?”
“Where do I even start?”
These are hard questions. They were hard before AI. They’re still hard now.
AI can help you think through them. It can surface options you hadn’t considered, explain trade-offs, poke holes in your assumptions. It’s a great sparring partner.
But it can’t think for you.
The trap
The trap is believing that because AI can write code, you can skip the part before the code.
You can’t.
If I’d started this morning by asking Claude to “build me a workflow engine,” I’d have gotten something. Probably something that runs. Probably something overcomplicated. Definitely something that doesn’t match my actual constraints or the actual problem I’m solving.
The output would look like code. It might even work. But it wouldn’t be right.
Because “right” isn’t about syntax. It’s about decisions. And decisions require thinking.
What my morning actually looked like
I started with the obvious approach. Look at how workflow engines are typically built. Database-backed execution state. Complex type systems. Multiple modes for different use cases.
AI was my sparring partner the whole way. I’d sketch an approach, then have Claude stress-test it. I spun up research agents to dig into how existing orchestration tools handle state. I wrote throwaway scripts to feel out different patterns.
The plan grew. More features, more flexibility, more complexity. Type definitions multiplied. The architecture got sophisticated.
Then I asked a different question.
What’s the simplest version that could actually work?
Not the most flexible. Not the most scalable. The simplest.
Working through that question—with AI helping me challenge every assumption—took hours. We explored dead ends. I had to let go of elegant abstractions that weren’t earning their complexity.
The answer I landed on was uncomfortable at first. Most of what I’d designed was premature. The workflow engine doesn’t need to track execution state in a database. It doesn’t need multiple execution modes. It doesn’t need complex input/output parsing.
It needs to chain prompts together. That’s it.
The agent is already extremely capable. Through prompts, it can run commands, read and write files, create PRs, review code. Everything.
So why was I building execution logic? Why was I parsing outputs? Why was I managing state?
I was solving problems the agent already solves.
The insight—prompts do the work, files are the interface, the system orchestrates not executes—came from the process. Not from asking AI to “design me a workflow engine.” From thinking it through, with AI as a collaborator, until the complexity burned away and the simple answer emerged.
That’s the work now. And it takes time.
The skills that still matter
The thinking part is where software engineering knowledge is still extremely valuable.
Understanding why you’d choose one architecture over another. Knowing which complexity is necessary and which is premature. Recognizing when you’re solving the wrong problem. Distilling requirements down to first principles. Making trade-offs that align with your actual constraints.
These aren’t prompting skills. These are engineering skills. Product skills. Builder skills.
AI amplifies them. It doesn’t replace them.
How I actually work now
Here’s what works for me:
Think first. What problem am I actually solving? What are my real constraints? What’s the simplest version that could work?
Think with AI. Use it as a sparring partner. Challenge assumptions. Explore alternatives. Let it poke holes in your plan.
Then build. Now AI can write most of the code. Because you’ve done the work to know what “right” looks like.
The order matters. Skip step one and you’re generating sophisticated garbage. Looks like code, runs like code, but doesn’t solve your actual problem.
This has always been true
Product managers know this. You can’t ship a good product by skipping discovery.
Product engineers know this. The best code solves the right problem, not just a problem.
And the new wave of AI-native builders will know this too. You can outsource the typing. You can’t outsource the thinking.
The tools changed. The fundamentals didn’t.
The uncomfortable truth
Here’s what nobody wants to hear. The thinking part takes time. It’s messy. It requires you to question your own ideas, sit with complexity before you can simplify it, and admit when you’ve been solving the wrong problem.
AI makes it tempting to skip all that. Just describe what you want and let it generate something. Ship it. Move on.
But the best builders I know spend more time thinking now, not less. They use AI as a sparring partner through the messy middle. They trust the process of going from complex to simple, even when it takes four hours to get there.
The thinking isn’t the obstacle to building. It’s the work itself.
And you can’t outsource it.