7 ms·

If somebody thinks an LLM is coming for everybody's coding job, I'd say this article is a great counterpoint just for existing. You could tell someone from dec

If somebody thinks an LLM is coming for everybody's coding job, I'd say this article is a great counterpoint just for existing. You could tell someone from decades ago that we now use a very high level language for complex tasks in complex code ecosystems, never even mention AI, explain that the parser is really generalist-biased, and this article would make perfect sense as an example of exemplary code by a modern coder working for a living. That's code in there, the stuff Xu Hao is writing. And also, that's not even getting into the debugging part... Which will be about other code, that looks different.

twelve40 3y ago
Exactly, I actually liked the systematic approach in the article, but it seemed pretty labor-intensive and ... not that much different from other types of programming
- sanderjd 3y ago
  To me, that's the whole point of this. I think it is directly analogous to the jump between assembly and higher level compiled languages. You could have said about that, "it still seems pretty labor intensive and not that much different than writing assembly", and that's true, but it was still a big improvement. Similarly, AI-assisted tools haven't solved the "creating software requires work" problem. But I think they're in the process of further shifting the cost curve, making more software possible to make.
nextworddev 3y ago
The opposite might be true, and here’s why - 1) by using English as spec, the barrier of entry has gone lower, 2) LLMs can also write prompts and self introspect to debug.
- notacoward 3y ago
  > LLMs can also write prompts and self introspect to debug. Why should we assume that won't lead to a rabbit hole of misunderstanding or outright hallucination? If it doesn't know what "correct" really is, even infinite levels of supervision and reinforcement might still be toward an incorrect goal.
  - ben_w 3y ago
    To which the normal response[0] is: that's just like humans. Of course, it's still bad that humans do it; but despite the scientific method etc., even successful humans often work towards an incorrect goal. [0] I am cultured, you're quoting memes, that AI is just a stochastic parrot: https://en.wikipedia.org/wiki/Emotive_conjugation https://en.wikipedia.org/wiki/Emotive_conjugation
    - notacoward 3y ago
      But it's not just like humans. For one thing it's built differently, with a different relationship between training and execution. It doesn't learn from its mistakes until it gets the equivalent of a brain transplant, and in fact extant AIs are notorious for doubling down instead of accepting correction. Even more importantly, the AI doesn't have real-world context, which is often helpful to notice when "correct" (to the spec) behavior is not useful, acceptable, or even safe in practice. This is why the idea of an AI controlling a physical system is so terrifying. Whatever requirement the prompter forgot to include will not be recognized by the AI either, whereas a human who knows about physical properties like mass or velocity or rigidity will intuitively honor requirements related to those. Adding layers is as likely to magnify errors as to correct them.
      - ben_w 3y ago
        > But it's not just like humans. For one thing it's built differently I'm referring to the behaviour, not the inner nature. > in fact extant AIs are notorious for doubling down instead of accepting correction. My experience suggests ChatGPT is better than, say, humans on Twitter. I've had the misfortune of several IRL humans who were also much, much worse; but the problem was much rarer outside social media. > Even more importantly, the AI doesn't have real-world context, which is often helpful to notice when "correct" (to the spec) behavior is not useful, acceptable, or even safe in practice. Absolutely a problem. Not only for AI, though. When I was a kid, my mum had a kneeling stool she couldn't use, because the woodworker she'd asked to reinforce it didn't understand it and put a rod where your legs should go. I've made the mistake of trying to use RegEx for what I thought was a limited-by-the-server subset of HTML, despite the infamous StackOverflow post, because I incorrectly thought it didn't apply to the situation. There's an ongoing two-way "real-world context" miss-match between those who want the state to be able to pierce encryption and those who consider that to be an existential threat to all digital services. > a human who knows about physical properties like mass or velocity or rigidity will intuitively honor requirements related to those Yeah, kinda, but also no. We can intuit within the range of our experience, but we had to invent counter-intuitive maths to make most of our modern technological wonders. -- All that said, with this: > It doesn't learn from its mistakes until it gets the equivalent of a brain transplant You've boosted my optimism that an ASI probably won't succeed if it decided it preferred our atoms to be rearranged to our detriments.
- mooreds 3y ago
  > by using English as spec, the barrier of entry has gone lower, I'm not sure that is true. The level of back and forth and refinements needed indicate to me that the "English" used is not the normal language I use when talking to people. It's almost like a refined version of cucumber with syntax that is slightly more forgiving. Maybe I'm being a codger, but LLMs seem (at least for now) far better for summarizing and giving high level overviews of concepts rather than nailing precise code requirements.
  - ben_w 3y ago
    > It's almost like a refined version of cucumber with syntax that is slightly more forgiving. I don't know if "cucumber" is autocorrupt or an actual non-vegetable thing; can you clarify?
    - omnicognate 3y ago
      https://cucumber.io/ https://cucumber.io/ That "did they actually mean that or was it autowrong?" feeling is going to get worse I fear.
    - mjr00 3y ago
      Not a typo.[0] In the 00s/early 10s, software went through a fad phase where people earnestly thought that by implementing Gherkin frameworks like Cucumber, you'd be able to hand off writing tests to "business people" in "plain English." It went about as well as you'd expect. [0] https://cucumber.io/docs/gherkin/ https://cucumber.io/docs/gherkin/
      - ben_w 3y ago
        Thanks! Despite that period being when I finished my Software Engineering degree, got my first job, and then attempted self-employment, I'd never heard of it before. Looking at the book titles — "Cucumber Recipes" in particular — even if I had encountered it, I might have assumed the whole thing was a joke.
      - Tainnor 3y ago
- ZephyrBlu 3y ago
  I think English as a spec actually makes the barrier of entry higher, not lower. Code itself is far easier to understand than an English description of the code. To understand an English description of code you already have to have a deeper understanding of what the code is doing. For code itself you can reference the syntax to understand what's going on. The prompt in this case is using very technical language that a beginner will have no idea about. But if you gave them the code they could at least struggle along and figure it out by looking things up.
  - deleted 3y ago
    [deleted]
  - lcnPylGDnU4H9OF 3y ago
    This reminds me of rubber ducking[0] in how it necessitates a certain understanding. If one is able to explain it in plain English it's because it is understood. [0] https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
  - nextworddev 3y ago
    Yes but LLMs can also be used by laypeople to explain the issue in plain English too. That’s the problem. Not that LLMs would need human to guide the debugging process anyways (at least in a few years)
    - ZephyrBlu 3y ago
      You still have the same problem... You cannot describe a technical field with plain English. If you did so the semantics would be incorrect. There is a reason jargon exists. The first two paragraphs alone are absolutely chock with terms that would not be easily explained to a layperson: "The current system is an online whiteboard system. Tech stack: typescript, react, redux, konvajs and react-konva. And vitest, react testing library for model, view model and related hooks, cypress component tests for view. All codes should be written in the tech stack mentioned above. Requirements should be implemented as react components in the MVVM architecture pattern." What is every library in that list? What is a model? What is a view model? What is a hook, component test, view, MVVM, etc? If a layperson could understand explanations for all these things then they would not be a layperson.
- gumballindie 3y ago
  I mean sure if the world were to run on basic code. Perhaps wordpress developers may feel slightly threatened by even that is well above all examples of a"i" code i've seen.
- agentultra 3y ago
  But you can't determine if a statement is true by simply reading more words. It's also not efficient for doing higher level work. There was a time before we had algebra where people were still expressing the same ideas but the notation wasn't there. Mathematics was expressed in "plain language." It's extremely difficult to read for us. For mathematician's of the time there was no other way to explain algorithms or expressions. For simple programs I have no doubt that these tools enable more people to generate code. However it's not going to be helpful for people working on hypervisors, networking stacks, operating systems, distributed databases, cryptography, and the like yet. For that you need a more precise language and an LLM that can reason about semantics and generate understandable proofs: not boilerplate proofs either -- they have to be elegant so that a human reading them can understand the problem as well. We're still a ways from being able to do that.
  - nextworddev 3y ago
    Arguably reading code can’t lead to definitive conclusions about its bug-free-ness
    - agentultra 3y ago
      Precisely! And neither can generating a handful of unit tests. As EWD would say, they only prove the existence of one error. Not that there are no errors. If we want more programs that are correct with respect to their specifications we need to write better, precise specifications… not wave our hands around. However for a lot of line-of-business tasks we’re generally fine with ambiguous, informal specifications. We’re not certain our programs are correct with respect to the specifications, if we had written them out formally, but it’s good enough. I think most businesses that are writing software that needs to be reliable and precise are not going to benefit from these kinds of tools for some time.
      - tjr 3y ago
        This is true in aerospace software. Lots of process, lots of specification, lots of verification. I wouldn't want to say that GPT-seque tools would be useless here, but I really don't see them offering the same kind of magic leverage that they might offer on some other projects. And vice-versa! Most software projects do not benefit from the rigor used in aerospace, because it's just not needed, and would be a waste of time. I am definitely seeing ways that GPT tools could speed up some aerospace work, but we need to be really really sure that things are being done correctly... not just mostly correct, or seemingly correct.
- have_faith 3y ago
  English as a spec is incredibly "fuzzy", there are many valid interpretations of intent. I don't think that can be avoided?
  - sarchertech 3y ago
    It can't. Legalese is an attempt to do so, and it's impenetrable by non experts and still frequently ambiguous.
- bartimus 3y ago
  But there's still going to have to be a human who has the ability to form a mental model of the thing that's needing to be implemented. Functionally and technically. The results of the LLM will vary depending on the level of know-how the human instructor has.
SanderNL 3y ago
Except you now have a way “upwards” from an abstraction POV. Regular code is severely limited and highly surgical, by design. This is not. All these abstraction layers were invented to serve old style manual coders. Why bother explaining in great detail about “Konva” layers and react anymore? Give it a few years and let it finetune on IT tech and I see this being reduced to “I want whiteboard app with X general characteristics” at which point I’d no longer speak about “programming”.
- themodelplumber 3y ago
  That "upwards" excludes a lot of relevant systems design logic that won't go away though, insofar as it is abstraction ad infinitum in the direction of fewer-relevant-details. What'll happen is, details will continue to be relevant as tastes adjust to the new normal. Like for my work, today, React is enterprise-ready, which is not good for me. It means it will likely dip my projects in unnecessary maintenance costs as compared to another widget of its type that does what I want in a lightweight manner. When I troubleshoot something of React's complexity, even my prompts will likely need to be longer. But also, that's just one component of one component. And you have to experience this stuff in the first place, to know that you should pay attention to these details and not those other ones, for a given job, for a given client, in a given industry, with given specs. So, if I was able to wave my hands I'd simply have all the problems I had back when I was a beginner. Ergo, it comes back to the clip art problem: Being able to buy clip art never made anyone a designer. But it made a lot of designers' jobs way easier. We are simply regressing toward the mean with regard to programming. It was never about computers in the first place, never so concerned with syntax. Anyway, back to browsing my theater program...
  - SanderNL 3y ago
    Fair enough, but don’t we abstract “upwards” all the time? Assembly won’t go away, but do you deal with it?
    - themodelplumber 3y ago
      For one, assembly ceases to be a relevant detail and is replaced by other relevant details. So, I can't code fast games in a 1984 workplace, currently, being too out of touch with assembly on a given chipset. But I also can't wave my hands at an LLM and expect a modern, fast game of the desired quality to code itself. (Even though a clip art-style result is possible, the requirements are always going to be special details) The upwards direction example is also interesting because it's foundational to the cognitive functionality of one of the Jungian personality types. But other personality perspectives also apply to coding, which means in part that the directional, metaphorical-abstraction view can effectively be a blind spot if we map it as the preferred view on outcomes. The most common blind spot for this personality involves questions of relevant details, and their intersection with planning for yet-unknowns. There is a tendency to hand-wave which ends up being similar to prophetic behavior. Jung called this the "voice in the wilderness" noting that it can easily detach from sensibility (rationality) by departing from life details. Kind of interesting stuff. (Ni-dominant type)
notacoward 3y ago
The problem is that it's not quite code. It's almost code, but without the precision, which puts it into a sort of Uncanny Valley of code-ness. It's detailed instructions for someone to write code, but the someone in this case is an alien or insane or on drugs so they might interpret it the way you meant it or they might go off on some weird tangent. You never know, and that means you'll need to check it with almost as much care as you'd take writing it. Also, having it write its own tests doesn't mean those tests will themselves be correct let alone complete. This is a problem we already have with humans, because any blind spot they had while writing the code will still be present for writing the tests. Who hasn't found a bug in tests, leading to acceptance of broken code and/or rejection of correct alternatives? There's no reason to believe this problem won't also exist with an AI, and they have more blind spots to begin with.
- elendee 3y ago
  I think often of the adage "it's harder to read code than write it". GPT gives you a lot to read. definitely a better consultant than coder imo. I've also had GPT write entirely false things, then I say "isn't that false?" and it says, "yes sorry about that" . very uncanny
  - fijiaarone 3y ago
    And the code that GPT does write, if it is even close to correct, must be code that exists in many places already, and usually (like the case of so much react code) doesn’t need to exist at all.
Veedrac 3y ago
‘Artists' jobs are safe because AI is bad at hands.’
- themodelplumber 3y ago
  Artists' jobs are safe in part because they can also use AI, and most already use relevant ecosystems that now incorporate AI. Consumers who can operate AI for clip art purposes are simply still part of the same non-artist-paying demographic they always were. Same with code
  - Veedrac 3y ago
    As farmers' jobs were safe because farmers can use farming tools. These arguments don't track even vaguely. You are doing the equivalent of analyzing the future of solar power by assuming solar will cost the same in 10 years as it does today, and that each new watt of solar is matched 1:1 with new units of demand. Neither of these are sensible. It may be that ML code tools never displace many people, or even that they supercharge demand, but you don't get to justified conclusions by assuming the future is just the present but with a bigger UNIX timestamp.
    - all2 3y ago
      Industrialization has made farming tools incredibly complex, so I believe the statement "farmers' jobs were safe because farmers can use farming tools" is correct. You still need a farmer to farm, but you now need less manpower to farm. The specialist is secure while the untrained laborer is at risk.
      - fijiaarone 3y ago
        And yet, despite there being more complex machinery in farming there is also much more untrained labor. People just don’t notice it because the untrained labor (millions of people) that plant and harvest are an underclass that does not speak their language or associate with them.
  - 3y ago
wpietri 3y ago
Yeah, I think there's a "stone soup" effect going on with AI. It's the same sort of thing you see happening with the customers of psychics. People often have poor awareness of how much they're putting in to a conversation. Or it's a bit like the way Tom Sawyer tricks other kids into painting the fence for him. For me a lot of the magic here is in knowing what questions to ask and when the answers aren't right. If you have those skills, is pounding out the code that hard? The interesting part for me is not generating new bits of code, but the long-term maintenance of a whole thing. A while back there was a fashion for coding "wizards", things that would ask some questions and then generate code for you. People were very excited, as they saw it as lowering the barrier to entry. But the fashion died out because it just pushed all the problems a bit further down the road. Now you had novice developers trying to understand and improve code they weren't competent to write. I suspect that in practice, anything a person can get a LLM to wholly write is also something that could be turned into a library or framework or service or no-code tool that they can just use. That, basically, if the novelty is low enough that an LLM can produce it, the novelty is low enough that there are better options than writing the code from scratch over and over.
- harlanlewis 3y ago
  Great points (and after checking your user name, I’ve been nodding my head to posts of yours for about a decade now). This is a bot tangential - your reference to stone soup is a wonderful example of the information density possible with natural language. And all the meaning and story behind the phrase is accessible to LLMs. I’ll have to start experimenting with idiom driven development, especially when prompt golfing.
- baq 3y ago
  I mostly agree except one critical detail: LLMs are the low code/no code service. You literally tell them what you want and if they’re fine tuned on the problem domain, you’re all set. Microsoft demo’d the office 365 integration and if it works half as well in practice they’ll own the space as much as they have in 1997.
  - wpietri 3y ago
karmasimida 3y ago
I was thinking that draft of the master plan ... you can't really just write it up this clear and easy. Overall, I don't think a 95% auto pilot GPT model would provide more efficiency than a 80% one.
thomaslord 3y ago
Yeah, even if ChatGPT could perfectly understand the prompts you'd still run into major issues with token limits. I tried to get it to rebuild a single page for me (to move from one UI framework to another) and I couldn't fit the existing code in the token limit. I might be able to get it to do a chunk of the initial work for a greenfield project if I perfected the prompts, but it's structurally incapable of maintaining existing code.

twelve40 3y ago

Exactly, I actually liked the systematic approach in the article, but it seemed pretty labor-intensive and ... not that much different from other types of programming

sanderjd 3y ago
To me, that's the whole point of this. I think it is directly analogous to the jump between assembly and higher level compiled languages. You could have said about that, "it still seems pretty labor intensive and not that much different than writing assembly", and that's true, but it was still a big improvement. Similarly, AI-assisted tools haven't solved the "creating software requires work" problem. But I think they're in the process of further shifting the cost curve, making more software possible to make.

nextworddev 3y ago

The opposite might be true, and here’s why - 1) by using English as spec, the barrier of entry has gone lower, 2) LLMs can also write prompts and self introspect to debug.

notacoward 3y ago
> LLMs can also write prompts and self introspect to debug. Why should we assume that won't lead to a rabbit hole of misunderstanding or outright hallucination? If it doesn't know what "correct" really is, even infinite levels of supervision and reinforcement might still be toward an incorrect goal.
- ben_w 3y ago
  To which the normal response[0] is: that's just like humans. Of course, it's still bad that humans do it; but despite the scientific method etc., even successful humans often work towards an incorrect goal. [0] I am cultured, you're quoting memes, that AI is just a stochastic parrot: https://en.wikipedia.org/wiki/Emotive_conjugation https://en.wikipedia.org/wiki/Emotive_conjugation
  - notacoward 3y ago
    But it's not just like humans. For one thing it's built differently, with a different relationship between training and execution. It doesn't learn from its mistakes until it gets the equivalent of a brain transplant, and in fact extant AIs are notorious for doubling down instead of accepting correction. Even more importantly, the AI doesn't have real-world context, which is often helpful to notice when "correct" (to the spec) behavior is not useful, acceptable, or even safe in practice. This is why the idea of an AI controlling a physical system is so terrifying. Whatever requirement the prompter forgot to include will not be recognized by the AI either, whereas a human who knows about physical properties like mass or velocity or rigidity will intuitively honor requirements related to those. Adding layers is as likely to magnify errors as to correct them.
    - ben_w 3y ago
      > But it's not just like humans. For one thing it's built differently I'm referring to the behaviour, not the inner nature. > in fact extant AIs are notorious for doubling down instead of accepting correction. My experience suggests ChatGPT is better than, say, humans on Twitter. I've had the misfortune of several IRL humans who were also much, much worse; but the problem was much rarer outside social media. > Even more importantly, the AI doesn't have real-world context, which is often helpful to notice when "correct" (to the spec) behavior is not useful, acceptable, or even safe in practice. Absolutely a problem. Not only for AI, though. When I was a kid, my mum had a kneeling stool she couldn't use, because the woodworker she'd asked to reinforce it didn't understand it and put a rod where your legs should go. I've made the mistake of trying to use RegEx for what I thought was a limited-by-the-server subset of HTML, despite the infamous StackOverflow post, because I incorrectly thought it didn't apply to the situation. There's an ongoing two-way "real-world context" miss-match between those who want the state to be able to pierce encryption and those who consider that to be an existential threat to all digital services. > a human who knows about physical properties like mass or velocity or rigidity will intuitively honor requirements related to those Yeah, kinda, but also no. We can intuit within the range of our experience, but we had to invent counter-intuitive maths to make most of our modern technological wonders. -- All that said, with this: > It doesn't learn from its mistakes until it gets the equivalent of a brain transplant You've boosted my optimism that an ASI probably won't succeed if it decided it preferred our atoms to be rearranged to our detriments.
mooreds 3y ago
> by using English as spec, the barrier of entry has gone lower, I'm not sure that is true. The level of back and forth and refinements needed indicate to me that the "English" used is not the normal language I use when talking to people. It's almost like a refined version of cucumber with syntax that is slightly more forgiving. Maybe I'm being a codger, but LLMs seem (at least for now) far better for summarizing and giving high level overviews of concepts rather than nailing precise code requirements.
- ben_w 3y ago
  > It's almost like a refined version of cucumber with syntax that is slightly more forgiving. I don't know if "cucumber" is autocorrupt or an actual non-vegetable thing; can you clarify?
  - omnicognate 3y ago
    https://cucumber.io/ https://cucumber.io/ That "did they actually mean that or was it autowrong?" feeling is going to get worse I fear.
  - mjr00 3y ago
    Not a typo.[0] In the 00s/early 10s, software went through a fad phase where people earnestly thought that by implementing Gherkin frameworks like Cucumber, you'd be able to hand off writing tests to "business people" in "plain English." It went about as well as you'd expect. [0] https://cucumber.io/docs/gherkin/ https://cucumber.io/docs/gherkin/
    - ben_w 3y ago
      Thanks! Despite that period being when I finished my Software Engineering degree, got my first job, and then attempted self-employment, I'd never heard of it before. Looking at the book titles — "Cucumber Recipes" in particular — even if I had encountered it, I might have assumed the whole thing was a joke.
    - Tainnor 3y ago
ZephyrBlu 3y ago
I think English as a spec actually makes the barrier of entry higher, not lower. Code itself is far easier to understand than an English description of the code. To understand an English description of code you already have to have a deeper understanding of what the code is doing. For code itself you can reference the syntax to understand what's going on. The prompt in this case is using very technical language that a beginner will have no idea about. But if you gave them the code they could at least struggle along and figure it out by looking things up.
- deleted 3y ago
  [deleted]
- lcnPylGDnU4H9OF 3y ago
  This reminds me of rubber ducking[0] in how it necessitates a certain understanding. If one is able to explain it in plain English it's because it is understood. [0] https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
- nextworddev 3y ago
  Yes but LLMs can also be used by laypeople to explain the issue in plain English too. That’s the problem. Not that LLMs would need human to guide the debugging process anyways (at least in a few years)
  - ZephyrBlu 3y ago
    You still have the same problem... You cannot describe a technical field with plain English. If you did so the semantics would be incorrect. There is a reason jargon exists. The first two paragraphs alone are absolutely chock with terms that would not be easily explained to a layperson: "The current system is an online whiteboard system. Tech stack: typescript, react, redux, konvajs and react-konva. And vitest, react testing library for model, view model and related hooks, cypress component tests for view. All codes should be written in the tech stack mentioned above. Requirements should be implemented as react components in the MVVM architecture pattern." What is every library in that list? What is a model? What is a view model? What is a hook, component test, view, MVVM, etc? If a layperson could understand explanations for all these things then they would not be a layperson.
gumballindie 3y ago
I mean sure if the world were to run on basic code. Perhaps wordpress developers may feel slightly threatened by even that is well above all examples of a"i" code i've seen.
agentultra 3y ago
But you can't determine if a statement is true by simply reading more words. It's also not efficient for doing higher level work. There was a time before we had algebra where people were still expressing the same ideas but the notation wasn't there. Mathematics was expressed in "plain language." It's extremely difficult to read for us. For mathematician's of the time there was no other way to explain algorithms or expressions. For simple programs I have no doubt that these tools enable more people to generate code. However it's not going to be helpful for people working on hypervisors, networking stacks, operating systems, distributed databases, cryptography, and the like yet. For that you need a more precise language and an LLM that can reason about semantics and generate understandable proofs: not boilerplate proofs either -- they have to be elegant so that a human reading them can understand the problem as well. We're still a ways from being able to do that.
- nextworddev 3y ago
  Arguably reading code can’t lead to definitive conclusions about its bug-free-ness
  - agentultra 3y ago
    Precisely! And neither can generating a handful of unit tests. As EWD would say, they only prove the existence of one error. Not that there are no errors. If we want more programs that are correct with respect to their specifications we need to write better, precise specifications… not wave our hands around. However for a lot of line-of-business tasks we’re generally fine with ambiguous, informal specifications. We’re not certain our programs are correct with respect to the specifications, if we had written them out formally, but it’s good enough. I think most businesses that are writing software that needs to be reliable and precise are not going to benefit from these kinds of tools for some time.
    - tjr 3y ago
      This is true in aerospace software. Lots of process, lots of specification, lots of verification. I wouldn't want to say that GPT-seque tools would be useless here, but I really don't see them offering the same kind of magic leverage that they might offer on some other projects. And vice-versa! Most software projects do not benefit from the rigor used in aerospace, because it's just not needed, and would be a waste of time. I am definitely seeing ways that GPT tools could speed up some aerospace work, but we need to be really really sure that things are being done correctly... not just mostly correct, or seemingly correct.
have_faith 3y ago
English as a spec is incredibly "fuzzy", there are many valid interpretations of intent. I don't think that can be avoided?
- sarchertech 3y ago
  It can't. Legalese is an attempt to do so, and it's impenetrable by non experts and still frequently ambiguous.
bartimus 3y ago
But there's still going to have to be a human who has the ability to form a mental model of the thing that's needing to be implemented. Functionally and technically. The results of the LLM will vary depending on the level of know-how the human instructor has.

SanderNL 3y ago

Except you now have a way “upwards” from an abstraction POV. Regular code is severely limited and highly surgical, by design. This is not. All these abstraction layers were invented to serve old style manual coders. Why bother explaining in great detail about “Konva” layers and react anymore? Give it a few years and let it finetune on IT tech and I see this being reduced to “I want whiteboard app with X general characteristics” at which point I’d no longer speak about “programming”.

themodelplumber 3y ago
That "upwards" excludes a lot of relevant systems design logic that won't go away though, insofar as it is abstraction ad infinitum in the direction of fewer-relevant-details. What'll happen is, details will continue to be relevant as tastes adjust to the new normal. Like for my work, today, React is enterprise-ready, which is not good for me. It means it will likely dip my projects in unnecessary maintenance costs as compared to another widget of its type that does what I want in a lightweight manner. When I troubleshoot something of React's complexity, even my prompts will likely need to be longer. But also, that's just one component of one component. And you have to experience this stuff in the first place, to know that you should pay attention to these details and not those other ones, for a given job, for a given client, in a given industry, with given specs. So, if I was able to wave my hands I'd simply have all the problems I had back when I was a beginner. Ergo, it comes back to the clip art problem: Being able to buy clip art never made anyone a designer. But it made a lot of designers' jobs way easier. We are simply regressing toward the mean with regard to programming. It was never about computers in the first place, never so concerned with syntax. Anyway, back to browsing my theater program...
- SanderNL 3y ago
  Fair enough, but don’t we abstract “upwards” all the time? Assembly won’t go away, but do you deal with it?
  - themodelplumber 3y ago
    For one, assembly ceases to be a relevant detail and is replaced by other relevant details. So, I can't code fast games in a 1984 workplace, currently, being too out of touch with assembly on a given chipset. But I also can't wave my hands at an LLM and expect a modern, fast game of the desired quality to code itself. (Even though a clip art-style result is possible, the requirements are always going to be special details) The upwards direction example is also interesting because it's foundational to the cognitive functionality of one of the Jungian personality types. But other personality perspectives also apply to coding, which means in part that the directional, metaphorical-abstraction view can effectively be a blind spot if we map it as the preferred view on outcomes. The most common blind spot for this personality involves questions of relevant details, and their intersection with planning for yet-unknowns. There is a tendency to hand-wave which ends up being similar to prophetic behavior. Jung called this the "voice in the wilderness" noting that it can easily detach from sensibility (rationality) by departing from life details. Kind of interesting stuff. (Ni-dominant type)

notacoward 3y ago

The problem is that it's not quite code. It's almost code, but without the precision, which puts it into a sort of Uncanny Valley of code-ness. It's detailed instructions for someone to write code, but the someone in this case is an alien or insane or on drugs so they might interpret it the way you meant it or they might go off on some weird tangent. You never know, and that means you'll need to check it with almost as much care as you'd take writing it. Also, having it write its own tests doesn't mean those tests will themselves be correct let alone complete. This is a problem we already have with humans, because any blind spot they had while writing the code will still be present for writing the tests. Who hasn't found a bug in tests, leading to acceptance of broken code and/or rejection of correct alternatives? There's no reason to believe this problem won't also exist with an AI, and they have more blind spots to begin with.

elendee 3y ago
I think often of the adage "it's harder to read code than write it". GPT gives you a lot to read. definitely a better consultant than coder imo. I've also had GPT write entirely false things, then I say "isn't that false?" and it says, "yes sorry about that" . very uncanny
- fijiaarone 3y ago
  And the code that GPT does write, if it is even close to correct, must be code that exists in many places already, and usually (like the case of so much react code) doesn’t need to exist at all.

Veedrac 3y ago

‘Artists' jobs are safe because AI is bad at hands.’

themodelplumber 3y ago
Artists' jobs are safe in part because they can also use AI, and most already use relevant ecosystems that now incorporate AI. Consumers who can operate AI for clip art purposes are simply still part of the same non-artist-paying demographic they always were. Same with code
- Veedrac 3y ago
  As farmers' jobs were safe because farmers can use farming tools. These arguments don't track even vaguely. You are doing the equivalent of analyzing the future of solar power by assuming solar will cost the same in 10 years as it does today, and that each new watt of solar is matched 1:1 with new units of demand. Neither of these are sensible. It may be that ML code tools never displace many people, or even that they supercharge demand, but you don't get to justified conclusions by assuming the future is just the present but with a bigger UNIX timestamp.
  - all2 3y ago
    Industrialization has made farming tools incredibly complex, so I believe the statement "farmers' jobs were safe because farmers can use farming tools" is correct. You still need a farmer to farm, but you now need less manpower to farm. The specialist is secure while the untrained laborer is at risk.
    - fijiaarone 3y ago
      And yet, despite there being more complex machinery in farming there is also much more untrained labor. People just don’t notice it because the untrained labor (millions of people) that plant and harvest are an underclass that does not speak their language or associate with them.
- 3y ago

wpietri 3y ago

Yeah, I think there's a "stone soup" effect going on with AI. It's the same sort of thing you see happening with the customers of psychics. People often have poor awareness of how much they're putting in to a conversation. Or it's a bit like the way Tom Sawyer tricks other kids into painting the fence for him. For me a lot of the magic here is in knowing what questions to ask and when the answers aren't right. If you have those skills, is pounding out the code that hard? The interesting part for me is not generating new bits of code, but the long-term maintenance of a whole thing. A while back there was a fashion for coding "wizards", things that would ask some questions and then generate code for you. People were very excited, as they saw it as lowering the barrier to entry. But the fashion died out because it just pushed all the problems a bit further down the road. Now you had novice developers trying to understand and improve code they weren't competent to write. I suspect that in practice, anything a person can get a LLM to wholly write is also something that could be turned into a library or framework or service or no-code tool that they can just use. That, basically, if the novelty is low enough that an LLM can produce it, the novelty is low enough that there are better options than writing the code from scratch over and over.

harlanlewis 3y ago
Great points (and after checking your user name, I’ve been nodding my head to posts of yours for about a decade now). This is a bot tangential - your reference to stone soup is a wonderful example of the information density possible with natural language. And all the meaning and story behind the phrase is accessible to LLMs. I’ll have to start experimenting with idiom driven development, especially when prompt golfing.
baq 3y ago
I mostly agree except one critical detail: LLMs are the low code/no code service. You literally tell them what you want and if they’re fine tuned on the problem domain, you’re all set. Microsoft demo’d the office 365 integration and if it works half as well in practice they’ll own the space as much as they have in 1997.
- wpietri 3y ago

karmasimida 3y ago

I was thinking that draft of the master plan ... you can't really just write it up this clear and easy. Overall, I don't think a 95% auto pilot GPT model would provide more efficiency than a 80% one.

thomaslord 3y ago

Yeah, even if ChatGPT could perfectly understand the prompts you'd still run into major issues with token limits. I tried to get it to rebuild a single page for me (to move from one UI framework to another) and I couldn't fit the existing code in the token limit. I might be able to get it to do a chunk of the initial work for a greenfield project if I perfected the prompts, but it's structurally incapable of maintaining existing code.