Antoine Lehurt

A few months ago I built a coffee tracker. Not because I desperately needed one. I’d been using an off-the-shelf app and it was fine. It did the job. It just wasn’t tuned for how I actually use it, and it came with a pile of features I never touched.

This time I could build exactly what I wanted. A few hours with an AI agent, and the thing worked the way I’d always wanted it to. Two years ago this project dies on the second weekend. The gap between what’s in my head and what’s on screen is still too wide, and the motivation is already gone.

I have a graveyard of those.

AI coding agents collapsed the friction that used to kill that kind of software. I’ve been rebuilding a small ecosystem of tools around how I actually work, capture, reading, tracking.

Personal software is where the shift feels most obvious. I already know the user and the workflow. I don’t need research, alignment, or buy-in. I just need to turn a private annoyance into a working tool before I lose interest. That’s why more of these things become worth making.

Internal software is different. Cheap code helps there too, but mostly when the hard parts are already settled. The users are known. The workflow is visible. The data already exists, usually scattered across a few systems and one cursed spreadsheet. The work is in the last mile, building the layer that makes an existing workflow less painful.

I’ve seen that at work. Support teams have used Lovable to build tools on top of data they already had access to. Engineering still mattered, and so did the underlying constraints. What got cheaper was the last mile, the workflow layer that turned existing data into something actually useful. It also meant they didn’t need to wait for engineering to prioritize that exact layer for them.

That is real leverage. It works because the coordination problem is already mostly solved.

Cheap code helps most where usefulness can outrun rough edges. A personal tool can be messy and still earn its keep. A workflow layer inside a team can too. Customer-facing products are different.

This is where the cheap-code story starts to thin out. You still need a problem enough people care about, and you still need them to switch and stay.

Cheap code helps most once you already have a hypothesis. It makes exploration cheaper, and it makes early validation easier because you can put a rough version in front of people fast. You can learn with something real instead of a doc or a mockup. But the later questions still wait for you: adoption, trust, and long-term complexity.

That’s why The Hacker News tarpit lands so hard. JA Westenberg cloned Hacker News in a few hours. On the surface it looks simple: links, votes, comments, accounts. But nobody is going to use that clone, because Hacker News is not mainly a bundle of features. It’s audience, norms, moderation, status, and habit layered on top of ordinary software.

Hacker News is an extreme case. The mechanism isn’t.

When you’re building for strangers, the hard part is getting into somebody else’s life. You have to reach people, earn enough trust for them to try the thing, and give them a reason to change habits they already have.

That also changes the kind of discipline software demands. When adding something gets cheap, bloat becomes the default failure mode. Features pile up because they’re easy to ship, not because they make the product sharper. Maintenance may get cheaper too, at least for a while. Complexity doesn’t. It compounds.

And compounding complexity is exactly where both humans and agents start to lose the map. Shipping gets easier faster than understanding does. Humans were never great at holding a full model of a growing system in their heads, and I don’t see much reason to believe agents have solved that problem either. If anything, they make it easier to defer the understanding until the system is already harder to reason about.

Maybe that’s the real change. Cheap code doesn’t make software simple. It makes more software worth attempting.

Personal tools, rough prototypes, and narrow internal layers can survive with rough edges because usefulness outruns polish. Customer-facing products live under a different gravity. Trust, habit, coordination, and complexity catch up fast.

Getting to a working thing is cheaper now. The harder part begins when other people have to trust it, use it, and keep depending on it.