4 ms·

> and it will be harder to find someone to talk to understand what they were trying to do at the time. This will be the big counter to AI generated tools; at o

> and it will be harder to find someone to talk to understand what they were trying to do at the time. This will be the big counter to AI generated tools; at one point they become black boxes and the only thing people can do is to try and fix them or replace them altogether. Of course, in theory, AI tooling will only improve; today's vibe coded software that in some cases generate revenue can be fed into the models of the future and improved upon. In theory. Personally, I hate it; I don't like magic or black boxes.

worldsayshi 1y ago
The prevailing counter narrative around vibe coding seems to be that "code output isn't the bottle neck, understanding the problem is". But shouldn't that make vibe coding a good tool for the tool belt? Use it to understand the outermost layer of the problem, then throw out the code and write a proper solution.
- thyristan 1y ago
  > [create prototype], then throw out the code and write a proper solution. Problem is, that in everyones' experience, this almost never happens. The prototype is declared "good enough, just needs a few small adjustments", rewrite is declared too expensive, too time-consuming. And crap goes to production.
  - ceuk 1y ago
    Watching was supposed to be a prototype become the production code is one of the most constant themes of my 20 year career
    - jmathai 1y ago
      Software takes longer to develop than other parts of the org want to wait. AI is emerging as a possible solution to this decades old problem.
      - zppln 1y ago
        No, the org will still have to wait for the requirements, which is what they were waiting for all along.
      - thyristan 1y ago
        Everything takes longer than ppl want to wait. But when building a house, ppl are more patient and tolerant about the time taken, because they can physically see the progress, the effort, the sweat. Software is intangible and invisible except maybe for beta-testers and developer liaisons. And the visual parts, like the nonfunctional GUI or web UI, are often taken as "most of the work is done", because that is what people see and interact with.
        jmathai 1y ago
        It's product management's job to bridge that gap. Break down and prioritize complex projects into smaller deliverables that keep the business folks happy. It's better than houses, IMO - no one moves into the bedroom once it's finished while waiting for the kitchen.
      - dudefeliciano 1y ago
        until the whole company fails because lack of polishing and security in the software. Think tea app openly accessible databases...
        spogbiper 1y ago
        is there any evidence the tea app failure was due to AI use?
      - ozim 1y ago
        I don’t really see this as universal truth with corporate customers stalling process for up to 2 years or end users being reluctant to change. We were deploying new changes every 2 weeks and it was too fast. End users need training and communication, pushback was quite a thing. We also just pushed back aggressive timeline we had for migration to new tech. Much faster interface with shorter paths - but users went all pitchforks and torches just because it was new. But with AI fortunately we will get rid of those pesky users right?
  - sdeframond 1y ago
    > Problem is How much is it a problem, really ? I mean, what are the alternatives ?
    - thyristan 1y ago
      The alternative is obviously: Do it right on the first try. How much of a problem it is can be seen with tons of products that are crap on release and only slowly get patched to a half-working state when the complaints start pouring in. But of course, this is status quo in software, so the perception of this as a problem among software people isn't universal I guess.
      - sdeframond 1y ago
        Sure. How about the tons of products we don't even see? Those that tried to do it right on the first try, then never delivered anything because there were too slow and expensive. Or those that delivered something useless because they did not understand the users' need. If "complaints start pouring in", that means the product is used. This in turns can mean two things: 1/ the product is actually useful despite its flaws, or 2/ the users have no choice, which is sad.
        bonoboTP 1y ago
        Exactly. There is a reason for the push. The natural default of many engineers is to "do things properly", which often boils down to trying to guess all kinds of possible future extensions (because we have to get the foundations and the architecture right), then everything becomes abstracted and there's this huge framework that is designed to deal with hypothetical future needs in an elegant and flexible way with best practices etc. etc. And as time passes the navel-gazing nature of the project grows, where you add so much abstraction that you need more stuff to manage the abstraction, generate templates that generate the config file to manage the compilation of the config file generator etc. Not saying this happens always, but that's what people want to avoid when they say they are okay with a quick hack if it works.
        thyristan 1y ago
  - worldsayshi 1y ago
    Yes, that's how it is. And that is a separate problem. And it also shifts the narrative a bit more towards 'the bottleneck is writing good code'.
  - lwhi 1y ago
    This is the absolute reality. I think we'll need to see some major f-ups before this current wave matures.
- camgunz 1y ago
  Coding is how I build a sufficiently deep understanding of the problem space--there's no separating coding and understanding for me. I acknowledge there's different ways of working (and I imagine this is one of the reasons a lot of people think they get a lot more value out of LLMs than I do), but like, having Cursor crank code out for me actually slows me down. I have to read all the stuff it does so I can coach it into doing better, and also use its work to build a good mental model of the problem, and all that takes longer than writing the code myself.
  - thyristan 1y ago
    Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code. But almost no-one really works like that, and those three separate steps are often done ad-hoc, by the same person, right when the fingers hit the keys.
    - camgunz 1y ago
      I can use those processes to understand things at a high level, but when those processes become detailed enough to give me the same level of understanding as coding, they're functionally code. I used to work in aerospace, and this is the work systems engineers are doing, and their output is extremely detailed--practically to the level of code. There's downsides of course, but the division of labor is nice because they don't need to like, decide algorithms or factoring exactly, and I don't need to be like, "hmm this... might fail? should there be a retry? what about watchdog blah blah".
    - naasking 1y ago
      > Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code. The promise of coding AI is that it can maybe automate that last step so more intelligent humans can actually have time to focus on the more important first parts.
    - Ma8ee 1y ago
pelario 1y ago
> Personally, I hate it; I don't like magic or black boxes. So, no compilers for you neither ? (To be fair: I'm not loving the whole vibe coding thing. But I'm trying to approach this wave with open mind, and looking for the good arguments in both side. This is not one of them)
- pjc50 1y ago
  Apart from various C UB fiascos, the compiler is neither a black box nor magic, and most of the worthwhile ones are even determinstic.
  - viralpraxis 1y ago
    I’m sorry for an off-topic, are there any non-determenistic compilers you can name? I’d been wondering for a while if they actually exist
    - pjc50 1y ago
      Accidental non-deterministic compilers are fairly easy if you use sort algorithms and containers that aren't "stable". You then can get situations where OS page allocation and things like different filenames give different output. This is why "deterministic build" wasn't just the default. Actual randomness is used in FPGA and ASIC compilers which use simulated annealing for layout. Sometimes the tools let you set the seed.
- dpoloncsak 1y ago
  I think you're misunderstanding. AI is not a black-box, and neither is a compiler. We(as a species) know how they work, and what they do. The 'black-boxes' are the theoretical systems non-technical users are building via 'vibe-coding'. When your LLM says we need to spin up an EC2 instance, users will spin one up. Is it configured? Why is it configured that way? Do you really need a VPS instead of a Pi? These are questions the users, who are building these systems, won't have answers to.
  - 1y ago
jack_h 1y ago
> or replace them altogether. Before AI companies were usually very reticent to do a rewrite or major refactoring of software because of the cost but that calculus may change with AI. A lot of physical products have ended up in this space where it's cheaper to buy a new product and throw out the old broken one rather than try and fix it. If AI lowers the cost of creating software then I'm not sure why it wouldn't go down the same path as physical goods.
- jrumbut 1y ago
  Every time software has gotten cheaper to create the end result has been we create a lot more software. There are still so many businesses running on pen and paper or excel spreadsheets or off the shelf software that doesn't do what they need. Hard to say what the future holds but I'm beginning to see the happy path get closer than it looked a year or two ago. Of course, on an individual basis it will be possible to end up in a spot where your hard earned skills are no longer in demand in your physical location, but that was always a possibility.

worldsayshi 1y ago

The prevailing counter narrative around vibe coding seems to be that "code output isn't the bottle neck, understanding the problem is". But shouldn't that make vibe coding a good tool for the tool belt? Use it to understand the outermost layer of the problem, then throw out the code and write a proper solution.

thyristan 1y ago
> [create prototype], then throw out the code and write a proper solution. Problem is, that in everyones' experience, this almost never happens. The prototype is declared "good enough, just needs a few small adjustments", rewrite is declared too expensive, too time-consuming. And crap goes to production.
- ceuk 1y ago
  Watching was supposed to be a prototype become the production code is one of the most constant themes of my 20 year career
  - jmathai 1y ago
    Software takes longer to develop than other parts of the org want to wait. AI is emerging as a possible solution to this decades old problem.
    - zppln 1y ago
      No, the org will still have to wait for the requirements, which is what they were waiting for all along.
    - thyristan 1y ago
      Everything takes longer than ppl want to wait. But when building a house, ppl are more patient and tolerant about the time taken, because they can physically see the progress, the effort, the sweat. Software is intangible and invisible except maybe for beta-testers and developer liaisons. And the visual parts, like the nonfunctional GUI or web UI, are often taken as "most of the work is done", because that is what people see and interact with.
      - jmathai 1y ago
        It's product management's job to bridge that gap. Break down and prioritize complex projects into smaller deliverables that keep the business folks happy. It's better than houses, IMO - no one moves into the bedroom once it's finished while waiting for the kitchen.
    - dudefeliciano 1y ago
      until the whole company fails because lack of polishing and security in the software. Think tea app openly accessible databases...
      - spogbiper 1y ago
        is there any evidence the tea app failure was due to AI use?
    - ozim 1y ago
      I don’t really see this as universal truth with corporate customers stalling process for up to 2 years or end users being reluctant to change. We were deploying new changes every 2 weeks and it was too fast. End users need training and communication, pushback was quite a thing. We also just pushed back aggressive timeline we had for migration to new tech. Much faster interface with shorter paths - but users went all pitchforks and torches just because it was new. But with AI fortunately we will get rid of those pesky users right?
- sdeframond 1y ago
  > Problem is How much is it a problem, really ? I mean, what are the alternatives ?
  - thyristan 1y ago
    The alternative is obviously: Do it right on the first try. How much of a problem it is can be seen with tons of products that are crap on release and only slowly get patched to a half-working state when the complaints start pouring in. But of course, this is status quo in software, so the perception of this as a problem among software people isn't universal I guess.
    - sdeframond 1y ago
      Sure. How about the tons of products we don't even see? Those that tried to do it right on the first try, then never delivered anything because there were too slow and expensive. Or those that delivered something useless because they did not understand the users' need. If "complaints start pouring in", that means the product is used. This in turns can mean two things: 1/ the product is actually useful despite its flaws, or 2/ the users have no choice, which is sad.
      - bonoboTP 1y ago
        Exactly. There is a reason for the push. The natural default of many engineers is to "do things properly", which often boils down to trying to guess all kinds of possible future extensions (because we have to get the foundations and the architecture right), then everything becomes abstracted and there's this huge framework that is designed to deal with hypothetical future needs in an elegant and flexible way with best practices etc. etc. And as time passes the navel-gazing nature of the project grows, where you add so much abstraction that you need more stuff to manage the abstraction, generate templates that generate the config file to manage the compilation of the config file generator etc. Not saying this happens always, but that's what people want to avoid when they say they are okay with a quick hack if it works.
      - thyristan 1y ago
- worldsayshi 1y ago
  Yes, that's how it is. And that is a separate problem. And it also shifts the narrative a bit more towards 'the bottleneck is writing good code'.
- lwhi 1y ago
  This is the absolute reality. I think we'll need to see some major f-ups before this current wave matures.
camgunz 1y ago
Coding is how I build a sufficiently deep understanding of the problem space--there's no separating coding and understanding for me. I acknowledge there's different ways of working (and I imagine this is one of the reasons a lot of people think they get a lot more value out of LLMs than I do), but like, having Cursor crank code out for me actually slows me down. I have to read all the stuff it does so I can coach it into doing better, and also use its work to build a good mental model of the problem, and all that takes longer than writing the code myself.
- thyristan 1y ago
  Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code. But almost no-one really works like that, and those three separate steps are often done ad-hoc, by the same person, right when the fingers hit the keys.
  - camgunz 1y ago
    I can use those processes to understand things at a high level, but when those processes become detailed enough to give me the same level of understanding as coding, they're functionally code. I used to work in aerospace, and this is the work systems engineers are doing, and their output is extremely detailed--practically to the level of code. There's downsides of course, but the division of labor is nice because they don't need to like, decide algorithms or factoring exactly, and I don't need to be like, "hmm this... might fail? should there be a retry? what about watchdog blah blah".
  - naasking 1y ago
    > Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code. The promise of coding AI is that it can maybe automate that last step so more intelligent humans can actually have time to focus on the more important first parts.
  - Ma8ee 1y ago

pelario 1y ago

> Personally, I hate it; I don't like magic or black boxes. So, no compilers for you neither ? (To be fair: I'm not loving the whole vibe coding thing. But I'm trying to approach this wave with open mind, and looking for the good arguments in both side. This is not one of them)

pjc50 1y ago
Apart from various C UB fiascos, the compiler is neither a black box nor magic, and most of the worthwhile ones are even determinstic.
- viralpraxis 1y ago
  I’m sorry for an off-topic, are there any non-determenistic compilers you can name? I’d been wondering for a while if they actually exist
  - pjc50 1y ago
    Accidental non-deterministic compilers are fairly easy if you use sort algorithms and containers that aren't "stable". You then can get situations where OS page allocation and things like different filenames give different output. This is why "deterministic build" wasn't just the default. Actual randomness is used in FPGA and ASIC compilers which use simulated annealing for layout. Sometimes the tools let you set the seed.
dpoloncsak 1y ago
I think you're misunderstanding. AI is not a black-box, and neither is a compiler. We(as a species) know how they work, and what they do. The 'black-boxes' are the theoretical systems non-technical users are building via 'vibe-coding'. When your LLM says we need to spin up an EC2 instance, users will spin one up. Is it configured? Why is it configured that way? Do you really need a VPS instead of a Pi? These are questions the users, who are building these systems, won't have answers to.
- 1y ago

jack_h 1y ago

> or replace them altogether. Before AI companies were usually very reticent to do a rewrite or major refactoring of software because of the cost but that calculus may change with AI. A lot of physical products have ended up in this space where it's cheaper to buy a new product and throw out the old broken one rather than try and fix it. If AI lowers the cost of creating software then I'm not sure why it wouldn't go down the same path as physical goods.

jrumbut 1y ago
Every time software has gotten cheaper to create the end result has been we create a lot more software. There are still so many businesses running on pen and paper or excel spreadsheets or off the shelf software that doesn't do what they need. Hard to say what the future holds but I'm beginning to see the happy path get closer than it looked a year or two ago. Of course, on an individual basis it will be possible to end up in a spot where your hard earned skills are no longer in demand in your physical location, but that was always a possibility.