You all know that guy who sometimes knows the answer, sometimes he thinks he knows the answer but is wrong, and sometimes flat out guesses, and is equally confident no matter which?
That's LLMs.
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
Thoughts, re-reading and oldie but a goodie:
www.joelonsoftware.com/2000/04/06/t...
If you are lucky—if your project succeeds and lasts—that old codebase some developer hates will be yours. You might even be the developer hates it. So... 1/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)
Let me admit up-front that this affirms my priors, but it's an excuse to put to writing something I've been thinking about: LLM code-writing tools aren't saving time so much as they're shifting what we're spending time on. (0/n)
www.reuters.com/business/ai-...
Is a single, compact case with all the non-security bit types too much to ask? The Vessel Tough 30X is so, so close.
I hate JIS screws. That's not true. I dislike Phillips screws almost as much as slotted, but I hate how much harder true JIS screwdrivers are to find and how hard they are to tell apart. And to make things worse, sometimes JIS screwdrivers and bits are still labeled as Phillips.
When it comes to food, the difference between my wife and me is "Eww! Weird!" and "Ooh! Weird!"
