4 ms·

Long-term SWEs at non-tech companies will spend much of their time reviewing vibe coded features/prototypes/scripts from non-technical employees and scaling the

by jjmarr 1y ago

Long-term SWEs at non-tech companies will spend much of their time reviewing vibe coded features/prototypes/scripts from non-technical employees and scaling them once they become critical infrastructure. This'll eliminate jobs in the "develop CRUD app" industry but will create better jobs in security/scalability/quality expertise. But it'll take a few years as all these vibe coded business process scripts start to fail. Programmers miss the human element, which is that many managers look at a software project as too risky, even if automating a business process could trivially save money. There are millions of people in the USA who spend most of their day manually transferring data from incompatible systems. AI allows anyone to create a hacky automation that demonstrates immediate value but has obvious flaws that can be fixed by a skilled SWE. That will make it easier to justify more spending on devs.

bitwize 1y ago
That is literally the exact promise of CASE tools in the 80s and the early 90s; UML code generation tools in the 2000s, and "low-code/no-code" platforms in the 2010s. It turned out to be a disaster every time, especially when the Idea Persons chucked their creations over the wall to SWEs to bash them into actual products because the Idea Persons had Far More Important Things To Do than maintain their coalesced brain farts. We're repeating history but with more energy consumption.
- ndileas 1y ago
  I wasn't around for the second millennium versions. At some point, doesn't there exist a kind of activation energy threshold where enough money/promise etc is gained from the prototype that this pattern works for good ideas and not for bad ones?
- bonsai_spool 1y ago
  I do think that there’s a difference in kind here - we’re not producing UML graphs that require programmer time to implement (or sending the diagrams to SE Asia and then code reviewing). The code ‘works’ - and the folks who are improving the prototype can also benefit from the tools that the Idea Person used.
  - sarchertech 1y ago
    The code worked for the examples the OP gave as well. They weren’t talking just about UML graphs, but about automated tools to turn those graphs into code. And in the case of low code/no code, those produced working prototypes as well. And you could in most cases export them to raw code.
- quxbar 1y ago
  LLMs unlock a fundamentally different paradigm of interaction, in my experience a non-technical person with a good humanities background can describe what they want adequately. This is without needing to master the arbitrary grammar of a no-code system. Does often inevitably turn out to be a 'toy' version of what a real business needs? Yes, but it's still strictly better than previous ways of working.
- jjmarr 1y ago
  It was a disaster because the tools were too difficult to use by their end-users, not because the software quality sucked. Meanwhile my mom can vibe code actual Python scripts to do parts of her job now.
ares623 1y ago
There better be new bootcamps on how to maintain these systems because without CRUD jobs how would someone new get the experience

by jjmarr 1y ago

bitwize 1y ago

That is literally the exact promise of CASE tools in the 80s and the early 90s; UML code generation tools in the 2000s, and "low-code/no-code" platforms in the 2010s. It turned out to be a disaster every time, especially when the Idea Persons chucked their creations over the wall to SWEs to bash them into actual products because the Idea Persons had Far More Important Things To Do than maintain their coalesced brain farts. We're repeating history but with more energy consumption.

ndileas 1y ago
I wasn't around for the second millennium versions. At some point, doesn't there exist a kind of activation energy threshold where enough money/promise etc is gained from the prototype that this pattern works for good ideas and not for bad ones?
bonsai_spool 1y ago
I do think that there’s a difference in kind here - we’re not producing UML graphs that require programmer time to implement (or sending the diagrams to SE Asia and then code reviewing). The code ‘works’ - and the folks who are improving the prototype can also benefit from the tools that the Idea Person used.
- sarchertech 1y ago
  The code worked for the examples the OP gave as well. They weren’t talking just about UML graphs, but about automated tools to turn those graphs into code. And in the case of low code/no code, those produced working prototypes as well. And you could in most cases export them to raw code.
quxbar 1y ago
LLMs unlock a fundamentally different paradigm of interaction, in my experience a non-technical person with a good humanities background can describe what they want adequately. This is without needing to master the arbitrary grammar of a no-code system. Does often inevitably turn out to be a 'toy' version of what a real business needs? Yes, but it's still strictly better than previous ways of working.
jjmarr 1y ago
It was a disaster because the tools were too difficult to use by their end-users, not because the software quality sucked. Meanwhile my mom can vibe code actual Python scripts to do parts of her job now.

ares623 1y ago

There better be new bootcamps on how to maintain these systems because without CRUD jobs how would someone new get the experience