The "It’s harder to read code than to write it" was always silly. The example spolsky gives to support it is basically "devs like to rewrite other devs code, therefore reading is hard" which is obviously bunch of nonsense. That's like saying reading poetry is harder than writing poetry because poets keep writing new poems despite the fact that Shakespeare already wrote it. Now that you can recruit LLM to explain any complicated codebase to you it's even less true.
This isn't a great analogy. The thing about code is it is part of a whole. While often code can be read in smaller pieces and understood, quite often you have to understand a very large part, if not all the work to really see what is going on.
This is why things like SAST are topical. They miss all kinds of exploits because they don't understand the program. The more in depth you try to scan the more the memory requirements explode.
Now LLMs are much better at this, but between context windows and costs you can bankrupt yourself pretty quick putting code bases in context memory.
This analogy directly addresses spolsky’s botched argument. The point is devs went into this career to dev not read other people’s code whether it makes business sense or not. What you said applies to writing code just as well as reading it so clearly writing cant be easier than reading - it’s at least as hard and most definitely harder
1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
2. technically risky ideas that you never would have tried because it didn't make sense from risk+effort/reward standpoint are now within reach. it isn't "go faster" per se but the speed at which you can try something out still changes the nature of engineering process.
> 1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)
I think it’s because most PEs are in general conservative (the whole “mr no” meme) and also have limited experience writing software so they will be slow to adapt to this paradigm shift
Because "platform engineering" isn't about writing bash scripts, it's about having a mental model of the system architecture. (Which the LLM definitely doesn't have.)
Also, it's always the case where you think LLMs are great at doing whatever it is that you don't understand or value.
There was lot of lofty ideas around devops/pe and the like but ime the grim reality is that in most of managers’ heads it’s basically “tools that product engs don’t want to be concerned with” and like i said current models are really really good at this. Also disagree on the mental model thing - give opus 4.7 or latest codex access to your code, design mds and your logging mcp - in five minutes it will be better at debugging production issues than 90% of platform engineers I’ve worked with. It is truly over
> and like i said current models are really really good at this
They're absolutely shit at this. You only say that because it's a thing you "don't want to be concerned with".
> in five minutes it will be better at debugging production issues
In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
> In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
Respectfully, unless someone is really really bad at articulating what the quality standards are or works with a very niche stack that is definitely not the case anymore with SOTA models
Respectfully, the current models are all trained on everyone else's legacy code as of roughly six months ago and largely always will be. If I'm doing my job right an LLM cannot meet my personal quality bar on its own because I will always need innovation and excellence they will never see and thus cannot deliver. I also think that training these tools on my personal quality bar is more work than just writing it myself.
LLMs are plenty innovative and generate good quality code by default, and great quality code when directed well.
If you're not seeing this, at best you're probably unable to direct them or use them well.
FWIW, if you don't believe the above, I challenge you to put up a quick git repo, where you are unable to get the deserved quality out, and we can quickly show you how the same quality is available via SOTA agents, within a fraction of hand-coded time.
I do agree with this. I was able to get exactly what I needed even out of GPT3.5. If you put enough parameters and examples, along with a real solid system prompt and (if you can) proper temperature and topK/topP, there's no reason they can't basically function like "smart typing assistants". The issue is that its a sliding scale of ambiguity to chaos. The more ambiguity, the more the LLM fills that in. And it can be very difficult and time consuming to know when you're being ambiguous or not (you don't know what you don't know, OR, you can't track what you aren't tracking).
Depending on the task, it can sometimes be just as arduous to produce enough guidance and guardrails to get the LLM to output exactly what you need that you can trust without issue or extensive review than it is to write it yourself and use the LLM just for ad-hoc generation. It's a constant balance and an endless amount of micro-decisions, honestly, but it's pretty essential to stay engaged and not YOLO with agents the way so many are. Most of my interactions with models these days are done in pseudo-code.
Great article! I use LLMs 99.9% in the chat box, to bounce ideas around, ask research and reference questions, and so forth. However, I have sworn off 'agents' entirely for serious code, for reasons your article captures almost totally and perfectly.
I'll still use 'agents' for throwaway tasks--mostly with local models--including tasks where some sort of ad-hoc code generation is in the critical path (e.g. scraping data).
True innovation is doing something new that has never been seen before. Even if you are doing it in a stable language that's just a stable poetry form (rhyme and meter and formatting), the real magic is the content of the poetry, and the real beauty of code is when the poetry reads well to both audiences, the compiler and the next maintainer, on multiple levels, the literal and the metaphorical.
LLMs can't reach the metaphorical. LLMs don't know what true beauty is. I will grant you they have gotten great at the literal and the poetry forms. But it is the beauty that elevates things to my quality bar, and makes a difference between "legacy code" and "innovation" to me.
What you're describing is not innovation in the business sense but some kind of experimental art. Software engineering is not art as the name suggests - it's a craft, even though there's a self-expression component to it.
I think we have different definitions of what a craft is. My boundary between art and craft is a lot looser, for instance. The way I see it there is craft to the best art and there is art embedded in the best craft. I think you are right that companies seem to ignore both the art and craft of software engineering and long wish the process were a predictable industrial machine much more than an art or a craft. But I will absolutely disagree with you that just because companies desire it to be an industrial process doesn't mean it isn't my job to understand the art of software design and how that influences the crafting of software.
You're presuming too much about what OP's quality standards are. Can SOTA models outperform the average junior engineer? Yes, obviously. Can they match the best human engineers, if those humans were given all the time and interest in the world? Equally obviously not.
I use hundreds of millions of tokens a month, and LLMs have completely transformed the way I work. They're also, frankly, pretty mid programmers.
Yes, and? Something can be both scare and inadequate to a given task. FAANG L5s cost a pretty penny but I wouldn't trust a random one to prove a crypto library correct.
Number of people who i personally met and would entrust a crypto library to i can count on one hand. You're moving that goalpost at relativistic speeds now.
it sold like 7 mil copies in a month. yes 98 was much more polished overall but 95 revolutionized personal computing as it was much more accessible than NeXT stuff
High dose aspirin (1000mg) + caffeine worked much better for me for migraines than paracetamol/ibuprofen/naproxen which did nothing. There're some studies supporting this too...
Only if you think consolidation of the entire tech industry being funneled into a dozen or so companies as positive sure.
Most of humanity doesn't think this, nor I doubt any devs like the current state of affairs where 4 companies dictate the direction of technology in this country.
Nobody dictates you anything - you’re welcome to setup your own dc if you wish to as some folks do. Not sure about “most of humanity” (lmao) but most of professionals in this line of work clearly don’t think it’s worth it for them
reply