3 ms·

They do all those things you've mentioned more efficiently than most of us, but they fall woefully short as soon as novelty is required. Creativity is not in th

They do all those things you've mentioned more efficiently than most of us, but they fall woefully short as soon as novelty is required. Creativity is not in their repertoire. So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce. But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step. I choose to look at it as an opportunity to spend more time on the interesting problems, and work at a higher level. We used to worry about pointers and memory allocation. Now we will worry less and less about how the code is written and more about the result it built.

9dev 10mo ago
I think your image of LLMs is a bit outdated. Claude Code with well-configured agents will get entirely novel stuff done pretty well, and that’s only going to get better over time. I wouldn’t want to bet my career on that anyway.
- germandiago 10mo ago
  I am all ears. What is your setup?
skydhash 10mo ago
> So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce. The same thing over and over again should be a SaaS, some internal tool, or a plugin. Computers are good at doing the same thing over and over again and that's what we've been using them for > But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step. Even if the high level description of a task may be similar to another, there's always something different in the implementation. A sports car and a sedan have roughly the same components, but they're not engineered the same. > We used to worry about pointers and memory allocation. Some still do. It's not in every case you will have a system that handle allocations and a garbage collector. And even in those, you will see memory leaks. > Now we will worry less and less about how the code is written and more about the result it built. Wasn't that Dreamweaver?
keyle 10mo ago
Take food for example. We don't eat food made by computers even though they're capable of making it from start to finish. Sure we eat carrots probably assisted by machines, but we are not eating dishes like protein bars all day every day. Our food is still better enjoyed when made by a chef. Software engineering will be the same. No one will want to use software made by a machine all day every day. There are differences in the execution and implementation. No one will want to read books entirely dreamed up by AI. Subtle parts of the books make us feel something only a human could have put right there right then. No one will want to see movies entirely made by AI. The list goes on. But you might say "software is different". Yes but no, in the abundance of choice, when there will be a ton of choice for a type of software due to the productivity increase, choice will become more prominent and the human driven software will win. Even today we pick the best terminal emulation software because we notice the difference between exquisitely crafted and bloated cruft.
- doug_durham 10mo ago
  You should look at other engineering disciplines. How many highway over passes have unique “chef quality” designs? Very few. Most engineering is commodity replications of existing designs. The exact same thing applies to software engineering. Most of us engineers are replicating designs that came earlier. LLMs are good at generating the rote designs that make up the bulk of software by volume. Who benefit from an artisanal REST interface? The best practices were codified over a decade ago.
  - keyle 10mo ago
    Just like cooking in the middle ages. As the kitchen, hygiene, etc. got better, so did the chefs and so did the food. This is just a transition. re-Rest API, you're right. But again, we use roombas to vacuum when the floor layout is friendly to them. Not all rooms can be vacuumed by roombas. Simple Rest api can be emitted one shot from an LLM and there is no room for interpretation. But ask a future LLM to make a new kind of social network and you'll end up with a mash up of the existing ones. Same thing, you and I won't use a manual screwdriver when we have 100 screws to get in, and we own an electric drill. That didn't reinvent screws nor the assembly of complex items. I'm keeping positive in the sense that LLMs will enable us to do more, and to learn faster. The sad part about vibe coding is you learn very little. And to live is to learn. You'll notice people vibecoding all day become less and less attached to the product they work on. That's because they've given away the dopamine hits of the many "ha-ha" moments that come from programming. They'll lose interest. They won't learn anymore and die off (career wise). So, businesses that put LLM first will slowly lose talent over time, and business that put developers first will thrive. It's just a transition. A fast one that hits us like a wall, and it's confusing, but software for humans will be better made by humans. I've been programming since the 80s. The level of complexity today is bat shit insane. I welcome the LLM help in managing 3 code bases of 3 languages spread across different architectures (my job) to keep sane!

9dev 10mo ago

I think your image of LLMs is a bit outdated. Claude Code with well-configured agents will get entirely novel stuff done pretty well, and that’s only going to get better over time. I wouldn’t want to bet my career on that anyway.

germandiago 10mo ago
I am all ears. What is your setup?

skydhash 10mo ago

> So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce. The same thing over and over again should be a SaaS, some internal tool, or a plugin. Computers are good at doing the same thing over and over again and that's what we've been using them for > But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step. Even if the high level description of a task may be similar to another, there's always something different in the implementation. A sports car and a sedan have roughly the same components, but they're not engineered the same. > We used to worry about pointers and memory allocation. Some still do. It's not in every case you will have a system that handle allocations and a garbage collector. And even in those, you will see memory leaks. > Now we will worry less and less about how the code is written and more about the result it built. Wasn't that Dreamweaver?

keyle 10mo ago

Take food for example. We don't eat food made by computers even though they're capable of making it from start to finish. Sure we eat carrots probably assisted by machines, but we are not eating dishes like protein bars all day every day. Our food is still better enjoyed when made by a chef. Software engineering will be the same. No one will want to use software made by a machine all day every day. There are differences in the execution and implementation. No one will want to read books entirely dreamed up by AI. Subtle parts of the books make us feel something only a human could have put right there right then. No one will want to see movies entirely made by AI. The list goes on. But you might say "software is different". Yes but no, in the abundance of choice, when there will be a ton of choice for a type of software due to the productivity increase, choice will become more prominent and the human driven software will win. Even today we pick the best terminal emulation software because we notice the difference between exquisitely crafted and bloated cruft.

doug_durham 10mo ago
You should look at other engineering disciplines. How many highway over passes have unique “chef quality” designs? Very few. Most engineering is commodity replications of existing designs. The exact same thing applies to software engineering. Most of us engineers are replicating designs that came earlier. LLMs are good at generating the rote designs that make up the bulk of software by volume. Who benefit from an artisanal REST interface? The best practices were codified over a decade ago.
- keyle 10mo ago
  Just like cooking in the middle ages. As the kitchen, hygiene, etc. got better, so did the chefs and so did the food. This is just a transition. re-Rest API, you're right. But again, we use roombas to vacuum when the floor layout is friendly to them. Not all rooms can be vacuumed by roombas. Simple Rest api can be emitted one shot from an LLM and there is no room for interpretation. But ask a future LLM to make a new kind of social network and you'll end up with a mash up of the existing ones. Same thing, you and I won't use a manual screwdriver when we have 100 screws to get in, and we own an electric drill. That didn't reinvent screws nor the assembly of complex items. I'm keeping positive in the sense that LLMs will enable us to do more, and to learn faster. The sad part about vibe coding is you learn very little. And to live is to learn. You'll notice people vibecoding all day become less and less attached to the product they work on. That's because they've given away the dopamine hits of the many "ha-ha" moments that come from programming. They'll lose interest. They won't learn anymore and die off (career wise). So, businesses that put LLM first will slowly lose talent over time, and business that put developers first will thrive. It's just a transition. A fast one that hits us like a wall, and it's confusing, but software for humans will be better made by humans. I've been programming since the 80s. The level of complexity today is bat shit insane. I welcome the LLM help in managing 3 code bases of 3 languages spread across different architectures (my job) to keep sane!