Software Engineering is back
4 points by nbardiuk
4 points by nbardiuk
I'd restate the thesis not as "software engineering is back", but as a shift in where the difficulty lives.
With agents and LLM tooling, code itself has become cheap. What's become expensive are architectural mistakes -- especally in systems with a long time horizon and a high cost of failure.
In those domains (infra, platforms, finance), this genuinely increases the value of enginering thinking: invariants, boundaries, explicit models, trade-offs.
In short-horizon systems, the opposite happens. Architecture has negative ROI, and engineering collapses into generative trial-and-error and framework cosplay.
But this polrization creates a new problem: the middle layer. Engineers who design "normal" architecture for medium-complexity systems are in the squeeze zone -- too expensive compared to agent-generated code, but not yet operting at the level of constraint designers. This is where the profession doesn't return --- it simply evaporates.
So this isn't a return of the profession so much as a polarization of roles: either you design constraints and use agents as leverage, or you operate cheap code in an environment where architecture simply doesn't pay.
I wonder if we'll see LLMs generate code with vulnerabilities, and the lack of widely-used frameworks means orgs will be slower to patch them.
This is exactly what I think is going to happen. We'll see an explosion of new products, whether corporate or just hobbiest, with much less follow-through. It is easy to start something new, much harder to keep it maintained, ESPECIALLY if the idea is that AI will give you even more code quicker.
The lack of commonality between code now means an organization won't get the warning that libFoo 3.2.4 has a CVE, they'll have to have their own security testing that catches it and patches their own copy, assuming they have spare agents to go back and do that.
Companies that aren't investing as heavily in security as they are in their token budget are in for an awakening.
Where do you draw the line between rejecting dependencies that do more than you need and including satisfying building blocks? I'm thrilled to manage my tiny-payload website with a bag of purpose-built shell scripts, but I also fold in Jekyll, markdown, bunny CDN with mild clickops, the convenient FTP UI in Nova, launchctl, goaccess, and surely curl someplace. I assume the author's work still has this boundary and mixture on some level.
"simplification" and "labour costs" are problems solved by frameworks if those frameworks are built and maintained by others.
But frameworks you build yourself are useful too. Frameworks bring structure and predictability. Frameworks help you fight entropy. Frameworks let you take application concerns and work on them, test them and maintain them separately from that application. Application code is the worst code to have to maintain - pulling out concerns into a framework is one way to keep an application under control.
LLMs make it easier to roll application specific bespoke frameworks, if you can develop a strong enough concept of what such a framework looks like.
I don't think we can say we don't need frameworks as LLMs will handle boilerplate and repetition instead. I think soon you will find that LLMs struggle with context, consistency and entropy as well.