
## The Big Idea

AI makes it easier than ever to build something that feels like it works. It does not make it easier to understand what you've built, how it works, or how it might break.

---

## Learning Feels Like Progress, Until It Doesn't

One of the most enjoyable parts of learning something new is how quickly it can feel like you're getting good at it.

You start from nothing, make a bit of progress, and then suddenly things begin to click. A few early wins stack up, and you get that dopamine boost from the feeling that you have a handle on what you're doing. If you've ever watched someone pick up a new skill for the first time, you've probably seen this happen. Beginner's luck and a handful of successful attempts can create a surprising amount of confidence.

The problem is that this confidence is often built on a very small slice of reality.

When you've been doing something for a long time, you develop an intuition for how much there is to know. Beginners do not have that perspective yet, which makes it easy to overestimate how far along they are. Eventually, if they stick with it, they run into the limits of their understanding. That moment, when things stop working as expected and the gaps become obvious, tends to be uncomfortable, but it is also where real learning begins.

This pattern is well understood as the [**Dunning-Kruger Effect**](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect). More formally, it describes the tendency of people with a small amount of experience to be overconfident in their abilities. It also captures the inverse tendency, where highly skilled people underestimate their relative competence. The effect was first identified by psychologists [David Dunning](https://en.wikipedia.org/wiki/David_Dunning) and [Justin Kruger](https://en.wikipedia.org/wiki/Justin_Kruger) in 1999.

The Dunning-Kruger Effect is a natural, typical pattern of human learning. It is **not** a sign of low intelligence. It's a lack of experience.

The issue is not confidence itself. It is confidence that has not yet been tested.

---

## AI Changes the Pace, Not the Fundamentals

When everyone has superpowered LLMs at our fingertips, the game changes. What's different now is how quickly someone can get an early sense of competence.

Rather than learn about weather patterns or signal processing or buying ads on Google (or whatever problem you're working on), you can slap a few sentences together and send it off to your LLM of choice, and in moments you can have a working prototype.

That's really cool - but it should give you at least a _little_ anxiety.

Modern AI tools make it possible to build things that would have taken weeks or months in a matter of hours. Someone who has never written code before can assemble a working application, connect it to real data, and deploy it to the internet without fully understanding how any of it works. The results are often impressive enough to reinforce the feeling that they are on the right track.

It is hard to overstate how big of a shift this is. The first program I ever wrote added three numbers together and printed the result to a terminal. It was simple, but it forced me to understand every step along the way. That constraint is largely gone now.

What has not changed is how computers behave. They still do exactly what you tell them to do, even when what you told them to do is incomplete, inconsistent, or quietly destructive. AI can help you write those instructions faster, but it does not guarantee that they're correct.

---

## Experience Is Mostly About Anticipating Failure

If you spend enough time around production systems, you start to realize that a large part of the job is not building new features, but anticipating and avoiding failure modes.

That is why experienced teams invest so much energy in things that can feel tedious at first glance. They plan before they build. They test changes in environments that are isolated from real users. They introduce safeguards like feature flags and rate limits, and they maintain the ability to roll back changes when something goes wrong. These practices exist because systems are fragile in ways that are not always obvious, especially early on.

If you are new to building software, and especially if you are learning through AI-assisted tools, there is a good chance you have not yet had the experience that makes these practices feel necessary. That is a normal part of the process. The risk comes from assuming that you can skip that part entirely, or worse, _not knowing_ that you should be doing it.

Dunning-Kruger comes for us all.

---

## The Real Risk Is Misplaced Confidence

The tools themselves are not the problem. The combination of speed and confidence is.

When you can build something quickly and it seems like it works right away, it's natural to trust it more than you should. That trust can extend further than it ought to, especially when the system begins to handle real data or real users.

Here's my April 2026 Prediction: Sometime soon, someone is going to push something into a context where the stakes are higher than their understanding of the system, and it is not going to behave the way they expect. Overconfidence will meet under-experience, and something will come crashing down. This will cause real, profound problems for a business that has been otherwise successful, and the dominos will start to fall. Will it be a fortune 500 company, a moonshot startup, a government agency, or a small business? I don't know the answer to that, but I feel confident that something will happen, and we'll all learn hard lessons from it.

It is not hard to imagine how it plays out. Ask your engineer friends about their biggest fears for failures in production: A script runs twice when it should have run once. A production database gets deleted with one little line of code. A set of permissions is broader than intended. A piece of logic that seemed harmless at small scale behaves very differently under load.

None of these scenarios are new, but the barrier to encountering them is now much lower.

---

## What This Means in Practice

If you have been doing this for a while, your role is not to discourage people from using these tools. It is to help them use them safely.

That usually means putting guardrails in place where they matter most. Limiting access to production systems, being deliberate about how credentials are managed, and creating environments where experimentation does not carry real risk all go a long way. Just as important is being open to the fact that people will be exploring vibe coding tools. That curiosity is a good thing! When exploration happens in the open, it is much easier to guide it.

If you are newer to this world, **the most useful thing you can do is adopt a deliberate skepticism** toward the tools you use and anything you build.

Assume that your system has edge cases you have not considered. Look for the places where it might break, especially under conditions that are slightly different from what you tested. Make sure you have a way to recover when something goes wrong, whether that means backups, staging environments, or simply the ability to turn something off quickly.

It is also worth writing down how your system works, at least at a high level. The decisions you make early on tend to fade from memory faster than you expect, and when something breaks, that context becomes incredibly valuable.

Perhaps most importantly, resist the urge to treat speed as the primary goal. Building quickly is useful, but building something you understand is what allows you to keep it running.

---

## Understanding the Tool Matters More Than Using It

None of this is an argument to avoid AI. These tools are genuinely useful, and they are only getting better.

But it is important to understand what they are doing. Large language models are not reasoning about your system in the way a human collaborator might. They are generating likely sequences of text based on patterns in their training data and the context you provide. That can produce very convincing output, but it does not come with guarantees.

The people who benefit most from these tools are the ones who can engage with them critically. They can ask better questions, recognize when something looks off, and take the time to verify the results before relying on them.

In practice, that means [spending more time reading and writing](https://mikebifulco.com/newsletter/next-great-engineering-skill-is-context-not-code) than you might expect. It means thinking through your systems in plain language, not just code, and being able to explain what they are doing and why.

---

## The Curve Is Still There

The underlying learning curve has not changed.

It is still easy to feel confident early on, and it is still necessary to move past that initial confidence to build something durable. AI has made the early stages faster and more rewarding, but it has not removed the need for deeper understanding.

If anything, it has made that understanding more important.


Dunning-Kruger for Vibe Coders

Learning Feels Like Progress, Until It Doesn't

AI Changes the Pace, Not the Fundamentals

Experience Is Mostly About Anticipating Failure

Understanding the Tool Matters More Than Using It


## The Big Idea

Your brain rewires itself based on what you practice. If you stop practicing hard things, you slowly lose the ability to do them.

---

Early in my career I remember sitting at a bar with two close friends, laughing about something we called **"information addiction."**

It would only take a few minutes of observation to see it: if we didn't know something, we googled it -- immediately.

Movie trivia? Google it.
Strange symptom after a long flight? Google it.
When was Sean Connery born? Google it.

At the time this felt revolutionary. As millennials, we grew in the first generation where knowledge was always within reach. Expertise wasn't something locked inside universities or trade guilds anymore. It was a few searches away.

That experience shaped a lot of how I think about my generation. The defining skill millennials developed wasn't memorization. It was learning how to learn. If you could research, synthesize, and experiment, there was almost no problem you couldn't teach yourself to solve.

But something has changed in the last few years.

The internet used to give you **information**. Now it increasingly gives you **answers** (whether or not they're correct is another story).

- Why read _Hamlet_ when an LLM can summarize it perfectly?
- Why grind through calculus when a model can solve every step instantly?
- Why learn Cantonese if a phone can translate the conversation for you?

The temptation is obvious... effort is optional now.

And human beings are very good at choosing the easier path.

I'm not immune to this either. I use LLMs all the time; they're incredible tools. They help me write code faster, summarize documents, and explore ideas in ways that would have taken much longer even a few years ago.

I've come to realize there's an important difference between **getting an answer** and **learning something**.

The difference is happening inside your brain.

## Neuroplasticity

There's a concept in neuroscience called **neuroplasticity**, which describes the brain's ability to reorganize itself based on how it's used.

In simple terms: the more you do something, the stronger the neural pathways supporting that activity become. Practice literally changes the structure of your brain. And if you stop practicing something long enough, those pathways weaken.

In other words: **use it or lose it** is a real thing.

That's why musicians practice. It's why I was fluent in Spanish after high school, but was barely conversational 15 years later. It's why someone who writes code every day develops instincts that no tutorial can fully explain.

Learning is not just absorbing information. It's building physical circuitry.

And circuitry only forms through effort.

## Some Lessons Are Best Learned the Hard Way

I can generate code with Claude or Codex. But I won't write great software unless I keep practicing and scrutinizing my code.

I can translate a paragraph of Spanish instantly with Google Translate. But I can't actually understand a conversation unless I spend years training my ear and vocabulary.

The same thing is true with music. The more often I pick up my guitar, the better my playing becomes. There's no shortcut to becoming a better musician.

Some knowledge only exists on the other side of repetition.

Which is why I've started to believe something that sounds slightly old-fashioned:

**Some lessons are best learned the hard way.**

Not because technology is bad. Not because efficiency is wrong. But because your brain still runs on the same rules it always has.

If we stop practicing difficult things, we eventually lose the ability to do them.

## A Small Suggestion

So here's my suggestion: Pick at least _one thing_ in your life that you're willing to learn the hard way.

Something where progress comes slowly. Something where you have to practice even when it's frustrating. Something where the only real path forward is repetition.

For me, it's been keeping up with music and language learning.

Neither of them can be optimized away. Both of them reward patience. And both of them sharpen a part of my brain that shortcuts can't reach. They challenge and strengthen parts of my brain that I wouldn't otherwise use, and help me have real, meaningful connections with other people in my life. They create opportunity, empathy, and human connection.

If you want to keep your wit sharp in an age of instant answers, make sure there's at least one thing you're still willing to practice the slow way.

---

## More from me this week

<Image
  publicId="newsletters/lessons-i-learned-the-hard-way/guithub"
  alt="Screenshot of the Guithub app for tuning your instrument"
  caption="I built the guitar tuner I always wanted"
/>

- Speaking of practicing music, I recently shipped the guitar tuner I always wanted - [Guithub](https://guithub.org) is a tiny little PWA for tuning your instrument on the fly. It has all the features I ever wanted: support for multiple tunings, capo positioning, as well as bass guitar, ukulele, banjo, and more. I also got to play with an aesthetic I like. If you're a musician, give it a look! Proper launch announcement coming soon.

- My interview with [Alex from Supergood](https://apisyouwonthate.com/podcast/supergood-is-building-unofficial-apis-for-everything/) for the APIs You Won't Hate podcast. Alex is a supremely thoughtful guy, and his company is building a super interesting product. Supergood is building unofficial APIs for everything - really.




Some things are best learned the hard way.

Lessons I Learned the Hard Way

Some Lessons Are Best Learned the Hard Way


## The Big Idea

Becoming a great product builder means falling in love with the process of building and rebuilding.

---

I have always felt like I'm somewhere between the before photo and the after photo.

As in -- I've never felt like I'm "finished" with anything, really. The next version is just around the corner. It's just mid-process.

For a long time, I assumed that feeling meant I was behind. That at some point I would arrive at a stable, finished version of myself, or my work, and finally feel settled. But the longer I build things for a living, the more I realize that the in-between feeling is a sign that I'm on the right track.

## The Engineer's Reality

If you write software, you live in the messy middle whether you like it or not. You ship something that works well enough. Then you watch how it behaves in the wild. You discover the edge case you didn't anticipate, or the assumption that quietly shaped the entire architecture, or the part of the interface that makes perfect sense to you and none at all to anyone else.

And then you rebuild.

Here's the secret: for great products, that rebuild keeps happening, all the time, at every scale. You rewrite a sentence in a `README` because it doesn't quite communicate what you meant. You refactor a function that felt clever last week and now just feels brittle. You restructure a module. You revisit a feature that solved the wrong problem. Sometimes you rethink the product entirely. If you are unlucky or ambitious enough, you end up rethinking the company.

The rebuild is fractal. It repeats at every level. The same humility is required whether you are fixing a single line or reimagining the direction of the business.

## Failing to learn from the past is a recipe for disaster

Teams that forget this are usually the ones that get surprised. Usually this is because it's taboo to question past decisions, despite the richness of learnings you get from seeing people use a product or feature after launch. Instead, boxes are checked and the product is deemed “good enough,” and instead of learning from the product's shortcomings and revisiting first principles, the team shifts into protection mode. Architecture calcifies. The roadmap becomes incremental.

Rebuilding starts to feel risky instead of necessary.

And that is exactly when the ground shifts beneath you. The cost of building something new keeps dropping. LLMs have dramatically reduced the time between idea and implementation. Patterns that once required deep specialization can now be scaffolded quickly. A small team with good taste and the willingness to rethink fundamentals can move faster than an entrenched organization that is busy defending yesterday's decisions.

Ever open up a beloved product and have the sinking feeling that it hasn't changed in years? In the past, that meant stable product-market fit. For utilitarian tools today, it might be a warning sign that someone is about to build something better.


## Looking at your past work

We _all_ cringe when we look back at what we produced years ago. _I can't believe I wrote that!_ is a sign that you've grown. If you look at a project from two years ago and wouldn't change a thing, that is when you should worry.

The cringe is useful. It is a divining rod. It points directly at the thing that is ready to be rebuilt. Your past work is a treasure trove of opportunities for self-disruption. Take your work, make it better, and help your teammates do the same.

## If you don't rebuild, someone else will

If you aren't willing to revisit your foundations, someone else will. Not because they are smarter, but often because they are less attached to the work, or to the "we've always done it this way" mentality that quietly takes hold in teams of all sizes.

Learning to love the rebuild isn't perfectionism, it's humility and honesty. Look at your own work and admit that the current version is not sacred, and you'll be able to build better things.

So look at the thing you shipped last quarter. Find the part that makes you wince. That is where you start.

---

## More Reading

- 📖 [The Messy Middle](https://hardcover.app/books/the-messy-middle) by Scott Belsky is a great reference point for falling in love with the sisyphean product building process.
- 🎥 [Ira Glass on Good Taste](https://www.youtube.com/watch?v=E7rCOlqGVQU) - Glass has a famous quote about how _everyone_ has bad taste at first, especially when doing creative work. The nut at the core of the message is that you will do best if you _just start making stuff now_. Product building is creative work - don't sell yourself short by thinking otherwise.
- 💎 [Today is Your Day to Start](https://mikebifulco.com/newsletter/today-is-your-day-to-start) - My treatise on a similar theme. The only better time to start than now was 10 years ago.


Learn to Love the Rebuild

Failing to learn from the past is a recipe for disaster


## The Big Idea

Stable products still need maintenance. Defaults and shiny features quietly tax systems over time, and efficiency is a sign of craftsmanship, not penny-pinching.

## “Just Enough” Is an Ongoing Practice

At some point, my next.js website crossed a line I did not notice right away. It was stable, not changing much apart from new posts and newsletters. Traffic was healthy. And yet, I was steadily consuming more of the resources measured by **Vercel's free tier**. Nothing had broken. Nothing felt slow. But the line on the graph kept moving in the wrong direction.

That surprised me.

We often tend to think of stability as the end of something. Engineer ship something, it works, and we move on. Modern web frameworks ship with helpful defaults, and those defaults are optimized for convenience, not restraint. Prefetching everything on the page. Recomputing pages that could have been built once. Redirecting politely when a bot is clearly probing your pagination. Individually, each decision makes sense. Over time, they quietly add up.

Taking time to chase this down pulled me away from real work, the kind with deadlines and people waiting on me. I am not short on things that demand attention.

The results of a few hours of my time were exactly the doctor ordered:

<Image
  publicId="newsletters/just-enough-is-an-ongoing-practice/isr-reads"
  alt="A screenshot of the Vercel dashboard showing ISR reads before and after the changes"
  caption="ISR Reads before and after the changes"
/>

<Image
  publicId="newsletters/just-enough-is-an-ongoing-practice/fast-origin-transfer"
  alt="A screenshot of the Vercel dashboard showing Fast Origin Transfer before and after the changes"
  caption="Fast Origin Transfer before and after the changes"
/>

ISR Reads and Fast Origin Transfer both dropped dramatically, and flattened out. The site went back to living comfortably within a modest tier, even with steady traffic. What struck me was not how clever the fixes were, but how ordinary they felt in hindsight. These were not optimizations born from genius. They were the result of paying attention.

<Aside type="note">

  👉 <b>Interested in the details of these changes?</b> Check out my post on [reducing Next.js bandwidth with link prefetch](https://mikebifulco.com/posts/reduce-nextjs-bandwidth-with-link-prefetch).

</Aside>


## Keeping the lights on

The larger takeaway isn't at all about ISR or Fast Origin Transfer or prefetching. I think there's a lesson in what it means for a product to be "finished".

Launches of new products and features are exciting. It is _always_ a thrill to be working on the new hotness, drawing attention from your peers and customers.

But - there is a version of craftsmanship that only shows up after spotlight moves on. Funny enough, during my time at Google and Stripe, this was called KTLO: Keeping The Lights On.

## The unsung hero of the product lifecycle

This is the craft and attention to detail that shapes the integrity of the system. Efficiency, performance, and even environmental impact rarely make it into launch announcements. They still shape the integrity of the system. It's the work that is often thankless, and invisible to end users.

Growing the skill for this kind of work is not a one-time event. It is a skill that must be cultivated over time. It is a skill that must be practiced regularly. It is a skill that must be honed over time.

This is the same idea I wrote about before as **[just enough, nothing more](https://mikebifulco.com/newsletter/reflecting-on-one-year-as-startup-cto#just-enough-and-nothing-more)**. You don't cross the finish line once. You return to it. You notice drift. You develop a sense for new signals to listen to from the systems you've built and used. You remove things that no longer serve the system. You question defaults that once seemed harmless.

A stable product is not a finished product. It is simply a product that now requires a different kind of care.

“Just enough” is not a milestone. It is an ongoing practice.


Just Enough Is an Ongoing Practice


## The Big idea

This year, my work shifted from "write code" to "orchestrate systems." That means communicating well, taking great notes, and using AI tools to enhance my thinking rather than replace it.


## The Hardware

I work on a 14" M2 MacBook Pro. I'm a big fan of the M-series chips - my M2 hasn't slowed down yet. I prefer portability over screen size since I do a lot of work from kitchen counters and coffee shops.

At my desk, I run dual 27" 4K monitors with the Mac in clamshell mode, plus a Logitech MX Keys keyboard and MX Master 3 mouse - a setup that hasn't changed in years.

I'm also getting more done on my phone than ever - currently a Pixel 10 Pro. I've been eyeing Nothing phones lately; their quirky-meets-minimal design ethos is appealing.

E-paper devices have been in and out of my bag this year. A friend gifted me a Daylight Computer, which I use for reading and notes. I also briefly had a Boox Palma 2 - a _sublime_ phone-sized e-reader I loved until its fragile screen broke. Glad I paid for the extended warranty.

## My Software Stack

The biggest change from last year? My software stack changes regularly now. I've flipped between IDEs, switched note-taking apps, and dabbled with AI tools across the spectrum - from ChatGPT and Gemini, to Copilot and Cursor and Claude Code, to fully-local models via Ollama.

The takeaway: flexibility beats loyalty. Tools are changing fast, and it's worth trying new ones to see what fits.

Here's what I'm _currently_ using:

### Claude Code

[Claude Code](https://claude.com/product/claude-code) lets me stay in the role I'm best at: planner, architect, reviewer, unblocker. I spend less time executing and more time shaping the work. Critically, it doesn't replace my judgment - it multiplies it. [I've been reviewing code for years](https://mikebifulco.com/newsletter/ai-is-your-intern-not-your-boss), and Claude keeps me reading code and providing active feedback. I'm not writing zero code, but I am writing a lot less.

### MCPs (Model Context Protocol)

MCPs are the quiet unlock. They connect Claude Code to real systems instead of isolated prompts - repos, tickets, docs, logs, all linked. This is what turns AI from a clever assistant into something that can reason alongside you.

### Obsidian

I take [**loads of notes**](https://mikebifulco.com/newsletter/unlock-productivity-with-networked-note-taking) - meetings, calls, books, friends, articles, you name it. I switched from Logseq to [Obsidian](https://obsidian.md/) this year due to an ongoing macOS bug that made Logseq painfully slow. Obsidian is fine, but it suffers from Notion's curse: it's too easy to get distracted perfecting your setup instead of using the tool.

### Raycast

[Raycast](https://www.raycast.com) replaces Spotlight on macOS. It's more than a launcher - I use it for translations (English ↔ Spanish), looking up Tailwind classes, finding Lucide icons, and dozens of other small utilities throughout my day.

### WisprFlow

[WisprFlow](https://ref.wisprflow.ai/mike-bifulco) is a voice-to-text tool that runs locally on your Mac. Talk to your computer and it turns into text. I'm a fan of multimodal input; I spent years on the Google Assistant team waiting for seamless switching between typing and talking. WisprFlow delivers that, and it understands code-speak surprisingly well. Say "users slash mike" and it outputs `users/mike`. I use it constantly now for thoughts while walking, rough designs, notes to myself, and messages to teammates.

### Linear

[Linear](https://linear.app) is still the backbone of planning for my team. It's where our shared understanding of the work plan lives. It's also where we share context with LLMs via MCPs, meaning Claude Code can read and update Linear tickets as work gets done. This helps documentation happen automatically instead of as an afterthought.

### The product stack

The way we build software at [Craftwork](https://craftwork.com) is changing too. We use TypeScript for most of our code now, steadily moving away from Ruby on Rails. The app lives in a monorepo: Next.js, React, TypeScript, OpenAPI, tRPC, and Postgres. We also rely on a handful of third-party tools: PostHog for analytics, Render for hosting, Sentry for errors, Stripe for payments, and Twilio for voice/SMS.

## The secret sauce

This is the year I started viewing my 20+ years of writing code as a replaceable commodity. Thanks to LLMs, the difference between an engineer and a 10x engineer is [no longer code](https://mikebifulco.com/newsletter/next-great-engineering-skill-is-context-not-code). It's context, collaboration, and communication, with humans and machines alike.

Many devs struggle with this. I share my tools and workflow because I find it helpful when others do the same, but ultimately the tools are worthless without the people. Bring humanity, creativity, and humility to your work. Invest in yourself.


My 2026 Developer Tech Stack


## The Big Idea
Most habits don't fall apart because people quit. They fall apart because they aren't sticky.


Cognitive science tells us that habits form when a simple loop closes: a cue triggers an action, the action produces a reward, and the brain decides the sequence is worth repeating.

As builders, we often focus on the loop inside our apps. But the most successful products understand that the loop starts long before a user ever signs up. This is The Zeroth Loop.

<SponsoredSection
  imagePublicId="sponsors/crowdstake/landing-page-builder"
  sponsorName="Crowdstake"
  CTAtext="Start Pre-Launch"
  brandColor="#0B5D9E"
  href="https://www.vpdae.com/redirect/rsv3r61v9hvqbdgc7czgbhwjhh6"
>

  ### Quickly turn ideas into beautiful landing pages

  Launch AI-powered waitlist landing pages in minutes. Test demand, pricing, and features. Know exactly what your audience wants before building - no tech skills required.

</SponsoredSection>

<img src='https://www.vpdae.com/open/cf6ab0e8.gif?opens=1' width='1' height='1' />

## The Zeroth Loop: Before the First Use

The first encounter with a product usually happens in the wild: a landing page, a demo video, or a screenshot shared on social media.

The strongest marketing moments already contain a full behavior loop. When you watch a great 15-second demo, your brain performs a dry run. You see the cue, you recognize the action, and you anticipate the reward.

A good demo doesn't just explain features; it allows the user to experience the payoff ahead of time. By the time they click "Sign Up," the habit loop already exists in outline form. The **Zeroth Loop** has already closed.

## Where Your Products Lose Momentum

Product people tend to spend loads of time planning and building the nuts-and-bolts of how our apps work. We spend hours designing the perfect onboarding flow, the perfect settings page, the perfect error message.

Marketing people tend to think about the moments _before_ features matter - how do people find and engage with your product in the first place?

These two perspectives are hugely important, and they need to work together. Neither is optional for your product to be successful.

Builders who don't have marketing chops tend to overestimate intent. We see a signup as commitment, but often it's just curiosity. If a person's first interaction with your product doesn't produce a clear, immediate reward, the behavior never stabilizes.

When this happens, nothing _really_ breaks. The app just fades into the background. It stays installed, the tab stays open, and the user simply forgets it exists.

The habit never formed, and all your work goes to waste.

## Systems Over Memory

This is why thoughtful nudges are so important. Reminders often get a bad reputation because they're implemented poorly, but their cognitive role is simple: they reintroduce the cue before a new routine vanishes from memory.

<Image
  publicId="newsletters/zeroth-loop-they-dont-quit-they-forget/reward-cycle"
  alt="The cue-response-reward cycle"
/>

Durable habits don't rely on willpower or perfect recall; they rely on systems that bring the cue back before the natural erosion of forgetful humans takes over.

## A Tiny Improvement: Design for Three Loops

Zoom out and reframe your product journey around the first three loops:

<Image
  publicId="newsletters/zeroth-loop-they-dont-quit-they-forget/three-loops"
  alt="A three-loop diagram"
  caption="A three-loop diagram"
/>

### The Zeroth Loop (Marketing)

Does your demo or screenshot allow the user to visualize the reward? Can they "feel" the problem being solved before they even have an account?

### The First Loop (Onboarding)

Is onboarding and time-to-value fast enough to keep the user engaged? Getting people to _do something useful_ for the first time is the critical path here.

### The Second Loop (Utility)
Once they take the action, how quickly do they get evidence of success? In other words, has your tool or app actually delivered on its promise?

## The Takeaway

The reward is rarely the interface. If your app helps people optimize code, the reward isn't a "Success" toast message- it's the faster build time or the green checkmark in GitHub.

The outcome has to show up in the user's own context. That external payoff is what creates the memory: "Last time I did this, something good happened." When that happens early, repetition follows naturally. When it doesn't, no amount of UI polish can save it.

---

## More reading on habit loops

- [The Power of Habit](https://hardcover.app/books/the-power-of-habit-why-we-do-what-we-do-in-life-and-business): A clear and approachable explanation of the cue-routine-reward loop, with enough real-world examples to make it useful beyond theory.

- [Fogg Behavior Model](https://thedecisionlab.com/reference-guide/psychology/fogg-behavior-model): A practical framework for understanding why behaviors happen, and why they often don't. Especially helpful for diagnosing stalled adoption.


The Zeroth Loop: They Don't Quit, They Forget

A Tiny Improvement: Design for Three Loops


## The Big Idea

What if sleeping a little better, moving a little more, and finding a sense of purpose could measurably change your life?

Not as a vibe. As a fact, supported by decades of research.


## How to live a long, happy life

When researchers study people who live the longest, most fulfilling lives, they don't find hacks or extreme discipline. They find the same small behaviors repeated quietly over time.

Thankfully, there's no magic to it. The behaviors that have emerged are simple and accessible, and -- apparently -- they work. If you're looking for a "one weird trick" panacea, you won't find it here. The fact of the matter is that when you repeat a few seemingly small behaviors over and over again, they start to add up.


## Why tiny beats dramatic

Big changes fail because they ask too much, too fast. Small habits succeed because they're easy to repeat. I love that this is backed by actual, real Behavioral science, too - the data shows that consistency is better than intensity.

A tiny habit rarely feels life-changing in the moment. But repeated often enough, it changes what a normal day looks like. Enough normal days, and the long arc follows.

## The same habits, over and over again

Across longevity research, the same few habits appear again and again:

- **Adequate rest:** Roughly seven to eight hours of quality sleep, consistently.

- **Eating lots of plants:** Meals centered on vegetables, fruits, legumes, and whole grains, with moderate portions.

- **Daily, natural movement:** Low-impact movement woven into everyday life.

- **Strong social connection:** Regular time with friends, family, or community. It's a stronger predictor of happiness than wealth.

- **A sense of purpose and optimism:** Feeling useful, connected, and oriented toward something that matters.

Over the course of a lifetime, these tiny shifts in mindset and behavior can have a massive impact on you. And to me, at least, no single one of these sounds particularly difficult to maintain.

## Little changes that snuck up on me.

For years, I have been adopting little, bitty morsels of self-improvement. They help me to grow personally, stay balanced, and manage stress.

When I started managing a team at Google during the pandemic, I adopted a [simple morning ritual](https://mikebifulco.com/newsletter/continuous-self-improvement). I do five minutes of journaling, and five minutes of meditation. Nothing elaborate. That small routine helped me manage stress and show up more consistently for my team.

I've also been doing daily language learning for years. Just a few minutes a day stretches a different part of my brain, and has satisfied my personal desire to learn something new. Even better, I'm at least _conversational_ in Spanish, and I can read a surprising amount of Japanese by now!

## The Long View

Longevity and happiness are on my mind a lot lately - I've been thinking about shaping the long arc of my life's story. I want to be as happy as possible for the small amount of time I have on earth. It's as easy as that!

I find it very encouraging that there is research behind these ideas... If small habits can reliably improve a day, it's not much of a leap to believe they can shape decades too.

As the new year approaches, maybe it's worth a complete shift in perspective: You don't need a hard reset. Instead, maybe adopt a habit that's easy enough to keep, even on bad days.

Then, maybe: another one.

## My Question for You

**When you try to build new habits, what actually works for you? How do you keep yourself honest once the motivation fades?**

Hit reply and tell me. I read every response, and I'm genuinely curious.

---

## More reading

Ready to go all-in on longevity, habits, and happiness? Here are some of the resources I found myself reading that really grabbed my attention.

- [A Harvard Study of Adult Development](https://news.harvard.edu/gazette/story/2017/04/over-nearly-80-years-harvard-study-has-been-showing-how-to-live-a-healthy-and-happy-life) shows that close relationships and social connection are stronger predictors of long, healthy lives than wealth, fame, or status.
- [Blue Zones and the Power 9 Principles](https://pmc.ncbi.nlm.nih.gov/articles/PMC6125071/) is a study on communities where people live past 100 most often. It identifies common lifestyle traits tied to longevity, like natural movement, purpose, and plant-forward diets.


Science-Backed Secrets of Long, Happy Lives


## The Big Idea

The best product ideas hide in plain sight, in your habits and everyone else's. Watch what people actually do, not what they say they want. Build for that.

Most teams start their search for ideas with a brainstorm. The trouble is that people are unreliable narrators of their own needs. We guess. We speculate. We tell ourselves a story about what might help, instead of looking at how we actually behave.

Lucky for you, a little applied science can give you a clearer way to see.

Below are three ideas rooted in behavioral psychology which can help you find opportunities through observation of your own habits and those of others.

### Revealed preference

**Revealed preference** is the idea that actions speak more clearly than opinions.

In the software world, these actions are everywhere. When developers repeat the same chores by hand, maintain a giant list of test data in a scratch file, or juggle three tools to get one thing done, they are revealing what they actually need.

[Bruno](https://www.usebruno.com/?ref=mikebifulco.com) is a clean example. It's an API tool that has gained favor as Postman added account login requirements that their users weren't asking for, while the real preference was simple: keep everything local, work fast, commit changes, share them with a team.

<Image
  publicId="newsletters/mirror-effect-cognition-behavioral-science/bruno"
  alt="A screenshot of the Bruno homepage"
  caption="Bruno's success isn't a coincidence. It's the result of paying attention to the way devs use their tools."
/>

Bruno didn't invent a new workflow. It paid attention to the one people were already trying to use.

### Habit loops

When behaviorists talk about the **Habit Loop**, they describe it as cue, routine, reward. If the routine becomes messy, people still follow it, because the reward matters.

But the mess reveals an opportunity.

Testing an API is a perfect illustration. The cue is obvious. The reward is seeing the result. What changed over time was the routine. Postman added friction. Bruno's approach added value. All Bruno did was design a routine that matched the way developers already think.

When you look closely at routines that people repeat every day, the problems usually introduce themselves.

### Jobs to Be Done

**Jobs to Be Done** reframes product building around one question: what job is someone trying to get done, and how well are their tools helping them do it?

People "hire" their tools and workflows when they get things done. Sometimes it means a stack of half solutions held together with muscle memory. When you see the duct tape, you are seeing the job that isn't being served very well.

In Bruno's case, the job was straightforward. Teams wanted an easy, dependable way to explore and share their API workflows with their teams. The job didn't change. The tools did.


## Gaze into your own mirror

This process of finding opportunities works best when you turn the lens on yourself.

Ever tried to describe your workflow to someone who has never done it before? I bet you'll find _something_ that sounds at least a little absurd that you've been doing for ages.

Look at the workflows you repeat without thinking. Look at where you slow down, or compensate, or adapt to a tool that isn't quite right. These moments are often small, but they are rarely isolated. If something bothers you, it probably bothers someone else. Enough shared friction becomes a market.

Most people think they need inspiration. What they really need is observation.

## The takeaway

You don't have to invent a brand new idea. You just have to watch behavior more closely than everyone else.

_Revealed preferences_ show you what people truly value.

_Habit loops_ show you where routines break down.

_Jobs to Be Done_ shows you why the work matters in the first place.

Everything else is just paying attention.

---

# Keep on learning, my dudes
- Everyone's favorite self-help author James Clear has a great article on the [Habit loop](https://jamesclear.com/habit-triggers) that's worth a read.
- [Jobs to be done](https://hardcover.app/books/jobs-to-be-done-theory-to-practice) is the OG tome by Clayton Christensen that broke ground on the idea of breaking down customer needs into specific "jobs" that your product can satisfy.


The Science of Spotting Hidden Product Ideas


## The Big Idea

Every message is a moment of influence. Make the nudge helpful and you'll create power users and build loyalty.

## What is Nudge Theory?

Nudge Theory is a framework for guiding user behavior through subtle, persuasive techniques. It is based on the idea that people are more likely to change their behavior if they are given a choice that is easy to make.

In other words, a little proactive messaging goes a long way.

### Why Nudge Theory Matters

There's a little bit of behavioral science at play when a product uses thoughtful nudges in its onboarding. Research in behavioral economics shows that small, well-timed cues can help people adopt new habits and tools more easily. In other words, a gentle nudge at the right moment can make all the difference.

## A concrete example: Blacksmith

That's exactly what we found with [Blacksmith](https://blacksmith.sh?utm_source=tinyimprovements&utm_medium=email&utm_campaign=nudge-theory-for-guiding-user-behavior). It promised to speed up our CI workflows for less cost, something my team at [Craftwork](https://craftwork.com) would benefit from immensely.

<Image
  publicId="newsletters/nudge-theory-for-guiding-user-behavior/blacksmith-value-prop"
  alt="A screenshot of the Blacksmith's home page value prop"
/>

Our initial onboarding was smooth - the software generated a PR to swap our CI workflows onto their infrastructure. The speed boost was immediate, and life-changing for my team.

### Thoughtful Nudges in Action

What really impressed me was what happened a day later - each day, I would receive an email with a new tip, rooted in behavioral insights, to guide us step-by-step on how to get the most value from Blacksmith.

From the first message, Blacksmith gently introduced us to one feature at a time. Each day, a new tip arrived - ensuring that the game-changing features the Blacksmith team built didn't get lost in my haste to try the product out on Day 1.

<Image
  publicId="newsletters/nudge-theory-for-guiding-user-behavior/blacksmith-drip-campaign"
  alt="A screenshot of the Blacksmith's onboarding process"
  caption="Zero code-changes required? Sign me up."
/>

They could have spent a lot of time developing a slick, highly-interactive onboarding wizard -- which I almost certainly would have skipped. Instead, a slick little drip campaign offered even more value for my team.

You better believe I tried each one.

---

## Use these powers for good

- The Wikipedia entry for [Nudge Theory](https://en.wikipedia.org/wiki/Nudge_theory) is a great primer - it may sound wishy-washy, but this is real behavioral science.
- Nudge Theory is, of course, a two-sided coin - there's a great paper on [ethical concerns with nudging](https://journals.sagepub.com/doi/10.1177/10434631231155005) that is worth a read.

So, how will you turn this knowledge into action? Whether you're building a product or trying to influence people to be better neighbors, there is a whole lot of power in the way you reach people with your messaging.










The Psychology Hack Hiding in Great Products


## The Big Idea

Open source works best when we treat each other like humans - not vending machines for bug fixes.

## How We Patched a Broken Package - and What It Taught Us

Recently at [Craftwork](https://craftwork.com), we hit a snag using the [@payloadcms/storage-uploadthing](https://github.com/payloadcms/payload/tree/main/packages/storage-uploadthing) plugin for image uploads in [Payload CMS](https://payloadcms.com).

One of our engineers dug in, found the issue, and fixed it. We opened a [pull request](https://github.com/payloadcms/payload/pull/14250), hoping to help others in the same situation.

But here's the thing: We couldn't afford to wait for the PR to get merged before moving forward. Publishing a forked npm package is a common fallback - but it can be hard to maintain long-term.

In addition to creating a fork to submit a fix, we used [`pnpm patch`](https://mikebifulco.com/posts/patching-npm-dependencies-with-pnpm-patch) to apply the fix to our repo. It's clean, version-controlled, and works until the upstream package is updated.


## Maintainers Aren't the Problem

It's easy to forget that open source projects are often maintained by small teams under heavy load. At the time of writing, Payload has over 375 open pull requests. Expecting our fix to jump the line would be absurd.

This isn't about neglect or indifference. It's about capacity.

In other repos, we've seen PRs sit untouched for months, with long threads of angsty, impatient comments. I get it - but that doesn't help anyone. Especially not the maintainers.


### A Better Way to Contribute

Here's what we did instead:

- 🛠 Fixed the issue locally using `pnpm patch` (need a tutorial? I [gotchu](https://mikebifulco.com/posts/patching-npm-dependencies-with-pnpm-patch))
- 💬 Shared the patch tutorial in the GitHub PR to unblock others
- 🔁 Opened a new, cleaner PR
- 🤝 Let the maintainers off the hook - no pressure, just help

This approach makes open source better for _everyone_. It gives control back to contributors, and it gives maintainers room to breathe.

It is easy to forget that contributing to open source isn't just Pull Requests - discussion, community building, managing expectations, and creative solutions help us all build a better internet together.

I'm confident you'll get more results if you treat people with humanity - and you will [build a reputation for yourself](https://mikebifulco.com/newsletter/serendipity-isnt-an-accident) that makes people eager to help you when they can.

---

## Want to Do Open Source Better?

Read [*Working in Public*](https://hardcover.app/books/working-in-public) by Nadia Eghbal. It's the best book I've read on the culture of open source: what's broken, what's beautiful, and what's worth fixing.

Also, if you like learning by watching smart people build in public, check out:

- [cmgriffing](https://www.twitch.tv/cmgriffing) streams dev work and product experiments on both Twitch and YouTub
- [Rizel Scarlett](https://www.twitch.tv/blackgirlbytes1) does open source work, conference prep, and interviews on her channel

---

## Give without the expectation of receiving

Open source is a special kind of economy. Show up with something useful. Share what you've learned. Make it easier for the next person.

Let's be better guests in each other's repos.


Contributing to Open Source without being a Jerk

How We Patched a Broken Package - and What It Taught Us

Give without the expectation of receiving


## The Big Idea

When providing accurate context is make-or-break for your workflow, everyone needs to become a better writer.

We convinced ourselves that moving fast was the same as being smart. Shipping first. Reacting faster than anyone else. What we did not notice is that this trained an entire generation of builders to think only in the moment, never on the record.

That mindset worked when everything stayed in your own head. It breaks completely when your collaborators are machines. And it is the same thing your teammates have quietly been begging you to fix for years.

### Why this suddenly matters

- With LLMs and agents, context is not just helpful, it is _everything_.
- Developers are historically allergic to context. We want to skip the ticket and jump to the code.
- That habit is now actively expensive.
- Clear writing is fast implementation. Fuzzy writing creates hallucinations, bugs, and rework, and wastes time.
- If you get good at writing for agents, you automatically get better at writing for humans. Your teammates have been asking for this for years anyway - they're gonna love you for it.



## A simple framework for writing to agents (and humans, and future-you)

1. State the problem or goal. What is happening? What outcome matters?
2. Provide history. What have you already tried, seen, or ruled out?
3. List constraints. What absolutely must not break?
4. Point to the code. If you were starting, where would you look first? Any past examples or similar patterns?

Go back and re-read your instructions, and imagine this is the first time you're hearing about the bug or feature you're describing. Is there enough information for you to get the job done?

Iterate as needed. That's really all there is to it.

## A real example

I was getting spam signups to the Tiny Improvements mailing list. Dozens a day. Instead of stewing on it internally like I used to, I wrote up this description from my phone while on a plane:

```
I have been getting spam signups on my newsletter form for the past couple weeks - can you read through `SubscriptionForm.tsx` and help me come up with a plan to deter spam signups?

Here are some sample subscriptions from the past few weeks that are all spam:
(list of ~50 spam signups, including the addresses, first and last names used)

Based on what I'm seeing here, I think we can probably do a few things to deter spam signups:
1. make sure the honeypot field on the form is working as expected
2. Automatically reject signups where the first name is mixed case has >3 capital letters: i.e. XavcASkiox
3. Automatically reject signups where the first name has >4 consecutive consonants: i.e. mtpDQVeZaqb

For signups that _fail_ any of our spam checks, we should make it look like the subscription was a success, but don't actually subscribe the email address, and instead log the spam signup attempt to Posthog analytics for further analysis.
```

That 90 seconds of writing turned into a working fix with minimal edits, and thankfully, spam fell off a cliff.

And bonus: writing it down cleared background mental noise I did not realize I was carrying.

## Conclusion

If context is now make-or-break, writing is no longer optional - it's the difference between wasting your time and speeding up your workflow.

Write down what you're thinking about. It frees your brain, helps your team, and makes agents actually useful.

_And if you're the one sending automated spam signups to my newsletter: c'mon, dude._

---

### For more Context on Context

- [Matt Pocock's video on LLM Context](https://youtu.be/-uW5-TaVXu4) is a superb explainer on the topic, with a really helpful series of diagrams to help you visualize the concept.
- Michael Reeves shows what happens when you [corrupt the back-context](https://www.youtube.com/shorts/WP5_XJY_P0Q) of an LLM conversation. It's chaotic - and convincing.


The next great engineering skill is not coding

A simple framework for writing to agents (and humans, and future-you)


## The Big Idea

Software has always required people to think like a computer. AI flips it on its head: people expect computers to work the way they think.

That shift sounds subtle, but it’s massive. It changes what “human-centered design” really means.

## From Rules to Recall

Traditional software is deterministic: repeatable, predictable, safe.
AI is different. It’s non-deterministic - send the same input to your favorite LLM twice, and you'll get different results.

Responses vary: sometimes it feels human, sometimes it feels flat wrong.

That unpredictability makes trust fragile. But it also makes experiences feel alive -- and perhaps counterintuitively, more trustworthy.

## Memory changes everything

Think about how different this is from your experience with traditional software: LLM-powered apps let you have a custom, differentiated experience every time you use them. Your chat session today is _shaped by_ your previous conversations.

Made an update to your profile? AI can suggest how to automate or change your work  next based on your new information.

Suddenly, Gmail and Google Docs _know about each other_, and can suggest helpful actions based on your work across both.

Screens don’t sit still anymore. They grow, adapt, and remember.

## Hybrid Intelligence

People who use software to get complex work done have traditionally needed to build mastery of their tools through repetition. There are _countless_ tutorials on how to use Photoshop to do hyper-specific tasks, because Photoshop is an app that has an incredibly broad set of features, a steep learning curve, and requires deliberate practice to master.

The curve was steep, but the payoff was control and precision.

In a world where AI is the interface, that mastery is _far_ less important.

Now, new users can pull up photoshop with literally no idea of how to accomplish their goal, other than to describe the outcome. That's enough for an agent to take a swing at the task, and often get it right. When it doesn't, the user can course-correct with more natural language.

That's pretty wild - and about as far from the goals of "traditional" UX as you can get.

For novices, it's liberating, but it means AI holds more knowledge of your past than you do.

## UX’s New Job

Design used to be about helping people find the right button. UX Practitioners labor endlessly over trying to make _your next step_ obvious.

I think that's going to fundamentally change.

For AI-powered work, design work needs to focus primarily on::
- Getting work done confidently
- Validating results users may not fully understand
- Making like the system feel like a partner, not a puzzle

Human-centered design has to evolve.

## What’s next?

Autocomplete is already table stakes. Some apps already _feel_ old without it. However, thoughtlessly slapping an AI layer onto a tired interface is worse - it feels cheap.

Here's where I think we're headed:

Conversational interfaces that actually work will be the norm for most workflows. Multimodal (voice + typing + camera) input will become far more common.

Work will regularly involve conversation and collaboration with multiple agents, fine tuned to perform specific tasks in concert with one-another.

User Interfaces will evolve beyond chat-with-an-llm-flavored UX: agents building compact, atomic, and situational UIs on the fly. For example: Want to update your bio? Here's a tiny form with _just_ what you need - nothing superfluous or distracting.

When that happens, we’ll need something like a UX-lint for AI-built experiences. Guardrails for design itself, so that AI-generated UIs look consistent, feel familiar, and don't break the fundamental rules of usability.

## What it means for Product Builders

👉 I’m not certain where this ends up, But I do know this: the products that win will be the ones that anticipate this new language of human-centered design, where AI, memory, and trust define the experience.


💌 Tiny Improvements

💌 Read the latest dispatch