This is accurate. I don’t disparage anyone opting out of using LLM coding tools for political/ecological/job satisfaction reasons but beneath the hype the business of making software is actually changing. It has always been about delivering higher order functionality with some explicit/implicit error rate. Users/customers fundamentally don’t care if your code base is spaghetti, they care that it works. Keeping code, data, and nonfunctional requirements under control has always been the real job of the developer/engineer.
The rate at which AI let’s you iterate, test, pin, and ship functionality is undeniable. The author complains about it inelegant code? The features get to market 100x sooner = more money and time to rework anything that causes a problem later. Author complains about hyperspecific tests? It’s a cheap guardrail for the agent you never really have to look at.
The author also calls it a service and not a tool, but that’s just not true. The big fancy frontier models are struggling to outpace open weight models you can run on consumer hardware. There are companies already moving to self hosted setups and saving bundles of cash. Don’t buy the marketing, it might be a pricey tool for you to personally own but it is a tool.
On the topic of AI lock-in (it writes a code base that only an AI can maintain): that’s a tradeoff you can account for or design around. If the business wants to take the risk and tie itself to AI models then so be it. If they want to keep it ergonomic for humans, you can still leverage AI to sand off all the edges and build the guardrails that humans need. Or a hybrid approach where critical systems get more human focus and AI handles the fringes.
Good architects and technical managers were already able to herd code monkeys toward complex, functional software without mentally compiling each line of code. Now those skills are becoming more generally required.
This is accurate. I don’t disparage anyone opting out of using LLM coding tools for political/ecological/job satisfaction reasons but beneath the hype the business of making software is actually changing. It has always been about delivering higher order functionality with some explicit/implicit error rate. Users/customers fundamentally don’t care if your code base is spaghetti, they care that it works. Keeping code, data, and nonfunctional requirements under control has always been the real job of the developer/engineer.
The rate at which AI let’s you iterate, test, pin, and ship functionality is undeniable. The author complains about it inelegant code? The features get to market 100x sooner = more money and time to rework anything that causes a problem later. Author complains about hyperspecific tests? It’s a cheap guardrail for the agent you never really have to look at.
The author also calls it a service and not a tool, but that’s just not true. The big fancy frontier models are struggling to outpace open weight models you can run on consumer hardware. There are companies already moving to self hosted setups and saving bundles of cash. Don’t buy the marketing, it might be a pricey tool for you to personally own but it is a tool.
On the topic of AI lock-in (it writes a code base that only an AI can maintain): that’s a tradeoff you can account for or design around. If the business wants to take the risk and tie itself to AI models then so be it. If they want to keep it ergonomic for humans, you can still leverage AI to sand off all the edges and build the guardrails that humans need. Or a hybrid approach where critical systems get more human focus and AI handles the fringes.
Good architects and technical managers were already able to herd code monkeys toward complex, functional software without mentally compiling each line of code. Now those skills are becoming more generally required.