5 ms·
In my experience, it’s even more effort to get good code with an agent-when writing by hand, I fully understand the rationale for each line I write. With ai, I
by bfbf 7mo ago
In my experience, it’s even more effort to get good code with an agent-when writing by hand, I fully understand the rationale for each line I write. With ai, I have to assess every clause and think about why it’s there. Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment); that’s not at all my experience with Codex.
Last month I did the majority of my work through an agent, and while I did review its work, I’m now finding edge cases and bugs of the kind that I’d never have expected a human to introduce. Obviously it’s on me to better review its output, but the perceived gains of just throwing a quick bug ticket at the ai quickly disappear when you want to have a scalable project.
- cpursley 7mo agoThrow your next bug at this: https://skills.sh/obra/superpowers/systematic-debugging https://skills.sh/obra/superpowers/systematic-debugging
- mixologic 7mo agoI find it amazing that skills are essentially excellent tools for humans to understand too.
- Vegenoid 7mo agoI really wish they were called lessons instead of skills. It makes way more sense and prevents the overloading of the term "skill".
- soulofmischief 7mo agoWe'd just be overloading "lessons" as well, and even more so because it takes more work to ground the concept, given its larger semantic distance from what we're describing.
- mycall 7mo agoThere is some papers [0] showing that the skill and agent files reduce the reasoning effectiveness in some use cases (e.g. autogenerated) [0] https://arxiv.org/abs/2602.11988 https://arxiv.org/abs/2602.11988 reference: https://news.ycombinator.com/item?id=47034087 https://news.ycombinator.com/item?id=47034087
- frgturpwd 7mo agoI hear you, but it seems quicker to predict whether the agent's solution is correct/sound before running it than to compose and "start" coding yourself. Understanding something that's already there seems like less effort. But I guess it highly depends on what you are doing and its level of complexity and how much you're offloading your authority and judgment.
- zozbot234 7mo agoYou need to have the AI write an increasingly detailed design and plan about what to code, assess the plan and revise it incrementally, then have it write code as planned and assess the code. You're essentially guiding the "Thinking" the AI would have to perform anyway. Yes, it takes more time and effort (though you could stop at a high-level plan and still do better than not planning at all), but it's way better than one-shotted vibe code.
- edgyquant 7mo agoThis works but still lacks most context around previous tasks and it isn’t trivial to get it to take that into account.
- pdhborges 7mo agoThe problem is those plans become huge. Now I have to review a huge plan and the comparatively short code change.
- zozbot234 7mo agoIt shouldn't be any longer than the actual code, just have it write "easy pseudocode" and it's still something that you can audit and have it translate into actual coding.
- mycall 7mo agoTDD is a great way to start the plan, stubbing things it needs to achieve with E2E tests being the most important. You still need to read through them so it won't cheat, but the codebase will be much better off with them than without them.
- heisenbit 7mo agoThere is demand for non scalable, not committed to be maintained code where smaller issues can tolerated. This demand is currently underserved as coding is somewhat expensive and focused on critical functions.
- Retr0id 7mo agoWhat are some examples of when buggy code can be tolerated?
- simonw 7mo agoIf the code is being used by a small group of people who are willing to figure out and share workarounds for those bugs - internal staff, for example.
- skydhash 7mo agoAren’t you also paying internal staff for their time. Waisting their time is waisting your money.
- simonw 7mo agoI've been in these situations before. If there's a known bug in an internal tool that would take the development team a day to investigate and fix - aka $10,000s - it's often smarter to send around an email saying "don't click the Froople button more than once, and if you do tell Benjamin and he'll fix it in the database for you". Of course LLMs change that equation now because the fix might take a few minutes instead.
- dns_snek 7mo ago> development team a day to investigate and fix - aka $10,000s What about the non-fictional 99.999999999% of the world that doesn't make $1000/hour?
- vips7L 7mo ago> Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment) Even my seniors are just copy pasting out whatever Claude says. People are naturally lazy, even if they know what they’re doing they don’t want to expend the effort.