alt Hacker NewsI see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.
Maybe it won't be a program, but just some LLM context as some data dump.
This program or context will take up the role of a PM. Developers will refer to the program, or ask context for clarifications and the developer will build the actual program with or without the help from LLMs.
Replies
This is already happening.
Clients come and show me their proof of concept, fully vibecoded, because they do not know / do not have the time to take it to prod. Other comments saying this will be automated in the future... may be. But even if that is the case, time and attention are still needed to make things happen.
With the extendended capabilities IA brings, having an IT person in-house makes more sense than ever, even for small shops.
> I see a different future. A future where software developers are approached by clients with requirements in the form of an LLM generated program. They do it because they are at a point where LLM fails to make new changes without breaking existing stuff.
That's not gonna happen :-/ I've already had clients tell me they only want it modified, and their expectation is that it's only a days worth of work to make it work.
So, a requirements document for updates to a legacy system?
the program itself is kind of useless. the client will send it anyway to demonstrate a proof of concept but hopefully the dev will build from scratch
what's important is the spec. the poc isn't a spec because the dev is being hired exactly because that software doesn't solve the problem fully - whatever it has missing is the important bits
this spec will probably be generated by a llm, but there is some noise added. if the client can send their prompt, alongside the whole llm session (maybe with sensitive tool calls redacted), the dev would have everything
I expect this to be automated too, and in the end boil down to paying for more tokens to fix the program.
Code too messy to be editable by an LLM is already too horrible for humans to touch. Fixing vibecoded software as a service will boil down to reverse-engineering requirements from the messed up program, and prompting a better model to design it properly and rewrite.
Eventually models will be trained to do this themselves, so it won't be a service you ask a dev for, it will be an extra charge on your AI subscription.