7 ms·

I'd like to share with HN an almost exact message I got from Fable today, with exactly ONE word changed for privacy reasons. I love what I can build now, but I

by jorl17 1mo ago

I'd like to share with HN an almost exact message I got from Fable today, with exactly ONE word changed for privacy reasons. I love what I can build now, but I sure as hell don't love the headaches this trend has been giving me. > So the full honest arc on the case we set out to fix: the expiry rules and day note tripled the loose version of the story, the relay fix carried the device’s own guardrail through the pipeline, the fair replay then revealed the last mechanism — ticket-anchoring — which none of the shipped layers reach. Remaining options, in order of my confidence: making the resolved-ticket summaries in the AI’s context carry their day so the expiry rules have something to bite on (small, mechanical, targeted at the observed anchor); and the plan-B second-model check, which structurally catches this class no matter how the model reasons. About $25 of headroom remains. Which way? Yikes. (The worst part is that I understand it)

DarmokTanagra 1mo ago
And yet you trust this abomination to write working code?
- jorl17 1mo ago
  Many things in life are about risk and tradeoffs. In some cases, I do not trust it to write code unchecked, and review everything it produces (which does not imply I catch all bugs, obviously). In other cases, occasional failure is an option, and the speed you get by iterating fast is absolutely worth not even looking at the code. So, do I trust this to write working code? Sometimes I do. If I'm doing work for a client, it is not very common for me to simply vibe code something, because part of what clients expect of me is high quality (it's part of how we position ourselves), and I cannot simply assume the LLM will produce high quality (and indeed it does not without a lot of guidance). When I do vibecode in such cases, I make it clear that I did so and why (e.g. because it's a tool to be used in the project to help DX, not a core part of the product). Still, I haven't written 10 consecutive manual lines of code in almost a year. If I'm working on something for myself, or on an internal product, then vibe coding is absolutely allowed and sometimes the norm. Here often we really do care about finding the right thing to build first. You can clearly feel the tipping point where the LLM starts to crumble under the weight of the mess it has created, but that often doesn't matter when building an MVP for market validation or for small products that don't get particularly big. Plus, clearly the tipping point takes longer to reach with better and smarter models, and to me it is very clear that you need to learn how to iterate with LLMs right. The things I vibe-code now are much better than those I did before, even with similar models, because the tooling and approaches (the "real harness" and my "mental harness") are better. As with any tool: it takes practice to know how to use it, and if you're a good engineer and problem solver, you are miles ahead of the competition. Anyone can vibecode, but those with this kind of mind seem to be much more successful. Nowadays I do produce a lot more than I used to, but I also have much more fun, perhaps only surpassed by when I learned how to code when I was a kid. A big chunk of this comes from my very privileged work position, where I get to call so many of the shots, and I'm aware of that. I would really say the biggest downside to all of this, on a personal level, is exactly what I shared: what comes out of the LLM while discussing has become hard to grasp (especially on larger context windows), and it doesn't help that so many people now like to just throw me whatever ChatGPT/Claude wrote verbatim. I can't stand that, especially because most of the time they don't realize they're throwing me incomplete and poorly thought-out ideas. Finally, naturally, like I said, this has to do with risk. I wouldn't trust Claude to give me legal advice, for example. I may check what it says and use it to brainstorm, but I wouldn't trust it with any meaningful informed decision like this.

by jorl17 1mo ago

DarmokTanagra 1mo ago

And yet you trust this abomination to write working code?

jorl17 1mo ago
Many things in life are about risk and tradeoffs. In some cases, I do not trust it to write code unchecked, and review everything it produces (which does not imply I catch all bugs, obviously). In other cases, occasional failure is an option, and the speed you get by iterating fast is absolutely worth not even looking at the code. So, do I trust this to write working code? Sometimes I do. If I'm doing work for a client, it is not very common for me to simply vibe code something, because part of what clients expect of me is high quality (it's part of how we position ourselves), and I cannot simply assume the LLM will produce high quality (and indeed it does not without a lot of guidance). When I do vibecode in such cases, I make it clear that I did so and why (e.g. because it's a tool to be used in the project to help DX, not a core part of the product). Still, I haven't written 10 consecutive manual lines of code in almost a year. If I'm working on something for myself, or on an internal product, then vibe coding is absolutely allowed and sometimes the norm. Here often we really do care about finding the right thing to build first. You can clearly feel the tipping point where the LLM starts to crumble under the weight of the mess it has created, but that often doesn't matter when building an MVP for market validation or for small products that don't get particularly big. Plus, clearly the tipping point takes longer to reach with better and smarter models, and to me it is very clear that you need to learn how to iterate with LLMs right. The things I vibe-code now are much better than those I did before, even with similar models, because the tooling and approaches (the "real harness" and my "mental harness") are better. As with any tool: it takes practice to know how to use it, and if you're a good engineer and problem solver, you are miles ahead of the competition. Anyone can vibecode, but those with this kind of mind seem to be much more successful. Nowadays I do produce a lot more than I used to, but I also have much more fun, perhaps only surpassed by when I learned how to code when I was a kid. A big chunk of this comes from my very privileged work position, where I get to call so many of the shots, and I'm aware of that. I would really say the biggest downside to all of this, on a personal level, is exactly what I shared: what comes out of the LLM while discussing has become hard to grasp (especially on larger context windows), and it doesn't help that so many people now like to just throw me whatever ChatGPT/Claude wrote verbatim. I can't stand that, especially because most of the time they don't realize they're throwing me incomplete and poorly thought-out ideas. Finally, naturally, like I said, this has to do with risk. I wouldn't trust Claude to give me legal advice, for example. I may check what it says and use it to brainstorm, but I wouldn't trust it with any meaningful informed decision like this.