AI makes projects with weak engineering culture fail much faster.
There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.
The most tragic aspect of this way of working is that, to the untrained eye, it works.
If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.
Just like someone buying a new luxury car on a credit card. You don't see the debt. You just see the car that looks great.
“Bad engineers always existed”
The difference is the speed.
It is the difference between crashing at 30 km/h and crashing at 200 km/h. Before AI, a bad engineer would struggle to produce code that even compiled. When they did produce something, it took them a long time and the blast radius was limited. The damage was bounded by how fast a human could type.
Now a bad engineer can produce 10,000 lines of working code before lunch. The damage we can do in an afternoon used to take them months. The speed at which bad decisions compound has changed completely while the speed at which you can fix them has not.
“Will anyone actually care?”
They will care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.
This was already happening before AI. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can get there in just a few months.
Reminder: being good at software engineering isn't just about algorithms or systems design or whatever. Even pre-LLMs, it 100% definitely wasn't correlated with how fast you can put out new features.
It's about creating a system that's easy to reason about: easy to debug, easy to change, and hard to break—even when it's complicated.
My number one tip for blogging is to lower your standards! Aim to hit publish while you are still actively unhappy with what you have written, because the only alternative is a huge folder full of drafts and never publishing anything at all.
Nobody will ever know how perfect the thing you intended to write would have been. The flaws you see in your writing are invisible to everyone else.
Me, I try to get into the mindset of playing live music, not recording a studio album. Except when I’m writing a piece where I really want it to be an album. Those aren’t rare, per se, but they’re occasional. If I tried to make every post a hall-of-famer I’d never get anything out.
I’m aiming for professionalism. I’m performing live in front of an audience — not just jamming in my garage or bedroom, fucking around. So I’m careful and concentrate. I want to hit every note, in time. But at my best I’m moving from song to song.
Widely shared on Hacker News and Lobsters — how much of that is fact vs. flattering to our egos as developers is hard to say. We want to feel like we're doing something difficult. Not quite rocket surgery, but by jove, not just anyone can write code!
It's fast. It's fun. It's software prototyping, pet projects, and agent sandboxes rolled into one giant bouncy endorphin rollercoaster.
For personal reasons, I'm late to the persistent-agents-and-coding-from-phones party. My home server died, and I couldn't summon the motivation to scavenge for parts. I've worked from laptops ever since: no persistence, no remote Claude Code sessions, no blinking lights.
Anyway: exe.dev is the easiest way I've found to dip your toes into coding agents from your phone.
Tuhin Nair’s article frames a common conflict. A business reduces uncertainty: ship an experiment, learn from the market, choose the next bet. Senior developers manage complexity and stability: keep the system understandable, reliable, and tied to clear responsibility.
Answering a request with maintenance costs addresses the wrong loop. A better response offers a shorter, cheaper experiment that answers the business question without binding the result to the core system. This turns technical judgment into a path toward evidence.