4 ms·

A few counterpoints: 1. If you don't care about code and only care about the "thing that it does when it's done", how do you solve problems in a way that is sa

A few counterpoints: 1. If you don't care about code and only care about the "thing that it does when it's done", how do you solve problems in a way that is satisfying? Because you are not really solving any problem but just using the AI to do it. Is prompting more satisfying than actually solving? 2. You claim you're done "learning about coding and stretching my personal knowledge in the area" but don't you think that's super dangerous? Like how can you just be done with learning when tech is constantly changing and new things come up everyday. In that sense, don't you think AI use is actually making you learn less and you're just justifying it with the whole "I love solving problems, not code" thing? 3. If you don't care about the code, do the people who hire you for it do? And if they do, then how can you claim you don't care about the code when you'll have to go through a review process and at least check the code meaning you have to care about the code itself, right?

pdntspa 11mo ago
Why can't both things be true? You can care about the code even if you don't write it. You can continue learning things by reading said code. And you can very rigidly enforce code quality guidelines and require the AI adhere to them.
- altmanaltman 11mo ago
  I mean if you're reading it and "rigidly" enforcing code quality guidelines, then you do care about the code, right? But the parent comment said they don't care about the code but what it does. Both of them cannot be true at the same time, since in your example, you do care about the code enough to read it and refactor it based on guidelines and not just "what the code" does.
keeda 11mo ago
Note I'm not saying one is better than the other, but my takes: 1. The problem solving is in figuring out what to prompt, which includes correctly defining the problem, identifying a potential solution, designing an architecture, decomposing it into smaller tasks, and so on. Giving it a generic prompt like "build a fitness tracker" will result in a fully working product but it will be bland as it would be the average of everything in its training data, and won't provide any new value. Instead, you probably want to build something that nobody else has, because that's where the value is. This will require you to get pretty deep into the problem domain, even if the code itself is abstracted away from you. Personally, once the shape of the solution and the code is crystallized in my head typing it out is a chore. I'd rather get it out ASAP, get the dopamine hit from seeing it work, and move on to the next task. These days I spend most of my time exploring the problem domain rather than writing code. 2. Learning still exists but at a different level; in fact it will be the only thing we will eventually be doing. E.g. I'm doing stuff today that I had negligible prior background in when I began. Without AI, I would probably require an advanced course to just get upto speed. But now I'm learning by doing while solving new problems, which is a brand new way of learning! Only I'm learning the problem domain rather than the intricacies of code. 3. Statistically speaking, the people who hire us don't really care about the code, they just want business results. (See: the difficulty of funding tech debt cleanup projects!) Personally, I still care about the code and review everything, whether written by me or the AI. But I can see how even that is rapidly becoming optional. I will say this: AI is rapidly revolutionizing our field and we need to adapt just as quickly.
- altmanaltman 11mo ago
  Honestly, I fundamentally disagree with this. Figuring out "what to prompt" is not problem-solving in a true sense imo. And if you're really going too deep into the problem domain, what is the point of having the code abstracted? My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out of it. And again, I fundamentally disagree that reviewing code will become optional or rather should become optional. But that's my personal take.
  - keeda 11mo ago
    > My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out of it. I'm not the person you originally replied to, so my take is different, which explains your confusion :-) However I do increasingly get the niggling sense I'm reviewing code out of habit rather than any specific benefit because I so rarely find something to change... > And if you're really going too deep into the problem domain, what is the point of having the code abstracted? Let's take my current work as an example: I'm doing stuff with computer vision (good old-fashioned OpenCV, because ML would be overkill for my case.) So the problem domain is now images and perception and retrieval, which is what I am learning and exploring. The actual code itself does not matter as much the high-level approach and the component algorithms and data structures -- none of which are individually novel BTW, but I believe I'm the only one combining them this way. As an example, I give a high-level prompt like "Write a method that accepts a list of bounding boxes, find all overlapping ones, choose the ones with substantial overlap and consolidate them into a single box, and return all consolidated boxes. Write tests for this method." The AI runs off and generates dozens of lines of code -- including a tunable parameter to control "substantial overlap", set to a reasonable default -- the tests pass, and when I plug in the method, 99.9% of the times the code works as expected. And because this is vision-based I can immediately verify by sight if the approach works! To me, the valuable part was coming up with that whole approach based on bounding boxes, which led to that prompt. The actual code in itself is not interesting because it is not a difficult problem, just a cumbersome one to handcode. To solve the overall problem I have to combine a large number of such sub-problems, so the leverage that AI gives me is enormous.
danielmarkbruce 11mo ago
are you really solving the problem, or is the compiler doing it?
- altmanaltman 11mo ago
  is the compiler really solving the problem or the electricity flowing through the machine?
  - ukuina 11mo ago
    Is it the electricity, or is it quantum entanglement with Roko's Basilisk?
    - hellouruguay 11mo ago
      Is it the Basilisk, or just a bit flip in the parent simulation?
      - danielmarkbruce 11mo ago
        the parent simulation wouldn't use something so crude as a "bit"...
  - danielmarkbruce 11mo ago
    exactly.....

pdntspa 11mo ago

Why can't both things be true? You can care about the code even if you don't write it. You can continue learning things by reading said code. And you can very rigidly enforce code quality guidelines and require the AI adhere to them.

altmanaltman 11mo ago
I mean if you're reading it and "rigidly" enforcing code quality guidelines, then you do care about the code, right? But the parent comment said they don't care about the code but what it does. Both of them cannot be true at the same time, since in your example, you do care about the code enough to read it and refactor it based on guidelines and not just "what the code" does.

keeda 11mo ago

Note I'm not saying one is better than the other, but my takes: 1. The problem solving is in figuring out what to prompt, which includes correctly defining the problem, identifying a potential solution, designing an architecture, decomposing it into smaller tasks, and so on. Giving it a generic prompt like "build a fitness tracker" will result in a fully working product but it will be bland as it would be the average of everything in its training data, and won't provide any new value. Instead, you probably want to build something that nobody else has, because that's where the value is. This will require you to get pretty deep into the problem domain, even if the code itself is abstracted away from you. Personally, once the shape of the solution and the code is crystallized in my head typing it out is a chore. I'd rather get it out ASAP, get the dopamine hit from seeing it work, and move on to the next task. These days I spend most of my time exploring the problem domain rather than writing code. 2. Learning still exists but at a different level; in fact it will be the only thing we will eventually be doing. E.g. I'm doing stuff today that I had negligible prior background in when I began. Without AI, I would probably require an advanced course to just get upto speed. But now I'm learning by doing while solving new problems, which is a brand new way of learning! Only I'm learning the problem domain rather than the intricacies of code. 3. Statistically speaking, the people who hire us don't really care about the code, they just want business results. (See: the difficulty of funding tech debt cleanup projects!) Personally, I still care about the code and review everything, whether written by me or the AI. But I can see how even that is rapidly becoming optional. I will say this: AI is rapidly revolutionizing our field and we need to adapt just as quickly.

altmanaltman 11mo ago
Honestly, I fundamentally disagree with this. Figuring out "what to prompt" is not problem-solving in a true sense imo. And if you're really going too deep into the problem domain, what is the point of having the code abstracted? My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out of it. And again, I fundamentally disagree that reviewing code will become optional or rather should become optional. But that's my personal take.
- keeda 11mo ago
  > My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out of it. I'm not the person you originally replied to, so my take is different, which explains your confusion :-) However I do increasingly get the niggling sense I'm reviewing code out of habit rather than any specific benefit because I so rarely find something to change... > And if you're really going too deep into the problem domain, what is the point of having the code abstracted? Let's take my current work as an example: I'm doing stuff with computer vision (good old-fashioned OpenCV, because ML would be overkill for my case.) So the problem domain is now images and perception and retrieval, which is what I am learning and exploring. The actual code itself does not matter as much the high-level approach and the component algorithms and data structures -- none of which are individually novel BTW, but I believe I'm the only one combining them this way. As an example, I give a high-level prompt like "Write a method that accepts a list of bounding boxes, find all overlapping ones, choose the ones with substantial overlap and consolidate them into a single box, and return all consolidated boxes. Write tests for this method." The AI runs off and generates dozens of lines of code -- including a tunable parameter to control "substantial overlap", set to a reasonable default -- the tests pass, and when I plug in the method, 99.9% of the times the code works as expected. And because this is vision-based I can immediately verify by sight if the approach works! To me, the valuable part was coming up with that whole approach based on bounding boxes, which led to that prompt. The actual code in itself is not interesting because it is not a difficult problem, just a cumbersome one to handcode. To solve the overall problem I have to combine a large number of such sub-problems, so the leverage that AI gives me is enormous.

danielmarkbruce 11mo ago

are you really solving the problem, or is the compiler doing it?

altmanaltman 11mo ago
is the compiler really solving the problem or the electricity flowing through the machine?
- ukuina 11mo ago
  Is it the electricity, or is it quantum entanglement with Roko's Basilisk?
  - hellouruguay 11mo ago
    Is it the Basilisk, or just a bit flip in the parent simulation?
    - danielmarkbruce 11mo ago
      the parent simulation wouldn't use something so crude as a "bit"...
- danielmarkbruce 11mo ago
  exactly.....