You know how the average dev will roll their eyes at taking over a maintenance of a "legacy" project. Where "legacy" means anything not written by themselves. Well, there will be a lot more of these maintenance takeovers soon. But instead of taking over the product of another dev agency that got fired / bankrupt / ..., you will take over projects from your marketing department. Apps implemented by the designers. Projects "kickstarted" by the project manager. Codebases at the point antropic / google / openai / ... tool became untenable. Most likely labelled as "just needs a little bit more work".
These LLM tools are amazing for prototypes. Amazing. I could not be anywhere near as productive for churning out prototypes as claude code is, even if I really tried. And these prototypes are great tools for arriving at the true (or at least slightly better) requirements.
Prototypes should get burned when "real" development starts. But they usually are not. And we're going to do much, much more prototyping in very near future.
> Apps implemented by the designers. Projects "kickstarted" by the project manager. Codebases at the point antropic / google / openai / ... tool became untenable. Most likely labelled as "just needs a little bit more work".
True, but not a new thing! You've never known true development pain until you're told something from another department "needs some help to get productionized", only to find out that it's a 300 tab Excel file with nightmarish cross-tab interdependencies and VBA macros.
Genuinely not sure if vibe coded Python would be an improvement for these type of "prototype" projects. They'll definitely continue to exist, though.
A friend got hired by a defense contractor to be the first developer on a new project! Greenfield developing! It turned out the project was here are 30,000 lines of Fortran77 written by two scientists who got Ph.Ds in Geology in ~1985, please make this do X, Y, and Z.
He left that job a week later. It never went on his resume or LinkedIn.
The prompts used to generate it might serve as a list of requirements, which would be helpful. If the codebase is an utter mess, rebuilding the app from prompts would be an option.
I have no idea whether these sorts of projects would be a rewrite or just tidying up, though. I haven't seen what happens when people with no coding experience prompt these. The code I've seen devs get LLMs to generate is usually okay enough to maintain. Not ideal, but workable.
Well… at least the vibe coded python codebase has better tooling. There are probably some cool tools for fixing rats nests of Macro’d Excel, but I’ve never found them.
> Prototypes should get burned [...] But they usually are not.
"There's nothing more permanent than a temporary solution that works"
I loved reading this blog post[0]. Everything starts with a spreadsheet and then instead of replacing it, people just keep building on top of it forever.
While I found the post funny to read, honestly I'm fine with all the mess. I'm happy to embrace it instead of forever polishing something that I will never ship.
Vibe coded apps are next level of mess though and people don't seem to recognise that while betting on 'AI will fix it later'.
What bums me out is the creativity of coming up with the idea and seeing it through. If the rest of my career involves cleaning up prototypes from PMs, designers and marketing, I will be a little sad.
You know how the average dev will roll their eyes at taking over a maintenance of a "legacy" project. Where "legacy" means anything not written by themselves. Well, there will be a lot more of these maintenance takeovers soon. But instead of taking over the product of another dev agency that got fired / bankrupt / ..., you will take over projects from your marketing department. Apps implemented by the designers. Projects "kickstarted" by the project manager. Codebases at the point antropic / google / openai / ... tool became untenable. Most likely labelled as "just needs a little bit more work".
These LLM tools are amazing for prototypes. Amazing. I could not be anywhere near as productive for churning out prototypes as claude code is, even if I really tried. And these prototypes are great tools for arriving at the true (or at least slightly better) requirements.
Prototypes should get burned when "real" development starts. But they usually are not. And we're going to do much, much more prototyping in very near future.