When coding style has been established among a team, or within an app, there are a lot of extra hoops to jump through, just to get it to look The Right Way, with no detectable benefit to the user.
If you put those choices aside and simply say: does it accomplish the goal per the spec (and is safe and scalable[0]), then you can get away with a lot more without the end user ever having a clue.
Sure, there's the argument for maintainability, and vibe coded monoliths tend to collapse in on themselves at ~30,000 LOC. But it used to be 2,000 LOC just a couple of years ago. Temporary problem.
[0]insisting that something be scalable isn't even necessary imo
You can control some simple things that way. But the subtle stylistic choices that many teams agree on are difficult to articulate clearly. Plus they don’t always do everything you tell them to in the prompts or rule files. Even when it’s extremely clear sometimes they just don’t. And often the thing you want isn’t clear.
Except the fact that the idioms and patterns used means that I can jump in and understand any part of the codebase, as I know it will be wired up and work the same as any other part.
I think here “to the user” is referring to the end user, not the programmer (the user of the coding style). There is a comprehension benefit for the team working on the code, but there is no direct¹ benefit to the end user.
--------
[1] The indirect benefits of there possibly being a faster release cadence and/or fewer bugs, could also be for many other reasons.
But you could say the same about tests, documentation, CI, issue trackers or really any piece of technology used. So it's not a very interesting statement if so.
> When coding style has been established among a team, or within an app, there are a lot of extra hoops to jump through, just to get it to look The Right Way, with no detectable benefit to the user.
Morphing an already decent PR into a different coding style is actually something that LLMs should excel at.
Do you have any references for "vibe coded monoliths tend to collapse in on themselves at ~30,000 LOC"? I haven't personally vibed up anything with that many LOC, so I'm legitimately curious if we have solid numbers yet for when this starts to happen (and for which definitions of "collapse").
Just my experience in vibe coding apps from gpt-3.5 onwards (mostly NextJS or Node). In gpt-3.5, I had to really hand-hold it, getting it to write one function at a time, then a separate task to glue the functions together.
Now, it can build almost all of an app from a single prompt, but will start to rewrite utility functions, or modules, forgetting that they already exist. Some of this is still solvable with clever prompting, but if you're just attacking it without thinking, ~30,000 LOC seems to be the app 'size' that it will start to exhibit those behaviors.
Related: does anyone know of a way to delete the original videos on trimmed ones? Apparently all edits to videos are non-destructive, so the 10-minute video that I trimmed to 2 seconds still takes up 8gb.
Incredible. I have such a hacked-together system to get my iCloud Photos backed up to an external drive while not filling my main laptop drive. This would be even better.
Lemay's appointment was widely celebrated, but he'd been at apple since 1999 and never got the gig. My guess is that there are valid reasons for that that may not be design-related.
Seems very clear now that we are going to see touch screen MacBooks. Which is a very silly idea. But explains why the UI "snaps" like an iPad, and everything is designed for touch.
More evidence that "coding elegance" is irrelevant to a product's success, which bodes well for AI generated code.
reply