4 ms·

I recently reviewed an app built mostly with vibe coding. The owner said it was almost ready to launch and just needed a quick check. After looking through it,

• jonkoops 4mo ago
  Honestly, this is my experience as well. LLMs make it easier to explore other domains, but they do not make you the master of one; you still need expert domain knowledge. That said, they do make excellent tools to quickly try out new ideas and dive into them; they can even be great learning accelerators if you have a curious mind.
• aaronbrethorst 4mo ago
  Totally agree.
• jaggederest 4mo ago
  Where I am headed, I think, is to basically be a platform engineer. The job is to create the guardrails, validation, prompt library, and both agent and manual reviews; that keeps the domain experts safe when they start using coding agents. It's a little bit like being T2/T3 customer support [or support engineer], but internal. You're there to catch the dangerous spots, the weird edge cases, and to make sure that everything is set up correctly, rather than to solve 100% of the routine problems yourself. There's also plenty of room for cross-cutting-concerns, of course
  • brandensilva 4mo ago
    Eventually infrastructure will be more simple to orchestrate too without faults I suspect from well developed devops harnesses. The risk and scale companies are willing to accept will still fall on humans for some time even then. I don't see most people vibe coding a million user app that has deeper needs than the basics we see now.
  • trojans1290 4mo ago
    Can you elaborate more on this type of role? Stack? Etc.
    • jaggederest 4mo ago
      I honestly just go with whatever the company is using - these days often typescript, and I build tooling and systems that catch errors and review PRs produced partially or completely by the domain experts. Nothing fancy about it, just good old engineering, where when an issue arises you create a test for it and make sure it can never reoccur, educate users, set up the correct infra, and lock down permissions (it's never been easier or more fun to set up an incredibly draconian role in e.g. aws IAM)
• xkcd-sucks 4mo ago
  Domain expertise combined with a QA mindset could replace SWE, but consistent QA mindset is rare
  • rustystump 4mo ago
    I don’t think so. Most things are sufficiently complicated enough to require multiple domain experts working together to achieve a goal. The dunning kruger effect is in full swing as people think AI replaces the domain expert need. Most of the value in the expert isnt the 80% but the tail 20% or 10% where AI fails. For a one of personal app or website, 80% is plenty but only that.
  • eggplantemoji69 4mo ago
    Personally my ability to understand atrophies / is reduced when compared to writing code ‘myself’ rather than fully being a reviewer. Probably similar to hand writing notes (while digesting + synthesizing and not just being a scribe) vs reading notes somebody else took.
    • cm11 4mo ago
      I'm guessing there's some science or research behind this, but I agree. Similarly, I've had projects where I did everything fairly solo—programmed, designed ux/ui, maybe validated with users, etc. It was significantly harder, particularly in the phase where you're working between the first two and the idea isn't perfectly set. It worked much better to design, then build in explicit steps, but it was so easy to start coding, have the design looking and feeling okay, then start iterating on the design—but iterating in code rather than Figma or wherever. It's fine for a little while, but you realize you've spent a day (maybe more) doing it in this less efficient way. It's similar to the 80/20 rule. When you're coding and designing from the hip, you'll do pretty well for awhile, but as you near completion, you can't quite tie up all the loose design ends. That's the part where it's probably better to just design fully to 100% first and then build, which is closer to what happens when the roles are separate. At least in my experience. I will say though that that part where you're designing in code (productively or wastefully) is pretty fun. At least until you hit the wall and get frustrated with how often you've deleted and rewrote the same thing ten times.
• consumer451 4mo ago
  > I used billions of tokens last month alone. I use Claude Code (Opus 4.6 at max effort) all day long, and I genuinely don't understand how this is possible. Is that usage paying off? This is very likely due to my lack of understanding, but... how?
  • letitgo12345 4mo ago
    Long codex sessions lead to a lot of cached token hits, esp when you resume them after a few hours.
    • consumer451 4mo ago
      I personally don't count cached hits as $used... Neither in my harnesses, nor in the LLM-enabled apps I create. A cached token cannot be counted 1:1 as to a non-cached token, that would be silly. Wait... when some Claude 5x/20x users say they are getting "$2000 of tokens for $100," does the 2k value include cached tokens, counted at the same $/token either way? We cannot be this dumb as a community, can we? I must be wrong/misunderstanding..
      • SatvikBeri 4mo ago
        I'm a fairly moderate user, never hit any kind of usage limits, but I used 44 million cache create tokens and 1.5 billion cache read tokens, which ccusage estimates would have cost $990, and calculates the different categories separately.
  • andai 4mo ago
    Vibe coded a simple game (10,000 tokens of source code) with two popular coding agents. (Once each, to compare.) One spent 200,000 tokens, to produce 10,000. The other spent 1.9 million. It could have been a single LLM call (10k tokens). lmao (I note that the latter was designed by a company whose main source of revenue is token spend...)
    • crab_galaxy 4mo ago