Another legacy monolith left unmaintained so long that updates became difficult is also being replaced piecemeal by proxying requests to it and redirecting them one at a time to new services. You can find a way. But do the next developer a favor and design replace-ability in when you can. 6/6

But better angels persuaded me to find a way to start building a new pattern alongside it and replacing one function at a time. 5/6

Even right now I'm facing the temptation to throw a project away and replace it wholesale because of a homespun query-builder that reaches its tendrils throughout the entire app. 4/6

Hopefully, this will mean refactoring will be easier in the future, and less code will have to be re-written to better reflect the updated requirements. In a worse case, the entire program can be re-written incrementally, Ship-of-Theseus style, making regular progress. 3/6

... here's how I try to design with that in mind. Any good decision you make addressing the application requirements will become wrong some day, so limit its reach. Build in loosely-coupled modules with well-defined interfaces that can be replaced individually. 2/6

There are exceptions. I've found LLMs pretty helpful for suggesting alternatives, reviewing code and identifying problems, and suggesting refactors to simplify code. (7/n)

Usually it works for the obvious cases, but is strangely organized or accomplishes things in a round-about way. In worse cases, there are non-obvious errors that are only caught after merging the change. Devs who can't write good SQL will push queries that miss cases or are unacceptably slow. (6/n)

i.e. anything you let an LLM do, you must have the knowledge and experience to thoroughly evaluate. I'm spending much more time reviewing and sending PRs back for re-work for nicely-formatted nonsense. (5/n)

LLMs are great at producing code that looks good. If you don't look closely, or if you don't know yourself what it should look like, it seems well-written. This is why my personal rule is, for anything important, don't trust an LLM to do anything you can't do. (4/n)

For more complex code changes, somebody winds up spending more time reviewing it than they would otherwise; hopefully the dev responsible for the change, or else the PR reviewer. If not them, then the next dev to work in that area, or the dev troubleshooting it. (3/n)

Anything else, and the time it takes to interpret the request and generate the code and for a dev to give it a once-over and accept the change is comparable to the time it would take to write it. (2/n)

First, on code I'm familiar with, as the article discusses. LLMs produce good-enough code for small tasks in well-written codebases with clear patterns. There's also not much of a difference in speed there unless we're talking long, tedious blocks of repetitive boilerplate. (1/n)

Is a single, compact case with all the non-security bit types too much to ask? The Vessel Tough 30X is so, so close.