On one end, you have code that can perform only the behaviour explicitly declared in the spec, but has to be thrown away and rewritten for any new or updated spec.

On the other end, you have code that implements or anticipates a wide range of future possible specs including the given one.

The AI can operate on any point on this spectrum, but it's not very good at choosing. The more complex the software, the more such choices need to be made.

When the number of bad choices reaches a certain critical mass, even a skilled engineer becomes powerless to undo all the bad choices, and even a powerful model becomes unable to reduce it back to a coherent spec.

The issue happens then if you're updating the individual research files on a regular basis. (Or making a long series of commits on a starting code base.) Every edit has a chance of doing a drive-by cleanup on nearby lines. Over a long enough timeline, it'll ablate your logic into something featureless, like if you compress an image too many times.

Turns out the implementation of the article is in Haskell, another declarative language.

At work. we use Power Query with it's M language - a declarative language with lazy evaluation.

Is there something about declarative languages that makes them especially suitable for data work?