161–170 of 174 posts
Earlier quoted context omitted.
That's the original context of the Andrej Karpathy comment, but it's just synonymous with LLM assisted coding now.
Not yet, but the more you will insist, the more it will be. But what is your proposal for differentiating between just prompting without looking at code vs just using LLM to generate code?
Earlier quoted context omitted.
Build tools to keep it in check.
Really, this. You still need to check its work, but it is also pretty good at checking its work if told to look at specific things. Make it stop. Tell it to review whether the code is cohesive. Tell it to review it for security issues. Tell it to review it for common problems you've seen in just your codebase . Tell it to write a todo list for everything it finds, and tell it fix it. And only review the code once it'…
I want to see this code written to some objective, to compare with what I would have written to the same objective. What I've seen so far are specs so detailed that very little is left to the discretion of the LLM.
What I want to see are those where the LLM is asked for something, and provided it because I am curious to compare it to my proposed solution.
(This sounds like a great idea for a site that shows users the user-submitted task, and only after they submit their attempt does it show them the LLM's attempt. Someone please vibe code this up, TIA)
Earlier quoted context omitted.
It sounds like you've never worked a job where you aren't just supporting 1 product that you built yourslef. Fix the bug and move on. I do not have the time or resources to understand it fully. It's a 20 year old app full of business logic and MS changed something in their API. I do not need to understand the full stack. I need to understand the bug and how to fix it. My boss wants it fixed yesterday. So I fix it and…
> It sounds like you've never worked a job where you aren't just supporting 1 product that you built yourslef In my 40 years of writing code, I’ve worked on many different code bases and in many different organisations. And I never changed a line of code, deleted code, or added more code unless I could run it in my head and ‘know’ (to the extent that it’s possible) what it will do and how it will interact with the re…
Or you were never under time pressure and always had enough time to do it.
Either way, I'm jealous for you. For me it's "here's code that Bob wrote 10 years ago, it's not working. Customers are complaining and this needs to be fixed yesterday".
"Sorry I need to understand what it will do and how it will interact with the rest of the project, that'll take a few days and I can't fix it before that" wasn't an option. You fix the immediate issue, run whatever tests it may have and throw it to QA for release approval.
Most likely the fix will work and nobody has to touch that bit in a few years. Should we spend time to understand it fully and document it, add proper and comprehensive tests? Yep. But the bosses will never approve the expense.
If I had an AI agent at point, it could "understand" the codebase in minutes and give me clues as to what's the blast radius for the possible fix.
Earlier quoted context omitted.
That’s only possible for relatively small projects.
Don't you have a fully conceptualized mental model of your body, to the point that you are quite functional with it? Isn't your body far, far, far more complicated than any software project could be? How'd you reckon?
[0] Which becomes painfully obvious when one ages, as all kinds of things start to hurt, and one doesn’t have a good understanding of why exactly, and how to stop it.
Earlier quoted context omitted.
Maybe read the original definition: https://x.com/karpathy/status/1886192184808149383 Or here: https://en.wikipedia.org/wiki/Vibe_coding Not looking at the code at all by default is essential to the term.
I agree, i'm saying any code it produces. Eg if you ignore 95% of the LLM's PR, are you vibe coding? Some would say no, because you read 5% of the PR. I would say yes, you are vibe coding. Ie you could say you vibe'd 95% of the PR, and i'd agree with that - but are you vibe coding then? You looked at 5% of the code, so you're not ignoring all of the code. Yet in the spirit of the phrase, it seems silly to say someone…
Earlier quoted context omitted.
I think the difference between the two is shrinking by the day. At this point I almost never need to address anything with the LLM's solution and could easily just go straight to testing for most things. The key difference is still the prompts and knowing what to reference/include in the context.
> I think the difference between the two is shrinking by the day. At this point I almost never need to address anything with the LLM's solution and could easily just go straight to testing for most things. Do you believe that atrophy is not a real thing? I've found that LLMs massively over-engineer things, regardless of the prompt used. How do you counter that without going back and forth at least a few times?
I still check the output but it is starting to feel like a sanity check more than a code review.
Earlier quoted context omitted.
"It was a non-trivial project, and I had to be paying attention to what the agent was doing" There is a big difference between vibe coding and llm assisted coding and the poster above seems to be aware of it.
Vibe coding is the name for LLM assisted coding, whether you like it or not.
I don't want to be that contrarian guy, but I find it energizing to go faster. For example, being able to blast through a list of niggling defects that need to be fixed is no longer a stultifying drag. I recently used a coding agent on a project where I was using an unfamiliar language, framework, API, and protocol. It was a non-trivial project, and I had to be paying attention to what the agent was doing because it…
There's something exhilarating about pushing through to some "everything works like I think it should" point, and you can often get there without doing the conscientious, diligent, methodical "right" way of doing things, and it's only getting easier. At the point where everything works, if it's not just a toy or experiment, you definitely have to go back and understand everything. There will be a ton to fix, and it m…
The exuberance of rapid early-stage development is mirrored by the despair of late-stage realizations that you've painted yourself into a corner, you don't understand enough about the code or the problem domain to move forward at all, and your AI coding assistant can't help either because the program is too large for it to reason about fully.
AI lets you make all the classic engineering project mistakes faster.
Earlier quoted context omitted.
I agree, i'm saying any code it produces. Eg if you ignore 95% of the LLM's PR, are you vibe coding? Some would say no, because you read 5% of the PR. I would say yes, you are vibe coding. Ie you could say you vibe'd 95% of the PR, and i'd agree with that - but are you vibe coding then? You looked at 5% of the code, so you're not ignoring all of the code. Yet in the spirit of the phrase, it seems silly to say someone…
The question is, to what purpose are you looking at those 5%? I reckon it’s because you don’t really trust the vibes. In that sense, you’re not vibe-coding.
I don't care about the 5% difference. I care about the bulk, the amount of bugs and poor logic that can slip in, etc. I have no attachment to the term "vibe coded", but it's useless to me if it doesn't describe this scenario.
Earlier quoted context omitted.
Vibe coding is the name for LLM assisted coding, whether you like it or not.
I disagree, "vibe" characterizes how the LLM is being used, not that AI is being used at all. The vibe part means it's not rigorous. Using an LLM to autocomplete a line in an otherwise traditionally coded project would not be considered "vibe" coding, despite being AI assisted, because the programmer can easily read and verify the line is as correct as if they had typed it character by character.