Peak AI Frenzy

There's an arc almost everyone who gets serious about AI runs, and I've now run it twice. Naming it, because I keep watching people arrive at step two and think it's the destination.

The arc. People get really into AI. You AI everything. Then you AI everything even more. You automate all the things. And then you start to see where the checkpoints are, and you realize you might have overbuilt and overused your tools. So you start thinking about the output instead of the machine. You come back down to using much less than you were at peak frenzy, and you still use it heavily every day. Maybe even as your primary interface. Just with less scaffolding around it.

I named the first version of this Architecture Cosplay. That was overbuilding the workspace: fifteen folders, per-initiative configs, a vault structure so elaborate I could not explain it in two minutes. I burned it down to four flat folders and two files and lost nothing. The rule I wrote then still holds: if you can't explain your AI workspace setup in under two minutes, it's probably costing you more than it's giving you.

This is the same mistake one layer up. Not overbuilding the workspace, overbuilding the automation. My receipts, all from this year: fifteen folders down to four. A certification speedrun I killed at 49 after setting a goal of 100. A paid automation tool uninstalled after I worked out that most of what it did was a couple of hours of building away. And most tellingly, I'm now much less excited about spending a weekend packaging a skill when a well-written prompt does the same job.

None of that is a retreat from AI. I use it more than I ever have. I use less of my own machinery around it.

Here's the part that actually matters, and it's not about tooling.

The exciting work, the frontier work, the genuinely new work, is typically not something you can automate on a recurring basis. You can automate the truly automatic stuff fast: internal operations, recurring reports, the mechanical parts of a workflow. That is fun, and it is worth doing, and it is not the difficult part of product management.

The difficult part is defining new products. Learning an industry. Learning where people actually hurt and why. Converting all of that into tickets at the speed developers are currently demolishing tickets.

That last clause is the whole story. The bottleneck moved. I published a receipt for this back in April without realizing what I was looking at: a developer took a signals doc off an epic, imported the context into his own session, and shipped epics one, two, and four in two days against a one-month estimate. I wrote at the time that the developer didn't get faster, the context did. True, and I framed it as a win.

Read it again in September and it is also the problem statement. If a developer can eat a month of scoped work in three days, the constraint is no longer engineering throughput. It's the person defining the work. That's me. That's my real challenge now, and no amount of skill-building fixes it, because the thing that's scarce is judgment about what to build, and judgment does not run on a cron.

So what do you actually do at the bottom of the comedown?

Automate the recurring stuff once, properly, and stop tinkering with it. Keep the tools that earn their keep daily. Delete the scaffolding that exists because building it was fun. And then spend the reclaimed hours on the ambiguous, unautomatable work you were avoiding by building robots, which, if you are honest, is exactly why the robots were so appealing.

Peak AI frenzy is a phase, not a plateau. Coming down from it is not losing interest. It's the point where the tools stop being the project.