6 ms·

Claude built a system in 3 rounds, latent bugs from round 1 exploded in round 3

33 points by yogthos 8mo ago

reedf1 8mo ago
It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue. At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex systems.
- Zafira 8mo ago
  > At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex. This sounds like arguing you can use these models to beat a game of whack-a-mole if you just know all the unknown unknowns and prompt it correctly about them. This is an assertion that is impossible to prove or disprove.
  - rafaelmn 8mo ago
    No it's more like if you knew how to build it before - LLM agents help you build it faster. There's really no useful analogy I can think of, but it fits my current role perfectly because my work is constantly interrupted by prod support, coordination, planning, context switching between issues etc. I rarely have blocks of "flow time" to do focused work. With LLMs I can keep progressing in parallel and then when I get to the block of time where I can actually dive deep it's review and guidance again - focus on high impact stuff instead of the noise. I don't think I'm any faster with this than my theoretical speed (LLMs spend a lot of time rebuilding context between steps, I have a feeling current level of agents is terrible at maintaining context for larger tasks, and also I'm guessing the model context length is white a lie - they might support working with 100k tokens but agents keep reloading stuff to context because old stuff is ignored). In practice I can get more done because I can get into the flow and back onto the task a lot faster. Will see how this pans out long term, but in current role I don't think there are alternatives, my performance would be shit otherwise.
    - dkdbejwi383 8mo ago
      You could probably replace LLM with "junior engineer" here as it sounds like you're basically a manager now. The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback.
      - lukan 8mo ago
        "The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback." No, but they can take "notes" and can load those notes into context. That does work, but is of course not so easy as it is with humans. It is all about cleaning up and maintaining a tidy context.
      - rafaelmn 8mo ago
        I don't like that analogy. If I had to work with a Claude like junior I would ask for them to get removed from my team - inability to learn stuff, completely unexpected/unrelatable faliure modes and performance. On the other hand Claudes tenacity, stamina and sustained speed is superhuman. The more capable models become the more valuable this is.
  - reedf1 8mo ago
    The same is true with human engineers - isn't this just what engineering is?
  - threethirtytwo 8mo ago
    >This is an assertion that is impossible to prove or disprove. This is a joke right? There are complex systems that exist today that are built exclusively via AI. Is that not obvious? The existence of such complex systems IS proof. I don't understand how people walk around claiming there's no proof? Really?
    - mmustapic 8mo ago
      The assertion was "if you really know how to prompt, give feedback, do small corrections and fix LLM errors, then everything works fine". It is impossible to prove or disprove because if everything DOES NOT work fine you can always say that the prompts were bad, the agent was not configured correctly, the model was old, etc. And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means.
      - threethirtytwo 8mo ago
        >And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means. If a program works, it means it's correct. If we know it's correct, it means we have a definition of what correct means otherwise how can we classify anything as "correct" or "incorrect". Then we can look at the prompts and see what was done in those prompts and those would be a "correct" way of prompting the LLM.
        satisfice 8mo ago
        You don’t know it works. That you so glibly speak about products working is proof that your engineering judgment is impaired. You can’t infer the exact contents of a black box merely by looking at outside behavior. The fundamental fallacy you are exhibiting here is similar to saying that rolling a six sided die and getting a “6” means that you will always get a 6 any time you roll it. And that if you get a 6 and wanted a 6, you must have therefore rolled those dice “correctly” and had you not gotten a 6 that would have meant you rolled them “wrong.” You know that is not true.
- stavros 8mo ago
  I'd agree, I've been building a personal assistant (https://github.com/skorokithakis/stavrobot https://github.com/skorokithakis/stavrobot) and I'm amazed that, for the first time ever, LLMs manage to build reliably, with much fewer bugs than I'd expect from a human, and without the repo devolving to unmaintainability after a few cycles. It's really amazing, we've crossed a threshold, and I don't know what that means for our jobs.
  - Grimblewald 8mo ago
    No bugs means nothing if bugs get hidden and llms are great at hiding bugs and will absolutely fail to find some fairly critical ones. Your own repo, which is slop at best, fails to meet its core premise > Another AI agent. This one is awesome, though, and very secure. it isn't secure. It took me less than three minutes to find a vulnerability. Start engaging with your own code, it isn't as good as you think it is. edit: i had kimi "red team" it out of curiosity, it found the main critical vulnerability i did and several others Severity - Count - Categories Critical - 2 - SQL Injection, Path Traversal High - 4 - SSRF, Auth Bypass, Privilege Escalation, Secret Exposure Medium - 3 - DoS, Information Disclosure, Injection You need to sit down and really think about what people who do know what they're doing are saying. You're going to get yourself into deep trouble with this. I'm not a security specialist, i take a recreational interest in security, and llm's are by no means expert. A human with skill and intent would, i would gamble, be able fuck your shit up in a major way.
    - reedf1 8mo ago
      Build a redteam into your feedback mechanism. Seriously. You've identified the problem and even solved it. Now automate it.
      - Grimblewald 8mo ago
        it sure can help, but it shouldn't be considered solved. Realistically you should treat it as vulnerable until it's received some attention from natural human folks who do know what they're doing. LLM's are great but they're not experts in any field as of yet.
- Grimblewald 8mo ago
  Say i buy into your mysticism based take, is it a useful tool if it blows up in damn well near every professionals face? lets say i accept you and you alone have the deep majiks required to use this tool correctly, when major platform devs could not so far, what makes this tool useful? Billions of dollars and environment ruining levels of worth it? I'd say the only real use for these tools to date has been mass surveillance, and sometimes semi useful boilerplate.
  - reedf1 8mo ago
    Honestly people are in such a weird place with this shit. I'm not saying don't read the fucking code - but I managed to get my setup to write 100k lines of indistinguishable SWE code in a week or so. The main limitation was my reading speed. This is something like a 10x speedup for me.
    - Grimblewald 8mo ago
      How does one verify 100k lines in a week? Let alone evaluate it to being SWE equivallent? That's super human. I like to think I am pretty good at what I do, but really critically engaging with 100k lines in a week is beyond even 10 of me. Forgive my skepticism, but I'm going to hazard the guess that you don't know what the fuck you're doing. You've lost your goddamn mind if you think you're doing anything other than skim read at a rate of 42 lines a minute for your entire work day without a break.
      - mikkupikku 8mo ago
        On Saturday I had claude generate ~10k of lines of Lua code which uses the libASS subtitle format to build up nearly two dozen GUI widgets from subtitle drawing primitives, including nestable scrollable containers with clipping, drop down menus, animated tab bars, and everything else I could think of. I read probably about 100 lines of code myself that day, I "verified" the code only by testing out the demo claude was updating through the process. Then on Sunday I woke up and had claude bang out a series of half a dozen projects each using this GUI library. First, a script that simply offers to loop a video when the end is reached. Updated several of my old scripts that just print text without any graphical formatting. Then more adventurous, a playlist visualizer with support for drag to reorder. Another that gives a nice little control overlay for TTS reading normal media subtitles. Another that let's people select clips from whatever they're watching, reorder them and write out an edit decision list, maybe I'll turn this one into a complete NLE today when I get home from work. Reading every line of code? Why? The shit works, if I notice a bug I go back to claude and demand a "thoughtful and well reasoned" fix, without even caring what the fix will be so long as it works. The concepts and building blocks used for all of this is shit I've learned myself the hard way, but to do it all myself would take weeks and I would certainly take many shortcuts, like certainly skipping animations and only implementing the bare minimum. The reason I could make that stuff work fast is because I already broadly knew the problem space, I've probably read the mpv manpage a thousand times before, so when the agent says its going to bind to shift+wheel for horizonal scrolling, I can tell it no, mpv has WHEEL_LEFT and RIGHT, use those. I can tell it to pump its brakes and stop planning to load a PNG overlay, because mpv will only load raw pixel data that way. I can tell it that dragging UI elements without simultaneously dragging the whole window certainly must be possible, because the first party OSC supports it so it should go read that mess of code and figure it out, which it dutifully does. If you know the problem space, you can get a whole lot done very fast, in a way that demonstrably works. Does it have bugs? I'd eat a hat if it doesn't. They'll get fixed if/when I find them. I'm not worried about it. Reading every line of code is for people writing airliner autopilots, not cheeky little desktop programs.
- jamiemallers 8mo ago
  [dead]
- croes 8mo ago
  > if you provide the correct feedback And how do you define correct feedback? If the output is correct?
  - reedf1 8mo ago
    I don't know if you deliberately cut-off the full point, but for the benefit of those with tired eyes I said 'feedback mechanisms', i.e. feedback in the control system sense.
    - croes 8mo ago
      The cut-off was not intended but what is the correct one? Is it wrong as soon the result is wrong?
      - reedf1 8mo ago
        We are still in early days and I'm sure this isn't the best way to approach this but here is what I do. 1. Agent context with platform/system idiosyncrasies, how to access tools, this is actually kept pretty minimal - and a line directing it to the plan document. 2. A plan document on how to make changes to the repo and work that needs to be done. This is a living document pruned by the orchestrating agent. Included in this document is a directive written by you to use, update the document after ever run. Here also is a guide on benchmarking, regression, unit tests that need to be performed every time. 2a. When an agent has a code change it is then analyzed by a council of subagents, each focused on a different area, some examples, security, maintainability, system architect, business domain expert. I encourage these to be adversarial "red team". We sit in the core loop until the code changes pass through the council. 2b. Additional subagents to create documentation, build architecture diagrams etc. 2c. A suggested workflow is created on how to independently invoke testing, and subagent, etc.
- zihotki 8mo ago
  According to the https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code https://blog.katanaquant.com/p/your-llm-doesnt-write-correct... previously discussed on HN, it may be at least partially true: > The vibes are not enough. Define what correct means. Then measure.
- mikkupikku 8mo ago
  Truth Nuke
- bartread 8mo ago
  > It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue. I think it's fair to say that you can get a long way with Claude very quickly if you're an individual or part of a very small team working on a greenfield project. Certainly at project sizes up to around 100k lines of code, it's pretty great. But I've been working startups off and on since 2024. My last "big" job was with a company that had a codebase well into the millions of lines of code. And whilst I keep in contact with a bunch of the team there, and I know they do use Claude and other similar tools, I don't get the vibe it's having quite the same impact. And these are very talented engineers, so I don't think it's a skill either. I think it's entirely possible that Claude is a great tool for bootstrapping and/or for solo devs or very small teams, but becomes considerably less effective when scaled across very large codebases, multiple teams, etc. For me, on that last point, the jury is out. Hopefully the company I'm working with now grows to a point where that becomes a problem I need to worry about but, in the meantime, Claude is doing great for us.
- ptak_dev 8mo ago
  [flagged]
- Greed 8mo ago
  Would definitely tend to agree. Whenever I read complaints about accuracy of LLMs with complex systems, it has generally been from those that aren't thinking very critically about how they're using them in the first place. If you were to replace that LLM with a real human junior, would you really walk away for a few weeks and then assume the solution given was correct by default when you got it back? Obviously not. So you identify and gatekeep the most critical parts ahead of time, make error correction part of the process, and chunk the Giant, Complex Thing into Smaller, Achievable, Verifiable Things. LLMs are proving to be very much force multipliers of the kind of developer you already are, and of those who report a 10x increase in productivity they're probably all being genuine. Whether that 10x is of careful, thoughtful choices or reckless rough-shod slop though is really an artifact of the developers themselves. I've been saying from the beginning that your effectiveness with LLMs is roughly equivalent to your ability to get effective results out of a real team of human contractors.
- yogthos 8mo ago
  The point is that we can make life easier for both ourselves and the agents by structuring code in a way that's conducive towards their strengths.
NotGMan 8mo ago
How is that different compared to a human dev that would miss bugs?
- Grimblewald 8mo ago
  The ability to plan long term and anticipate flow on errors.
  - onion2k 8mo ago
    You chosen AI agent can and will plan as far ahead as you tell it to plan. If you tell it to do things in iteration 1 that might block it in iteration 3 then you should have told it more about where you want to go back in iteration 1.
    - Grimblewald 8mo ago
      At some point I have to describe what I need with such a level of detail and precision, that if I had chosen to wrote it in my language of interest I'd have had the code I wanted long before i finish writing all the boundry conditions, safe guards, long term pitfalls etc. Thats if the system even respects all of those things, it might just lose track of some instruction at some point or make some bs placeholder and now we're back to bug hunting, only i'm now wading through code that is best described as slop.
      - onion2k 8mo ago
        You're saying that projects need to be waterfall rather than Agile in order to avoid making architecture mistakes you'll regret later. The problem with that is that as you build you learn things, and that changes the plan. Consequently those mistakes are inevitable. What you should do is an approach where you have a high level plan up front, and detailed plans about the specific features as you need them. Mistakes will still happen but you'll be able to see them, and correct them, faster.
        8mo ago
karel-3d 8mo ago
I have no idea what am I reading > Mycelium structures applications as directed graphs of pure data transformations. Each node (cell) has explicit input/output schemas. Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time. Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes. No still don't understand > Mycelium uses Maestro state machines and Malli contracts to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement. Nope, still don't
- IshKebab 8mo ago
  Yeah it reads very Time Cube...
- harperlee 8mo ago
  I don't understand why the poster (which is the author) links us to a slop report of a test for their library. It would be much more effective to cover part of this info into the README where we get the context of what they want to achieve (where there is a very clear "Why?" section), and then link to it instead. I have flagged it as AI slop.
  - karel-3d 8mo ago
    I don't understand LISP or Clojure, but it seems to be some kind of library for making web services out of LISP, which has some separate components that are somehow well defined. And somehow it's all related to AI. Again I don't know much about Clojure and I am too slow for functional programming in general.
  - yogthos 8mo ago
    The whole point of the framework is to see what LLM oriented framework would look like. My argument is that the way code is normally structured is not conducive towards LLMs because context grows in unbounded way, and they end up getting lost. The whole point of the 'slop' report is to have the LLM try implementing the features using both the traditional approach and the framework and then reflect on how it fared with each approach.
irenetusuq 8mo ago
[dead]
flowerthoughts 8mo ago
I've used the analogy of a circular saw before ("it's not really sawing, because you can't feel the wood...") It's easy to just slab on a Skil saw, cut through the beam and it'll be somewhat straight. But when every manual stroke counts, there's enough time on a human time scale to correct every little mistake. It's definitely possible to become skilled at using the circular saw, but it takes effort that it feels like you don't need at first. This is similar. LLMs are so powerful for writing code that it's easy to become complacent and forget your role as the engineer using the tool: guaranteeing correctness, security, safety and performance of the end result. When you're not invested in every if-statement, forgetting to check edge cases is really easy to do. And as much as I like Claude writing test cases for me, I also have to ensure the coverage is decent, that the implicit assumptions made about external library code is correct, etc. It takes a lot of effort to do it right. I don't know why Mycelium thinks they invented interfaces for module boundaries, but I'm pretty sure they are still as suceptible to that "0" not behaving as you'd expect, or the empty string being interpreted as "missing." Or the CSG algorithm working, except if your hole edges are incident with some boundary edges. Edit: spelling
- zihotki 8mo ago
  Your analogy with a Skil saw is genius! You can cut much faster but it's also much more dangerous. Just like the AI indeed.
- 4b11b4 8mo ago
  I've been thinking like a CNC. It can be made, but the edges are rough, needs sanding. OR - you accept that the edges are borderline dangerous. Also, some complex joints can't be built with a CNC
- yogthos 8mo ago
  I agree with everything you're saying here, and I'm not arguing the approach eliminates the need for the human to be in the loop. That's not the goal. What I'm trying to do is to create hard context boundaries which help both the human and the agent understand what the code is doing. With Mycelium, you have a graph expressing the top level logic, so you have a declarative workflow that you can review. With traditional code this is mixed in together with the implementation details, and you have to tease out the business logic by reading through the code. Mycelium creates a hard boundary between implementation details which live in the cells, and the high level business logic of the application. You can set up a workflow manifest which declares what you're doing. Then you can go an implement each step in form of a cell. And then you can review it and test it in isolation without having to consider the entire application. This is the part that reduces the cognitive load and makes it easier to ensure that the code is doing what's intended. As a note, I'm not arguing that I invented anything fundamentally new here. Workflow engines have been around for a while. I'm simply applying the idea directly in the context of coding agents.
josefritzishere 8mo ago
"Too Many requests" message. Hug of death?

33 points by yogthos 8mo ago

It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue. At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex systems.

Zafira 8mo ago
> At the moment it is a mysterious, occasionally fickle, tool - but if you provide the correct feedback mechanisms and provide small tweaks and context at idiosyncrasies, it's possible to get agents to reliably build very complex. This sounds like arguing you can use these models to beat a game of whack-a-mole if you just know all the unknown unknowns and prompt it correctly about them. This is an assertion that is impossible to prove or disprove.
- rafaelmn 8mo ago
  No it's more like if you knew how to build it before - LLM agents help you build it faster. There's really no useful analogy I can think of, but it fits my current role perfectly because my work is constantly interrupted by prod support, coordination, planning, context switching between issues etc. I rarely have blocks of "flow time" to do focused work. With LLMs I can keep progressing in parallel and then when I get to the block of time where I can actually dive deep it's review and guidance again - focus on high impact stuff instead of the noise. I don't think I'm any faster with this than my theoretical speed (LLMs spend a lot of time rebuilding context between steps, I have a feeling current level of agents is terrible at maintaining context for larger tasks, and also I'm guessing the model context length is white a lie - they might support working with 100k tokens but agents keep reloading stuff to context because old stuff is ignored). In practice I can get more done because I can get into the flow and back onto the task a lot faster. Will see how this pans out long term, but in current role I don't think there are alternatives, my performance would be shit otherwise.
  - dkdbejwi383 8mo ago
    You could probably replace LLM with "junior engineer" here as it sounds like you're basically a manager now. The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback.
    - lukan 8mo ago
      "The big negative that LLMs have in comparison with junior engineers is that they can't learn and internalise new information based on feedback." No, but they can take "notes" and can load those notes into context. That does work, but is of course not so easy as it is with humans. It is all about cleaning up and maintaining a tidy context.
    - rafaelmn 8mo ago
      I don't like that analogy. If I had to work with a Claude like junior I would ask for them to get removed from my team - inability to learn stuff, completely unexpected/unrelatable faliure modes and performance. On the other hand Claudes tenacity, stamina and sustained speed is superhuman. The more capable models become the more valuable this is.
- reedf1 8mo ago
  The same is true with human engineers - isn't this just what engineering is?
- threethirtytwo 8mo ago
  >This is an assertion that is impossible to prove or disprove. This is a joke right? There are complex systems that exist today that are built exclusively via AI. Is that not obvious? The existence of such complex systems IS proof. I don't understand how people walk around claiming there's no proof? Really?
  - mmustapic 8mo ago
    The assertion was "if you really know how to prompt, give feedback, do small corrections and fix LLM errors, then everything works fine". It is impossible to prove or disprove because if everything DOES NOT work fine you can always say that the prompts were bad, the agent was not configured correctly, the model was old, etc. And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means.
    - threethirtytwo 8mo ago
      >And if it DOES work, then all of the previous was done correctly, but without any decent definition of what correct means. If a program works, it means it's correct. If we know it's correct, it means we have a definition of what correct means otherwise how can we classify anything as "correct" or "incorrect". Then we can look at the prompts and see what was done in those prompts and those would be a "correct" way of prompting the LLM.
      - satisfice 8mo ago
        You don’t know it works. That you so glibly speak about products working is proof that your engineering judgment is impaired. You can’t infer the exact contents of a black box merely by looking at outside behavior. The fundamental fallacy you are exhibiting here is similar to saying that rolling a six sided die and getting a “6” means that you will always get a 6 any time you roll it. And that if you get a 6 and wanted a 6, you must have therefore rolled those dice “correctly” and had you not gotten a 6 that would have meant you rolled them “wrong.” You know that is not true.
stavros 8mo ago
I'd agree, I've been building a personal assistant (https://github.com/skorokithakis/stavrobot https://github.com/skorokithakis/stavrobot) and I'm amazed that, for the first time ever, LLMs manage to build reliably, with much fewer bugs than I'd expect from a human, and without the repo devolving to unmaintainability after a few cycles. It's really amazing, we've crossed a threshold, and I don't know what that means for our jobs.
- Grimblewald 8mo ago
  No bugs means nothing if bugs get hidden and llms are great at hiding bugs and will absolutely fail to find some fairly critical ones. Your own repo, which is slop at best, fails to meet its core premise > Another AI agent. This one is awesome, though, and very secure. it isn't secure. It took me less than three minutes to find a vulnerability. Start engaging with your own code, it isn't as good as you think it is. edit: i had kimi "red team" it out of curiosity, it found the main critical vulnerability i did and several others Severity - Count - Categories Critical - 2 - SQL Injection, Path Traversal High - 4 - SSRF, Auth Bypass, Privilege Escalation, Secret Exposure Medium - 3 - DoS, Information Disclosure, Injection You need to sit down and really think about what people who do know what they're doing are saying. You're going to get yourself into deep trouble with this. I'm not a security specialist, i take a recreational interest in security, and llm's are by no means expert. A human with skill and intent would, i would gamble, be able fuck your shit up in a major way.
  - reedf1 8mo ago
    Build a redteam into your feedback mechanism. Seriously. You've identified the problem and even solved it. Now automate it.
    - Grimblewald 8mo ago
      it sure can help, but it shouldn't be considered solved. Realistically you should treat it as vulnerable until it's received some attention from natural human folks who do know what they're doing. LLM's are great but they're not experts in any field as of yet.
Grimblewald 8mo ago
Say i buy into your mysticism based take, is it a useful tool if it blows up in damn well near every professionals face? lets say i accept you and you alone have the deep majiks required to use this tool correctly, when major platform devs could not so far, what makes this tool useful? Billions of dollars and environment ruining levels of worth it? I'd say the only real use for these tools to date has been mass surveillance, and sometimes semi useful boilerplate.
- reedf1 8mo ago
  Honestly people are in such a weird place with this shit. I'm not saying don't read the fucking code - but I managed to get my setup to write 100k lines of indistinguishable SWE code in a week or so. The main limitation was my reading speed. This is something like a 10x speedup for me.
  - Grimblewald 8mo ago
    How does one verify 100k lines in a week? Let alone evaluate it to being SWE equivallent? That's super human. I like to think I am pretty good at what I do, but really critically engaging with 100k lines in a week is beyond even 10 of me. Forgive my skepticism, but I'm going to hazard the guess that you don't know what the fuck you're doing. You've lost your goddamn mind if you think you're doing anything other than skim read at a rate of 42 lines a minute for your entire work day without a break.
    - mikkupikku 8mo ago
      On Saturday I had claude generate ~10k of lines of Lua code which uses the libASS subtitle format to build up nearly two dozen GUI widgets from subtitle drawing primitives, including nestable scrollable containers with clipping, drop down menus, animated tab bars, and everything else I could think of. I read probably about 100 lines of code myself that day, I "verified" the code only by testing out the demo claude was updating through the process. Then on Sunday I woke up and had claude bang out a series of half a dozen projects each using this GUI library. First, a script that simply offers to loop a video when the end is reached. Updated several of my old scripts that just print text without any graphical formatting. Then more adventurous, a playlist visualizer with support for drag to reorder. Another that gives a nice little control overlay for TTS reading normal media subtitles. Another that let's people select clips from whatever they're watching, reorder them and write out an edit decision list, maybe I'll turn this one into a complete NLE today when I get home from work. Reading every line of code? Why? The shit works, if I notice a bug I go back to claude and demand a "thoughtful and well reasoned" fix, without even caring what the fix will be so long as it works. The concepts and building blocks used for all of this is shit I've learned myself the hard way, but to do it all myself would take weeks and I would certainly take many shortcuts, like certainly skipping animations and only implementing the bare minimum. The reason I could make that stuff work fast is because I already broadly knew the problem space, I've probably read the mpv manpage a thousand times before, so when the agent says its going to bind to shift+wheel for horizonal scrolling, I can tell it no, mpv has WHEEL_LEFT and RIGHT, use those. I can tell it to pump its brakes and stop planning to load a PNG overlay, because mpv will only load raw pixel data that way. I can tell it that dragging UI elements without simultaneously dragging the whole window certainly must be possible, because the first party OSC supports it so it should go read that mess of code and figure it out, which it dutifully does. If you know the problem space, you can get a whole lot done very fast, in a way that demonstrably works. Does it have bugs? I'd eat a hat if it doesn't. They'll get fixed if/when I find them. I'm not worried about it. Reading every line of code is for people writing airliner autopilots, not cheeky little desktop programs.
jamiemallers 8mo ago
[dead]
croes 8mo ago
> if you provide the correct feedback And how do you define correct feedback? If the output is correct?
- reedf1 8mo ago
  I don't know if you deliberately cut-off the full point, but for the benefit of those with tired eyes I said 'feedback mechanisms', i.e. feedback in the control system sense.
  - croes 8mo ago
    The cut-off was not intended but what is the correct one? Is it wrong as soon the result is wrong?
    - reedf1 8mo ago
      We are still in early days and I'm sure this isn't the best way to approach this but here is what I do. 1. Agent context with platform/system idiosyncrasies, how to access tools, this is actually kept pretty minimal - and a line directing it to the plan document. 2. A plan document on how to make changes to the repo and work that needs to be done. This is a living document pruned by the orchestrating agent. Included in this document is a directive written by you to use, update the document after ever run. Here also is a guide on benchmarking, regression, unit tests that need to be performed every time. 2a. When an agent has a code change it is then analyzed by a council of subagents, each focused on a different area, some examples, security, maintainability, system architect, business domain expert. I encourage these to be adversarial "red team". We sit in the core loop until the code changes pass through the council. 2b. Additional subagents to create documentation, build architecture diagrams etc. 2c. A suggested workflow is created on how to independently invoke testing, and subagent, etc.
zihotki 8mo ago
According to the https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code https://blog.katanaquant.com/p/your-llm-doesnt-write-correct... previously discussed on HN, it may be at least partially true: > The vibes are not enough. Define what correct means. Then measure.
mikkupikku 8mo ago
Truth Nuke
bartread 8mo ago
> It's starting to become obvious that if you can't effectively use AI to build systems it is a skill issue. I think it's fair to say that you can get a long way with Claude very quickly if you're an individual or part of a very small team working on a greenfield project. Certainly at project sizes up to around 100k lines of code, it's pretty great. But I've been working startups off and on since 2024. My last "big" job was with a company that had a codebase well into the millions of lines of code. And whilst I keep in contact with a bunch of the team there, and I know they do use Claude and other similar tools, I don't get the vibe it's having quite the same impact. And these are very talented engineers, so I don't think it's a skill either. I think it's entirely possible that Claude is a great tool for bootstrapping and/or for solo devs or very small teams, but becomes considerably less effective when scaled across very large codebases, multiple teams, etc. For me, on that last point, the jury is out. Hopefully the company I'm working with now grows to a point where that becomes a problem I need to worry about but, in the meantime, Claude is doing great for us.
ptak_dev 8mo ago
[flagged]
Greed 8mo ago
Would definitely tend to agree. Whenever I read complaints about accuracy of LLMs with complex systems, it has generally been from those that aren't thinking very critically about how they're using them in the first place. If you were to replace that LLM with a real human junior, would you really walk away for a few weeks and then assume the solution given was correct by default when you got it back? Obviously not. So you identify and gatekeep the most critical parts ahead of time, make error correction part of the process, and chunk the Giant, Complex Thing into Smaller, Achievable, Verifiable Things. LLMs are proving to be very much force multipliers of the kind of developer you already are, and of those who report a 10x increase in productivity they're probably all being genuine. Whether that 10x is of careful, thoughtful choices or reckless rough-shod slop though is really an artifact of the developers themselves. I've been saying from the beginning that your effectiveness with LLMs is roughly equivalent to your ability to get effective results out of a real team of human contractors.
yogthos 8mo ago
The point is that we can make life easier for both ourselves and the agents by structuring code in a way that's conducive towards their strengths.

NotGMan 8mo ago

How is that different compared to a human dev that would miss bugs?

Grimblewald 8mo ago
The ability to plan long term and anticipate flow on errors.
- onion2k 8mo ago
  You chosen AI agent can and will plan as far ahead as you tell it to plan. If you tell it to do things in iteration 1 that might block it in iteration 3 then you should have told it more about where you want to go back in iteration 1.
  - Grimblewald 8mo ago
    At some point I have to describe what I need with such a level of detail and precision, that if I had chosen to wrote it in my language of interest I'd have had the code I wanted long before i finish writing all the boundry conditions, safe guards, long term pitfalls etc. Thats if the system even respects all of those things, it might just lose track of some instruction at some point or make some bs placeholder and now we're back to bug hunting, only i'm now wading through code that is best described as slop.
    - onion2k 8mo ago
      You're saying that projects need to be waterfall rather than Agile in order to avoid making architecture mistakes you'll regret later. The problem with that is that as you build you learn things, and that changes the plan. Consequently those mistakes are inevitable. What you should do is an approach where you have a high level plan up front, and detailed plans about the specific features as you need them. Mistakes will still happen but you'll be able to see them, and correct them, faster.
      - 8mo ago

karel-3d 8mo ago

I have no idea what am I reading > Mycelium structures applications as directed graphs of pure data transformations. Each node (cell) has explicit input/output schemas. Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time. Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes. No still don't understand > Mycelium uses Maestro state machines and Malli contracts to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement. Nope, still don't

IshKebab 8mo ago
Yeah it reads very Time Cube...
harperlee 8mo ago
I don't understand why the poster (which is the author) links us to a slop report of a test for their library. It would be much more effective to cover part of this info into the README where we get the context of what they want to achieve (where there is a very clear "Why?" section), and then link to it instead. I have flagged it as AI slop.
- karel-3d 8mo ago
  I don't understand LISP or Clojure, but it seems to be some kind of library for making web services out of LISP, which has some separate components that are somehow well defined. And somehow it's all related to AI. Again I don't know much about Clojure and I am too slow for functional programming in general.
- yogthos 8mo ago
  The whole point of the framework is to see what LLM oriented framework would look like. My argument is that the way code is normally structured is not conducive towards LLMs because context grows in unbounded way, and they end up getting lost. The whole point of the 'slop' report is to have the LLM try implementing the features using both the traditional approach and the framework and then reflect on how it fared with each approach.

irenetusuq 8mo ago

[dead]

flowerthoughts 8mo ago

I've used the analogy of a circular saw before ("it's not really sawing, because you can't feel the wood...") It's easy to just slab on a Skil saw, cut through the beam and it'll be somewhat straight. But when every manual stroke counts, there's enough time on a human time scale to correct every little mistake. It's definitely possible to become skilled at using the circular saw, but it takes effort that it feels like you don't need at first. This is similar. LLMs are so powerful for writing code that it's easy to become complacent and forget your role as the engineer using the tool: guaranteeing correctness, security, safety and performance of the end result. When you're not invested in every if-statement, forgetting to check edge cases is really easy to do. And as much as I like Claude writing test cases for me, I also have to ensure the coverage is decent, that the implicit assumptions made about external library code is correct, etc. It takes a lot of effort to do it right. I don't know why Mycelium thinks they invented interfaces for module boundaries, but I'm pretty sure they are still as suceptible to that "0" not behaving as you'd expect, or the empty string being interpreted as "missing." Or the CSG algorithm working, except if your hole edges are incident with some boundary edges. Edit: spelling

zihotki 8mo ago
Your analogy with a Skil saw is genius! You can cut much faster but it's also much more dangerous. Just like the AI indeed.
4b11b4 8mo ago
I've been thinking like a CNC. It can be made, but the edges are rough, needs sanding. OR - you accept that the edges are borderline dangerous. Also, some complex joints can't be built with a CNC
yogthos 8mo ago
I agree with everything you're saying here, and I'm not arguing the approach eliminates the need for the human to be in the loop. That's not the goal. What I'm trying to do is to create hard context boundaries which help both the human and the agent understand what the code is doing. With Mycelium, you have a graph expressing the top level logic, so you have a declarative workflow that you can review. With traditional code this is mixed in together with the implementation details, and you have to tease out the business logic by reading through the code. Mycelium creates a hard boundary between implementation details which live in the cells, and the high level business logic of the application. You can set up a workflow manifest which declares what you're doing. Then you can go an implement each step in form of a cell. And then you can review it and test it in isolation without having to consider the entire application. This is the part that reduces the cognitive load and makes it easier to ensure that the code is doing what's intended. As a note, I'm not arguing that I invented anything fundamentally new here. Workflow engines have been around for a while. I'm simply applying the idea directly in the context of coding agents.

josefritzishere 8mo ago

"Too Many requests" message. Hug of death?