None of the "code generation" stuff is new by the way.
-
@jg This is a good argument—as a silver lining it may force programmers into systems thinking and learn about systems design instead of just blindly hacking on low-level stuff.
Otoh without knowing low-level stuff inside-out you can’t do higher level thinking properly.
I wonder how many programmers actually have the discipline to do this properly.
@thomasfuchs The devs Ive worked with who think in systems never had to be forced. I think it's more about identity than discipline. Some people see themselves as "i write code" and some see themselves as "I solve problems". The first group will struggle with systems thinking regardless of skill level. The second group has been waiting for it.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs also see “No silver bullet” by Fred Brooks https://en.wikipedia.org/wiki/No_Silver_Bullet#Brooks1986, https://www.cs.unc.edu/techreports/86-020.pdf
-
@thomasfuchs I generally agree with you, but I don't think I ever expected to see OOP framed as a tool for the suits to get us to work faster.
@ted Even a broken clock is right twice a day ¯\_(ツ)_/¯
-
this is spot on. I've watched companies spend millions on 'AI solutions' that are just fancy wrappers around APIs anyone can call. The real value is in the data moat and workflow integration, not the model itself
@SergiuDinIT What I have yet to see is a discussion of agents’ reliance on schema-less, non-deterministic api (not sure how else to describe natural-language based prompts), which is an even bigger problem when a single request involves orchestrating multiple agents. With these type of interfaces it is hard to do testing (esp. considering variability intrinsic to this type of “api”), hard to detect failures, and the responsibility/accountability for resulting errors is diffused; with most of the risk is shifted to whoever is being subjected to the output of such a system (I have a story about such a system being developed by a medical claim processor).
-
@thomasfuchs this is one of the things that pissed me off about the Paul Ford op-ed. Like, he wants software dev to be so easy that it takes no effort. But even if that were to be possible, the amount of shit that would be produced would be exponentially worse.
All these people think that making all the difficult things easy will automatically elevate everything, but that’s not really the main and foremost thing happening with AI and they’re turning a blind eye on so much bad stuff.
@990000 correct
-
@thomasfuchs What is new is that it suddenly started working.
@jacobgorm I bet you that e.g. Visual Basic in the 1990s was a much bigger improvement on time spent coding apps than any AI agents are today.
My point isn't that it "works" (or doesn't); my point is that it is largely irrelevant because writing code isn't the bottleneck when making software.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs Its like everyone forgot what they learned in "Introduction to software engineering" We all at least took that class didn't we?
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs Yep. I have made that point as well. My father worked with one such years ago for COBOL.We are furiously agreeing.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs "all you have to do is meticulously and accurately describe 100% of your requirements and restrictions"
Sure, seems great Jan.
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs Where are all the one-person companies selling amazing new products? Why don't the LLM companies use their own product to put everyone else out of business? It's because they would rather sell the shovels than try to mine themselves of course.
-
@thomasfuchs Where are all the one-person companies selling amazing new products? Why don't the LLM companies use their own product to put everyone else out of business? It's because they would rather sell the shovels than try to mine themselves of course.
@skotchygut the only difference with the gold rush is that they’re giving away shovels for free that are paid for by the investors they’re defrauding
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
-
None of the "code generation" stuff is new by the way.
The tech industry has tried to speed up coding and increase software output for the last 3 to 4 decades, by various means; e.g. Rapid Application Development, Expert Systems, Object-Oriented Programming, thousands of different frameworks all the way to trying to off-shore development and exploit third-world labor.
The problem with this is: there is no software scarcity. Pretending that "we can't make software fast enough" is a red herring to hide the fact that making (good) software is 90% painstaking research, design, planning, marketing and talking to and supporting customers.
And 10% writing the actual code—the C-suite is doing ye olde "trying to find a technical solution to a social problem".
@thomasfuchs this is true and it bothers me so much that people keep talking as if we haven't been trying to "generate" code since the invention of c
-
@thomasfuchs @dymaxion The other 90% is configuration where to be fair LLMs are useful quite regularly.
-
@thomasfuchs "all you have to do is meticulously and accurately describe 100% of your requirements and restrictions"
Sure, seems great Jan.
@petrillic @thomasfuchs in a language like English which is open to misinterpretation. Writing a complete and unambiguous spec in English is just as time consuming as writing working code. I see philosophy logic courses becoming required learning for future ‘ai developers’
-
@grepe Yeah, though those specific people are probably already prone to believe in magical thinking (more prone to everything spanning from being religious to pseudo-science to racism; not saying they believe in any of this, just that they're more susceptible to it).
@thomasfuchs actually - no. i understand where that assumption comes from but it is very wrong. in my case one of them is a professor on renowned university doing academic research. and, surprisingly, being prone to believing pseudoscience, being religious or racist is not connected in my experience... this is anecdotal but i've known medical doctors who were into homeopathy (former flat mate), religious astrophysicists (colleague), racist atheists (class mates) and very rational and inclusive priests (jesuit)...
-
@thomasfuchs actually - no. i understand where that assumption comes from but it is very wrong. in my case one of them is a professor on renowned university doing academic research. and, surprisingly, being prone to believing pseudoscience, being religious or racist is not connected in my experience... this is anecdotal but i've known medical doctors who were into homeopathy (former flat mate), religious astrophysicists (colleague), racist atheists (class mates) and very rational and inclusive priests (jesuit)...
@grepe intelligence and wisdom in a specific field does not automatically extend to other fields ¯\_(ツ)_/¯
People with thorough systems and rational thinking are relatively rare.
This might be an evolutionary thing as much as cultural/educational.
-
@thomasfuchs "all you have to do is meticulously and accurately describe 100% of your requirements and restrictions"
Sure, seems great Jan.
@petrillic @thomasfuchs This. As someone who took at least two courses that delved deep into requirements and iteration of said requirements in undergrad, and then having to work with requirements constantly at work, it blows my mind how there's people that feign that what they do is engineering, that claim that requirements are an easy task for LLMs.
No they're not, and they probably have cognitive dissonance so huge that they can never be good at engineering.
-
The gist of this is that _even if code-generating LLMs work perfectly_, it doesn't have that much of an impact on how good the software works for people; which in turn means it won't matter for profits.
@thomasfuchs
Oh, it's even worse than that: modifying, correcting issues, maintaining in general is perhaps 95% of the time.So overall, the LLM can save you 5% on 10% . If it works. Which it doesn't.
