I think as an industry LLM assisted programming is largely amplifying an existing gap: commercial software is often under much higher speed constraints and much lower correctness constraints than the sorts of software that can be created by deeply understanding a software system.<p>Obviously this depends on the industry; aviation software that runs in regulated environments is probably under even <i>higher</i> correctness constraints than that which Sussman discusses. Accounting software too needs to balance books correctly or risk fines. But most software needs to be mostly correct. New features and better UX is more useful for the users of many systems than fixing tail frequency bugs.<p>Personally I do hobby code on systems I understand from scratch. Writing for older, well documented retro hardware for example is very fun. Writing things from simple abstractions is also fun. But my speed in doing this is something I know is not commercially viable and that's fine by me.<p>Many fields have a commercial aspect of them that has a much lower quality bar and a much higher output speed bar than their hobby equivalents. Wedding photography, voice acting, the quotidian demand for these things is far lower than appreciating an Ansel Adams piece in a museum.
It's pleasant to read an article that genuinely seems written by a person; warts and all. It doesn't matter that it repeats some of its points. Actually maybe that's the point. I hope more people try this.
The Android example is a bummer. After this many years and generations of GUI frameworks, you should not have to experiment nor dig into source code to learn how to do something as simple as laying out your widgets.<p>The docs should have examples for that kind of thing.
I can't imagine programming without understanding aka vibe coding. Hence I will never vibe code.
What do you do to learn new programming construct? What did you do to learn programming - didn't you write<p><pre><code> #include <stdio.h>
int main() {
printf("Hello World");
return 0;
}
</code></pre>
while having no idea what 'stdio.h' is?
Choosing not to know what stdio.h means is willful ignorance, an LLM has little to do with said chosen ignorance, that is a choice because "hey it works on machine!" and when I pushed it, nobody seemed to mind.<p>What a time to be alive. Actively choosing to rebuke knowledge because "what the fuck does it matter anyways"
no.
it was the first question I asked and was given a satisfactory explanation (along the lines of, "this adds things to your program that help it write text to the screen.")
The two don’t have to be mutually exclusive. You can let the agent code and you review it, or vice versa. No different from being a team lead where you don’t write all the code, or even review each and every line of code, but you have a very firm grasp of the code base.
-- me, two months ago
Interesting piece - reading it I found myself skimming, the point being made was being made repeatedly, albeit showing that as the author grew as a developer so did the complexity of the software they were using.<p>There was one thing that screamed in my head, though, whilst reading it, was, yes we can have a look at the library being used, read the code, and understand what its actually doing (this is one of the reasons I like Go so much, no matter who the upstream author is it's generally clear what they're doing [caveat: there are always going to be authors that obfuscate the f*ck out of code, no matter the language], the one thing, though, is systems like Netflix, hundreds of microservices running together in ways that people have NFI what it's all doing.<p>It just doesn't fit into one person's head anymore.<p>So, a single head can manage the data pathways for some subset of the system overall, and they might even get right down to the metal, the sheer size of the system means they only have a partial view, and abstractions (in the form of C4 diagrams) only show how complex the beast has become.
> <i>It just doesn't fit into one person's head anymore.</i><p>True, but I think it doesn't have to, at least not everything at the same time.<p>You can still usually understand the ins and outs of a specific component/service/module/etc with some time - e.g. if you have to develop or maintain that component.<p>Alternatively, you can also try to understand certain data or action paths throughout all components of the system - that's what OP did with the layout bug: They were trying to understand how Android's relayouting logic worked, so they managed to get a mostly complete picture of all the pieces that are involved in that specific functionality. But they probably didn't bother to learn the rest of Android's UI renderer or other unrelated components with the same thoroughness.<p>I think this kind of "selective understanding" where make conscious decisions which parts you want to understand and which you treat like a semi-predictable black box works well in practice.
In the world that the AI bros want for us, understanding has become a hobby.
Yep. It is a luxury. Nowadays I use AI for work, and my productivity increases. However, I don't learn much from the tasks, because I get more tasks since the team went down half size. Understanding is a luxury now.
The problem with that is - AI isn't a developer.<p>By that I mean, it's fabulous for taking the input I give it, processing it, and returning a collection of tokens that it has found in its training data that do what is being asked.<p>It's regurgitating fragments of prior work - I have zero complaint about that, just as a developer you now need to understand what those fragments combined do, and whether that really fits with your actual desire - or not.<p>To put it into old people's terms "You got the answer from Stack Overflow? Was that the code from one of the answers.... or the question?"