This article is not about vibe coding per se, it's about not having strong boundaries between you as the developer, and your client. You should not be allowing the client to dictate how you work, much less them having the permissions to merge in code. This was true before AI too, where clients might say, do X this way, and you should simply say no, because they are paying for your expertise*. It's like hiring a plumber then trying to tell them how to fix the toilet.
*as an aside, this reminds me of the classic joke where the client asks for the price list for a developer's services:
I do it: $500
I do it, but you watch: $750
I do it, and you help: $1,000
You do it yourself: $5,000
You start it, and you want me to finish it: $10,000
Back when I saw doing freelance work, the worst type of client was the one who was semi-technical, meaning they were technical enough to write code that they wanted to contribute to the project or to have strong architectural opinions, but not technical enough to understand the nuances and the implications of their suggestions.
I guess that, with vibe coding, it is very easy for every client to become like this.
> [...] they wanted to contribute to the project or to have strong architectural opinions
Also the worst kind of tech line-manager - typically promoted from individual contributors , but still want to argue about architecture, having arrived at their strong opinion within the 7 minutes they perused the design document between meetings.
If you're such a manager, you need to stop, if you're working with one, change teams or change jobs - you cannot win.
What are your thoughts on the idea from the book High Output Management where everyone's outputs under the manager is considered the managers output. Aka if they're choosing incorrectly it's trivial to explain the facts for them to choose right. If they don't you get them to agree to the wrong choice in writing and move on
> if they're choosing incorrectly it's trivial to explain the facts for them to choose right
It's far from trivial when there are multiple, clearly-communicated trade-offs (documented in the design doc!) that, but you happen to land on opposite ends of value-judgements (e.g. pattern A is easier to maintain based on my experience with the codebase & bugs that have popped up, but manager thinks pattern B is simpler to implement, but brittle). The debate wastes time, and signals mistrust when you're the staff engineer, or the design was OK'd by staff/rest of team
Video/audio production here and the exact same rules apply. You can’t let clients dictate your tools any more than you feel you should tell your plumber what they can use to fix your sink.
“We use Premiere.” Cool. I use Resolve. If we aren’t collaborating on the edit then this is an irrelevant conversation. You want a final product, that’s what you hired me for my dude. If you want me to slot into your existing editing pipeline that’s a totally different discussion.
“Last guy shot on a Red.” Cool. Hire them. Oh right you hired me this time. Interesting! Should we unpack that?
Freelancers: Stand your ground! Stand by your work! Tell clients to trust you!
No one said all freelancers are good, but either way none of the questions I gave as examples are indicators of my skill as a shooter/editor. The final product is all that matters. Whether I used Premiere, Resolve, FCPX, etc. to get there is immaterial.
If you pay me for a 30s highlight, you get a 30s highlight. If you don’t like the highlight itself that’s a different discussion.
This is exactly it. Some clients end up turning everything into a messy room and messy desk, decide to get help not to do it, see a clean space to create, and then start making a mess all over again.
Asking such clients why are we here? What have previous attempts (becuase they have been done) provided and not provided, and why do you think they did or didn't have long term viability so we didn't need to talk.
This is less about coding and helping people learn how to think about where and how things cna fit in.
It's great to go fast with vibe coding, especially if you like disposable code that you can iterate with. In the hands of an a developer they might be able to try more things or get more done in some way, but maybe not all the ways especially if the client isn't clear.
The ability of the client ot explain what they want well with good external signals and how well they know how to ask will often be a huge indicator long before they try to pull you into their web of creating spider diagrams like the spiders who have taken something.
When I implemented the pixelation censorship effect in The Sims 1, I actually injected some random noise every frame, so it made the pixels shimmer, even when time was paused. That helped make it less obvious that it wasn't actually censoring penises, boobs, vaginas, and assholes, because the Sims were actually more like smooth Barbie dolls or GI-Joes with no actual naughty bits to censor, and the players knowing that would have embarrassed the poor Sims.
[...]
The other nasty bug involving pixelization that we did manage to fix before shipping, but that I unfortunately didn't save any video of, involved the maid NPC, who was originally programmed by a really brilliant summer intern, but had a few quirks:
A Sim would need to go potty, and walk into the bathroom, pixelate their body, and sit down on the toilet, then proceed to have a nice leisurely bowel movement in their trousers. In the process, the toilet would suddenly become dirty and clogged, which attracted the maid into the bathroom (this was before "privacy" was implemented).
She would then stroll over to toilet, whip out a plunger from "hammerspace" [1], and thrust it into the toilet between the pooping Sim's legs, and proceed to move it up and down vigorously by its wooden handle. The "Unnecessary Censorship" [2] strongly implied that the maid was performing a manual act of digital sex work. That little bug required quite a lot of SimAntics [3] programming to fix!
Us testers have been dealing with that crap forever. Every non-tester thinks they know how a professional tester should work, and imagines our work is just writing test cases.
There are multiple stories of public facing applications with Microsoft active directory as the source of user accounts that speak to the worst examples of this.
I was involved in such an attempt but it never got off the ground.
If you haven't faced or witnessed it, it is a moment that you will not forget, and then over time little by little, realize it might not be so uncommon.
*as an aside, this reminds me of the classic joke where the client asks for the price list for a developer's services:
I do it: $500
I do it, but you watch: $750
I do it, and you help: $1,000
You do it yourself: $5,000
You start it, and you want me to finish it: $10,000