I didn’t set out to build a system that builds products.
I just got tired of clicking “continue.”
The first real shift didn’t happen with some big architectural decision. It happened because I was behind on a feature and decided to just vibe in Cursor and brute force it with AI.
No process. No system. Just prompting and shipping.
And it worked.
That was the first “oh shit” moment.
Not in a hype way. In a very practical way. I realized I could take something from idea to working code in hours instead of days. Not perfectly, but real enough to ship and iterate.
That’s when we started taking it seriously.
We moved into CLI-based workflows with Claude and began thinking about what a real process could look like if AI wasn’t just a helper in the IDE, but the thing actually doing the work.
The Old Model
Before this, we were operating like most product teams.
Idea → spec → roadmap → sprint → feature.
AI was there, but lightly. Mostly inside the IDE. Helping write code faster, not changing how we worked.
It still required:
- PRDs
- sprint planning
- story point estimation
- backlog grooming
- manual releases
- a bunch of SaaS tools stitched together
It worked. But it was slow.
Where It Actually Broke
The first version of this “new” workflow wasn’t a system.
It was just us using AI more aggressively.
We built out skills in Claude Code. Stored them in a repo. Refined them over time. Got to a point where we could consistently ship real code through it.
But everything was still manual.
I was the orchestrator.
I was:
- telling it to continue
- reviewing changes locally
- committing code
- waiting for CodeRabbit feedback
- going back to Claude to fix issues
- repeating that loop multiple times
At some point I realized I wasn’t building product anymore.
I was managing a workflow.
And most of that workflow was just me clicking “continue” and trying to keep multiple terminal tabs straight.
Enter Dumb Eric
That’s when we built the first version of the orchestrator.
A deterministic system that could:
- pull in tasks from Linear
- execute steps in order
- hand off between stages
- pause when human input was needed
- move forward automatically when it wasn’t
We called it Dumb Eric because it wasn’t trying to be smart.
It just ran the flow.
That alone changed everything.
The Next Problem
Once the orchestrator was in place, a new gap showed up.
The system worked, but it lacked judgment.
It could execute steps, but it couldn’t reason about them well.
So we layered an LLM on top.
Now we had:
- deterministic orchestration for structure
- LLM reasoning for decision-making
That combination turned out to be the real unlock.
Not autonomous agents running wild.
Not rigid workflows.
The blend of both.
Then It Started Improving Itself
As we used the system more, it started breaking in predictable ways.
Edge cases. Bugs. inefficiencies.
Instead of fixing those manually, we built a self-improvement loop.
The system could:
- identify issues
- create tickets for itself
- propose improvements
- implement changes
At that point, something interesting happened.
It started getting better without us directly touching it.
Then I Became the Bottleneck Again
The more it improved, the more suggestions it generated.
And suddenly I was back in the loop.
Reviewing every change. Approving every improvement.
Different work. Same bottleneck.
So we added auto-merge with confidence thresholds.
If the system was confident enough, it could ship its own improvements.
Now Dumb Eric updates himself.
Somewhere Along the Way, This Stopped Being a Product Workflow
At this point, what we had wasn’t just a better dev process.
It was a system that could build product end to end.
Features. Documentation. Knowledge base updates.
And then we extended it to content.
Our course creation pipeline now looks exactly like our software pipeline:
- Linear task with human inputs
- AI writes brief, storyboard, research
- human approves
- AI writes scripts
- human approves
- AI produces content (voice, visuals, slides)
- changes are made by prompting and re-rendering
The stack is a mix of local models, animation tools like Rive, and code-based video editing with Remotion.
But the important part isn’t the tools.
It’s the workflow.
What Disappeared
We didn’t replace our old process with a better version.
We made most of it unnecessary.
No more:
- PRDs
- long fantasy roadmaps
- sprint planning
- story points
- backlog grooming
- manual releases
- buying SaaS for everything
- costly, manual course production workflows
Course production used to be a real investment.
Planning, scripting, recording, editing, revisions. It added up quickly in both time and cost.
Now it runs through the same system as everything else.
A course goes from idea → brief → script → production through a pipeline, with human approvals in the right places.
The marginal cost of producing a course is basically zero.
Not because the work disappeared.
Because the system does it.
What Surprised Me
A few things I didn’t expect:
Deterministic orchestration + LLM reasoning is far more effective than either alone.
Agents don’t need to be that smart if the workflow is good.
Self-improving systems actually work in practice.
And the biggest one:
The bottleneck isn’t building anymore.
It’s human decision speed.
What This Actually Is
If I had to describe it in one sentence:
It’s a system that builds product end to end.
Right now, it’s a product factory.
By the end of the year, it’ll be a company factory.
How This Actually Happened
This wasn’t designed upfront.
It emerged.
Every step came from removing pain:
- too slow → use AI
- too manual → build orchestrator
- too rigid → add LLM reasoning
- too fragile → add self-improvement
- too dependent on me → add auto-merge
Every time I became the bottleneck, I removed myself.
Where to Start
Don’t start by trying to build a system.
Start by feeling the pain.
Build something real first.
For us, that meant:
- using Claude Code skills
- getting to a point where we could actually ship code through it
- refining that process until it worked
Only then did we start removing friction.
If you don’t feel the pain, you’ll overbuild the system.
The Shift
The goal isn’t to use AI to build faster.
It’s to build a system where product is the output, not the work.
That’s the difference.
Most teams are still trying to use AI inside their existing process.
The real shift is building a system where the process disappears.
Once you cross that line, everything changes.
Leave a Reply