Comment by gyomu

You just described the burden of outsourcing programming.

Fair enough but I am a programmer because I like programming. If I wanted to be a product manager I could have made that transition with or without LLMs.

I can't help but imagine training horses vs training cats. One of them is rewarding, a pleasure, beautiful to see, the other is frustrating, leaves you with a lot of scratches and ultimately both of you "agreeing" on a marginal compromise.

This is why people thinkless of artists like Damien Hirst and Jeff Koons because their hands have never once touched the art. They have no connection to the effort. To the process. To the trail and error. To the suffer. They’ve out sourced it, monetized it, and make it as efficient as possible. It’s also soulless.

To me it feels a bit like literate programming, it forces you to form a much more accurate idea of your project before your start. Not a bad thing, but can be wasteful also when eventually you realise after the fact that the idea was actually not that good :)

> need to make it crystal clear

That's not an upside in that it's unique to LLM vs human written code. When writing it yourself, you also need to make it crystal clear. You do that in the language of implementation.

I think harder while using agents, just not about the same things. Just because we all got a super powers doesn't make the problems go away, they just move and we still have our full brains to solve them.

It isn't all great, skills that feel important have already started atrophying, but other skills have been strengthened. The hardest part is in being able to pace onself as well as figuring out how to start cracking certain problems.

Uniqueness is not the aim. Who cares if something is uniquely bad? But in any case, yes, if you use LLMs uncritically, as a substitute for reasoning, then you obviously aren't doing any reasoning and your brain will atrophy.

But it is also true that most programming tedious and hardly enriching for the mind. In those cases, LLMs can be a benefit. When you have identified the pattern or principle behind a tedious change, an LLM can work like a junior assistant, allowing you to focus on the essentials. You still need to issue detailed and clear instructions, you still need to verify the work.

Of course, the utility of LLMs is a signal that either the industry is bad at abstracting, or that there's some practical limit.

Yet another example of "comments that are only sort of true because high temperature sampling isn't allowed".

If you use LLMs at very high temperature with samplers which correctly keep your writing coherent (i.e. Min_p, or better like top-h, P-less decoding, etc), than "regression to the mean" literally DOES NOT HAPPEN!!!!

When I read discussions about this sort of thing, I often find that folks look harder for similarities and patterns but once they succeed here, they ignore the differences. AI in particular is so full of this "pattern matching" style of thinking that the really significance of this tech, ie., how absolutely new and different it is, yeah it just sort of goes ignored, or even worse, machines get "pattern matched" into humans and folks argue from that point of view lol witness all the "new musicians" who vibe code disco hits, I'll invariably see the argument that AIs train on existing music just like humans do so whats the big deal?

But these arguments and the OP's article do reinforce that AI rots brains. Even my sparing use of googles gemini and my interaction with the bots here have really dinged my ability to do simple math.

OS and compilers have a deterministic public interface. They obey a specification developers know, so you they can be relied on to write correct software that depends on them even without knowing the internal behavior. Generative AI does not have those properties.

> I didn't write my own OS. I didn't write my own compiler. I didn't write the standard library. I just use them. I could write them

Maybe, but beware assuming you could do something you haven't actually tried to do.

Everything is easy in the abstract.

> No, your favorite movie is not crap because the creators didn't grind their own lens.

But Pulp Fiction would not have been a masterpiece if Tarantino just typed “Write a gangster movie.” into a prompt field.

The creative process is not dependent on the abstraction.

> For me, lots of programming is the same. I just want to assemble the pieces

How did those pieces came to be? By someone assembling other pieces or by someone crafting them together out of nowhere because nobody else had written them by the time?

Of course you reuse other parts and abstractions to do whatever things that you're not working on but each time you do something that hasn't been done before you can't but engage the creative process, even if you're sitting on top of 50 years worth of abstractions.

In other words, what a programmer essentially has is a playfield. And whether the playfield is a stack of transistors or coding agents, when you program you create something new even if it's defined and built in terms of the playfield.

>I instead just fill my house/apartment with stuff already made and still feel like it's mine.

I'm starting to wonder if we lose something in all this convenience. Perhaps my life is better because I cook my own food, wash my own dishes, chop my own firewood, drive my own car, write my own software. Outwardly the results look better the more I outsource but inwardly I'm not so sure.

On the subject of furnishing your house the IKEA effect seems to confirm this.

https://en.wikipedia.org/wiki/IKEA_effect

I really appreciate this sentiment. It feels absolutely overwhelming the pace at which new tools and AI protocols are being released, leaving a feeling of constantly falling behind. But approaching from the other end, I can just make things that I do come up with and explore the new protocols only if I can't do the thing with what I've already grasped.

There are two stages to becoming a decent programmer: first you learn to use abstraction, then you learn when not to use abstraction.

Trying to find the right level is the art. Once you learn the tools of the trade and can do abstraction, it's natural to want to abstract everything. Most programmers go through such a phase. But sometimes things really are distinct and trying to find an abstraction that does both will never be satisfactory.

When building a house there are generally a few distinct trades that do the work: bricklayers, joiners, plumbers, electricians etc. You could try to abstract them all: it's all just joining stuff together isn't it? But something would be lost. The dangers of working with electricity are completely different to working with bricks. On the other hand, if people were too specialised it wouldn't work either. You wouldn't expect a whole gang of electricians, one who can only do lighting, one who can only do sockets, one who can only do wiring etc. After centuries of experience we've found a few trades that work well together.

So, yes, it's all just abstraction, but you can go too far.

> No, your favorite movie is not crap because the creators didn't grind their own lens.

One of the reasons Barry Lyndon is over 50 years old and still looks like no other movie today is because Kubrick tracked down a few lenses originally designed for NASA and had custom mounts built for them to use with cinema cameras.

https://neiloseman.com/barry-lyndon-the-full-story-of-the-fa...

> Popular and highly acclaimed games not at crap because they didn't write their own physics engine (Zelda uses Havok)

Super Mario Bros is known for having a surprisingly subtle and complex physics system that enabled the game to feel both challenging and fair even for players very new to consoles. Celeste a newer game also famous for being very difficult yet not feeling punishing does something similar:

https://maddymakesgames.com/articles/celeste_and_towerfall_p...

> or their own game engine (Plenty of great games use Unreal or Unity)

And Minecraft doesn't, which is why few other games at the time of its release felt and played like it.

You're correct that no one builds everything from scratch all the time. However, if all you ever do is cobble a few pre-made things together, I think you'll discover that nothing you make is ever that interesting or enduring in value. Sure, it can be useful, and satisfying. But the kinds of things that really leave a mark on people, that affect them deeply, always have at least some aspect where the creator got obsessive and went off the deep end and did their own thing from scratch.

Further, you'll never learn what a transformative experience it can be to be that creator who gets obsessive about a thing. You'll miss out on discovering the weird parts of your own soul that are more fascinated by some corner of the universe than anyone else is.

I have a lot of regrets in my life, but I don't regret the various times I've decided I've deeply dug into some thing and doing it from scratch. Often, that has turned out later to be some of the most long-term useful things I've done even though it seemed like a selfish indulgence at the time.

Of course, it's your life. But consider that there may be a hidden cost to always skimming along across the tops of the stacks of things that already exist out there. There is growth in the depths.

Did you not read the post? You're talking from the space of the Builder while neglecting the Thinker. That's fine for some people, but not for others.

> we had companies that employed many people, so that the top level of the company could simply specify what they wanted, and the lower levels only had to focus on making individual parts.

I think this makes a perfect counter-example. Because this structure is an important reason for YC to exist and what the HN crowd often rallies against.

Such large companies - generally - don't make good products. Large companies rarely make good products in this way. Most, today, just buy companies that built something in the GP's cited vein: a creative process, with pivots, learnings, more pivots, failures or - when successful - most often successful in an entirely different form or area than originally envisioned. Even the large tech monopolies of today originated like that. Zuckerberg never envisioned VR worlds, photo-sharing apps, or chat apps, when he started the campus-fotobook-website. Bezos did not have some 5d-chess blueprint that included the largest internet-infrastructure-for-hire when he started selling books online.

If anything, this only strengthens the point you are arguing against: a business that operates by a "head" "specifying what they want" and having "something" figure out how to build the parts, is historically a very bad and inefficient way to build things.

And therein lies the crux: some people love to craft each part themselves, whereas others love to orchestrate but not manufacture each part.

With LLMs and engineers often being forced by management to use them, everyone is pushed to become like the second group, even though it goes against their nature. The former group see the part as a means, whereas the latter view it as the end.

Some people love the craft itself and that is either taken away or hollowed out.

This is really what it’s about.

As someone that started with Machine Code, I'm grateful for compiled -even interpreted- languages. I can’t imagine doing the kind of work that I do, nowadays, in Machine Code.

I’m finding it quite interesting, using LLM-assisted development. I still need to keep an eye on things (for example, the LLM tends to suggest crazy complex solutions, like writing an entire control from scratch, when a simple subclass, and five lines of code, will work much better), but it’s actually been a great boon.

I find that I learn a lot, using an LLM, and I love to learn.

Yes, but bad ingredients do not make a yummy pudding.

Or, it's like trying to make a MacBook Pro by buying electronics boards from AliExpress and wiring them together.

It's more like the chess.com vs lichess example in my mind. On the one hand you have a big org, dozens of devs, on the other you have one guy doing a better job.

It's amazing what one competent developer can do, and it's amazing how little a hundred devs end up actually doing when weighed down by beaurocracy. And lets not pretend even half of them qualify as competent, not to mention they probably don't care either. They get to work and have a 45 min coffee break, move some stuff around in the Kanban board, have another coffee break, then lunch, then foosball etc. Ad when they actually write some code it's ass.

And sure, for those guys maybe LLMs represent a huge productivity boost. For me it's usually faster to do the work myself than to coax the bot into creating something acceptable.

Counterpoint (more devil's advocate), I'd argue it's better than an LLM writes something (e.g. the solution or thinking through of a problem) than nothing at all.

Counterpoint to my own counterpoint, will anyone actually (want to) read it?

counterpoint to the third degree, to loop it back around, an LLM might and I'd even argue an LLM is better at reading and ingesting long text (I'm thinking architectural documentation etc) than humans are. Speaking for myself, I struggle to read attentively through e.g. a document, I quickly lose interest and scan read or just focus on what I need instead.

Writing is how I think through a problem too, but that also applies to writing and communicating with an AI coding agent. I don't need to write the code per se to do the thinking.

Yep, this is the sweet spot. Though I still let it type code a lot - boilerplate stuff I’d be bored out of my mind typing. And I’ve found it has an extremely high success rate typing that code on top of its very easy for me to review that code. No friction at all. Granted this is often no larger than 100 lines or so (across various files).

If it takes you more than a few seconds or so to understand code an agent generated you’re going to make mistakes. You should know exactly what it’s going to produce before it produces it.

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.

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.

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.

> 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.

If you're only building things that have been built before, then sure, though I'd argue we already had solutions for that before LLMs.

there is a presumption that the models we are using today are 'good enough'. by models I mean thinks like linkers and package managers, micro services and cluster management tools.

I personally think that we're not done evolving really, and to call it quits today would leave alot of efficiency and productivity on the table

As with furniture, it's supply vs demand, and it's a discussion that goes back decades at this point.

Very few people (even before LLM coding tools) actually did low level "artisanal" coding; I'd argue the vast majority of software development goes into implementing features in b2b / b2c software, building screens, logins, overviews, detail pages, etc. That requires (required?) software engineers too, and skill / experience / etc, but it was more assembling existing parts and connecting them.

Years ago there was already a feeling that a lot of software development boiled down to taping libraries together.

Or from another perspective, replace "LLM" with "outsourcing".

I would argue the opposite..

What you get right now is mass replicated software, just another copy of sap/office/Spotify/whatever

That software is not made individually for you, you get a copy like millions of other people and there is nearly no market anymore for individual software.

Llms might change that, we have a bunch of internal apps now for small annoying things..

They all have there quirks, but are only accessible internally and make life a little bit easier for people working for us.

Most of them are one shot llms things, throw away if you do not need it anymore or just one shoot again

Acceptance of mass production is only post establishment of quality control.

Skipping over that step results in a world of knock offs and product failures.

People buy Zara or H&M because they can offload the work of verifying quality to the brand.

This was a major hurdle that mass manufacturing had to overcome to achieve dominance.

In my company, [enterprise IT] architects are separated into two kinds. People with a CV longer than my arm who know/anticipate everything that could fail and have reached a level of understandind that I personnally call "wisdom". And theorists, who read books and norms, who focus mostly on the nominal case, and have no idea [and no interest] in how the real world will be a hard brick wall that challenges each and every idea you invent.

Not being hands-on, and more important not LISTENING to the hands-on people and learning from them, is a massive issue in my surroundings.

So thinking hard on something is cool. But making it real is a whole different story.

Note: as Steve used to say, "real artists ship".

you think El Anatsui would concur that they didn't interact directly with what they were building? "hands on", "material you're shaping" is a metaphor

It's all individual. That's like saying writing only happens when you know exactly the story to tell. I love open a blank project with a vague idea of what I want to do, and then just start exploring while I'm coding.

> That said, the framing feels a bit too poetic for engineering.

I wholeheartedly disagree but I tend to believe that's going to be highly dependent on what type of developer a person is. One who leans towards the craftsmanship side or one who leans towards the deliverables side. It will also be impacted by the type of development they are exposed to. Are they in an environment where they can even have a "lump of clay" moment or is all their time spent on systems that are too old/archaic/complex/whatever to ever really absorb the essence of the problem the code is addressing?

The OP's quote is exactly how I feel about software. I often don't know exactly what I'm going to build. I start with a general idea and it morphs towards excellence by the iteration. My idea changes, and is sharpened, as it repeatedly runs into reality. And by that I mean, it's sharpened as I write and refactor the code.

I personally don't have the same ability to do that with code review because the amount of time I spend reviewing/absorbing the solution isn't sufficient to really get to know the problem space or the code.

This keeps coming up again and again and again, but like how many times were you able to copy paste SO solution wholesale and just have it work? Other than for THE most simple cases (usually CSS) there would always have to be some understanding involved. Of course you don't always learn deeply every time, but the whole "copy paste off of stackoverflow" was always an exaggeration that is being used in seeming earnest.

> Sometimes you want a utilitarian teapot to reliably pour a cup of tea.

If you pardon the analogy, watch how Japanese make a utilitarian teapot which reliably pours a cup of tea.

It's more complicated and skill-intensive than it looks.

In both realms, making an artistic vase can be simpler than a simple utilitarian tool.

AI is good at making (poor quality, arguably) artistic vases via its stochastic output, not highly refined, reliable tools. Tolerances on these are tighter.

I don't think this comparison holds up. With a higher-level language, the material you're building with is a formal description of the software, which can be fed back into a compiler to get a deterministic outcome.

With an LLM, you put in a high-level description, and then check in the "machine code" (generated code).

Depends on the problem. If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. Manually coding a signup flow #875 is not my idea of fun either. But if the complexity is in the implementation, it’s different. Doing complex cryptography, doing performance optimization or near-hardware stuff is just a different class of problems.

import claypot

trillion dollar industry boys

> you're probably not going to learn a ton with clay pot #10,001

Why not just use a library at that point? We already have support for abstractions in programming.

Ironic. The frequency and predictability of this type of response — “This criticism of new technology is invalid because someone was wrong once in the past about unrelated technology” — means there might as well be an LLM posting these replies to every applicable article. It’s boring and no one learns anything.

It would be a lot more interesting to point out the differences and similarities yourself. But then if you wanted an interesting discussion you wouldn’t be posting trite flamebait in the first place, would you?

Interesting comparison. I remember watching a video on that. Landscape paintings, portraits, etc, was an art that has taken an enormous nosedive. We, as humans, have missed out on a lot of art because of the invention of the camera. On the other hand, the benefits of the camera need no elaboration. Currently AI had a lot of foot guns though, which I don't believe the camera had. I hope AI gets to that point too.

> Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.

This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted:

  The process, which is an iterative one, is what leads you 
  towards understanding what you actually want to make, 
  whether you were aware of it or not at the beginning.

Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."

Source?

Yeah, and cameras changed art forever.