This has been the majority of my professional coding experience since the 90's ::shrug::. Having to take ownership of some Java Spring application felt a lot like stepping through an assembly program or some random ROM. Each line of code just returns values and modifies a bunch of other stuff at the same time and you slowly build up a mental model of what it's doing and what it's trying to do!
The way I approach is, I try to design or solve the issue first to the best of my ability, then I let the LLM give me its solution. Compare and take whatever is useful. I know this is not the most effective way, but it's the way I feel like I'm still thinking and not becoming super dependent.
I find that even though I have to spend time understanding what the llm wrote, it's still faster and less energy sapping than if i write the code myself.
Plus I just get the LLM to write tests for it's code and I make sure the coverage is complete.
But it does make me feel uneasy still, like a dirty little cheat.
i've learned a ton from ai suggestions, but right now its like 5-10% of suggestions. If that number was any higher i might not have the motivation to open the black box
... but without all the signs we look for as proof that a given library must not be too bad, since those signs are traces left by developers and by other users of the library, and LLM-generated code doesn't have any other users (I mean, to the extent it's copying existing code, kinda, but it'll be remixed and removed from its original context, so good luck tracking down the source and double-good-luck figuring out if any proof of quality found there is relevant to what you've got)
> One problem I have is that AI is writing code I don't understand completely, yet I'm still responsible for it.
With vibe coding, you are as much a reviewer/editor as an author, and as an editor should never accept generated code that you don't understand. Happily, the same technology that generated the code can explain the code.
No, with vibe coding you are not a reviewer an editor or an author, quoting from the source:
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
...
I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it.
No, they actually have the files pane on the left, live preview mid-top, terminal errors mid-bottom, and the agent on the right. no looking at code.
Cursor has a "yolo mode" where you don't have to click accept for tooling even for system commands and people whitelist commands like sudo, su, and rf :))) I wish I was kidding.
The vibes are coming from changing to actual product (design, UX, functionality) and not from the code. The code in fact doesn't matter at all. At this point that's only ok for throwaway prototypes (but for those it's quite wonderful), the more the application requires careful maintainable engineering, you need to read every line and leash the LLM. It's a bit of a continuum between the two edges in reality.
> No, with vibe coding you are not a reviewer an editor or an author, quoting from the source:
That was the joke, which Karpathy found "quite amusing" and "not too bad for throwaway weekend projects". In reality, you won't even get that far with vibe coding if you don't understand what's going on.
Considering a library is just a component of the application and not the whole application itself. And one can typically understand the inputs and outputs of a library without having to know the detailed functionally of the code behind the library. I would say yes, it is different.
But this of course can still open up potential vulnerabilities or unexpected behavior. The way I see it, there is some level of trust behind the library that it was built competently
I don't think I've ever seen that actually happen, if you mean reading a meaningful amount of the dep's code.
How many teams importing React have even one member who's ever read even a dozen key paths & files in the React codebase? Think it's more than 10%? I'd bet it's closer to 1% than 10%, of teams on which even one member has done that, ever. Do they check the diff for every update? Shit, IME you're lucky if a single person reads the entire changelog before updating, and certainly nobody's reading the diff. Repeat for everything else. Functionally nobody does this, outside niches where small numbers of low-line-count deps are the norm.
Rails, all those imports from Square you used to have to use to cut the "WT actual F is this?" rate in Android dev to something non-crazy making, et c. Basically nobody even skims this stuff, and I don't think the number of businesses willing to pay for their developers to do that is large.
Like any legacy code, understanding the codebase does not mean reading and memorizing every line in the repo. It's a sense of understanding the rough data flow, then having more intimate understandings of the functions you need at that moment.
Unlike "vibes" there should always be a sense of purpose on why each function is needed and what you plan to do with the output, even if in some cases you treat hat function like a black box in terms of implementation (which IMO should be avoided, but situations may make the implementation above your understanding).