Could you explain why it would be a goal to understand the system less, rather than more?
It seems harder to know if you have good tests while lowering your expertise in the system.
An LLM can produce far more code than a human can understand. And the famous rule that "optimizations are entirely pointless unless you're optimizing at the constraint" is logistics 101.
To accelerate software development, you either need to remove or lessen the need for code understanding, or make it much quicker for humans to gain that understanding. Making the LLM faster won't help you if the LLM isn't the bottleneck.
A lot of old-school software engineering is about how to deal with this reality.
In the old days even if I knew how the software worked when I wrote it, I’d have no idea how it worked when I looked at it weeks later.
It’s also easy to modify software without knowing how it works. This produces modifications that hopefully appear to work, but that break other things, sometimes unknown things.
Of course less competent engineers (or anyone on a particularly disorganized or desperate day) can literally hand-write code they don’t understand even as they write it, but that’s not really what I’m talking about.
> literally hand-write code they don’t understand even as they write it
I find this literally impossible. How can you even start typing anything without knowing what to type?
Have you never "fixed a bug", only to realize that you just papered over a single symptom, while the underlying bug is still intact?
People you're disagreeing with (I think!), would say that during your first attempt, you didn't _really_ understand the part you're modifying.
It is _very easy_ to do this in large codebases, and even more so when working on anything touching UI.
You don't know what these things do and what their effects really are (examples and syntax illustrative, but this is the kind of code that has disastrous effects when used carelessly), but you know they achieve your particular micro goal of "make things go fast" or "make this fit in packets on these strange industrial networks customer X has" or whatever.
Etc.
Eventually we're going to reach a point where they don't have to understand the code themselves. The democratization of software creation is going to be fascinating.
There are small towns all over the world which could realistically have their own little "hometown app" now, that really does track all the interesting things going on there. People don't need "The (Unofficial) Smallville Happenings" Facebook pages anymore. These don't all have some programmer who cares enough about building such a thing to make it happen, but they probably do have a teenager or even a retiree who would have a lot of fun making something that really works well for the people of that town and how they want to use it. The barrier to entry just became low enough to get over.
And that's just one example. There are SO MANY problems that used to require mega investment to solve at scale to get any traction at all. Now communities can build them for themselves. And they'll never be the kind of data target that a megacorp is, because you'd have to target each little app individually, hoping there was something useful in there.
The democratization of software development is going to have lots of things that go nowhere, and lots of little hobby projects, and a few things people will actually hear about and care about. But a lot of people's lives will become incrementally better and I'm excited to see that.
So accelerate the vibe coding of shit nobody wants or asked for, just to see some metric go up somewhere.
Are we still getting bonuses for the number of tokens we can burn?
Frontier models today don't really write incorrect code at the micro level. They do miss edge cases at the high level though, and that's what we want to test, is the scenarios.