LLMs Reduce Development Friction. Is That a Good Thing?

Even as an “LLM-skeptic”, it would be silly for me to say that the tools are useless for software development. There are clearly times where they can be useful, whether that’s to perform a refactoring too complicated for IDE tooling, or to get a proof-of-concept put together. With that said, in my time both using and watching others use LLMs, I have noticed a troubling trend: they help reduce friction when developing software – friction that can help us to better understand and improve the systems we work on.

Over the years, I’ve changed my opinions about what makes a good, maintainable piece of software. One of the talks that I think has influenced my opinions the most is J. B. Rainsberger’s “Integrated Tests Are a Scam”. While I might not agree with the conclusions he comes to about how to structure our tests, one piece of this talk has stuck with me: when your tests are hard to write, you probably have a flaw in your system design. It exerts a kind of “pressure” on you to challenge the past choices you’ve made.

I’ve worked with many engineers (and I won’t claim I’m never amongst them) who find the need to lean on LLMs to write tests for them. It’s easier to ask a machine that has context on the problem to write them than to write them ourselves. But by doing this, are we robbing ourselves of the chance to learn, and to make our designs better? Sure, we may feel this friction when writing other parts of our code. With that said, in my experience, those who lean on LLMs to write the “boring” tests are also asking LLMs to try and fill in gaps where their abstractions have made a solution harder to implement.

I see this as a collaboration problem, too, especially if you work on a “platform” team that serves other internal teams. If an external contributor comes into a codebase, their first reaction to this friction might be to ask an owner of the codebase for help. This collaboration has a secondary effect: it informs the owners of the codebase where they need to alter their designs to better serve their peers’ needs.

Other contributors may choose to lean on an LLM to get in-and-out of the unfamiliar codebase as fast as possible. It’s true that this may help them get the work done more quickly, but we’ve robbed both parties of a chance to learn; the external contributor loses the opportunity to learn more about a system they don’t normally interact with, and the owners lose a chance to learn how to better help their customers.

At the end of it all, I don’t see a black and white solution here; certainly there will be times when fast code is worth the trade-off. At the same time, I want to challenge my fellow engineers to not reach for an LLM the next time they find themselves facing a thorny problem. The temporary discomfort may be a valuable growth opportunity as an engineer.