3 ms·

> Being a developer will mean something else Not really. Programming means explaining the machine what to do. How you do it has changed over the years. From wr

by GuB-42 1y ago

> Being a developer will mean something else Not really. Programming means explaining the machine what to do. How you do it has changed over the years. From writing machine language and punching cards to gluing frameworks and drawing boxes. But the core is always the same: take approximative and ambiguous requirements from someone who doesn't really knows what he wants and turn it into something precise the machine can execute reliably, without supervision. Over the years, programmers have figured out that the best way to do it is with code. GUIs are usually not expressive enough, and English is too ambiguous and/or too verbose, that's why we have programming languages. There are fields that had specialized languages before electronic computers existed, like maths, and for the same reason. LLMs are just the current step in the evolution of programming, but the role of the programmer is still the same: getting the machine to do what people want, be it by prompting, drawing, or writing code, and I suspect code will still prevail. LLMs are quite good at repeating what has been done before, but having them write something original using natural language descriptions is quite a frustrating experience, and if you are programming, there is a good chance there is at least something original to it, otherwise, why not use an off-the-shelf product? We are at the peak of the hype cycle now, but things will settle down. Some things will change for sure, as always when some new technology emerges.

aaronblohowiak 1y ago
+100. I feel like a lot of people need to go re-read moon is a harsh mistress.
lubujackson 1y ago
I agree, I see AI as just a level of abstraction. Make a function to do X, Y, Z? Works great. Even architect a DAG, pretty good. Integrate everything smoothly? Call in the devs. On the bright side, the element of development that is LEAST represented in teaching and interviewing (how to structure large codebases) will be the new frontier and differentiator. But much as scripting language removed the focus on pointers and memory management, AI will abstract away discrete blocks of code. It is kind of the dream of open source software, but advanced - don't rebuild standard functions. But also, don't bother searching for them or work out how to integrate them. Just request what you need and keep going.
- bluefirebrand 1y ago
  > I agree, I see AI as just a level of abstraction. Make a function to do X, Y, Z? Works great. Even architect a DAG, pretty good. Integrate everything smoothly? Call in the devs. "Your job is now to integrate all of this AI generated slop together smoothly" is a thought that is going to keep me up at night and probably remove years from my life from stress I don't mean to sound flippant. What you are describing sounds like a nightmare. Plumbing libraries together is just such a boring, miserable chore. Have AI solve all the fun challenging parts and then personally do the gruntwork of wiring it all together? I wish I were closer to retirement. Or death
catigula 1y ago
The problem with this idea is that the current systems have gone from being completely incapable of taking the developer role in this equation to somewhat capable of taking the developer role (i.e. newer agents). At this clip it isn't very hard to imagine the developer layer becoming obsolete or reduced down to one architect directing many agents. In fact, this is probably already somewhat possible. I don't really write code anymore, I direct claude code to make the edits. This is a much faster workflow than the old one.
yesco 1y ago
I like to joke with people that us programmers automated our jobs away decades ago, we just tell our fancy compilers what we want and they magically generate all the code for us! I don't see LLMs as much different really, our jobs becoming easier just means there's more things we can do now and with more capabilities comes more demand. Not right away of course.
- dehrmann 1y ago
  What's different is compilers do deterministic, repetitive work that's correct practically every time. AI takes the hard part, the ambiguity, and gets it sorta ok some of the time.
  - datadrivenangel 1y ago
    I have bad news about compilers.
    - const_cast 1y ago
      No he's right - compilers pretty much do the same thing every time. It's very rare that there's bugs in compilers, and even if the assembly is different, if it works the same it doesn't matter.
  - skydhash 1y ago
    The hard part is not the ambiguous part and it never were. You just need to talk with the stakeholder to sort it out. That's the requirement phase and all it requires is good communication skills. The hard part is to have a consistent system that can evolve without costing too much. And the bigger the system, the harder it is to get this right. We have principles like modularity, cohesion, information hiding,... to help us on that front, but not a clear guideline on how to achieve it. That's the design phase. Once you have the two above done, coding is often quite easy. And if you have a good programming ecosystem and people that know it, it can be done quite fast.
- ethbr1 1y ago
  100% agree with this thread, because it's the discussion about why no code (and cloud/SaaS to a lesser degree) failed to deliver on their utopian promises. Largely, because there were still upstream blockers that constrained throughput. Typically imprecise business requirements (because someone hadn't thought sufficiently about the problem) or operation at scale issues (poorly generalizing architecture). > our jobs becoming easier just means there's more things we can do now and with more capabilities comes more demand This is the repeatedly forgotten lesson from the computing / digitization revolution! The reason they changed the world wasn't because they were more capable (versus their manual precursors) but because they were economically cheaper. Consequently, they enabled an entire class of problems to be worked on that were previously uneconomical. E.g. there's no company on the planet that wouldn't be interested in more realtime detail of its financial operations... but that wasn't worth enough to pay bodies to continually tabulate it. >> The NoCode movement didn't eliminate developers; it created NoCode specialists and backend integrators. The cloud didn't eliminate system administrators; it transformed them into DevOps engineers at double the salary. Similarly, the article feels around the issue here but loses two important takeaways: 1) Technologies that revolutionize the world decrease total cost to deliver preexisting value. 2) Salary ~= value, for as many positions as demand supports. Whether are more or fewer backend integrators, devops engineers, etc. post-transformation isn't foretold. In recent history, those who upskill their productivity reap larger salaries, while others' positions disappear. I.e. the cloud engineer supporting millions of users, instead of the many bodies that used to take to deliver less efficiently. It remains to be seen whether AI coding will stimulate more demand or simply increase the value of the same / fewer positions. PS: If I were career plotting today, there's no way in hell I'd be aiming for anything that didn't have a customer-interactive component. Those business solution formulation skills are going to be a key differentiator any way it goes. The "locked in a closet" coder, no matter how good, is going to be a valuable addition for fewer and fewer positions.
zamalek 1y ago
My way of thinking about this has been: code is to a developer as bricks are to a builder. Writing a line of code is merely the final 10% of the work, there's a whole bunch of cognitive effort that precedes it. Just like a builder has already established a blueprint, set up straight lines, mixed cement, and what-have-you, prioir to laying a brick.
surgical_fire 1y ago
Those are very good points. I am finding LLMs useful for coding in that it can do a lot of heavy lifting for me, and then I jump in and do some finishing touches. It is also sort of decent at reviewing my code and suggesting improvements, writing unit tests etc. Hidden in all that is I have to describe all of those things, in detail, for the LLM to do a decent job. I can of course do a "Write unit tests for me", but I notice it does a much better job if I describe what are the test cases, and even how I want things tested.

by GuB-42 1y ago

aaronblohowiak 1y ago

+100. I feel like a lot of people need to go re-read moon is a harsh mistress.

lubujackson 1y ago

I agree, I see AI as just a level of abstraction. Make a function to do X, Y, Z? Works great. Even architect a DAG, pretty good. Integrate everything smoothly? Call in the devs. On the bright side, the element of development that is LEAST represented in teaching and interviewing (how to structure large codebases) will be the new frontier and differentiator. But much as scripting language removed the focus on pointers and memory management, AI will abstract away discrete blocks of code. It is kind of the dream of open source software, but advanced - don't rebuild standard functions. But also, don't bother searching for them or work out how to integrate them. Just request what you need and keep going.

bluefirebrand 1y ago
> I agree, I see AI as just a level of abstraction. Make a function to do X, Y, Z? Works great. Even architect a DAG, pretty good. Integrate everything smoothly? Call in the devs. "Your job is now to integrate all of this AI generated slop together smoothly" is a thought that is going to keep me up at night and probably remove years from my life from stress I don't mean to sound flippant. What you are describing sounds like a nightmare. Plumbing libraries together is just such a boring, miserable chore. Have AI solve all the fun challenging parts and then personally do the gruntwork of wiring it all together? I wish I were closer to retirement. Or death

catigula 1y ago

The problem with this idea is that the current systems have gone from being completely incapable of taking the developer role in this equation to somewhat capable of taking the developer role (i.e. newer agents). At this clip it isn't very hard to imagine the developer layer becoming obsolete or reduced down to one architect directing many agents. In fact, this is probably already somewhat possible. I don't really write code anymore, I direct claude code to make the edits. This is a much faster workflow than the old one.

yesco 1y ago

I like to joke with people that us programmers automated our jobs away decades ago, we just tell our fancy compilers what we want and they magically generate all the code for us! I don't see LLMs as much different really, our jobs becoming easier just means there's more things we can do now and with more capabilities comes more demand. Not right away of course.

dehrmann 1y ago
What's different is compilers do deterministic, repetitive work that's correct practically every time. AI takes the hard part, the ambiguity, and gets it sorta ok some of the time.
- datadrivenangel 1y ago
  I have bad news about compilers.
  - const_cast 1y ago
    No he's right - compilers pretty much do the same thing every time. It's very rare that there's bugs in compilers, and even if the assembly is different, if it works the same it doesn't matter.
- skydhash 1y ago
  The hard part is not the ambiguous part and it never were. You just need to talk with the stakeholder to sort it out. That's the requirement phase and all it requires is good communication skills. The hard part is to have a consistent system that can evolve without costing too much. And the bigger the system, the harder it is to get this right. We have principles like modularity, cohesion, information hiding,... to help us on that front, but not a clear guideline on how to achieve it. That's the design phase. Once you have the two above done, coding is often quite easy. And if you have a good programming ecosystem and people that know it, it can be done quite fast.
ethbr1 1y ago
100% agree with this thread, because it's the discussion about why no code (and cloud/SaaS to a lesser degree) failed to deliver on their utopian promises. Largely, because there were still upstream blockers that constrained throughput. Typically imprecise business requirements (because someone hadn't thought sufficiently about the problem) or operation at scale issues (poorly generalizing architecture). > our jobs becoming easier just means there's more things we can do now and with more capabilities comes more demand This is the repeatedly forgotten lesson from the computing / digitization revolution! The reason they changed the world wasn't because they were more capable (versus their manual precursors) but because they were economically cheaper. Consequently, they enabled an entire class of problems to be worked on that were previously uneconomical. E.g. there's no company on the planet that wouldn't be interested in more realtime detail of its financial operations... but that wasn't worth enough to pay bodies to continually tabulate it. >> The NoCode movement didn't eliminate developers; it created NoCode specialists and backend integrators. The cloud didn't eliminate system administrators; it transformed them into DevOps engineers at double the salary. Similarly, the article feels around the issue here but loses two important takeaways: 1) Technologies that revolutionize the world decrease total cost to deliver preexisting value. 2) Salary ~= value, for as many positions as demand supports. Whether are more or fewer backend integrators, devops engineers, etc. post-transformation isn't foretold. In recent history, those who upskill their productivity reap larger salaries, while others' positions disappear. I.e. the cloud engineer supporting millions of users, instead of the many bodies that used to take to deliver less efficiently. It remains to be seen whether AI coding will stimulate more demand or simply increase the value of the same / fewer positions. PS: If I were career plotting today, there's no way in hell I'd be aiming for anything that didn't have a customer-interactive component. Those business solution formulation skills are going to be a key differentiator any way it goes. The "locked in a closet" coder, no matter how good, is going to be a valuable addition for fewer and fewer positions.

zamalek 1y ago

My way of thinking about this has been: code is to a developer as bricks are to a builder. Writing a line of code is merely the final 10% of the work, there's a whole bunch of cognitive effort that precedes it. Just like a builder has already established a blueprint, set up straight lines, mixed cement, and what-have-you, prioir to laying a brick.

surgical_fire 1y ago

Those are very good points. I am finding LLMs useful for coding in that it can do a lot of heavy lifting for me, and then I jump in and do some finishing touches. It is also sort of decent at reviewing my code and suggesting improvements, writing unit tests etc. Hidden in all that is I have to describe all of those things, in detail, for the LLM to do a decent job. I can of course do a "Write unit tests for me", but I notice it does a much better job if I describe what are the test cases, and even how I want things tested.