7 ms·

A repeated trend is that Claude Code only gets 70-80% of the way, which is fine and something I wish was emphasized more by people pushing agents. This bullet

• throwmeaway222 1y ago
  Thanks for the tip - we employees should run and re-run the code generation hundreds of times even if the changes are pretty good. That way, the brass will see a huge bill without many actual commits. Sorry boss, it looks like we need to hire more software engineers since the AI route still isn't mathing.
  • mdaniel 1y ago
    > we employees should run and re-run the code generation hundreds of times Well, Anthropic sure thinks that you should. Number go up!
    • drewvlaz 1y ago
      One really has to wonder what their actual margins are though, considering the Claude Code plans vs API pricing
    • wahnfrieden 1y ago
      It is accurate though. I even run multiple attempts in parallel. Which is a strategy that can work with human teams too.
  • gmueckl 1y ago
    Data centers are CapEx, employees are OpEx. Building more data centers is cheap. Employees can always supervise more agents...
    • zer00eyz 1y ago
      Data centers are cap ex Except the power and cooling demands of the current crop of GPU's means you are not fitting full density in a rack. There is a real material increase in fiber use because of your now more distributed equipment. (because 800gbps interconnects are NOT cheap). You can't capitalize power costs: this is now a non-trivial cost to account for. And the more power you use for compute the more power you have to use for cooling... (Power density is now so high that cooling with something other than air is looking not just attractive but like it is going to be a requirement.) Meanwhile the cost of lending right now is high compared to recent decades... The accounting side of things isnt as pretty as one would like it to be.
      • gmueckl 1y ago
        That is a much more grounded reply than my comment deserved. Thanks!
      • dvsfish 1y ago
        Can't you capitalize power costs to an extent by building a solar and battery array? A sufficiently wealthy company would have the means to find a place to put it that can optimise for both conditions I imagine. I am a total layman in this regard though so pretty happy to be told I'm wrong. Apologies if I completely misinterpreted what you're meaning.
  • Graziano_M 1y ago
    Don’t forget to smash the power looms as well.
    • aprilthird2021 1y ago
      Is it OK to be a Luddite? https://archive.nytimes.com/www.nytimes.com/books/97/05/18/reviews/pynchon-luddite.html https://archive.nytimes.com/www.nytimes.com/books/97/05/18/r...?
      • aspenmayer 1y ago
        Must we choose between Leviathan or oblivion? Is a steady state society possible, or even desirable? https://en.wikipedia.org/wiki/William_Ophuls#Leviathan_or_oblivion?,_1973 https://en.wikipedia.org/wiki/William_Ophuls#Leviathan_or_ob...
  • godelski 1y ago
    Unironically this can actually be a good idea. Instead of "rerunning," run in parallel. Then pick the best solution. Pros: - Saved Time! - Scalable! - Big Bill? Cons: - Big Bill - AI written code
    • DANmode 1y ago
      Have you seen human-written code?
      • withinboredom 1y ago
        At least when you tell a human the indentation is wrong, they can fix it on the first try. Watched an AI agent last night try to fix indentation by using sed for 20 minutes before I just fixed it myself after cringing.
        • aeontech 1y ago
          I mean... this is a deterministic task, can just run it through autoformatter? Why ask AI to do indentation of all things?
          • theshrike79 1y ago
            This is why I have a standing order for all LLMs to run goimports on any file they've edited. It'll fix imports and minor nags without the LLM having to waste context on removing a line there or changing ' to " somewhere. Even better if you use an LLM with Hook support, just have the hook run formatters on the file after each edit.
          • jvanderbot 1y ago
            One time I explained that I was afraid of tesla full self driving, because while using it my tesla accelerated to 45mph in a parking lot that was parallel to the road and only separated by a curb. The pushback I got was "Why would you use FSD in a parking lot". Well, "Full", right? Same here. It's either capable of working unsupervised or not. And if not, you have to start wondering what you're even doing if you're at your keyboard, running tools, editing code that you don't like, etc. We're still working out the edge cases with these "Full" self driving editors. It vastly diminishes the usefulness if it's going to spend 20 minutes (and $) on stupid simple things.
• bdangubic 1y ago
  That's easy to say when the employee is not personally paying the massive amount of compute running Claude Code for a half-hour. you can do the same for $200/month
  • tough 1y ago
    it has limits too, it lasted like 1-2 weeks without only (for me personally at least)
    • artvandelai 1y ago
      The limits are in 5 hour windows. You'd have to heavily work on 2+ projects in that window to hit the limit using ~500k tokens/min for around 4.5 hours, and even then it'll reset on the next window.
    • bdangubic 1y ago
      with all dues respect you really need to learn the tools you are using which includes any usage limits (which are temporal). I run CC in 4 to 8 terminals my entire workday, every workday…
  • tomlockwood 1y ago
    Yeah sweet what's the burn rate?
• jonstewart 1y ago
  And just like a slot machine, it seems pretty clear that some people get addicted to it even if it doesn’t make them better off.
• threatofrain 1y ago
  This is an easy calculation for everyone. Think about whether Claude is giving you the a sufficient boost in performance, and if not... then it's too expensive. No doubt some people are in some combination of domain, legacy, complexity of codebase, etc., where Claude just doesn't cut it.
• preommr 1y ago
  > A repeated trend is that Claude Code only gets 70-80% of the way, which is fine and something I wish was emphasized more by people pushing agents. I have been pretty successful at using llms for code generation. I have a simple rule that something is either 90%>ai or none at all (exluding inline completions, and very obvious text editing). The model has an inherent understanding of some problems due to it's training data (e.g. setting up a web server with little to no deps in golang), that it can do with almost 100% certainty, where it's really easy to blaze through in a few minutes, and then I can setup the architecture for some very flat code flows. This can genuinely improve my output by 30%-50%
  • randmeerkat 1y ago
    > I have a simple rule that something is either 90%>ai or none at all… 10% is the time it works 100% of the time.
  • MPSimmons 1y ago
    Agree with your experiences. I've also found that if I build a lightweight skeleton of the structure of the program, it does a much better job. Also, ensuring that it does a full fledged planning/non-executing step before starting to change things leads to good results. I have been using Cline in VSCode, and I've been enjoying it a lot.
• benreesman 1y ago
  The slot machine thing has a pretty compelling corollary: crank the formal systems rigor up as high as you can. Vibe coding in Python is seductive but ultimately you end up in a bad place with a big bill to show for it. Vibe coding in Haskell is a "how much money am I willing to pour in per unit clean, correct, maintainable code" exercise. With GHC cranked up to `-Wall -Werror` and some nasty property tests? Watching Claude Code try to weasel out with a mock goes from infuriating to amusing: bam, unused parameter! Now why would the test suite be demanding that a property holds on an unused parameter... And Haskell is just an example, TypeScript is in some ways even more powerful in it's type system, so lots of projects have scope to dabble with what I'm calling "hyper modern vibe coding": just start putting a bunch of really nasty fastcheck and generic bounds on stuff and watch Claude Code try to cheat. Your move, Claude Code, I know you want to check off that line on the TODO list like I want to breathe, so what's it gonna be? I find it usually gives up and does the work you paid for.
  • deleted 1y ago
    [deleted]
  • kevinventullo 1y ago
    Interesting, I wonder if there is a way to quantify the value of this technique. Like give Claude the same task in Haskell vs. Python and see which one converges correctly first.
• AzzyHN 1y ago
  Not to mention, if an employee could usually write pretty good code but maybe 30% of the time they wrote something so non-functional it had to be entirely scrapped, they'd be fired.
  • melagonster 1y ago
    But what if he only want 20$/per month?
• TrainedMonkey 1y ago
  $200 per month will get you roughly 4-5 hours of non-stop single-threaded usage per day. A bigger issue here is that the random process is not a good engineering pattern. It's not repeatable, does not drive coherent architecture, and struggles with complex problems. In my experience, problem size correlates inversely with generated code quality. Engineering is a process of divide-and-conquer and there is a good reason people don't use bogo (random) sort in production. More specifically, if you only look at the final code, you are either spending a lot of time reviewing the code or accepting the code with less review scrutiny. Carefully reviewing semi random diffs seems like a poor use of time... so I suspect the default is less review scrutiny and higher tech debt. Interestingly enough, higher tech debt might be an acceptable tradeoff if you believe that soon Code Assistants will be good enough to burn the tech debt down autonomously or with minimal oversight. On the other hand, if the code you are writing is not allowed to fail, the stakes change and you can't pick the less review option. I never thought to codify it as a process, but here is what I do to guide the development process: - Start by stating the problem and asking Claude Code to: analyze the existing code, restate the problem in a structured fashion, scan the codebase for existing patterns solving the problem, brainstorm alternative solutions. An enhancement here could be to have a map / list of the codebase to improve the search. - Evaluate presented solutions and iterate on the list. Add problem details, provide insight, eliminate the solutions that would not work. A lot of times I have enough context to pick a winner here, but if not, I ask for more details about each solution and their relative pros and cons. - Ask Claude to provide a detailed plan for the down-selected solution. Carefully review the plan (a significantly faster endeavor compared to reviewing the whole diff). Iterate on the plan as needed; after that, tell Claude to save the plan for comparison after the implementation and then to get cracking. - Review Claude's report of what was implemented vs. what was initially planned. This step is crucial because Claude will try dumb things to get things working, and I've already done the legwork on making sure we're not doing anything dumb in the previous step. Make changes as needed. - After implementation, I generally do a pass on the unit tests because Claude is extremely prolific with them. You generally need to let it write unit tests to make sure it is on the right track. Here, I ask it to scan all of the unit tests and identify similar or identical code. After that, I ask for refactor options that most importantly maximize clarity, secondly minimize lines of code, and thirdly minimize diffs. Pick the best ones. Yes, I accept that the above process takes significantly longer for any single change; however, in my experience, it produces far superior results in a bounded amount of time. P.S. if you got this far please leave some feedback on how I can improve the flow.
• maerch 1y ago
  > A repeated trend is that Claude Code only gets 70-80% of the way, which is fine and something I wish was emphasized more by people pushing agents. Recently, I realized that this applies not only to the first 70–80% of a project but sometimes also to the final 70-80%. I couldn’t make progress with Claude on a major refactoring from scratch, so I started implementing it myself. Once I had shaped the idea clearly enough but in a very early state, I handed it back to Claude to finish and it worked flawlessly, down to the last CHANGELOG entry, without any further input from me. I saw this as a form of extensive guardrails or prompting-by-example.
  • golergka 1y ago
    That’s why I like using it and get more fulfilment from coding than before: I do the fun parts. AI does the mundane.
  • bavell 1y ago
    I need to try this - started using Claude code a few days ago and have been struggling to get good implementations with some high-complexity refactors. It keeps over engineering and creating more problems than it solves. It's getting close though, and I think your approach would work very well for this scenario!
    • theshrike79 1y ago
      Claude has a tendency to reinvent the wheel heavily. It'll create a massive bespoke class to do something that is already in the stdlib. But if there's a pattern of already using stdlib functions, it can copy that easily.
      • lonelyasacloud 1y ago
        Basically, to get the best out Claude (or any of the other agents) it if it is possible to tell it about something ahead of time time then it is generally wise to, be that in seed skeleton code, comments, CLAUDE.md etc
    • LeafItAlone 1y ago
• paulddraper 1y ago
  Who is paying? Should be the same party as is getting the rewards of the productivity gains.
• FeepingCreature 1y ago
  Yeah my most common aider command sequence is > /undo > /clear > ↑ ↑ ↑ ⏎
• deleted 1y ago
  [deleted]
• jordanb 1y ago
  And this is the marketing pitch from the people selling this stuff. ¯\_ (ツ)_/¯
• oc1 1y ago
  Funny thing their recommendation to save state as claude code has still no ability for restore checkpoints (like cline has) despite being many times requested. Who are they kidding.