I find it funny how the best practices for programmers, ignored in most IT companies, get reinvented as the best practices for AIs.
Boring: The documentation should be in code, not in external Word documents uploaded to the company SharePoint server.
Exciting: The documentation for the AI should be in code, not in external Word documents uploaded to the company SharePoint server.
Boring: You should give your developers the big picture of the project, not just micromanage them using Jira tasks.
Exciting: You should give your AI the big picture of the project in CLAUDE.md, not just micromanage it using prompts.
Boring: Refactoring makes your developers more productive in long term.
Exciting: Refactoring makes your AI more productive in long term.
To be clear, the guy who wrote this article is Martin Fowler. Fowler was the author of a book literally titled "Refactoring", which he wrote over 20 years ago (it didn't invent the term "refactoring", but it's widely credited as popularizing it).
In other words, this is not some new AI-bandwagon-jumping blogger trying to rebrand old practices as something new ... this is the guy who coined the very term "refactoring"! He's not pretending what's old is new, he's arguing that best practices from 20+ years ago remain relevant (and showing receipts).
The website is martinfowler.com, but the article seems to be written by Giles Edwards-Alexander.
Oh, I stand corrected (thanks for the catch)!
It’s an easy mistake to make, given the name of the website, but Fowler frequently hosts guest authors. This article was written by Giles Edwards-Alexander, ThoughtWorks CTO for EMEA.
My namesake, er, not quite ;).
No this isn't mindless reinventing --- this is finally having clear empiric evidence for something that we knew the entire time. This is a huge relief!
Next up is demonstrating the AI is more productive with better programming languages.
I've already seen at least one promising experiment about how static checking helps LLMs: https://arxiv.org/abs/2606.01522
Key parts of the abstract:
> This raises a question the programming-language community has not previously had reason to ask: should error-message detail be calibrated differently for AI agents than for humans?
> We investigate this question through a controlled experiment using Shplait, an ML-style statically typed language. We construct a suite of programs containing a single deliberate type error each, and measure how often an AI agent repairs them under ablation: a detailed error context using the unification stack; a proximate error location; a minimal type error; and a dynamic (test suite) error only. An automated oracle uses a test suite to classify each repair attempt as a type error, semantically incorrect, or semantically correct.
> We find concrete evidence that more detailed error messages generally improve an agent's ability to fix type errors. We also find that the presence of a type system appears to help more than only test suite failure reports.
i can't wait for that one haha
> Next up is demonstrating the AI is more productive with better programming languages.
That actually would be pretty exciting!
But, wouldn't AI be biased toward more popular languages, since those will by nature of their popularity provide more sources for training material?
Even still, the AI could demonstrate which algorithms or maybe patterns and techniques are more productive, in the context of the popular languages.
That’s not necessarily a bad thing.
As an example, 110v American outlet plugs are almost certainly not the most efficient way to power devices and appliances; but, because they are so standard and are good enough, using them massively eases the burden of making, buying and selling powered appliances in the US. Similar story with USB C.
> That’s not necessarily a bad thing.
True, and to my point, "popular" isn't necessarily "better".
> because they are so standard and are good enough, using them massively eases the burden of making, buying and selling powered appliances
Yes, but LLMs can do the heavy lifting when analyzing the "better programming languages" for productivity. There will be a bias toward popularity in their training sources, though.
Outlets benefit from standards, however. Every device (well kind of) uses the same few plug types, and a different plug would be a disadvantage.
On the other hand, having a bunch of different languages is an advantage. People can pick the best tool for the job, and experiment with new language features.
Exactly