Trent Cockerham
Black-and-white photo of a home office desk with a laptop, monitor, guitar amp, and electric guitar
Field Notes

I Got Tired of Clicking “Continue”

5 min read

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.

Get new posts by email

One email when something new goes out. No spam, no recycled AI takes. Unsubscribe anytime.