Jake Dubin

I’ve been thinking a lot lately about where humans fit into all of this.

Not in theory.

In real systems.

There’s a lot of talk about human-in-the-loop.

Usually framed as a safety net.
Something you add when the system isn’t confident.

But that’s not how it feels when you’re actually building.

What I’m seeing is that the real challenge isn’t just having a human in the loop.

It’s knowing when to bring them in.

Too early, and you slow everything down.
Too late, and you’re reacting instead of guiding.

There’s a timing to it.

A sense of flow.

The system needs to move on its own when it can.
And then pause, at the right moment, when judgment matters.

That’s harder than it sounds.

Because it means the system has to understand more than just tasks.

It has to understand intent.

What’s actually trying to be accomplished.
What matters in that moment.
What can move forward, and what needs a decision.

I’ve been working through this while refining the UI.

Trying to remove friction.
Trying to make the next step feel obvious.
Trying to make it natural for the system to ask for input without feeling like it’s interrupting.

When it works, it feels different.

You’re not fighting the system.
You’re moving with it.

And when it needs you, it’s clear why.

That’s the part I think a lot of people miss.

Human-in-the-loop isn’t just about control.

It’s about coordination.

And when that’s done right, the system starts to feel less like a tool…

…and more like something you work alongside. ☕

There’s a moment when you’re building something where you start to notice the world catching up.

Features start showing up in other tools.
Concepts you’ve been thinking about quietly start getting talked about more openly.

If you’re not careful, that can feel like you’re falling behind.

I’ve felt that a bit recently.

But when I step back, I see something different.

Most of what’s showing up are pieces.

A feature here.
A capability there.
Something that looks similar on the surface.

What I’ve been focused on is how those pieces actually work together.

Not just what the system can do.
But how it guides someone through doing it.

That’s a different problem.

It’s easy to build something that generates output.
It’s harder to build something that helps someone move forward with clarity.

That’s where I’ve been spending my time.

Thinking about intent.
Thinking about flow.
Thinking about what happens next without the user having to guess.

Because in every system I’ve ever worked on, that’s where things break down.

Not in capability.
In coordination.

So yeah, things are moving fast right now.

But I don’t think this is a race to ship the most features.

It’s a race to actually understand what we’re building.

And once you see that clearly, you start making very different decisions. ☕

It feels like every day brings another AI headline.

New models.
New agents.
New capabilities.
New warnings about what jobs are disappearing next.

The pace of announcements right now is dizzying.

But when you’re actually building something, the experience feels very different.

While the headlines swirl around, most of my time is spent doing the same things builders have always done. Debugging systems. Reworking architecture. Testing assumptions. Trying ideas that fail and fixing them.

CoffeeBreak has been a good reminder of that.

AI can generate code quickly. It can suggest patterns and explore solutions. But turning those pieces into a coherent system still requires patience and judgment.

Real progress rarely looks like the headlines.

It looks like slow improvements, small fixes, and occasional breakthroughs after a lot of iteration.

From the outside, AI development looks like a race.

From the inside, it still feels like engineering.

The headlines will keep coming.

Meanwhile, the real work continues. ☕

Lately I have been letting AI do more of the work while building CoffeeBreak.

Not because I think it is better than human developers.
Because I wanted to see what it would actually do.

I let it build a large portion of the backend. I knew the architecture wasn’t the way I would normally do it, but I let it ride. The point was to learn.

Eventually it broke.

So I nudged it.

AI tried to correct the issue, but it kept iterating around the edges instead of fixing the root problem. It was trying very hard not to break anything that might be running.

The problem was that it was already broken.

I nudged it again. Same behavior.
Another iteration. Another partial fix. Still broken.

After two weeks of watching it circle the problem, I finally stepped in and started fixing it myself.

One thing I have always believed as a developer is that when something is broken, the only acceptable outcome is fixing it. You cannot be afraid of making it worse. It already does not work.

Even if you break it further, it is still broken.
Fixing it is the only path forward.

AI struggles with that line of reasoning.

It tries to preserve stability even when the system is already unstable. It optimizes for not breaking things instead of restoring function.

That is an interesting lesson.

AI is incredibly useful. It can accelerate development, generate ideas, and help explore patterns. But it still does not replace ownership of the system.

Someone has to understand when the only option left is to grab the reins and fix the problem.

That part still belongs to us.

CoffeeBreak should be back online soon. ☕

This week felt volatile.

Markets swung on AI headlines.
Layoffs were tied to automation.
Companies raced to release new agent capabilities.
Even a fictional research post managed to rattle investors.

It would be easy to read that as instability.

At the same time, we’ve been deep in alpha testing CoffeeBreak.

And here’s what struck me.

Inside the work, it doesn’t feel chaotic.
It feels incremental.

Bug fixes.
Edge cases.
Logging improvements.
Governance decisions.
Human review loops.

The headlines are loud.
The real work is quiet.

I’ve noticed this pattern before.

During big transitions, fear moves faster than clarity.
Markets react before systems stabilize.

But underneath it all, people are still building.

Still testing.
Still integrating.
Still trying to make things reliable.

That’s the part that doesn’t make headlines.

And maybe that’s the point.

☕

Every few decades, we convince ourselves that this time is different.

This time, technology won’t just change jobs.
It will eliminate them.

We said it about the automobile.
We said it about electricity.
We said it about the internet.

Henry Ford didn’t eliminate work.
He rearranged it.

Yes, there were fewer blacksmiths and buggy makers.
But there were more mechanics, factory workers, road builders, traffic engineers, gas station operators, parts manufacturers, and logistics planners.

Entire industries formed around the new tool.

AI feels similar.

It will eliminate certain patterns of work. That’s inevitable.
But it will also create entirely new layers of responsibility, maintenance, integration, oversight, and design.

The mistake is assuming the surface change is the whole story.

The deeper story is value migration.

Work doesn’t disappear.
It moves.

The interesting question isn’t “Will AI replace engineers?”

It’s “What new responsibilities will emerge because of AI?”

That’s where the opportunity is.

☕