Launch day is not the feature

LLMs have made companies faster than ever, or at least that’s how it looks from the product side. A PO dreams up a feature over breakfast and by the afternoon it’s live for every user, so from where they’re standing we’ve never shipped faster.

Zoom out to the whole life of a feature, though, and that first implementation turns out to be the shortest chapter. After the release come the bug fixes, the performance work, the surprise interactions with every other feature in the app, and the design revisions once real people start using it. Underneath all of that runs the part that never ends: monitoring, writing tests and keeping them up to date, and making sure the feature’s dependencies don’t quietly rot.

Don’t get me wrong, LLMs make every one of those phases faster too, just nowhere near as much as they speed up the first one. The trouble is that the first phase is also the most visible, so when a PM watches it get ten times faster, they assume everything else did as well. But a lot of software work doesn’t depend on how fast my LLM can burn tokens. Sometimes we’re waiting on an external vendor, on the opinion of an actual designer, on client feedback, or on that one-in-a-million crash to finally happen in production so we have something to fix.

“I don’t know, Claude did it”

Then comes the uncomfortable truth: understanding code is harder than writing it. This isn’t a new problem (ask anyone who has inherited a legacy codebase), and yes, LLMs have made understanding code faster as well. But review is a conversation. Sometimes you need to ask the PR author why something works the way it does, and sometimes it takes a few rounds of back and forth before it’s right. That conversation is over the moment the answer is “I don’t know, Claude did it.”

So I consider it a form of disrespect when someone hands me code they know nothing about and asks me to merge it. They haven’t saved anyone time; they’ve just moved the cost of understanding the code from their desk to mine. I won’t take those requests seriously, partly for my own sanity, but mostly out of respect for the clients who rely on my software.

Give a rifle to a monkey

Before I became a tech lead, one of the things I hated most was spineless tech leads: the ones who said yes to every deadline, waved every shortcut through, and left the team to clean up afterwards. Now that I’m in the seat, I understand them a little better. Saying yes is by far the easiest path, because nobody gets upset in the meeting and the debt only comes due months later.

I refuse to become that, so I stand my ground with product. What has changed is how much damage carelessness can do. A PM with no engineering background and access to the most advanced models can now produce a lot of code that is fast, confident-looking, and completely unaware of what it breaks. I treat that the way I’d treat a monkey with a rifle: the monkey isn’t malicious and the rifle isn’t evil, but I’m not going to stand next to it and admire the aim.

None of this is about gatekeeping who gets to write code. If you want to contribute, great, as long as you understand it, test it, own it, and can answer questions about it, which is the same bar I hold every engineer to. You don’t get special treatment because your LinkedIn title is different from mine. If I asked for access to my company’s bank credentials and then messed up a transaction, “I’m not a finance guy” wouldn’t cut it as an excuse.

No shortcuts, only tradeoffs

And guys, learning is still possible, you know? LLMs have made it way faster too. The same model that writes the code for you will happily explain it to you, line by line, as many times as you need, without ever getting tired of your questions. It’s also one of the few investments that never loses value, because once you’ve learnt something, it’s very hard to unlearn it.

So when someone wants to contribute but doesn’t want to learn, I don’t buy that it’s a lack of means; it’s a choice. When I ask “why did you store this in Redis instead of adding it to the Postgres users table?”, the answer shouldn’t be “idk”. That question should be the trigger for a non-technical contributor to learn something new, and the fact that it never happens appalls me.

There are no shortcuts here, only tradeoffs. Skipping the understanding doesn’t make its cost disappear; it moves it onto the reviewer, onto whoever is on call that night, and eventually onto the client who hits the bug. If you want the speed, you pay for it with the time it takes to understand what you’re shipping.

One “S” in SaaS is dead. I’m just not sure which one.

The popular take is that the first S is the one dying. Software is turning into a commodity, and if anyone can prompt an app into existence, why would they pay for one?

But look at what clients actually pay for, because it was never really the code. They pay for someone to stand behind it: to fix it at 2 a.m., to keep it secure, and to make sure next month’s release doesn’t break the workflow their business runs on. That’s the second S, the service, and it’s exactly what dies when nobody on the team understands the code they shipped, because you can’t support what you can’t explain.

So maybe both are on the line: software keeps getting cheaper to make while good service keeps getting harder to give. And let me tell you something: when a customer has just lost all of their data because of a server reboot, that’s not the best time to learn the difference between Redis and Postgres.

Writing the software is the cheap part now. Everything that happens after you ship depends on you understanding that software deeply, and that’s the one thing an LLM can’t do for you. It’s also what will put you ahead.

If you make it you own it

I’ve yet to see a tech company without the tech people. Maybe that changes in a few years, once the models get good enough that nobody needs to understand anything anymore. For now, if you open a PR, you own it, just like everyone else.