An engineer with 15 years of experience says his gut instinct is now wrong about what makes a bad idea

Bad ideas that aren't bad anymore

After 15 years in software, Devon C. Estes noticed his instincts about bad ideas were failing him. His team now lets Claude write the PRs while the ticket owner reviews and merges them, with no teammate review at all. They split people across separate work streams and saw no knowledge silos, because Claude can bring anyone up to speed in minutes. He now tells engineers to skip deep framework expertise and build judgment instead.

Deep expertise in a specific technology is a lot less valuable when you have a collaborator that has read all of the source code for that framework and can answer any question about it in a few seconds.
  1. sn

    I'm a principal engineer. Code reviews still matter for production software.

    Maybe your opinion is that I'm not vibe coding hard enough, and if I did AI better we wouldn't need code reviews. I disagree - both engineers and LLMs are still adding unneeded complexity or choose the wrong abstractions in ways that will cause problems down the road, don't think about all the corner cases, and pick the wrong handling for error conditions. They add in things that seem like a good idea to them and don't stick to the spec.

    If my company stops doing code reviews for the software that matters, I'll quit.

    Engineers not in the startup crunch should aim for using LLMs to code better, not faster. Faster just creates technical debt and ups your long term costs.

  2. xg15

    The common theme across those different examples seems to be:

    "Before, we had to be careful to allow each team member to build experience and expertise with our codebase and avoid dynamics that could form knowledge silos. Now this stuff doesn't matter anymore because everyone can just ask Claude to explain everything to them."

    I'm not so sure about that, honestly. In the short term, it works, yes. But in the long term, it might be as if you have some very good books, but zero hands-on experience with a thing. We all know that boom knowledge is different from learned experience.

  3. ro_sharp

    Why do so many people think that code reviews are primarily about mistrust or spotting mistakes?

    IMO they’re primarily about ensuring shared understanding and agreement, not just about how things are changing now, but how they’ll change in the future..

  4. kbiessy

    I'm going to talk about the item on this list that I know best. The "building instead of buying" is the one I’d question.

    The cost of writing the tool is mostly gone, on that I agree. The cost of owning it hasn’t moved that much I think. If I look after the software stack of a couple of small companies I know, the custom tools are those that end up hurting the most. Nobody remembers it was custom made, until the API call breaks, or the person who built it leaves. I think the cost of maintenance is particularly high.

    An afternoon build doesn’t fix long terme maintenance, nor does it provide functional knowledge. I think generalists stand to gain a lot from AI, but there will still be a huge role for experts to guide and maintain software in the future.

  5. ahartmetz

    >Introducing a language or tool nobody on the team knows [is not a bad idea anymore]

    OK, now I'm sure that the guy is full of shit.

More from this day

2026-11-12