Code-quality

• The Death of Clever Code

  One positive product of working with Agentic tools is they rarely suggest clever code. No arcane one-liners, no “look how smart I am” abstractions. And, well, I’m here for it.

  Before we continue it helps to understand a bit about how LLMs work. These models are optimized for pattern recognition. They’ve been trained on massive amounts of code and learned what patterns appear most frequently.

  Clever code, by definition, is bespoke. It’s the unusual pattern, the one-off trick. There just isn’t enough training data for cleverness. The AI gravitates toward the common, readable solution instead.

  Let me give you an example.

  Show Me the Code

  Here’s a nested ternary:

  const result = a > b ? (c > d ? 'high' : 'mid') : (e > f ? 'low' : 'none');
  

  I’d be impressed if you could explain that correctly on your first try. What happens when there’s a bug in one of those conditions? Good luck debugging that.

  Now here’s the same logic:

  let result;
  if (a > b) {
    if (c > d) {
      result = 'high';
    } else {
      result = 'mid';
    }
  } else {
    if (e > f) {
      result = 'low';
    } else {
      result = 'none';
    }
  }
  

  A lot easier, right? If it’s easy to read, it’s easy to maintain. The AI tooling doesn’t struggle to read either version, but you might, and when there is a bug, explaining exactly what needs to change becomes the hard part.

  Actually wait. It turns out, not all complexity is created equal.

  Two Kinds of Complexity

  Essential complexity is the complexity of the problem itself. If you’re building a mortgage calculator or doing tax calculations, there’s inherent complexity in understanding the domain. You can’t simplify that away, and you shouldn’t try.

  Accidental complexity is the stuff you introduce. The nested ternary instead of the if/else. Five layers of abstraction for the sake of abstraction that only runs in a specific edge case. Generic utility functions where you’ve tried to cover every possible scenario, but realistically you only need two or three cases.

  Ok but what about abstraction, since abstraction is where accidental complexity loves to hide?

  Good Abstraction vs. Bad Abstraction

  Abstraction shows up everywhere in programming, but let’s think about it in two flavors.

  Good abstraction hides details the caller doesn’t need to care about. The interface clearly communicates what it does. Think array.sort(), you look at it and immediately know what’s happening. Those dang arrays getting some sort of sorted. You know exactly what it does without caring about the implementation.

  Bad abstraction hides details you do need to understand in order to use it correctly. Think of a processData() method that’s doing six different things with an internal state that’s nearly impossible to test. And splitting it into processData1() through processData6() doesn’t help either. That’s just moving the vegetables around on your plate which doesn’t mean you’ve actually finished dinner.

  AI Signals

  So why does any of this matter for working with AI coding tools?

  Because if the agents keep getting your code wrong, if they consistently misunderstand what a function does or there are incorrect modifications, that’s a signal.

  It’s telling you that your code has some flavor of cleverness that makes it hard to reason about. Not just for the AI, but for your team, and for you six months from now.

  The goal is to code where the complexity comes from the problem, not from the solution. The AI struggling with your code is like a canary in the coal mine for maintainability.

  Mar 25, 2026 / AI / Programming / Code-quality

  Enjoyed this?