6 ms·

I think many people are missing the overall meaning of these sorts of posts.. that is they are describing a new type of programmer that will only use agents and

I think many people are missing the overall meaning of these sorts of posts.. that is they are describing a new type of programmer that will only use agents and never read the underlying code. These vibe/agent coders will use natural(-ish) language to communicate with the agents and wouldn't look at the code anymore than, say, a PHP developer would look at the underlying assembly. It is not the level of abstraction they are working on. There are many use cases where this type of coding will work fine and it will let many people who previously couldn't really take advantage of computers to do so. This is great but in no way will do anything to replace the need for code that requires humans to understand (which, in turn, requires participation in the writing).

straydusk 9mo ago
I'm glad you wrote this comment because I completely agree with it. I don't think that there is not a need for software engineers to deeply consider architecture; who can fully understand the truly critical systems that exist at most software companies; who can help dream up the harness capabilities to make these agents work better. I just am describing what I'm doing now, and what I'm seeing at the leading edge of using these tools. It's a different approach - but I think it'll become the most common way of producing software.
re-thc 9mo ago
> that is they are describing a new type of programmer that will only use agents and never read the underlying code > and wouldn't look at the code anymore than, say, a PHP developer would look at the underlying assembly This really puts down the work that the PHP maintainers have done. Many people spend a lot of time crafting the PHP codebase so you don't have to look at the underlying assembly. There is a certain amount of trust that I as a PHP developer assume. Is this what the agents do? No. They scrape random bits of code everywhere and put something together with no craft. How do I know they won't hide exploits somewhere? How do I know they don't leak my credentials?
- 6510 9mo ago
  That is true for all languages. Very high quality until you use a lib, a module or an api.
jkhdigital 9mo ago
Your analogy to PHP developers not reading assembly got me thinking. Early resistance to high-level (i.e. compiled) languages came from assembly programmers who couldn’t imagine that the compiler could generate code that was just as performant as their hand-crafted product. For a while they were right, but improved compiler design and the relentless performance increases in hardware made it so that even an extra 10-20% boost you might get from perfectly hand-crafted assembly was almost never worth the developer time. There is an obvious parallel here, but it’s not quite the same. The high-level language is effectively a formal spec for the abstract machine which is faithfully translated by the (hopefully bug-free) compiler. Natural language is not a formal spec for anything, and LLM-based agents are not formally verifiable software. So the tradeoffs involved are not only about developer time vs. performance, but also correctness.
- ytoawwhra92 9mo ago
  For a great many software projects no formal spec exists. The code is the spec, and it gets modified constantly based on user feedback and other requirements that often appear out of nowhere. For many projects, maybe ~80% of the thinking about how the software should work happens after some version of the software exists and is being used to do meaningful work. Put another way, if you don't know what correct is before you start working then no tradeoff exists.
  - majormajor 9mo ago
    > Put another way, if you don't know what correct is before you start working then no tradeoff exists. This goes out the window the first time you get real users, though. Hyrum's Law bites people all the time. "What sorts of things can you build if you don't have long-term sneaky contracts and dependencies" is a really interesting question and has a HUGE pool of answers that used to be not worth the effort. But it's largely a different pool of software than the ones people get paid for today.
    - ytoawwhra92 9mo ago
      > This goes out the window the first time you get real users, though. Not really. Many users are happy for their software to change if it's a genuine improvement. Some users aren't, but you can always fire them. Certainly there's a scale beyond which this becomes untenable, but it's far higher than "the first time you get real users".

straydusk 9mo ago

I'm glad you wrote this comment because I completely agree with it. I don't think that there is not a need for software engineers to deeply consider architecture; who can fully understand the truly critical systems that exist at most software companies; who can help dream up the harness capabilities to make these agents work better. I just am describing what I'm doing now, and what I'm seeing at the leading edge of using these tools. It's a different approach - but I think it'll become the most common way of producing software.

re-thc 9mo ago

> that is they are describing a new type of programmer that will only use agents and never read the underlying code > and wouldn't look at the code anymore than, say, a PHP developer would look at the underlying assembly This really puts down the work that the PHP maintainers have done. Many people spend a lot of time crafting the PHP codebase so you don't have to look at the underlying assembly. There is a certain amount of trust that I as a PHP developer assume. Is this what the agents do? No. They scrape random bits of code everywhere and put something together with no craft. How do I know they won't hide exploits somewhere? How do I know they don't leak my credentials?

6510 9mo ago
That is true for all languages. Very high quality until you use a lib, a module or an api.

jkhdigital 9mo ago

Your analogy to PHP developers not reading assembly got me thinking. Early resistance to high-level (i.e. compiled) languages came from assembly programmers who couldn’t imagine that the compiler could generate code that was just as performant as their hand-crafted product. For a while they were right, but improved compiler design and the relentless performance increases in hardware made it so that even an extra 10-20% boost you might get from perfectly hand-crafted assembly was almost never worth the developer time. There is an obvious parallel here, but it’s not quite the same. The high-level language is effectively a formal spec for the abstract machine which is faithfully translated by the (hopefully bug-free) compiler. Natural language is not a formal spec for anything, and LLM-based agents are not formally verifiable software. So the tradeoffs involved are not only about developer time vs. performance, but also correctness.

ytoawwhra92 9mo ago
For a great many software projects no formal spec exists. The code is the spec, and it gets modified constantly based on user feedback and other requirements that often appear out of nowhere. For many projects, maybe ~80% of the thinking about how the software should work happens after some version of the software exists and is being used to do meaningful work. Put another way, if you don't know what correct is before you start working then no tradeoff exists.
- majormajor 9mo ago
  > Put another way, if you don't know what correct is before you start working then no tradeoff exists. This goes out the window the first time you get real users, though. Hyrum's Law bites people all the time. "What sorts of things can you build if you don't have long-term sneaky contracts and dependencies" is a really interesting question and has a HUGE pool of answers that used to be not worth the effort. But it's largely a different pool of software than the ones people get paid for today.
  - ytoawwhra92 9mo ago
    > This goes out the window the first time you get real users, though. Not really. Many users are happy for their software to change if it's a genuine improvement. Some users aren't, but you can always fire them. Certainly there's a scale beyond which this becomes untenable, but it's far higher than "the first time you get real users".