Great piece, but it misses the elephant in the room: the lion's share of economic benefit from refactoring will come from the fact that it makes it easier for humans to understand. That means 3am pages get resolved faster, fewer bugs will end up in prod, and your team can ship faster than your competition - gaining a leg up in the market. Most importantly, folks will be more comfortable accepting responsibility and ownership of a system when they understand it... this means that if/when something goes wrong, people will more quickly jump in and fix it, and when things could be better, folks will jump in and improve it.
The Economic Benefit of Refactoring
51–60 of 132 posts
Re: The Economic Benefit of Refactoring
#52I 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 develope…
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.
Re: The Economic Benefit of Refactoring
#53> Claude.ai was better than Claude Code
Why is this something users have to distinguish? Why can't these generative AIs choose good names for things?
Re: The Economic Benefit of Refactoring
#54I can very much relate to the experiences described in the article. In my projects, I have multiple Claude skills and rules aiming at making my files (the code, but also the Claude files themselves) more token-effective. I have seen huge differences in token usage before and after invoking those skills, which I regularly do as part of having Claude audit my projects; although I haven't measured them. Those projects are (like the one in the article) fully developed by Claude Code, so I found such audits and mindful token usage very necessary.
Re: The Economic Benefit of Refactoring
#55> Claude is unable to look at code, look at refactorings in general and work out which are suitable to apply
I am just sitting here waiting for Grady Booch to write "Architecture!"
Re: The Economic Benefit of Refactoring
#56> Add a new ItemWatchStore public async trait to the Firestore layer, following existing patterns exactly. The trait must have three methods:
async fn watch_item(&self, item_id: &str, user_id: &str) -> Result async fn unwatch_item(&self, item_id: &str, user_id: &str) -> Result async fn watched_items_for_user(&self, user_id: &str) -> Result>
This shows the limitations of vibe coding. It takes someone with a long history of software development to prompt for something like this.
Even though the model is writing 100% of the code, still needed someone with a lot of programming knowledge to write the prompt.
Re: The Economic Benefit of Refactoring
#57This is such a nice piece, this is how people should write about AI. Specific, grounded to how the tools are actually being used, and quantitative. There is so much bad AI commentary that is incredibly vague, divorced from any actual use cases, or written by people who don't actually use the tools. It is good to see a critique that is "here is a thing AI is bad at and measurements to show it" rather than gesturing "h…
Yes, more like this please, universe!
Re: The Economic Benefit of Refactoring
#58> Add a new ItemWatchStore public async trait to the Firestore layer, following existing patterns exactly. The trait must have three methods: async fn watch_item(&self, item_id: &str, user_id: &str) -> Result async fn unwatch_item(&self, item_id: &str, user_id: &str) -> Result async fn watched_items_for_user(&self, user_id: &str) -> Result > This shows the limitations of vibe coding. It takes someone with a long hist…
After reading a fair amount of OSS code, it's rather glaring that the data structures and algorithms are more like atoms than molecules in software design. We do have some molecules in the Design patterns, but they are more suitable to the OOP universe, like the collection api (filter, map, take,...) when dealing with groups of objects or the reactive api for dealing with concurrent tasks.
Most of software development is looking at some process and then decomposing it recursively until you get to those molecules/atoms of the computing world. Coding them is trivial, and while you can gain a certain boost from the AI, after a while you no longer have to write that much code. It will turn into a balancing act where the introduction of a new concept has to be done carefully.
Re: The Economic Benefit of Refactoring
#59Was hoping for a process diagram on how refactoring removes bottlenecks during software developement and allows you to ship faster etc :)
Still a nice writeup and love how these meta analysises (presumeably) done via AI can now easily capture metrics that inform your workflow.
Re: The Economic Benefit of Refactoring
#60This is such a nice piece, this is how people should write about AI. Specific, grounded to how the tools are actually being used, and quantitative. There is so much bad AI commentary that is incredibly vague, divorced from any actual use cases, or written by people who don't actually use the tools. It is good to see a critique that is "here is a thing AI is bad at and measurements to show it" rather than gesturing "h…
Yes, more like this please, universe!
I’ll try to keep it up.