Fuck Forward as Engineering Discipline

A few weeks ago, mid-afternoon, mid-stuck, I caught myself saying something out loud to my desk: "fuck it, fuck forward."

I'd been spinning on a Slack notification bug for an hour. The chain had run, the data was correct, the formatter was dropping content, and I'd already spent more energy debugging than the bug was worth. The right move wasn't another hour of root-cause analysis. It was: ship the obvious fix, see if the next morning's chain delivered, evaluate then.

I shipped the obvious fix. The next morning's chain delivered. I moved on.

That phrase — fuck forward — has since become a load-bearing piece of how I run my own engineering work. I'd describe it as my single most-used operating principle. And every time I use it, it surprises me how much it does.

What It Is

Fuck forward is a stance, not a strategy. It says: when life or work is stale, broken, dull, or merely uncertain, just keep moving. Pick a direction. Ship the next thing. Trust momentum to surface information you can't get by sitting still.

It's adjacent to "bias toward action" and "default to motion" — the canon advice in every founder's handbook — but it's not quite either of those. The conventional advice frames action as a virtue and inaction as a failure. Fuck forward doesn't moralize. It just says: when you're stuck, the cost of standing still is higher than the cost of being a little wrong, so move.

The phrase is intentionally crass. The crassness is part of the point. It's a kick, not a memo. You don't deploy "bias toward action" at 4 PM on a Friday when you're trying to decide whether to ship a small fix or wait until Monday. You deploy "fuck forward."

The Day It Paid Off Most

Today.

I started the morning with what looked like a simple question — "the Cortex MCP isn't connecting" — and ended the day having shipped four pull requests across two repositories, deployed a brand-new Postgres database, federated it with the existing memory store, indexed thirty-eight thousand session turns, captured five-point-six billion cache tokens of session history, installed two LaunchAgents, registered a new background worker, built a dashboard tab, and drafted blog posts (including this one).

That outcome was not in the plan when the morning started.

The morning started with a connection error in a desktop app. The afternoon ended with a production data lake.

What got me from one to the other wasn't planning. Planning, if I'd done it cold, would have given me a roadmap that took weeks. What got me there was: finish the current thing, see what the next obvious thing is, do that, repeat.

Fix MCP → "wait, why aren't we capturing every tool call?" → design the lake → ship migrations → backfill → "what about the dashboard?" → ship the tab → "what about the blog?" → write the posts. Each step opened a clear next step. None of the steps were planned in advance. All of them rode the momentum of the previous one.

That's fuck forward in execution form. Not "skip planning" — let the planning fall out of the doing.

Why It Beats Plan-First in Solo Infra Work

There's a counterintuitive thesis here that I want to make explicit.

In team work, plan-first is usually correct, because the cost of coordination dwarfs the cost of any individual's wrong direction. You write a spec, you get review, you align, you build. The spec is the artifact that keeps the team coherent. Without it, you ship in different directions and your work cancels itself out.

In solo infra work, the math inverts. The coordination cost is zero — there's no one to coordinate with. The wrong-direction cost is bounded — you can pivot the moment you notice. The artifact that would have kept a team coherent has no audience to be coherent for. You're not maintaining alignment with anyone but yourself. Writing a spec is just a delay before you start.

What you do need in solo work is a strong sense of when momentum has run out and a clean step has finished. Fuck forward isn't "ignore signals." It's "ride the signal you have until it stops being a signal." When the current step is done, the next step usually surfaces because you're done — you can see what's now needed in a way you couldn't before you started.

The plan-first approach assumes you can see the road from the starting line. Often you can't. Often the road is only visible from a hundred feet down it. Fuck forward acknowledges that and just starts walking.

The Disciplines That Make It Safe

I want to be careful here. Fuck forward, applied without discipline, becomes recklessness. Cowboy coding. Live edits to production. Ship-first-debug-later. Burnout, technical debt, regrettable irreversible decisions.

The reason it works for me — when it works — is because of three disciplines I've built in underneath it. They're the seatbelt that lets the car go fast.

Branch-first, always. No code edit goes to main without a feature branch and a pull request. The pre-push hooks on my repos enforce this. It's a hard rule, not a soft preference. The branch is the place where momentum runs without consequence. If I'm wrong, I throw the branch away. If I'm right, I merge.

Code review on every PR. I run an automated review pass on every diff before merge. It's a few minutes of API spend per PR. Today it caught a Bearer token leak in a privacy redactor that would have shipped real secrets to a database. That single save was worth a year of review costs. The reviewer is the second pair of eyes that lets me move quickly without abandoning quality.

Reversibility by default. Every change ships with its own undo. Migrations are paired up/down. Features are gated on env vars. Configs have backups. The cost of being wrong is bounded by the cost of running the down migration, which is the cost of one statement. That bound is what makes it safe to fuck forward — you're never one bad commit away from a hard recovery.

Without those three disciplines, fuck forward is reckless. With those three disciplines, it's the cheapest way I've found to ship.

When It Doesn't Work

I want to name the failure modes too, because they're real.

On other people's systems. Fuck forward is a solo philosophy. The moment another person depends on your work, the cost of being wrong becomes their cost. Someone else's project, someone else's customer, someone else's deploy — slow down, plan, communicate.

On irreversible decisions. Brand names. Domain purchases. Public launches. Trademark filings. Press releases. Anything where the act of shipping makes the next state unfixable. Reversibility-by-default doesn't apply when the artifact is permanent. Plan-first beats fuck forward here, every time.

When you're tired. I have lost more time to bad decisions made at 11 PM than to any other failure mode. The principle of motion only works when you can read your own signals. When you can't tell whether the current step is done, stop. Sleep. Restart in the morning. The current step will still be there.

When the bounded downside isn't actually bounded. I've made this mistake. Cowboy-edited a hook script that wasn't in git, no backup, "it'll only take a second." It took two hours to recover and reconstruct. The downside was not bounded — it just felt bounded in the moment. Anything you'd panic to lose needs a backup, regardless of how routine the change feels.

The Real Lesson

Fuck forward, as I use it, is a lever against my own perfectionism.

Left to my own instincts, I will plan a thing for three days when one day of doing would have surfaced the right plan. I will spec a feature for a week when a working prototype in an afternoon would have answered ninety percent of the spec questions for free. I will refuse to ship until the design is "right," which I will define recursively until the design is right enough, which it never will be.

That tendency, unchecked, is its own failure mode. It's the failure mode that doesn't look like a failure mode — I'm being thorough, I'm being careful, I'm gathering more information — but it's actually a slow-motion paralysis dressed up as professionalism.

Fuck forward is the corrective. It's the sentence I say to myself, out loud, when I notice the perfectionism kicking in. It's the permission to ship the merely-good in service of something I can iterate on. It's the trust that the next direction will reveal itself once the current one is done.

It's not a rejection of planning. It's a rejection of premature planning. The plan you write at the start of a project is, in solo infra work, almost always wrong. The plan you write at the end of a project is, almost always, what you should have followed. The right move is to ship into the gap between those two plans and let the work teach you what the right plan was.

The phrase is crude. The discipline underneath it is not.

---

This is part 12 — and the closer — of a series on building autonomous AI infrastructure on consumer hardware. If you've been planning for two weeks and haven't shipped yet, the planning has stopped earning its keep. Ship the merely-good thing today and let it teach you the rest.