The two tasks of writing code and engineering software cannot be separated without damaging the integrity of the mental model of the engineer. Having architects who didn't interact with the code always produced map/territory mismatches.
I realized at some point yesterday that these kinds of shortcuts would no longer be accepted
with competent LLM use.
One example: in some old code I wrote I had assumed that the Rust Hash impl for a type is stable over time. This is not the case in general, but writing a custom hasher for a complex type is incredibly annoying, so I took that shortcut. That was fine for years, but came back to bite me this week as I was trying to update a dependency.
How much incidental complexity is due to that kind of thing? An LLM code review would flag this instantly, and one would also write a stable hash function for you.
It's hard to let that go, but you already had to in larger human organizations/collaborations where you might be assigned work on systems you never/seldom touch, or coming back to a project you haven't touched in a long time.
You don't need a mental model when you can automate the reasoning and the benchmarks that vet the reasoning. Your mental model is better spent pondering->reconsidering high level things like invariants, and then automating the the proof and implementation of those decisions.
Consider how you can just get Claude to start a workflow of 15 Fable agents to fan out over your system looking for correction/simplification/perf opportunities before spawn another wave of agents to vet the list of findings. How much time and energy and studying of the code would it have taken you to build and vet the same list?
Problem with the analogy is that the strain in software engineering is necessary for an in depth understanding of the code.
The question is whether that depth of knowledge is ultimately more helpful than the speed that we can build with AI.
I love to say that
Some managers didn't pass the Turing testNo? Why?
Because software languages are a pretty good abstraction.
To the extent that good abstractions are in place, you can avoid looking at code specifically.
Those don't perfectly well exist, so it takes a lot of self discipline and the right tools/methods, but invariably, AI will produce better systems.
That said, its very easy to produce slop, so well see much more of it.
But mostly, it will be AI from here on in, as a matter of productivity. There are some arguments on the margins but those will fade over the next few years.
'At minimum' - the 'power tools' are here to stay.
Looking at the compiler output is a totally valid concept, but it's definitely a niche case.
It's arguably more important with Java than with the compiler output for something like C++, as C2 is much more unpredictable and dependent on runtime circumstances. You also want to be real certain that bounds and null checks are omitted as those come at a pretty big performance premium.
> No? Why?
> Because software languages are a pretty good abstraction.
No, it’s because compilers produce deterministic output. I am so tired of this argument.
If I’m not concerned with the performance of my code, I can be 100% confident that that exact code will produce the correct assembly every time. That’s why I don’t read it. Not because I don’t care.
It's entirely the nature of the abstraction.
You want it to work as expected, it does not have to produce the same thing each time.
Source: I work on an operating system.
An LLM translating a prompt to to high-level code has a much lower degree of predictability. To say an LLM prompt is a comparable abstraction is unfair, though I admit it's getting very close.
But yes, it has to fulfill some kind of contract defined by the absraction.
It's less a problem of the LLM, and more so how we use them, and the inherent tooling around it.
Programming abstractions offer interfaces to functionality that are both simplified in use and restricted in capability. (e.g. any API or compiler.) I don't see how LLMs meet that definition.
It seems more like we're talking about offloading or delegation, here. And that's a valid business tactic, certainly, but it's not a software abstraction any more than a CTO is an abstraction of a tech lead, no?
> But yes, it has to fulfill some kind of contract defined by the absraction.
I don't follow. Is the contact here the design specification for the system? If so, again, I'd argue that's not an abstraction.
That's definitely an abstraction.
IDLs are a form of abstraction, they're a requirement somewhat more formally described.
Remember UML? That was an attempt to go 1/2 layer above the code, that was an abstraction.
There were tons of tools like that.
APIs are an abstraction - maybe the best example. We write code to match exactly the behaviour defined by an APU - as long as it meets the requirement of that contract, then 'it's good'. And there could be many ways of doing that.
This is true to such an extent that I have to question the overall competence of anybody who makes the comparison. It's an enormous red flag.
I'd recommend reading Joel spolsky's leaky abstractions essay coz while it applies less and less 20 years later to things like kernel abstractions it explains very well why treating the LLM as a compiler sets you up for abject failures.