https://codemanship.wordpress.com/2025/09/30/comprehension-debt-the-ticking-time-bomb-of-llm-generated-code/

Skip to content
 

Codemanship's Blog

Code Craft Codified

Menu

  * Home
  * About
  * Training

Codemanship's Blog

Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code

An effect that's being more and more widely reported is the increase
in time it's taking developers to modify or fix code that was
generated by Large Language Models.

If you've worked on legacy systems that were written by other people,
perhaps decades ago, you'll recognise this phenomenon. Before we can
safely change code, we first need to understand it - understand what
it does, and also oftentimes why it does it the way it does. In that
sense, this is nothing new.

What is new is the scale of the problem being created as
lightning-speed code generators spew reams of unread code into
millions of projects.

Teams that care about quality will take the time to review and
understand (and more often than not, rework) LLM-generated code
before it makes it into the repo. This slows things down, to the
extent that any time saved using the LLM coding assistant is often
canceled out by the downstream effort.

But some teams have opted for a different approach. They're the ones
checking in code nobody's read, and that's only been cursorily tested
- if it's been tested at all. And, evidently, there's a lot of them.

When teams produce code faster than they can understand it, it
creates what I've been calling "comprehension debt". If the software
gets used, then the odds are high that at some point that generated
code will need to change. The "A.I." boosters will say "We can just
get the tool to do that". And that might work maybe 70% of the time.

But those of us who've experimented a lot with using LLMs for code
generation and modification know that there will be times when the
tool just won't be able to do it.

"Doom loops", when we go round and round in circles trying to get an
LLM, or a bunch of different LLMs, to fix a problem that it just
doesn't seem to be able to, are an everyday experience using this
technology. Anyone claiming it doesn't happen to them has either been
extremely lucky, or is fibbing.

It's pretty much guaranteed that there will be many times when we
have to edit the code ourselves. The "comprehension debt" is the
extra time it's going to take us to understand it first.

And we're sitting on a rapidly growing mountain of it.

Share this:

  * Click to share on X (Opens in new window) X
  * Click to share on Facebook (Opens in new window) Facebook
  * Click to share on LinkedIn (Opens in new window) LinkedIn
  * Click to share on Reddit (Opens in new window) Reddit
  * Click to email a link to a friend (Opens in new window) Email
  * 

Like Loading...

Related

Unknown's avatar

Author: codemanship

Founder of Codemanship Ltd and code craft coach and trainer View all
posts by codemanship

Unknown's avatarAuthor codemanshipPosted on September 30, 2025
Categories a.i., code quality

Leave a comment Cancel reply

 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
 [                                             ] 
D[                                             ] 

Post navigation

Previous Previous post: TDD Under The Microscope #2 - Assert First
Search for: [                    ] Search
Recent Posts

  * Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code
  * TDD Under The Microscope #2 - Assert First
  * What Are The "Objects" in "Object-Oriented Programming"?
  * TDD Under The Microscope #1 - Usage-Driven Design
  * Code Reviews as Exploratory Testing

Archives

  * September 2025
  * August 2025
  * July 2025
  * June 2025
  * May 2025
  * April 2025
  * March 2025
  * February 2025
  * January 2025
  * December 2024
  * December 2023
  * November 2023
  * September 2023
  * September 2021
  * August 2021
  * July 2021
  * May 2021
  * April 2021
  * March 2021
  * February 2021
  * January 2021
  * December 2020
  * October 2020
  * September 2020
  * August 2020
  * July 2020
  * June 2020
  * May 2020
  * April 2020
  * March 2020
  * February 2020
  * January 2020
  * December 2019
  * November 2019
  * October 2019
  * September 2019
  * August 2019
  * July 2019
  * June 2019
  * May 2019
  * April 2019
  * March 2019

Categories

  * #NoBacklogs
  * a.i.
  * agility
  * apprenticeships
  * architecture
  * code craft
  * code quality
  * concurrency
  * continuous delivery
  * continuous inspection
  * designprinciples
  * functional programming
  * goals
  * high-integrity
  * learning
  * mentoring
  * people
  * refactoring
  * requirements
  * software development
  * tdd
  * teams
  * testing
  * trends
  * trust
  * Uncategorized

  * Home
  * About
  * Training

Codemanship's Blog Blog at WordPress.com.

  * Comment
  * Reblog
  * Subscribe Subscribed
      + [croppe] Codemanship's Blog
        Join 63 other subscribers
        [                    ]
        Sign me up
      + Already have a WordPress.com account? Log in now.
  * 
      + [croppe] Codemanship's Blog
      + Subscribe Subscribed
      + Sign up
      + Log in
      + Copy shortlink
      + Report this content
      + View post in Reader
      + Manage subscriptions
      + Collapse this bar

%d

[b]