“It’s tough to make predictions, especially about the future.”

— Yogi Berra (attributed)

If you’re shooting at a moving target, you don’t aim at where it is. You aim at where it’s going to be.

Under normal conditions, most of the variables are solved. You know the distance. You know the wind. You know how fast the target is moving and in what direction. You know how long your projectile takes to travel. You can calculate the lead and take the shot.

Now imagine you don’t know any of that. You’re not sure how far away the target is. You don’t know its speed, or whether it’s accelerating. The wind keeps changing. Your own platform is moving. And everyone around you disagrees about the error bars on each of these unknowns - not just the values, but how uncertain to be about them.

That’s roughly where we are with AI tooling.

People keep asking whether they should be writing agent-first applications. Whether they should adopt Temporal. Whether they should build for the tooling that exists today or the tooling they expect in twelve months.

Steve Yegge spent months building his tool on Temporal - “the gold standard for workflow orchestration,” he called it, “the Bagger 288 of workflow orchestrators.” Then he found it was overkill for his use case and pivoted away. He still thinks it’ll be key for enterprise AI workflows. But he aimed, adjusted, and fired again.

Nobody knows. The capabilities are moving. The best practices don’t exist yet because nobody’s had time to make the mistakes that generate them. You have to aim off - but you’re guessing at every variable.

The CRUD question

Eric Raymond announced a project over the new year: a tool to compile data model descriptions directly into CRUD applications. The interesting part wasn’t the tool itself - it was his framing.

“A huge percentage of business software is what’s called CRUD applications… But it’s deeply silly that these are ever written by hand.”

He’s steering LLMs to do the heavy coding. He’s looking for collaborators not to write code, but to tell him what CRUD interfaces should actually look like.

Most software is CRUD apps. Forms that write to databases, databases that feed dashboards, dashboards that inform decisions. If that’s what you’re building, the question of whether to adopt agent-first tooling might be simpler than it looks. The fundamentals haven’t changed. They’ve just become easier - possibly to the point where hand-coding them stops making sense.

But if you’re building something more speculative - trying to hit a target twelve months out - you have to lead.

The hackers

The early web and early open source were the same movement, really. Hackers who shipped things before the business models existed. Before the best practices existed. Before anyone knew what the internet would become.

They aimed off. They built for a world that didn’t exist yet, and some of them were right. We live off their work now.

Eternal September marked the moment the mainstream arrived. But the infrastructure was already there. The protocols, the tools, the culture. All built by people who couldn’t have predicted what they were building for.

Position before submission

I wrote before about the BJJ principle of establishing position before attempting a submission. The same logic applies here. You don’t need to know exactly where you’re going. You need to be in a position where multiple outcomes work.

That might mean building modular systems that can be rewired. It might mean avoiding lock-in to tooling that could be obsolete by summer. It might mean accepting that some of what you build will be throwaway - and building it anyway, because the learning compounds.

The horseless carriage instinct is strong. We naturally describe new things in terms of old things. But the old thing is a bad guide when the target is moving this fast.

The inkblot

I keep coming back to the inkblot strategy. Small bets, fast iteration, willingness to be wrong. It’s the only approach that makes sense when you can’t see clearly.

Lead the target. Adjust. Fire again.