And I wouldn't write this article 3 months ago. Since then the quality of the output jumped significantly, it is now possible to put the agent into a proper harness (plan/edit/review/test) and the output is good — and if it's not, you discard it and try again, or point out a detail for the next cycle of improvements.
Yes, this requires a lot of forethought to set up, but it works.
I'm not talking only about "web things", I'm working on a project that involves engineering calculations and a lot of optimization of hot paths, both CPU and GPU.
Let’s be honest, how many devs are actually creating something interesting/unique at their work?
Most of the time, our job is just picking the right combination of well-known patterns to make the best possible trade-offs while fulfilling the requirements.
Right. I don't trust LLM's to pick the right pattern. It will pick _a_ pattern and it will mostly sorta fulfill the requirements.
It’s a winner-takes-all market. There are no buyers for off brand Salesforce or Uber.
> …a slightly accelerated
> modeling phase and then
> let them loose on
> the implementation…
If you mean _visual_ modeling ala UML [1], then I have it on "good authority" [2] that's a sound approach…_____
MODEL
…
The Verdict: If you provide a clear instruction like "Before you touch the code, read architecture.puml and ensure your changes do not violate the defined inheritance/dependency structure," the agent will be very effective at following it.
If you just "hope" it bears it in mind, it probably won't.
_The agent is a tool, not a mind-reader; it will take the shortest path to a passing test unless you wall that path off with your architectural models_.
…
To make it actually work, you need to turn the UML from a "suggestion" into a "blocker." You should add a section to your AGENTS.md (or CLAUDE.md ) that looks like this:
1. Tool Trigger: By using words like "…"
…Why this works:
…
_____
Yeh even if LLMs are 10x better than today you probably still don't want to implement cryptography from scratch, but use a library.
I also like the 3d printing analogy. We will see how good LLMs get, but I will say that a lot of AI coded tools today have the same feeling as 3d printed hardware. If no engineer was involved the software is cheap and breaks under pressure because no one considered the edge cases. It looks good on the surface but if you use it for something serious it does break.
The engineer might still use an LLM/3d printer but where necessary he'll use a metal connection (write code by hand or at least tightly guide the LLM) to make the product sturdy.
That's LLMs extending C and C++ Undefined Behaviour to every project regardless of language.
-------------------
EDIT: I tried articulating it in a blog post in a sleep-deprived frenzy of writing on Sunday - https://www.lelanthran.com/chap14/content.html
What are the incentives for doing that? What are the incentives for everyone else to move?
So if proven things exist for basics, what's the incentive to not use them? If everyone decides they're too heavy, they could make and publish new libraries and tools would pick those up. And since they're old, the feature-set is probably more nuanced than you expect. YAGNI is a motto for doing less to avoid creating code debt, but writing more net new code to avoid using a stable and proven library doesn't fit that.
You know what would happen if all the people who handwrote and maintained those libraries revoked their code from the training datasets and forbid their use by the models?
:clown face emoji:
This LLM-maxxing is always a myopic one-way argument. The LLMs steal logic from the humans who invent it, then people claim those humans are no longer required. Yet, in the end, it's humans all the way down. It's never not.
The MCP servers combined with agentic search solved this possibility, just this year superseding RAG methods but all techniques have their place. I don't see much of a future for RAG though, given its computational intensity.
Long story short, training and fine tuning is no longer necessary for an LLM to understand the latest libraries, and therefore the "permission" to train would not even be something applicable to debate
it's a fast moving field, best not to have a strong opinion about anything
How would they know what superior code is? They're trained on all code. My expectation and experience has been that they write median code in the best-case scenario (small greenfields projects, deeply specified, etc).
The code is mostly not bad, but most programmers i have worked with write far better code.
I think it's the opposite -- if you have a good way to design your software (e.g., conceptual and modular), LLM will generate the understanding as well. Design does not only mean code architecture, it also means how you express the concepts in it to a user. If software isn't really understood by humans, I doubt LLMs will be able to generate working code for it anyway, so we get a design problem to solve.
LLM's are only as good as they are because we have such amazing incredible open source software everywhere. Because their job is to look at the types of really good libraries that have decades of direct and indirect wisdom poured into them, and then to be a little glue.
Yes the LLM can go make you alternatives, and it will be mostly fine-ish in many cases. But LLMs are not about pure endless frivolous frontiersing. They deeply reward and they are trained on what the settlers and town planners have done (referencing Wardley here).
And they will be far better at using those good robust well built tools (which they have latently built-in to their models some!) than they will be at re-learning and fine-tuning for your bespoke weird hodgepodge solution.
Cheap design is cheap now. Sure. But good design will be ever more important. Model's ability, their capacity, is a function of what material they can work with, and I can't for the life of me imagine shorting yourself with cheap design like proposed here. The LLM's are very good, but but honing in on good design is hard, period, and I think that judgement and character is something the next orders of magnitude of parameters is still not going to close the gap on.
For example, when a designer sends me the SVG icons he created, I no longer need to push back against just using a library. Instead, I can just give these icons to Claude Code and ask it to "Make like react-icons," and an hour later, my issue is solved with minimal input from me. The LLM can use all available data, since the problem is not new.
But many software problems challenge LLMs, especially with features lacking public training data, and creating solutions for these issues is certainly not cheap.
GenAI generally makes software cheaper. But there is a huge difference in how much. Prototypes and jigs may be 90% cheaper (just making up numbers here), while for production software it may be closer to 10%.
AI is taking over Senior Devs' Work is the same as IKEA is taking over carpenter's moat - no, no, and again no way.
AI lets you do some impressive stuff, I really enjoy using it. No doubt about that.
But app development, the full Software Delivery Life Cycle - boy, is AI bad. And I mean in a very extreme way.
I talked to a carpenter yesterday about IKEA. He said, people call him to integrate their IKEA stuff, especially the expensive stuff.
And AI is the same.
Configuration Handling: Works on my machine, impressive SaaS app, fast, cool, PostgreSQL etc.
And then there is the final moment: Docker, Live Server - and BOOM! deployment failed.
If you ever happen to debug and fix certain infrastructure and therefore deployment fails - you wish you were doing COBOL or x86/M68000 assembly code like it is 1987 all over again - if you happen to be a very seasoned Senior Dev with a lot of war stories to share.
If you are some vibe coder or consulting MBA - good luck.
AI fails so bad at doing certain things consistently well - and it costs company dearly.
Firing up a Landing Page in React using some Tailwind + ShadCN UI - oh well...
Software Design, Solution Architecture - the hard things are getting harder, not cheaper.
IKEA is great - for certain use cases. It made carpenter's work only more valuable. They thrived because of IKEA, they didn't suffer. In fact, there is more work for them to do. Is their business still hard, of course, but difficult in a different way (talent).
And all doomer's talking about the dev apocalypse - if AI takes over software development, who is in trouble then? Computer Science, software development? Or any and every job market out there?
Think twice. Develop and deploy ten considerably complex SaaS apps using AI and tell me how it went.
Access to information got cheaper. A fool with a tool is still a fool.
Less maintenance and flexibility. You're not really "designing software" until you have a 20+ year old product.
Vibe coders really embody the "temporarily embarrassed billionaire" mindset so perfectly.
TFA's take makes sense in a certain context. Getting a high-quality design which is flexible in desirable ways is now easier than ever. As the human asking an LLM for the design, maybe you shouldn't be claiming to have "designed" it, though.
More to the point how much of that profit is generated from selling those customers data rather than earning those customers payments?
There’s a reason why most vibe coded apps I’ve seen leak keys and have basic security flaws all over the place.
If you don’t know what you’re doing and you’re generating code at scale that you can’t manage you’re going to have a bad time.
The models are trained on all the slop we had to ship under time pressure and swore we’d fix later, etc. They’re not going to autocomplete the good code. They’re going to autocomplete the most common denominator code.
I don’t agree that design is cheap. Maybe for line-of-business software that doesn’t matter much.