[froh]

> The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution.

I intuit this also is an intrinsic limit to LLM based approaches to "you don't need them expensive programmers no more"

with LLMs magically "generating the solution" you move the responsibility for concise expression of the problem up the ladder.

and then you "program" in prompts, reviewing the LLM-proposed formalization ("code").

I other words, the nature of "programming" changes to prompt engineering. alas you still have to understand formal languages (code)...

so there'll always be plenty to do for humans who can "math" :-)

[mmcdermott]

There is a disconnect somewhere. When I read online, I hear about how GenAI/LLMs replace programmers and office workers. When I go to work, I mostly hear the question of how we can apply GenAI/LLMs, apart from discussion of the general buzz.

Maybe this is a reflection of local conditions, I'm not sure, but it doesn't seem like the truly revolutionary changes require the solution to find a problem. It was immediately clear what you could do with assembly line automation, or the motor car, or the printing press.

[eru]

Electricity famously took perhaps twenty years for people to slowly figure out how to re-organise factories around it.. Hence the delayed impact on productivity figures.

To elaborate: in the bad old days of you had one big engine, eg a steam engine, that was driving shafts and belts all around the factory. There was a lot of friction, and this was dangerous. So you had to carefully design your factory around these constraints. That's the era of multi-story factories: you used the third dimension to cram more workstations closer to your prime mover.

With electricity, even if you have to make your own, you just need cables and you can install small electric motors for every task on every workstation. Now your factory layout becomes a lot more flexible, and you can optimise for eg material flow through your factory and for cost. That's when factories becomes mostly sprawling one-story buildings.

I simplify, but figuring all of that out took time.

[conradev]

a quote from Steve Jobs, explaining that the breakthrough invention was the fractional horsepower motor:

"Let’s look at the brief history of computers. Best way to understand it’s probably an analogy. Take the electric motor. The electric motor was first invented in the late 1800s. And when it was first invented, it was only possible to build a very, very large one, which meant that it could only be cost-justified for very large applications. And therefore electric motors did not proliferate very fast at all.

But the next breakthrough was when somebody took one of these large electric motors and they ran a shaft through the middle of a factory and, through a series of belts and pulleys, brought…shared the horsepower of this one large electric motor on 15 or 20 medium-size workstations, thereby allowing one electric motor to be cost-justified on some medium-scale tasks. And electric motors proliferated even further then.

But the real breakthrough was the invention of the fractional-horsepower electric motor. We could then bring the horsepower directly to where it was needed and cost-justified it on a totally individual application. And I think there’s about 55 or so fractional-horsepower motors now in every household."

[mmcdermott]

Adoption takes time, for sure, especially when dealing with fixed assets like a factory. The difference I'm poking at is that electricity had a clear value proposition and improved over time. I see people looking for the value proposition in GenAI/LLMs, which brings me to the original question.

If GenAI now was like early electricity, we would know what we wanted to use it for, even if we weren't there yet. That isn't what it looks like to me, but I'd be curious to know if that's just where I'm sitting, metaphorically speaking.

Every company I have worked for had more work than hands for programming and other knowledge work. Capacity is valuable. Does anyone here see GenAI teams being spun up for "management" by a human? Or do we see fancy Google search / code completion?

[eru]

> Adoption takes time, for sure, especially when dealing with fixed assets like a factory.

I was talking about the need to re-imagine and re-organise how factories work, not about the physical factories themselves. So it's more like a 'software' problem.

> Does anyone here see GenAI teams being spun up for "management" by a human? Or do we see fancy Google search / code completion?

How would the two cases look different? If you have a human worker that uses GenAI to help her complete tasks (via something like fancy auto-completion of text, code etc) that previously took a whole human team, that's exactly how you would 'spin up a team of GenAI for management by a human' would look like, wouldn't it?

It's just our framing that's different, and perhaps who that human is: you take someone who's familiar with the actual work and give her the tools to be faster, instead of taking someone who's more familiar with the meta-level work of managing humans.

I suspect that's because managing humans is a rather specialised skill in the grand scheme of things, and one that doesn't help much with telling GenAI what to do. (And, human managers are more expensive per hour than individual contributors.)

---

In any case, I agree that GenAI at the moment is still too immature to be trusted with much on its own. I hope more globally optimising AI like AlphaGo etc comes back in style, instead of essentially 'greedy' contemporary GenAI that just produces one token after another.

[mmcdermott]

What I'm picturing is two divergent paths with very different impacts on human interaction.

1) Every human programmer becomes the surgeon in Fred Brooks's surgical team model (https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur...) and AI provides the rest. In effect, all working human programmers are software architects in the sense that they exist in large companies. The unstated assumption here is that going from vague user input to a solution is roughly equivalent to AGI, and so is further out than anything on the immediate horizon.

2) GenAI is used as a sort of advanced template/snippet/autocomplete system.

The first one is a fundamental paradigm shift. Professional programmers don't cease to exist, but the profession becomes inherently smaller and more elite. The bar is higher and there isn't room for many perfectly intelligent people who work in the field today.

The second one is a force multiplier and is helpful, but is also a much more banal economic question, namely whether the tool generates enough value to justify the cost.

I have no complaint either way and I'm definitely interested in the next step beyond what we've seen so far. The hype implies that the first branch above is where everything is headed, hence the "death of programming as a profession" type articles that seem to be making the rounds, but that isn't what I've seen day-to-day, which is what prompted the original thought.

[jerf]

I think it's a lot of little things. There's a lot of people very motivated to keep presenting not just AI in general, but the AI we have in hand right now as the next big thing. We've got literally trillions of dollars of wealth tied up in that being maintained right now. It's a great news article to get eyeballs in an attention economy. The prospect of the monetary savings has the asset-owning class salivating.

But I think a more subtle, harder-to-see aspect, that may well be bigger than all those forces, is a general underestimation of how often the problem is knowing what to do rather than how. "How" factors in, certainly, in various complicated ways. But "what" is the complicated thing.

And I suspect that's what will actually gas out this current AI binge. It isn't just that they don't know "what"... it's that they can in many cases make it harder to learn "what" because the user is so busy with "how". That classic movie quote "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should" may take on a new dimension of meaning in an AI era. You were so concerned with how to do the task and letting the computer do all the thinking you didn't consider whether that's what you should be doing at all.

Also, I'm sure a lot of people will read this as me claiming AI can't learn what to do. Actually, no, I don't claim that. I'm talking about the humans here. Even if AI can get better at "what", if humans get too used to not thinking about it and don't even use the AI tool properly, AI is a long way from being able to fill in that deficit.

[adamc]

Not to mention someone would need to evaluate and test the proposed solution... which with today's LLMs I would not bet heavily on its correctness.

This is some years ago, but a friend of mine, trained in a 4GL that was still a procedural programming language, went somewhere that was using a higher level, model-based generation of code based on that language. It turned out they still needed a few people who understood how things worked beneath the hood.

I am deeply skeptical that human-language level specifications will ever capture all the things that really need to be said for programming, any more than they do for mathematics. There are reasons for formalisms. English is slippery.

[devjab]

This is only true to an extend. We have a lot of digitally inclined workers who’re developing programs or scripts to handle a lot of things for them. It’s imperfect and often wildly insecure and inefficient, but unlike any previous no-code or “standard” solution it actually works. Often in conjunction with “standard” solutions.

On one hand you’re correct in that there will always be a need for programmers. I really doubt there will be a great need for generalist programmers though. The one area that may survive is the people who’re capable of transforming business needs and rules into code. Which requires a social and analytical skillset for cooperating with non tech people. You’ll also see a demand for skilled programmers at scale and for embedded programming, but the giant work force of generalist developers (and probably web developers once Figma and similar lets designers generate better code) is likely going to become much smaller in the coming decades.

Then is basically what the entire office workforce is facing. AI believers have been saying AI would do to the office what robots did to the assembly line for years, but now it actually seems like they’re going to be correct.

[stroupwaffle]

Another parallel is type foundries and printing presses. At one point people operated these linotype machines which used molten lead. Of course this transitioned to photo typesetting which, to the dismay of everyone had poor results. Along came Donald Knuth and TeX to fix those deficiencies. NOTE: mechanical printing has a profoundly better result no matter what. It is the ink and the impression in paper that makes it superior (for letterforms and such).

So, if AI follows suit, we will witness the dumb (but very knowledgeable) AI start to supplant workers with questionable results; and then someone (or a team) will make a discovery to take it to the limit and it’ll be game over for large swaths of jobs.

https://en.m.wikipedia.org/wiki/Hot_metal_typesetting

[Animats]

TeX was predated by a family of macro-based document languages that began with RUNOFF and continued through roff, nroff, troff, ditroff, and groff. Plus tbl, eqn, and mm*. Some manual pages still use that stuff. Most Linux systems still install it by default. TeX has roughly the same concept, a macro-based layout language, but a better design with far less cruft.

[jasfi]

A lot of business people want to get something functional that they can sell, and hire a programmer if/when they can afford one. That niche is seeing a lot of uptake with regards to LLM based approaches.

This works for them because an MVP typically isn't a lot of code for what they need, and LLMs have a limited scope within which they can generate something that works.

[immibis]

In fact we've been using programming LLMs for a long time, which we call compilers.

[mannykannot]

The acronym LLM stands for what is now a term of art for a class of information- processing systems which are produced by, and themselves produce their output by, methods very unlike those for compilers. This is just as well, considering the consequences that would follow from compilers routinely hallucinating.