[rossdavidh]

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part.

For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to find out what programming actually needs to be done, is to program something that's not it, and then replace it. This may need to be done multiple times. Programming is only occasionally the final product, it is much more often the means of working through what it is that is actually needed. This is very difficult for the people who ask for the software, to understand, and it is quite often very difficult for the people doing the programming to understand.

Most of what is being done, during programming, is working through the problem space in a way which will make it more obvious what your mistakes are, in your understanding of the problem and what a solution would look like. Once you have arrived at that understanding, then there are a variety of ways to make what you need, but that is not the rate-limiting step.

[Aurornis]

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part.

I’m growing tired of this aphorism because I’ve been in enough situations where it was not true.

Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole reason the business opportunity existed was that it was an extremely hard engineering problem.

I can see how one could go through a career where the programming itself is not that hard if you’re mostly connecting existing frameworks together and setting up all of the tests and CI infrastructure around it. I have also had jobs where none of the programming problems were all that complicated but we spent hundreds of hours dealing with all of the meetings, documents and debates surrounding every change. Those were not my favorite companies

[llmssuck]

> it was an extremely hard engineering problem

But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc.

I might be misunderstanding, but I cannot see how programming itself can be challenging in any way. It's not trivial per se or quickly over, but I fail to see how it can be anything but mechanical in and of itself. This feels like "writing" as in grammar and typing is the hard part of writing a book.

[simonw]

I count "figuring out how to do it" as part of the work of programming, personally.

[llmssuck]

Fair enough, but I think that never really worked all that well. What I mean is that the term "programming" would then essentially cover anything and everything that can be put into an algorithm of some sort. Neutrino detection, user management dashboards, CRUD APIs, basically everything is programming.

It would explain a lot of misunderstanding between "programmers" though.

[rstuart4133]

It's true that we often split software engineering into two pieces: doing the design and implementing the code. In fact I often prefer to think of it as computer systems engineering because the design phase often goes well beyond software. You have to think about what networks are used, what the hardware form factor should be used, even how many check digits should be put on a barcode.

But then you go onto say this:

> But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc.

That implies LLMs can't help with design of something that needs voice recognition and missile guidance systems. If that's your claim, it's wrong. In fact they are far better at being sounding boards and search engines than they are at coding. They make the same large number of mistakes in design tasks as they do in software coding, but in design tasks the human is constantly in the loop, examining all of the LLM's output so the errors don't matter so much. In vibe coding the human removes themselves from the loop to a large extent. The errors become shipped bugs.

[Anamon]

They can help with those tasks because there are decades of published research on them. I don't think LLMs change anything here. Even before LLMs, it wouldn't have been efficient to ignore readily available lessons from those who solved similar problems before. As you put it, LLMs can be great search engines. It's not that they changed the task.

Whether you have to solve a problem that is hard today because there aren't many available resources, or something well discussed that you can research with Google or an LLM, I don't think it changes anything about their argument that once you know what to do, actually turning it into working code is comparatively mundane and unchallenging, and always has been to some degree.

[satvikpendem]

Well yes, those are all programming, just as there are many different types of engineering, civil, mechanical, nuclear etc.

[stefs]

one example i come back to is multithreaded layouting/rendering browser engines. it was mentioned in the servo blog post back then when mozilla worked on it: "we tried it in c++ but it was simply too hard and complicated" (the argument was that they were able to do it in rust). still, as long as rust wasn't avaiable, the problem was considered "too hard" for the team that wrote firefox. in my opinion that's a solid argument for "programming problem that was too hard".

but as simon said, i too consider coming up with "the algorithms, the strategy" as part of programming. saying "it's easy to do if you know exactly how to do it" is somewhat tautological.

[Loic]

I am spending about 10h per day solving chemical engineering problems (dynamic simulation, model predictive control, etc.). The programming is hard on top of hard science. Even after 25 years of experience, it is still hard to find the right abstraction to implement everything.

Still, one thing I really like with LLM/AI, is that now, I can allow myself to test different abstractions a bit faster. I can allow myself to "try" more complex refactoring on a feature branch, because if I describe correctly the abstraction I want, the LLM/AI tool will be normally good at producing it. But to describe my abstraction, I need to pull all my programming and engineering years of experience.

But at the end of the day, I always tell my wife, that with these new tools, which I could not imagine so powerful 3 years ago, I live in the future :-)

[llmssuck]

I suppose the complexity of the domain is the main driver of the difficulty level. Perhaps that's the intuition that I'm trying to pin down: programming itself, the typing of words for the compiler, the act of converting pure thought into code, seems mechanical at best. But if you include the act of abstraction itself, then I concede it changes the equation. I don't find it to be all that clear what is and isn't programming to be honest.

Especially once you get to describe your abstractions in plain (or slightly technical) English instead of code I find it hard to say "programming" is being performed, but in many ways the case could be made that it remained the same and only the shape of the artifacts is different now.

[wmwragg]

Yep, I think people who repeat this aphorism essentially equate programming with typing, or as you say just connecting existing bits together. Programming is the working out how to get a computer to perform some task, not just the typing, it's the algorithms, the performance balancing, the structuring, the integration etc.

[pydry]

Or theyre just picturing some CRUD app that needs to connect to a few APIs being made for a clueless exec who doesnt even understand their own business problem.

To be fair, a lot of programming does end up being just that.

[yibg]

Probably difference in the boundary of what programming entails too. Eg is coming up with the algo itself part of programming or only the writing the implementation part after the algo is clear.

The first is hard, the second much less so.

[Anamon]

I think that's fine and probably kind of their point, no? Because that other part before the typing is also the thing that LLMs are woefully shit at, unless it's a common and solved problem with 1000 published examples.

[johnnyanmac]

>Some times the programming part really is very hard even when it’s easy to know what needs to be built

Sometimes. Most programming jobs out there just need a button on a website or a 2 line fix for some off-by-1 error, though. Those who are working on novel, cutting edge problems are relatively rare.

As you said, most software enginering is connecting existing frameworks together and being in meetings on how/when best to do it. Not necessarily a bad thing at all, but that's why the metaphor of the mechanic or doctor works out here, where the labor to know where and how to fix something is worth much more than the actual part (or medicine's) cost.

[ravenstine]

Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

The saying also ignores the fact that humans are not perfect programmers, and they all vary in skills and motives. Being a programmer often not about simply writing new code but modifying existing code, and that can be incredibly challenging when that code is hairbrained or overly clever and the people who wrote it are long gone. That involves programming and it's really hard.

[Yokohiii]

Isn't overly clever code a result of programmers doing simple things the hard mode?

Okay it's a spicy take, because juniors also tend to write too smart code.

Figuring out what to do and how to do it, is maybe not hard but it's effort. It's a hidden thing because it's not flat coding time, it requires planning, research, exploration and cooperation.

It's also true that some seemingly simple things are very hard. There are probably countless workarounds out there and the programmer wasn't even aware he is dodging an NP hard bullet.

Both arguments are valid.

I think the weight leans on effort, because effort is harder to avoid. Work, complexity, cruft piles up, no matter what you do. But you can work around hard problems. Not always but often enough. Not every business is NASA and has to do everything right, a 90% solution still generates 90% returns, and no one dies.

[anyonecancode]

> Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

Isn't this kind of true, though? Housing construction, for instance, isn't bottlenecked by the technical difficulties of building, but by political and regulatory hurdles. Or look at large, capital-intensive projects such as the always-proposed, never built new Hudson river train tubes. Actually building these will take billions of dollars and many years, but even they would be long built by now were it not for their constantly being blocked by political jockeying.

Building stuff _does_ often involve difficult technical challenges, but I still think that as a general aphorism the observation that this isn't the _hardest_ part holds true.

[llmssuck]

We might have different concepts of "hard", but if I were a construction worker I think I would agree. Hell, I'm a developer and I agree. Figuring out what to do definitely is the hard part. The rest is work and can be sweaty, but it's not hard as if it's full of impenetrable math or requiring undiscovered physics. It's just time-consuming and in the case of construction work physically tiring.

It might be that I have been doing this for too long and no longer see it.

[johnnyanmac]

I imagine the hard part isn't the literal building of the stuff. It's the months or years of politics, beauracracy, and bids needed to get to a point where you can build it.

That's not to discount the intensity of the labor. Just that the labor is rarely the bottleneck in building stuff.

[ravenstine]

I see what you're saying, and our labor isn't the bottleneck from the perspective of engineers. However, I'm pretty sure that business leadership would beg to differ. They see engineering as a necessary evil to getting their products out the window, and it can never be done fast enough. The solution is the bottleneck in their eyes. Engineers have a better understanding of why they do what they do, hence they get that their work isn't inherently a bottleneck in spite of how challenging it can be.

But yes, in reality, you're correct that programming itself is not (or should not) be a bottleneck, but the process around developing a product definitely can be. The irony here is that this bottleneck usually gets worse the more corporate a business becomes and the more they try to treat programming as if it were a bottleneck. Not a day goes by that my job isn't made more difficult because the business wants greater agility and efficiency.

[siliconc0w]

+1 A huge amount of software - probably most - is not actually generating value and in many cases is actually reducing value.

I've seen teams build and re-build the same infrastructure over and over.

I saw a request that could have been met with a few SQL queries and a dashboard got turned into a huge endeavor that implements parts of an ETL, Configuration Management, CI/CD, and Ticketing system and is now in the critical path of all requests all because people didn't ask the right questions and the incentive in a large organization is to build a mini-empire to reign over.

That said, smart infrastructure investment absolutely can be a competitive advantage. Google's infrastructure is, IMO, a competitive advantage. The amount of vertical integration and scale is unparalleled.

[Aurornis]

One of the most confusing moments in my early career was when someone spent two whole quarters building a custom tool that did something a mature and well respected open source project did for us. There was no advantage to his tool and he would admit it when cornered by the question.

We all thought he would get reprimanded for wasting so much time, but by the time management figured out was happening they decided they needed to sell it as a very important idea rather than admit they just spent $100,000 of engineering time on something nobody needed. So it turned into something to celebrate and we were supposed to find ways to use it.

That company went down in flames about a year later. That’s how I learned one way to spot broken organizations and get out early rather than going down with the ship.

[siliconc0w]

I heard a CEO try to sell some tech they had as this hugely valuable IP and a competitive moat.

When I asked the team that is supposed to use it, "We haven't used that in six months and it wouldn't be missed if it were to go away".

[shiroiuma]

>Google's infrastructure is, IMO, a competitive advantage. The amount of vertical integration and scale is unparalleled.

It's too bad they don't put this kind of thinking into their customer service.

[shimman]

Incentive of undemocratic groups is to build mini-empires yes, but if the business decisions were led by workers instead of a group of tyrants it'll most likely be a better decision. If we want lived examples of this, look at recorded history.

[shiroiuma]

>if the business decisions were led by workers instead of a group of tyrants it'll most likely be a better decision.

I don't see how. The workers will want to work on things that they enjoy, or that make them look good, regardless of how much they help the company's bottom line. Why would workers not want to build mini-empires of their own? If you're thinking that other workers in the company would vote them down, the problem with this is idea is that other workers in the company won't know about or understand why this time-wasting group is doing what it's doing, because it's not part of their competency. Do you keep track of business decisions and happenings in some other group in your company (assuming you're in a large organization)? Of course not; you don't have time to keep track of everything happening across the organization. So why would workers in your worker-led company do any better?

The entire point of leadership is that individuals don't have the time or expertise to know all this stuff and make smart decisions.

[cm11]

This concept exists outside of engineering too. It's captured in the more negatively intentioned: ““The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer". In user research, it's a much better signal when people correct you than when they agree. Politeness is easy—especially under the circumstances (power dynamic of you paying them, they only half care about your work, people generally want to be nice/agreeable, etc.)—such that you should be weary of it. Similarly trying to get real project goals or real requirements or real intentions from a PM or a boss, who may well be hiding that they there isn't much vision underneath things, is the same. The problem is that as productive as it is for developing the team's thinking, it will (1) probably come off as unproductive and challenging because you're slowing "progress" and (2) saying dumb wrong things makes you seem dumb and wrong. But per the concept, even when you do have the foresight to question, you're not allowed to just ask.

[CodeMage]

> the actual programming is not the hard part

We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard.

[johnnyanmac]

It's all relative. The general idea of this is that a software engineer spent years studying such concepts and then years more working in legacy code.

so it's second nature to do the mechanical operation of "extend a new class from Widget and add a function that returns the number of pencils pushed", and then somewhat easy after a few years to "pipe the pencil pushing function into the website frontend to display". Even if just describing this to a non SWE would have their eyes glaze over, and a junior SWE would struggle getting things integrated.

The painter metaphor works well here:

>Picasso in a restaurant, asked him to scribble something on a napkin, and said she would be happy to pay whatever he felt it was worth. Picasso complied and then said, “That will be $10,000.”

>“But you did that in thirty seconds,” the astonished woman replied.

>“No,” Picasso said. “It has taken me forty years to do that.”

(Disclaimer: I do not think Picasso literally said this, but it's a very common tale)

[zingar]

Hard perhaps but it feels a lot easier now than three years ago. Or so my backlog of personal projects outside of my most familiar stack would suggest.

[9rx]

What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

Determining what to program can be hard, but that was already considered earlier.

The only other place where I sometimes see it become hard for some people is where they treat programming as an art and are always going down crazy rabbit holes to chase their artistic vision. Although I would say that isn't so much that programming is hard, but rather art that is trying to push boundaries is hard. That is something that holds regardless of the artistic medium.

[CodeMage]

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Given a set of requirements, there are many different ways to write a program to satisfy them. Some of those programs will be more efficient than others. Some will scale better. Some will end up having subtle bugs that are hard to reproduce.

[9rx]

> That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself?

> there are many different ways to write a program to satisfy them.

"What to program" being hard was accepted from the onset and so far we see no disagreement with that.

[CodeMage]

> Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself?

Being able to transcribe sentences in a certain language is the skill kids pick up in elementary schools. Being a writer requires a whole set of skills built on top of that.

The reason why I brought up that difference in the first place is because both of these are called "writing". When a fan says "I heard the author is writing the next book in the series" or when an author says "I haven't been able to focus on writing due to my health issues", they're not talking about the low-level transcription skill.

> "What to program" being hard was accepted from the onset and so far we see no disagreement with that.

Similar to your interpretation of "writing", you're choosing to interpret "programming" as a process of transcribing an algorithm into a certain programming language, and everything else ends up being defined as "what to program".

That's an overly reductive interpretation, given the original context:

> For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to find out what programming actually needs to be done, is to program something that's not it, and then replace it. This may need to be done multiple times. Programming is only occasionally the final product, it is much more often the means of working through what it is that is actually needed.

> [...]

> Most of what is being done, during programming, is working through the problem space in a way which will make it more obvious what your mistakes are, in your understanding of the problem and what a solution would look like.

Notice that the original comment talks defines "determining what to program" as a process of refining your understanding of the problem itself.

In my reading of the original comment, understanding what your users need is "what to program". Writing code that solves your users' requirements is "programming".

[9rx]

> Writing code that solves your users' requirements is "programming".

For me, I need to have a solution figured out before writing code. I am not even sure how you could write code before having the problem solved. Your approach would be insightful.

Like, I get it is effectively impossible to gather all user requirements upfront and that you need to build a product to find out what details you overlooked. That means software is an iterative process. But within each iteration, surely you still need to have the solution — to the extent that it satisfies the known requirements — prepared before you can write code? Maybe if you had an infinite number of monkeys you could have them bang out something that accidentally works by throwing down random keywords, but in the real world where it is only you and your code has to meaningful, what you program is simply the expression of what to program.

Writing code is just means of conveyance, no?

[krackers]

If good writing was easy then "LLM slop writing" wouldn't be a thing.

[9rx]

Not at all. LLM slop exists exactly because writing is easy, but figuring out what to write is hard.

[ozim]

You sound like you would confidently say that you can play chess. Basic moves are easy to learn by very young children.

But if only thing you know are basic moves playing against a player with 1600 ELO you are not going to win without serious training and 1600 is still far below grand master level.

[9rx]

Absolutely. I am quite capable of moving the pieces around a chess board within the confines of the rules. I think you would be hard-pressed to find many who are incapable of that, given exposure to the game. If that isn't easy, what is? I am not all that good at figuring out what moves to make, but that analogs with "what to program", not "programming" as it pertains to the discussion that has been talking place. Nobody has ever suggested "what to program" is easy.

[ozim]

You missed the point.

At some level even if you know basic moves those moves are wrong.

Some things are hard to express in code even if you know exactly what you need to achieve and you know all the basic moves like loops and if statements.

If you know that you have to do a check mate or get amount of points and you know how to do basic moves but you don’t know any openings you are going to loose in 3-5 moves. If you get past openings you might get to 15 moves. If you do easiest greedy approach you loose if you take easiest defensive approach you loose.

It is not „what to program” because in chess you exactly know what is the goal. Getting to that goal alone is hard.

[9rx]

> Some things are hard to express in code even if you know exactly what you need to achieve and you know all the basic moves like loops and if statements.

Like what? Are you, perhaps, confusing "hard" with "time consuming"? Some things take a long time to express in code (absent AI, at least). It's not hard, though. It's just rote copying down what you have already determined "what needs to be programmed". Getting to the point where it is just rote copying can be difficult, but is decidedly in the "what to program" phase.

[manquer]

> Young children seem to pick it up with ease. It cannot be that hard

It is other way around. Children can pick up a lot of skills that adults struggle at, like languages for example.

Plenty of research has shown reduced plasticity of the brain has stronger correlation to learning speed and ability as it grows old. Most breakthrough research is usually at age 40 or less or chess grand-masters fade in skill after. 25-40 is probably age group where the optimal balance between knowledge experience and learning ability for best outcomes.

[mikebenfield]

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

They do? I've known plenty of kids and young adults who utterly failed to become even borderline competent at programming.

[9rx]

They don't? It is taught in schools in the early elementary level. I see no indication that most are failing.

I think we can agree that few of them would be economically useful due to not knowing what to program. There is no sign of competency on that front. Certainly, even the best programmer in the world could theoretically be economically useless. Programmers only become economically useful when they can bridge "what to program".

[wpollock]

> They don't? It is taught in schools in the early elementary level. I see no indication that most are failing.

Programming in elementary schools typically involves moving a turtle around on the screen. (My mother taught 4th grade in New York for many years, and I believe her when she explained the computer instruction.)

Economically valueable programming is much more complex than is taught in many schools through freshman college. (I taught programming at the college level from 1980 till I retired in 2020.)

[9rx]

Because economically valuable programming has to consider what to program, not simply follow the instructions handed down by a teacher of exactly where and how to move a turtle on the screen. But nobody questions "what to program" not being hard. It was explicitly asserted in the very first comment on this topic as being hard and that has also carried in the comments that have followed.

[liquid_thyme]

This is true when fresh college grads are building stuff. Experienced engineers know how to build things much more efficiently.

Also people like to fantasize that their project, their API, their little corner of the codebase is special and requires special treatment. And that you simply cant copy the design of someone much more experienced who has already solved the problem 10 years ago. In fact many devs boast about how they solved (resolved) that complex problem.

In other domains - Professional engineers (non-swe) know that there is no shame in simply copying the design for a bridge that is still standing after all those years.

[travisgriggs]

> All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part.

HARD AGREE. But…

Taken as just such, one might conclude that we should spend less time writing software and more time in design or planning or requirement gathering or spec generating.

What I’ve learned is that the painful process of discovery usually requires a large contribution of doing.

A wise early mentor in my career told me “it usually takes around three times to get it right”. I’ve always taken that as “get failing” and “be willing to burn the disk packs” [https://wiki.c2.com/?BurnTheDiskpacks]

[Sevii]

While it's true that 'figuring out what exactly needs to be programmed' was always the hard part. It's not the part that the most money was spent on. Actually programming the thing always took up the most time and money.

[rossdavidh]

True enough, but I think that a lot of "actually programming the thing" turned out to be "figuring out what exactly needs to be programmed". Afterwards, people did not want to admit that this was the case, perhaps even to themselves, because it seemed like a failure to plan. However, in most (nearly all?) cases, spending more time prior to programming would not have resulted in a better result. Usually, the best way to figure out what needs to be programmed, is to start doing it, and occasionally take a step back to evaluate what you've learned about the problem space and how that changes what you want to actually program.

In other words "figuring out what needs to be programmed" and "actually programming the thing" look the same while they're happening. Afterwards, one could say that the first 90% was figuring out, and only the last 10% was actually doing it. The reason the distinction matters, is that if you do something that makes programming happen faster, but figuring out happen slower, then it can have the surprising affect of making it take longer to get the whole thing done.

[pajtl]

> Usually, the best way to figure out what needs to be programmed, is to start doing it, and occasionally take a step back to evaluate what you've learned about the problem space and how that changes what you want to actually program.

Replace the verb "program" with "do" or anything else, and you've got a profound universal philosophical insight right there

[hectdev]

I'm curious how this would work with LLMs increasing the speed to prototype. Low stakes changes to try something out, learn from it, and pivot.

My company is fully remote so all meetings are virtual and can be set to have transcripts, parsing through that for the changes needed and trying it out can be a simple as copy-paste, plan, verify, execute, and distribute.

[jimbokun]

> Actually programming the thing always took up the most time and money.

I'm curious is any quantitative research has been done comparing time writing code vs time gathering and understanding requirements, documenting, coordinating efforts across developers, design and architecture, etc.

[groundzeros2015]

For whatever reason 1/10 engineers seem to be able to bring an idea from start to finish by themselves. I don’t know that it’s technical skill, but something difficult is going on there.

[jimbokun]

No, that's exactly the topic of the article.

The claim is that most software teams do not consider the financial impact of their work. Is what they are doing producing value that can be measured in dollars and cents and is greater than the cost of their combined cost of employment?

The article suggests that there is a lot of programming being done without considering what exactly needs to be programmed.

[9rx]

> The article suggests that there is a lot of programming being done without considering what exactly needs to be programmed.

And the parent rightfully points out that you cannot know exactly what needs to be programmed until after you've done it and have measured the outcome. We literally call the process development; for good reason. Software is built on hunches and necessarily so. There is an assumption that in the future the cost of the work will pay back in spades, but until you arrive in that future, who knows? Hence why businesses focus on metrics that try to observe progress towards finding out rather than tracking immediate economic payoff.

The interesting takeaway from the article, if you haven't give this topic much thought already, is that the changing financial landscape means that businesses are going to be more hesitant to take those risks. Right now there still seems to be enough optimism in AI payoffs to keep things relatively alive, but if that runs out of steam...

[socalgal2]

> . This may need to be done multiple times. Programming is only occasionally the final product, it is much more often the means of working through what it is that is actually needed.

LLMs make this trivial. I can try 20 different approaches or design ideas in a day. VS manually doing it and it taking much longer.

[highfrequency]

Agreed, but are you also implying that the process of iteratively "programming something that's not it, and then replacing it" multiple times is not in the scope of what LLMs can/will do?

[sarchertech]

Most of the time taken during this process is spent getting feedback, processing it, and learning that it's not it. So even if LLMs drive the build time to zero, they won't speed up the process very much at all. Think 10% improvement not 10x improvement.

[theonething]

I'd even argue LLMs can speed up this iterative process.

[antonvs]

> Figuring out what exactly needs programmed is the hard part.

Making good decisions is the hard part, whether it's about programming or about what needs to be programmed.