{
  "path": "/posts/2025/vibe-coding",
  "site": "at://did:plc:mracrip6qu3vw46nbewg44sm/site.standard.publication/self",
  "tags": [
    "vibe_coding",
    "agents"
  ],
  "$type": "site.standard.document",
  "title": "Vibe Coding in early 2025",
  "updatedAt": "2025-07-18T13:50:16.000Z",
  "publishedAt": "2025-04-06T13:50:16.000Z",
  "textContent": "This post is an edit and repost of my rant from Bluesky\n\nSome problems with vibe coding\n\nHaving done a lot of vibe coding lately, I think I'll move away from it (for now) as a primary approach to build any software that I care about, even a little bit.\nCurrent agents eventually fail to adhere to some prompt despite various attempts and approaches.\nWhenever this happens and I look in the codebase I am usually mortified by what I find.\n\nYou might argue I need to use rules better or something like that.\nI would say that isn't vibe coding as I understand it.\nI interpret vibe coding as the agent addressing whatever whim I have in the realm of the possible, figuring it out for me.\nMostly, I end up with spaghetti codebases that the agent cannot untangle and that I don't want to untangle.\n\nAgents have a strong tendency to start generating code.\nGive one a task and it is off to the races.\nIn a new project, this approach isn't the worst thing.\nIn a project with existing functionality, this becomes a problem due to a combination of lack of context and lack of effective planning.\nThe two go hand in hand.\n\nAgents use search to look around a codebase to find relevant files to pull into context.\nYou can also use rules, documentation, or READMEs to define how an agent should structure the codebase.\nAt some point, often unbeknownst to you, the agent fails to pull a relevant file into the context window or misses reading a rule it should follow.\n\nInitially, this oversight doesn't manifest as a problem.\nThe agent does what it does best: writes some code to solve the problem.\nNo shared states available in the React app?\nNo problem, it'll write some hooks for you.\nYou validate the behavior in the browser.\nLooks good?\nCommit and ship.\nYou can get away with doing this and never reading the code...for a while.\n\nNow the codebase has fragmented state.\nYou come back to the codebase 15 commits later.\nThe application has grown considerably -- agents are good at a lot of code.\nYou prompt the agent to make more changes using the state and it fails.\nTry some follow up prompts, debug, add MCPs to pull in more context.\nWhy isn't it working?\n\nFinally you crack open the code.\nWhat are you even looking at?\nProbably something that feels like thousands of lines of a legacy codebase, even if you wrote the whole thing that week.\nYou can use the model to find which code deals with the problem you currently have.\nYou'll probably find that state is everywhere.\nState in hooks.\nState in redux.\nState in zustand.\nYou really should have written more rules to define your codebase conventions.\n\nBut it's too late.\nEven if you had reasonable codebase conventions, for every convention rule you do write there will be one the model eventually misses.\nThe agent will invisibly write working code that makes decisions on your behalf, filling in under specified requirements, and eventually you will have a tangled mess of a codebase.\n\nThe code the agent writes will work and appear to meet your requirements, but if you don't read or at least skim the code (and have some idea what you're looking at), you're not going to realize when the model deviates in its approach from what you consider reasonable.\n\nThis deviation becomes a problem only later when you realize it's happened but at that point the agent has made more poor decisions based on this initial one.\n\nWith current agents, I don't believe all of these problems can be anticipated.\nI don't believe you can rule-write your way out of them because you rarely know what the X0,000 line codebase should look like when it's only X,000 lines.\nYou can write code that remains flexible and is refactorable, but today, you can only rely on yourself to know if the agent has deviated from the rules you wrote.\nAgents don't follow instructions consistently enough to be expected to follow them without verification of the code itself.\n\nWhen I notice an agent isn't following instructions as I'd hoped, I could evaluate the plan and pull in more context in case the agent missed something.\nTo be able to do a good job of that, I need to know the codebase, at least architecturally.\nI need to know how state is managed, what libraries are used, how the file hierarchy is organized.\n\nI need to know these things in case the model misses something when generating code, so I can step in and make corrections or at least steer it back in the right direction.\nIf I only find out the model has been doing something like weird state duplication and synchronization _after_ the agent finally stops being able to make progress, it's going to be painful to get back on track.\n\nThe agent cannot be prompted to code itself out of the hole it digs.\nI've tried.\nI've told the model to identify duplication and refactor.\nI've read the code and identified the points of duplication then told the model where and prompted for a refactor.\nState of the art agents fail.\n\nSo where do I go from here?\nI've actually had immense success writing code using agents and models with my hands on the wheel.\nFor production code, this has always been the only viable option.\nBut for personal projects, I now appreciate the ceiling vibe coding places upon them.\n\nI can vibe code a fun game but eventually, I may not be able to add more features due to the unmaintainable sprawl the model eventually creates.\n\nThere is a small cost here. I have to be a touch more thoughtful as I build something to ensure the agent is staying on the rails.\n\nIn doing so I understand how my project works, learn new things as I collaborate with the agent, and keep the code in a state where it can continue to be extended.\nI'll definitely progress more slowly than fully embracing the vibes but I won't fly off the rails either.\n\nFor now, I'm out on pure vibe coding but I'll still be using models and agents often to help me write code.\n\n---\n\nReply on Bluesky",
  "canonicalUrl": "https://www.danielcorin.com/posts/2025/vibe-coding"
}