6 ms·

>> Bad engineers continue being bad, good engineers continue being good. I don't know if good engineers can necessarily continue to be good. There is limit to

>> Bad engineers continue being bad, good engineers continue being good. I don't know if good engineers can necessarily continue to be good. There is limit to how much careful consideration one can give if everything is on an accelerated timeline. Regardless good or not, there is limit on how much influence you have on setting those timelines. The whole playing field is changing.

andai 5mo ago
An old comic I like: - I've taken a controversial new pill that accelerates my brain. -- So you're smart now? - I'm stupid faster! That being said, being stupid faster can work if validation is cheap (and exists in the first place). Turns out "eh close enough" for AGI is just stupidity in an "until done" loop. (Technically referred to as Ralphing.)
- Salgat 5mo ago
  So the chimpanzees on the keyboard thing is real.
- sanderjd 5mo ago
  Yep, validation is key. The smartest thing I've heard on this, which has reoriented how I think about this is that the objective function of a piece of software is now more important to get right than the implementation.
  - dspillett 5mo ago
    > the objective function of a piece of software is now more important to get right than the implementation That has always been the case. That is why weeks or even months of programming and other project busy work could replace a couple of days of time getting properly fleshed out requirements down.
    - sanderjd 5mo ago
      Agreed, it has always been the case. But I've never thought of it that way so explicitly. And I might argue that the important distinction is that the objective function is programmatically verifiable (which the word "requirements" has not always implied).
  - andai 5mo ago
    Turns out what was being rewarded all along is "the code looks all right" and "it looks like it works".
    - sanderjd 5mo ago
      No, what is rewarded is "the code has been shown to conform to the given objective function" and especially "that objective function is a good representation of what we are trying to accomplish with this code".
- teddyh 5mo ago
  You mean this one: <https://knowyourmeme.com/photos/1567852-shen-comix https://knowyourmeme.com/photos/1567852-shen-comix>
  - andai 5mo ago
    My favorite one: https://iili.io/BZbHyP9.jpg https://iili.io/BZbHyP9.jpg I've optimized my game's code and it finally runs at 1000 FPS. --So your game is good now? It's shit faster.
  - karmickoala 5mo ago
    "I'm doing 1000 calculations per second and they're all wrong"
- dpoloncsak 5mo ago
  I say this usually about self-driving cars, but the phrase fits here too. "It doesn't need to be perfect. It just needs to be better than the average human, and humans suck at driving."
sanderjd 5mo ago
Hmmm, I think I disagree with this. I estimate that I'm now spending about 10 to 30 hours less time a week in the mechanical parts of writing and refactoring code, researching how to plumb components together, and doing "figure out how to do unfamiliar thing" research. All of those hours are time that can now be spent doing "careful consideration" (or just being with my family or at the gym or reading a book, which is all cognitively valuable as well). Now, I suppose I agree that if timelines accelerate ahead of that amount of regained time, then I'm net worse off, but that's not the current situation at the moment, in my experience.
- truncate 5mo ago
  Maybe we do different things. Not that you are wrong about spending less time on things that you don't care about, but at the same time all that mechanical things helps you build a really good mental model of your product from high level design to individual classes. If I already have a good mental model of that I can direct AI to make really good changes fast, if I don't I will get things done ... but it does end up with less than ideal changes that compounds over time. What you said: "figure out how to do unfamiliar thing" -- is correct, and will get things done, but overall quality, maintainability or understanding how individual pieces work...that's what you don't get. One can argue who care about all that as AI can take care of that or already can. I don't think its true today at-least.
  - sanderjd 5mo ago
    I guess I just don't really agree that doing the tedious mechanical things is all that helpful for building the necessary mental model. I mean, I do think it was useful (indeed, necessary) for me to actually type out very similar lines of code over and over again when I was building up the programming skillset, but I really think the marginal value of that is just very low for me at this point. I worry a lot about how we're going to train the next generation of people without there being any incentive to do this part of the process! But for me, I already did that part. What I find is actually necessary for me to have a mental model of the system is not typing out the definitions of the classes and such, but rather operating and debugging the system. I really do need to try to do things, and dig into logs, and figure out what's going on when something is off. And pretty much always ends up requiring reading and understanding a bunch of the implementation. But whether I personally typed out that implementation, or one of my colleagues, or an AI, is less important. I mean, I already had to be able to build a mental model of a system that I didn't fully implement myself! I essentially never work on anything that I have developed in its entirety on my own.
ori_b 5mo ago
It's deeper. We used to mock architects that stepped back and stopped coding, because they generated trash. There's a cycle that is needed for good system design. Start with a problem and an approach, and write some code. As you write the code, you reify the design and flesh out the edge cases, learning where you got the details wrong. As you learn the details, you go back to the drawing board and shuffle the puzzle pieces, and try again. Polished, effective systems don't just fall out of an engineers head. They're learned as you shape them. Good engineers won't continue to be good when vibe-coding, because the thing that made them good was the learning loop. They may be able to coast for a while, at best.
- beeandapenguin 5mo ago
  Reminds me of Gall’s Law from his book Systemantics. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
  - ori_b 5mo ago
    I find that the learning and iteration tends to lead to a simplified system, if you're willing to look hard enough at the shapes needed. When there's a lot of complexity, it's often repetitive translation layers, and not something fundamental to the problem being solved.
- sothatsit 5mo ago
  You don’t need to write code by hand to learn from iterations and experiments. I run more experiments and try out more different solutions than I ever could before, and that leads to better decisions. I still read all the code that gets shipped, and don’t want to give that up, but the idea that all craft and learning is lost when you don’t is a bit silly. The craft/learning just moves.
  - 5mo ago
datsci_est_2015 5mo ago
> if everything is on an accelerated timeline Good engineers are also capable of managing expectations. They can effectively communicate with stakeholders what compromises must be made in order to meet accelerated timelines, just as they always have. We’ve already had conversations with overeager product people what the ramifications are for introducing their vibe coded monstrosities: - Have you considered X? - Have you considered Y? Their contributions are quickly shot down by other stakeholders as being too risky compared to the more measured contributions of proper engineers (still accelerated by AI, but not fully vibe-coded). If that’s not the situation where you work, then unfortunately it’s time to start playing politics or find a new place to work that knows how to properly assess risk.
runarberg 5mo ago
When there is all that crap out there, good engineer may simply just carry out, call it good and leave the industry. Personally seeing the proliferation of wibe coded apps has made me hesitant of publishing and promoting my AI free apps.
paulddraper 5mo ago
There is no limit. Or at least, the limit is increasing by the day.

andai 5mo ago

An old comic I like: - I've taken a controversial new pill that accelerates my brain. -- So you're smart now? - I'm stupid faster! That being said, being stupid faster can work if validation is cheap (and exists in the first place). Turns out "eh close enough" for AGI is just stupidity in an "until done" loop. (Technically referred to as Ralphing.)

Salgat 5mo ago
So the chimpanzees on the keyboard thing is real.
sanderjd 5mo ago
Yep, validation is key. The smartest thing I've heard on this, which has reoriented how I think about this is that the objective function of a piece of software is now more important to get right than the implementation.
- dspillett 5mo ago
  > the objective function of a piece of software is now more important to get right than the implementation That has always been the case. That is why weeks or even months of programming and other project busy work could replace a couple of days of time getting properly fleshed out requirements down.
  - sanderjd 5mo ago
    Agreed, it has always been the case. But I've never thought of it that way so explicitly. And I might argue that the important distinction is that the objective function is programmatically verifiable (which the word "requirements" has not always implied).
- andai 5mo ago
  Turns out what was being rewarded all along is "the code looks all right" and "it looks like it works".
  - sanderjd 5mo ago
    No, what is rewarded is "the code has been shown to conform to the given objective function" and especially "that objective function is a good representation of what we are trying to accomplish with this code".
teddyh 5mo ago
You mean this one: <https://knowyourmeme.com/photos/1567852-shen-comix https://knowyourmeme.com/photos/1567852-shen-comix>
- andai 5mo ago
  My favorite one: https://iili.io/BZbHyP9.jpg https://iili.io/BZbHyP9.jpg I've optimized my game's code and it finally runs at 1000 FPS. --So your game is good now? It's shit faster.
- karmickoala 5mo ago
  "I'm doing 1000 calculations per second and they're all wrong"
dpoloncsak 5mo ago
I say this usually about self-driving cars, but the phrase fits here too. "It doesn't need to be perfect. It just needs to be better than the average human, and humans suck at driving."

sanderjd 5mo ago

Hmmm, I think I disagree with this. I estimate that I'm now spending about 10 to 30 hours less time a week in the mechanical parts of writing and refactoring code, researching how to plumb components together, and doing "figure out how to do unfamiliar thing" research. All of those hours are time that can now be spent doing "careful consideration" (or just being with my family or at the gym or reading a book, which is all cognitively valuable as well). Now, I suppose I agree that if timelines accelerate ahead of that amount of regained time, then I'm net worse off, but that's not the current situation at the moment, in my experience.

truncate 5mo ago
Maybe we do different things. Not that you are wrong about spending less time on things that you don't care about, but at the same time all that mechanical things helps you build a really good mental model of your product from high level design to individual classes. If I already have a good mental model of that I can direct AI to make really good changes fast, if I don't I will get things done ... but it does end up with less than ideal changes that compounds over time. What you said: "figure out how to do unfamiliar thing" -- is correct, and will get things done, but overall quality, maintainability or understanding how individual pieces work...that's what you don't get. One can argue who care about all that as AI can take care of that or already can. I don't think its true today at-least.
- sanderjd 5mo ago
  I guess I just don't really agree that doing the tedious mechanical things is all that helpful for building the necessary mental model. I mean, I do think it was useful (indeed, necessary) for me to actually type out very similar lines of code over and over again when I was building up the programming skillset, but I really think the marginal value of that is just very low for me at this point. I worry a lot about how we're going to train the next generation of people without there being any incentive to do this part of the process! But for me, I already did that part. What I find is actually necessary for me to have a mental model of the system is not typing out the definitions of the classes and such, but rather operating and debugging the system. I really do need to try to do things, and dig into logs, and figure out what's going on when something is off. And pretty much always ends up requiring reading and understanding a bunch of the implementation. But whether I personally typed out that implementation, or one of my colleagues, or an AI, is less important. I mean, I already had to be able to build a mental model of a system that I didn't fully implement myself! I essentially never work on anything that I have developed in its entirety on my own.

ori_b 5mo ago

It's deeper. We used to mock architects that stepped back and stopped coding, because they generated trash. There's a cycle that is needed for good system design. Start with a problem and an approach, and write some code. As you write the code, you reify the design and flesh out the edge cases, learning where you got the details wrong. As you learn the details, you go back to the drawing board and shuffle the puzzle pieces, and try again. Polished, effective systems don't just fall out of an engineers head. They're learned as you shape them. Good engineers won't continue to be good when vibe-coding, because the thing that made them good was the learning loop. They may be able to coast for a while, at best.

beeandapenguin 5mo ago
Reminds me of Gall’s Law from his book Systemantics. A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
- ori_b 5mo ago
  I find that the learning and iteration tends to lead to a simplified system, if you're willing to look hard enough at the shapes needed. When there's a lot of complexity, it's often repetitive translation layers, and not something fundamental to the problem being solved.
sothatsit 5mo ago
You don’t need to write code by hand to learn from iterations and experiments. I run more experiments and try out more different solutions than I ever could before, and that leads to better decisions. I still read all the code that gets shipped, and don’t want to give that up, but the idea that all craft and learning is lost when you don’t is a bit silly. The craft/learning just moves.
- 5mo ago

datsci_est_2015 5mo ago

> if everything is on an accelerated timeline Good engineers are also capable of managing expectations. They can effectively communicate with stakeholders what compromises must be made in order to meet accelerated timelines, just as they always have. We’ve already had conversations with overeager product people what the ramifications are for introducing their vibe coded monstrosities: - Have you considered X? - Have you considered Y? Their contributions are quickly shot down by other stakeholders as being too risky compared to the more measured contributions of proper engineers (still accelerated by AI, but not fully vibe-coded). If that’s not the situation where you work, then unfortunately it’s time to start playing politics or find a new place to work that knows how to properly assess risk.

runarberg 5mo ago

When there is all that crap out there, good engineer may simply just carry out, call it good and leave the industry. Personally seeing the proliferation of wibe coded apps has made me hesitant of publishing and promoting my AI free apps.

paulddraper 5mo ago

There is no limit. Or at least, the limit is increasing by the day.