Comment by oceanplexian
20 hours ago
Coding is not at all like working a lump of clay unless you’re still writing assembly.
You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs. The artificial syntax that you use to move the bricks around is the thing you call coding.
The human element of discovery is still there if a robot stacks the bricks based on a different set of syntax (Natural Language), nothing about that precludes authenticity or the human element of creation.
It depends what you're doing not really what you do it with.
I can do some crud apps where it's just data input to data store to output with little shaping needed. Or I can do apps where there's lots of filters, actions and logic to happen based on what's inputted that require some thought to ensure actually solve the problem it's proposed for.
"Shaping the clay" isn't about the clay, it's about the shaping. If you have to make a ball of clay and also have to make a bridge of Lego a 175kg human can stand on, you'll learn more about Lego and building it than you will about clay.
Get someone to give you a Lego instruction sheet and you'll learn far less, because you're not shaping anymore.
> You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs.
Correct. However, you will probably notice that your solution to the problem doesn't feel right, when the bricks that are available to you, don't compose well. The AI will just happily smash together bricks and at first glance it might seem that the task is done.
Choosing the right abstraction (bricks) is part of finding the right solution. And understanding that choice often requires exploration and contemplation. AI can't give you that.
Not yet, anyway; I do trust LLMs for writing snippets or features at this point, but I don't trust them for setting up new applications, technology choices, architectures, etc.
The other day people were talking about metrics, the amount of lines of code people vs LLMs could output in any given time, or the lines of code in an LLM assisted application - using LOC as a metric for productivity.
But would an LLM ever suggest using a utility or library, or re-architecture an application, over writing their own code?
I've got a fairly simple application, renders a table (and in future some charts) with metrics. At the moment all that is done "by hand", last features were stuff like filtering and sorting the data. But that kind of thing can also be done by a "data table" library. Or the whole application can be thrown out in favor of a workbook (one of those data analysis tools, I'm not at home in that are at all). That'd save hundreds of lines of code + maintenance burden.
I was creating a Jira/bb wrapper with node recently and Claude actually used plenty of libraries to solve some tasks.
1 reply →
Unless you limit your scope of problem solving to only what you can do yourself, you are going to have to delegate work - your abstraction is going to be specs and delegating work to other people and ensuring it works well together and follows the specs - just like working with an LLm.
Exactly, and that's why I find AI coding solving this well, because I find it tedious to put the bricks together for the umpteenth time when I can just have an AI do it (which I will of course verify the code when it's done, not advocating for vibe coding here).
This actually leaves me with a lot more time to think, about what I want the UI to look like, how I'll market my software, and so on.
> Coding is not at all like working a lump of clay unless you’re still writing assembly.
Isn't the analogy apt? You can't make a working car using a lump of clay, just a car statue, a lump of clay is already an abstraction of objects you can make in reality.
Bingo.
Lego boxes include a set of instructions that implies there's only one way to assemble the contents, but that's sometimes an injustice to the creative space that Legos are built to provide. There can be a joy in algorithmically building the thing some other designers worked to make look nice, but there's a creative space outside the instructions, too.
The risk of LLMs laying more of these bricks isn't just loss of authenticity and less human elements of discovery and creation, it's further down the path of "there's only one instruction manual in the Lego box, and that's all the robots know and build for you". It's an increased commodification of a few legacy designers' worth of work over a larger creative space than at first seems apparent.
I think the analogy to high level programming languages misunderstands the value of abstraction and notation. You can’t reason about the behavior of an English prompt because English is underspecified. The value of code is that it has a fairly strong semantic correlation to machine operations, and reasoning about high level code is equivalent to reasoning about machine code. That’s why even with all this advancement we continue to check in code to our repositories and leave the sloppy English in our chat history.
Yep. Any statement in python or others can be mapped to something that the machine will do. And it will be the same thing every single time (concurrency and race issue aside). There’s no english sentence that can be as clear.
We’ve created formal notation to shorten writing. And computation is formal notation that is actually useful. Why write pages of specs when I could write a few lines of code?
There's also creative space inside the formal notation. It's not just "these are the known abstractions, please lego them together", the formal syntax and notation is just one part of the whole. The syntax and notation define the forms of poetry (here's the meter, here's the rhyme scheme, here's how the whitespace works), but as software developers we're still filling in the words that fit that meter and rhyme scheme and whitespace. We're adding the flowery metaphors in the way we choose variable names and the comments we choose to add and the order we define things or choose to use them.
Software developers can use the exact same "lego block" abstractions ("this code just multiplies two numbers") and tell very different stories with it ("this code is the formula for force power", "this code computes a probability of two events occurring", "this code gives us our progress bar state as the combination of two sub-processes", etc).
LLMs have only so many "stories" they are trained on, and so many ways of thinking about the "why" of a piece of code rather than mechanical "what".
1 reply →
> plugging them together like LEGOs
Aren't Legos known for their ability to enable creativity and endless possibilities? It doesn't feel that different from the clay analogy, except a bit coarser grained.
You’re both right. It just depends on the problems you’re solving and the languages you use.
I find languages like JavaScript promote the idea that of “Lego programming” because you’re encouraged to use a module for everything.
But when you start exploring ideas that haven’t been thoroughly explored already, and particularly in systems languages which are less zealous about DRY (don’t repeat yourself) methodologies, the you can feel a lot more like a sculptor.
Likewise if you’re building frameworks rather than reusing them.
So it really depends on the problems you’re solving.
For general day-to-day coding for your average 9-to-5 software engineering job, I can definitely relate to why people might think coding is basically “LEGO engineering”.
changing "clay" for "legos" doesn't change the core argument. The tactile feel you get for the medium as you work it with your hands and the "artificial syntax" imposed by the medium.