In some ways they are giving you a spec and UI mocks to implement.
Then we go back to the old “the prototype works; I’m the boss and I’m telling you to deploy it to production”
I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a process, the quality of code/architecture matters little if the low bar of functionality is met. Functionality can be sold to customers or used to test the market. It’s basically the whole MVP thing and the MVP should be a bit jank. If it wasn’t, you spent too much time/effort on it.
All said, there’s definitely some approaches to make it less jank from day one. Unfortunately, jankiness is a subjective metric.
If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.
You will never get the chance of "customers requesting changes" if you never ship.
The company with the janky code that shipped will. And they will iterate and get better - as described by your process.
Why does good code imply never shipping?
Managers and Developers have different thresholds for “good enough to release”. The former are not the one on call for bugs or the one that get blamed for outage, but they are the ones that get praised when projects are completed quickly. Anything that’s past demo level is good for them.
For example: Company A - janky code, ships quick Company B - great code, ships quick Company C - great code, ships slow Company D - janky code. Ships slow
The average survival rate will be in the following order: B > A > C > D
My point is company A will capture the market and iterate quicker than company C.
Company B is what you're probably thinking of , and what many people think they are building.
Company D is what most people are actually building.
Company C will win out in the long run over company B if they have capital and network.
Product Managers coding is like Developers writing marketing pitches.
Worse, often you need to spend years before you realize how an initial design decision was a mistake - not only are you proposing to throw away millions of dollars worth of work - you also don't know that your proposed better design is really better.
Heard it so many times.
Experienced developers in a domain can sometimes anticipate the issues, but experience only comes from failing.
The real answer is allowing some budget to fix things and then fixing them as you go along.
The prototypers, who move fast and break things, who throw together shiny first versions that look great and work some of the time;
The architects, who take the prototypes and take the time to build it correctly;
And the gardeners, who maintain the built system for the next 10-30 years, fixing bugs, making incremental improvements to speed or resource usage, and updating dependencies so that it continues to function on modern machines.
The crazy thing is that there are a ton of developers with different tastes who would love to fill each of the roles, but not many companies that are able to manage all three types without pushing everyone into one bucket.
Like they actually iterate on the UX alot when they are vibecoding things up, answer alot of questions that can onky be answered when you see an initial version of experience and realize something is off. Id rather they waste the clankers time with that than mine
One of my faults is "When somebody tries to explain something I hear 'A' and everyone else in the room hears 'B'". And vice-versa. But if someone can iterate a very VERY rough cut of what they want and hand it off to a design / development team ... well ... damn. That might make everyone's life a lot easier.
You're saying even that bit doesn't require them.