Minimizing Effort, Magnifying Effort, and Prayer

Minimizing Effort, Magnifying Effort, and Prayer

Update: Vibe Coding

Vibe Coding in 2025

Since I started on my journey of AI assisted building, "vibe coding" has become a thing. So far as I can see it's basically people threatening their AI coding companion to get them to do things that they (the user) do not understand in the slightest.

At first, I wanted to write about how I've been using AI to build this site and a few other projects. Now it feels like whatever insight I had to offer to begin with might be tangled up in a lot of hype.

So I wanted to reframe the conversation around effort and result.

Minimization of High Effort

"Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes." - Goodhart's Law

How do structured teams maximize product results with minimal effort?

In my observation, when left to their own devices they typically don't.

In fact, we humans are particularly well adapted very good at making our effort appear as output.

If it’s a tech-based decision (server or client API calls meant for consumption by another team or external developers) at the beginning of the startup lifecycle, it is usually the decision of the most experienced engineer. Sometimes what they do breaks, and if this happens enough, your company will create process and possibly a whole department around Architecture or around mission-critical Core functionality. Theoretically, the amount of process is the right fit for the problem. Often this initiates a cycle where an Architecture or Core team will place more and more onerous terms on developers until efficiency becomes a bugbear, at which point the Architecture or Core team will be dissolved. Teams being siloed and then dissolved will erase how anything worked before the new process was added, and technical decision making will once again follow the anarcho-YOLO model.

For anything UX based (has a UI – users type, click, or poke at it), most of the time I’ve seen early socialization of decisions being designers creating relatively high-fidelity mocks in Figma or another piece of design software. Visual things tend to invite more opinion than logical things like API endpoints because most human beings can rest their eyes on something visual, come up with a thought, and send that thought straight out of their mouths without knowing anything at all about anything. For this reason, a relatively large amount of time is spent in high-fidelity design to sell decisions to executives, who have their own very important jobs and tend to make individual approvals based on small amounts of low-detail information. While the decision is often Low Effort on an individual basis, the organization’s expenditure of effort is High Effort. Compounding this, in order to mitigate the effects of Low Effort product decisions, we impose Product Management process. This effort is split over a host of related activities: design, orchestrating useful CX research activities, technical specification building and proof of concepts on the technical side, development, QA, experimentation, etc. This evolution also appears to be cyclical: it becomes larger and less efficient until something like a spike in interest rates happens. Then all of the process is either heaved out, or more nimble startups edge out the slower-moving competition.

We take it as a given that technology will increase meaningful outcomes by the people who wield it. It increases output by making output lower effort and therefore higher value. Ranking our activities and the value they are expected to generate against our effort seems easy enough. Do we stand by that? Or are we good at making our effort appear as output?

“[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” - Conway’s Law

Magnifying Low Effort

How minimal could the effort be for* making product decisions with as little intermediary output or process?

Reminded me of Tesla's process for ensuring that they are not over-engineering anything. A good read even if you're not into Tesla.

Here's the Tesla tl;dr:

  1. Question Every Requirement
    1. Before automating, question every requirement.
    2. Each should have the name of the person who created the requirement on it.
    3. That way the person can be asked “why?”
    4. If it is a valid requirement, it can be asked to be made “less dumb”:
      1. Simpler
      2. As little complexity as possible
  2. Delete Any Part or Process You Can
    1. No process should be improved if it can be completely eliminated.
    2. If you don’t end up adding back 10% of what you eliminated, you didn’t eliminate enough.
  3. Simplify and Optimize
    1. Must do 1 & 2 first.
    2. (It’s never correct to do this if you haven’t done 1 and 2 first).
  4. Accelerate Cycle Time
    1. Any process can be sped up, but do 1 - 3 first.
    2. A fast process that completes unneeded tasks gains nothing.
  5. Automate
    1. Make an honest assessment of whether or not automation is truly the best path to take.

Applying the Tesla Over Engineering lens to the activities of a startup, it is similar to Y Combinator's famous advice to "do things that don't scale." Getting a startup started takes effort past the initial release, so you need to build and test incrementally -- unscalably -- at first to build something capable of unicorn scale.

Is this an amount of effort that a relatively busy human being can apply? What kinds of things can be built like this with modern AI-powered tooling?

Next Steps - Effort Magnification Culture

"What founders have a hard time grasping (and Steve himself might have had a hard time grasping) is what insanely great morphs into as you roll the time slider back to the first couple months of a startup's life. It's not the product that should be insanely great, but the experience of being your user. The product is just one component of that. For a big company it's necessarily the dominant one. But you can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness." - Paul Graham

Here we are in the age of Vibe Coding. It's depressing that once we have the tools in place to augment a judicious use of effort we have a culture war spring up about the least-common-denominator usage of the tools. (For the record I'm not complaining about the memes -- the memes like the video above are hilarious and they can stay.) I’m going to iterate on a Effort Magnification stack for a few projects I’ve wanted to bring to life.

I think that "Effort Magnification" is different from "Vibe Coding". Here's how I break it down:

  1. Traditional Development - Fatally hamstrung by the valuation hacking of the ZIRP. Now synonymous with filling feedback channels with noise.
  2. Vibe Coding - prayer.
  3. Effort Magnification - Augmenting human effort to produce meaningful result, not a stand-in for knowing what you are doing. Or a ritualistic act meant to cloak the operator as a "creator" when they are not.