The Learning Loop and Llms

Front end design should have been all drag and drop years ago. LLMs should be doing it now. If it were not for the fact that HTML is a terrible way to encode a 2D layout, it would have been.

Hm... I think I get what Mr. Joshi is saying, but the headline clashes with the notion that the essence of what we do is automation, and that includes automating the automation.

This at first blush smells like "Don't write code that writes code," which... Some of the most useful tools I've ever written are macros to automate patterns in code, and I know that's not what he means.

Perhaps a better way to say it is "Automating writing software doesn't remove the need to understand it?"

Learning what though? When I wrote software I learn the domain, the problem space, the architecture, the requirements, etc, as well as how to turn those things into code. I don't actually care about the code though - as soon as something changes I'll throw the code out or change it. It's an artefact of the process of solving a problem, which isn't the important bit. The abstract solution is what I care about.

LLMs only really help to automate the production of the least important bit. That's fine.

Spoiler: the author used LLMs to automate much of his development work.

There are parts of software development, which requires understanding purpose and code and making good decisions or having in depth understanding to ootikize. And there are parts where it's just boring ceremony for using a library or doing some refactorings.

The first one is mostly requiring experienced humans, the alter one is boring and good to automate.

The problem is with all the in between. And in getting people to be able to do the first. There AI can be a tool and a distraction.

So is drawing and painting. Didn't stop many techies in here from using it. Many techies believe their tech is improving the world even when their tech is stealing people's copyrighted art or making people depressed.

The actual title is: The Learning Loop and LLMs

For some reason johnwheeler editorialized it, and most of the comments are responding to the title and not the contents of the article (though that's normal regardless of whether the correct title or a different one is used, it's HN tradition).

I'm happy to learn the essential complexity (e.g. business logic) but see low/no value in learning incidental complexity (code implementation details).

No, what I think LLMs really teach us is that we have too many different languages. I think we need exactly one informal one, and exactly one formal one, and that's about it.

This ignores learning styles [0], and assumes that everyone learns by experimentation. Some people don't, they learn by reading/studying and don't ever need to experiment. They go from reading all the literature on the subject to building stuff on the first try. Of course they still make mistakes and learn from those mistakes, but they don't experiment to find out what went wrong; they go back to the books/blogs/docs and work out what they did wrong, then correct the code and try again.

Similarly there are some engineering departments that absolutely do design everything first and only then code it up, and if there are problems in the coding stage they go back to design. I'm not saying they're efficient or that this is best practice, but it suits some organisations.

[0] https://en.wikipedia.org/wiki/Learning_styles there's a ton of different approaches to this, and a lot of it is now discredited. But the core concept: that people learn differently, isn't disputed.

In itself, I'm not sure this is a great argument. Putting shoes on a horse is an act of learning. Butchering your own pig is an act of learning. Sewing your own clothes is an act of learning. Writing your own operating system is an act of learning... but if you don't do any of that, you're not necessarily worse off. Maybe you just have more time to learn other things.

Maybe there's a broader critique of LLMs in here: if you outsource most of your intellectual activity to an LLM, what else is left? But I don't think this is the argument the author is making.

This is by far the best piece I have read in relation to programming and LLMs. Not just, on how to approach LLMs as a programmer, but on the nature of programming itself. Inexperienced programmers, in particular, who come across this will be lucky indeed.

"Programming as theory building" still undefeated.

Also, fun to see the literal section separator glyphs from "A Pattern Language" turn up.

>leaving us with zero internalized knowledge of the complex machinery we've just adopted

To be fair I have this with my own code, about 3 days after writing it.

I agree, writing some software requires learning and understanding. But sometimes, one just needs something done (if one's job is not software engineer) and then LLMs are indispensable. Also in some software projects (at least in my personal experience) there is stuff that is important and requires thought, and a lot of other stuff that's just boilerplate, connecting this to that etc. I am more than happy to delegate that. It gives me more time to think about stuff that's actually important.

Respectfully disagree.

Why is the current level of language abstraction the ideal one for learning, which must be preserved? Why not C? Why not COBOL? Why not assembly? Why not binary?

My hypothesis is that we can and will adapt to experience the same kind of learning OP describes at a higher level of abstraction, specs implemented by agents.

It will take time to adapt to that reality, and the patterns and practices we have today will have to evolve. But I think OP's view is too short-sighted, rooted in what they know and are most comfortable with. We're going to need to be uncomfortable for a bit.

> I recently developed a framework for building distributed systems—based on the patterns I describe in my book. I experimented heavily with LLMs. They helped in brainstorming, naming, and generating boilerplate. But just as often, they produced code that was subtly wrong or misaligned with the deeper intent. I had to throw away large sections and start from scratch.

Well i do this but i force it to make my code modular and i replace whole parts quite often, but it's tactical moves in an overall strategy. The LLM generates crap, however, it can replace crap quite efficiently with the right guidance.

The way I talk about is is that the value you deliver as a software "engineer" is: taste and good guesses. Anyone can bang out code given enough time. Anyone can read docs on how to implement an algorithm and implement it eventually. The way you deliver value is by having a feel for the service and good instincts about where to look first and how to approach problems. The only way to develop that taste and familiarity is to work on stuff yourself.

Once you can show, without doubt, what you should do software engineers have very little value. The reason they are still essential is that product choices are generally made under very ambiguous conditions. John Carmack said "If you aren't sure which way to do something, do it both ways and see which works better."[1] This might seem like it goes against what I am saying but actually narrowing "everything possible" to two options is huge value! That is a lot of what you provide as an engineer and the only way you are going to hone that sense is by working on your company's' product in production.

[1] https://aeflash.com/2013-01/john-carmack.html

the tool is actually FOR learning, not for replacing it. acting like LLMs are somehow supposed to reflect back more bits than they take in is input is completely absurd to me. i bet my left kidney that i could take the patterns he describes in his book and get an LLM to reproduce them faithfully. and do it with fewer tokens than the book itself.

we can't automate it anyway and vibe coding is overrated: https://medium.com/thoughts-on-machine-learning/vibe-coding-...

> Software development has always resisted the idea that it can be turned into an assembly line.

This is... only true in a very very narrow sense. Broadly, it's our job to create assembly lines. We name them and package them up, and even share them around. Sometimes we even delve into FactoryFactoryFactory.

> The people writing code aren't just 'implementers'; they are central to discovering the right design.

I often remember the title of a paper from 40 years ago "Programming as Theory Building". (And comparatively-recently discussed here [0].)

This framing also helps highlight the strengths and dangers of LLMs. The same aspects that lead internet-philosophers into crackpot theories can affect programmers creating their no-so-philosophical ones. (Sycophancy, false appearance of authoritative data, etc.)

[0] https://news.ycombinator.com/item?id=42592543

I thoroughly love the meta programming features of cpp to generate code for me.