6 ms·

This “short leash” seems like more of a crutch to me, and a sign of not giving the AI enough detail on the problem to begin with, or not reviewing and iterating

This “short leash” seems like more of a crutch to me, and a sign of not giving the AI enough detail on the problem to begin with, or not reviewing and iterating on its output. Hand-holding great models like Fable through implementation is a waste of time, and a waste of Fable. You can have increasingly nuanced discussions with stronger models, and they write a lot better code than they used to. The process of discussing designs and their implementations, questioning things that look weird to you, and actually reading the AI’s responses also helps to find better solutions. For example, one time I wanted to write a greedy solver for a problem, and in my discussion with Opus on the idea it suggested using an existing MILP library to solve the problem exactly. I’d never even heard of MILP, but my final implementation ended up being better and simpler than what I’d have done alone.

densekernel 3mo ago
I tend to agree, If you have invested significantly in the planning phase and there is momentum in the architecture and conventions that already exist in the project, the implementation phase might not need as much oversight as is suggested here. > You can discover that your initial idea was dumb and a better one exists The planning and architecture phase is usually where I make these types of discovery at a high level. > Your agent might go “off the rails” and start doing something you don’t want it to do Candidly these orthogonal, inadvertent edits aren't as bad as they once were and for impactful changes there should be at least some test coverage, even if that test coverage is just "freezing" what was implemented. As you mentioned the final review discussion is a good chance to verify beyond what review or adversarial review agents find.
- visarga 3mo ago
  I think the obvious solution here is to beef up the test side of the app, much more than when writing code by hand. Tests represent project knowledge in executable format. The LLM does not need to be careful to remember every detail of the tests. You don't need to vet every small interaction, it automates review work as well. Even better if the project was built from the start to be easier to test and observe. But my golden rule remains - no code without tests, expand test suite all the time.
  - densekernel 3mo ago
    I agree, human-steered, AI-implemented test cases can at least capture the acceptance criteria. It's then more efficient to inspect if existing test cases are being modified as part of the delivery of something new and inspect why.
deleted 3mo ago
[deleted]
fy20 3mo ago
The article feels like micromanaging AI. If you think about it like a junior employee, micromanaging them will mean they end up doing the work you want and do it your way. But they won't bring any of their ideas to the table, which in the long run could be beneficial to everyone on the team.
echelon 3mo ago
This is the method I use. It makes sure that I understand everything being generated and that I maintain a firm working knowledge of the codebase at all times. I can easily steer it too.
sixtram 3mo ago
You say you can have increasingly nuanced discussions with stronger models. What I say is, when I asked Claude why he applied a certain change I didn't understand, and boy, it was a small change, he said he "reasoned from first principles" based on the code paths. But it didn't work, and when I asked, "Okay, describe the steps of your reasoning from first principles," it literally answered that it had just made it up. So, nuanced discussions with models, I don't buy it.
- solenoid0937 3mo ago
  Posts like this are meaningless without more context - the model you're using, the harness, the initial prompt and context. Fable is better than most staff engineers at my FAANG.
  - hrmon 3mo ago
    But staff engineers take "responsibility"
  - sn0n 3mo ago
    Maybe I’m missing something, but he talks about charm and tasks (repos on his GitHub). Charm being his harness, and tasks being one of his skills. Idk, maybe I’m mistaken from reading the article… https://github.com/taoeffect https://github.com/taoeffect
  - maccard 3mo ago
    > Fable is better than most staff engineers at my FAANG. While this wouldn’t entirely surprise me, my experience is just not that. Using Claude and fable, it regularly (poorly) recreates features that exist inside our codebase. Sure, I could give way more initial context but at a certain point I’ve given so much context that I would have been faster writing the code myself, or I could have literally handed it to even a fresh graduate to write.
  - well_ackshually 3mo ago
    Fable will definitely be the one on call when it inevitably breaks down from the pile of shit slop it wrote at 5AM, don't worry <3
zquzra 3mo ago
Do you have a background in CS or optimization? MILP is a pretty standard concept in algorithms/optimization. So this example doesn't really convince me that the AI reached some unusually superior conclusion. It sounds more like it suggested a well-known technique that you personally hadn't encountered. Useful, yes, but that seems more about background knowledge gaps than about the merits of letting the tool run unconstrained.
- sothatsit 3mo ago
  There are always concepts that some people think are a basic, that others haven't heard of. The entire benefit here is that AI can point out what we miss. There are certainly techniques you don't know about, or just didn't think to apply to a problem, that others would find to be pretty standard.
RealityVoid 3mo ago
I am a bit confused which part you disagree with specifically. Reading AI responses and reviewing code seems to be what you propose as well. Your example with MLIP is something that would not be prevented by this approach, during the planing phase, it would surface. I guess the devil is in the details and the way you prompt it for starting the task matters. But IMO you absolutely need to check the output, need to engage with what the model is doing, need to probe why something is built the way the model tries to build it.
- sothatsit 3mo ago
  I disagree with keeping an eye on the model as it is working, approving every command, and denying and stopping the model when you think it has gone wrong. It is not that it is actively harmful to do this, but rather that it is a waste of time and you can avoid the need for it through better design discussions and review. Micro-managing and keeping the AI on a "short leash" also lends itself better to telling models to do smaller units of work at a time instead of discussing broader design concerns. That is why I think someone doing this would miss the MILP solution, because they might never discuss the overall design with the model but rather just tell it what to implement next.
  - te_chris 3mo ago
    I agree. Better to let it rip in a sandbox then spend your time correcting the finished product. Waste of time being in the middle.
  - RealityVoid 3mo ago
    I personally am somewhere between you and the author. I don't check _all_ the intermediary steps, but I do try to understand what it's doing [1] and follow the process. Mostly I let it do the changes itself without supervision at each step but when a coherent "chunk" of work is done, I go through it really thoroughly. In almost 90% of the cases after a chunk is done some adjustments are needed. I find broad architectural design to be _better_ if you follow along in the process because you better understand the direction it's going earlier and you can shift the high level direction much earlier. Even if you check its steps, you can ask it for its take on high-level architectural aspects along the way, no problem. I think personal touch matters a lot though, because I naturally ask it and try to get the big picture image. [1] I actually find it really instructive what tooling it uses to tackle a problem, I got to become a much better console user because of it

densekernel 3mo ago

I tend to agree, If you have invested significantly in the planning phase and there is momentum in the architecture and conventions that already exist in the project, the implementation phase might not need as much oversight as is suggested here. > You can discover that your initial idea was dumb and a better one exists The planning and architecture phase is usually where I make these types of discovery at a high level. > Your agent might go “off the rails” and start doing something you don’t want it to do Candidly these orthogonal, inadvertent edits aren't as bad as they once were and for impactful changes there should be at least some test coverage, even if that test coverage is just "freezing" what was implemented. As you mentioned the final review discussion is a good chance to verify beyond what review or adversarial review agents find.

visarga 3mo ago
I think the obvious solution here is to beef up the test side of the app, much more than when writing code by hand. Tests represent project knowledge in executable format. The LLM does not need to be careful to remember every detail of the tests. You don't need to vet every small interaction, it automates review work as well. Even better if the project was built from the start to be easier to test and observe. But my golden rule remains - no code without tests, expand test suite all the time.
- densekernel 3mo ago
  I agree, human-steered, AI-implemented test cases can at least capture the acceptance criteria. It's then more efficient to inspect if existing test cases are being modified as part of the delivery of something new and inspect why.

deleted 3mo ago

[deleted]

fy20 3mo ago

The article feels like micromanaging AI. If you think about it like a junior employee, micromanaging them will mean they end up doing the work you want and do it your way. But they won't bring any of their ideas to the table, which in the long run could be beneficial to everyone on the team.

echelon 3mo ago

This is the method I use. It makes sure that I understand everything being generated and that I maintain a firm working knowledge of the codebase at all times. I can easily steer it too.

sixtram 3mo ago

You say you can have increasingly nuanced discussions with stronger models. What I say is, when I asked Claude why he applied a certain change I didn't understand, and boy, it was a small change, he said he "reasoned from first principles" based on the code paths. But it didn't work, and when I asked, "Okay, describe the steps of your reasoning from first principles," it literally answered that it had just made it up. So, nuanced discussions with models, I don't buy it.

solenoid0937 3mo ago
Posts like this are meaningless without more context - the model you're using, the harness, the initial prompt and context. Fable is better than most staff engineers at my FAANG.
- hrmon 3mo ago
  But staff engineers take "responsibility"
- sn0n 3mo ago
  Maybe I’m missing something, but he talks about charm and tasks (repos on his GitHub). Charm being his harness, and tasks being one of his skills. Idk, maybe I’m mistaken from reading the article… https://github.com/taoeffect https://github.com/taoeffect
- maccard 3mo ago
  > Fable is better than most staff engineers at my FAANG. While this wouldn’t entirely surprise me, my experience is just not that. Using Claude and fable, it regularly (poorly) recreates features that exist inside our codebase. Sure, I could give way more initial context but at a certain point I’ve given so much context that I would have been faster writing the code myself, or I could have literally handed it to even a fresh graduate to write.
- well_ackshually 3mo ago
  Fable will definitely be the one on call when it inevitably breaks down from the pile of shit slop it wrote at 5AM, don't worry <3

zquzra 3mo ago

Do you have a background in CS or optimization? MILP is a pretty standard concept in algorithms/optimization. So this example doesn't really convince me that the AI reached some unusually superior conclusion. It sounds more like it suggested a well-known technique that you personally hadn't encountered. Useful, yes, but that seems more about background knowledge gaps than about the merits of letting the tool run unconstrained.

sothatsit 3mo ago
There are always concepts that some people think are a basic, that others haven't heard of. The entire benefit here is that AI can point out what we miss. There are certainly techniques you don't know about, or just didn't think to apply to a problem, that others would find to be pretty standard.

RealityVoid 3mo ago

I am a bit confused which part you disagree with specifically. Reading AI responses and reviewing code seems to be what you propose as well. Your example with MLIP is something that would not be prevented by this approach, during the planing phase, it would surface. I guess the devil is in the details and the way you prompt it for starting the task matters. But IMO you absolutely need to check the output, need to engage with what the model is doing, need to probe why something is built the way the model tries to build it.

sothatsit 3mo ago
I disagree with keeping an eye on the model as it is working, approving every command, and denying and stopping the model when you think it has gone wrong. It is not that it is actively harmful to do this, but rather that it is a waste of time and you can avoid the need for it through better design discussions and review. Micro-managing and keeping the AI on a "short leash" also lends itself better to telling models to do smaller units of work at a time instead of discussing broader design concerns. That is why I think someone doing this would miss the MILP solution, because they might never discuss the overall design with the model but rather just tell it what to implement next.
- te_chris 3mo ago
  I agree. Better to let it rip in a sandbox then spend your time correcting the finished product. Waste of time being in the middle.
- RealityVoid 3mo ago
  I personally am somewhere between you and the author. I don't check _all_ the intermediary steps, but I do try to understand what it's doing [1] and follow the process. Mostly I let it do the changes itself without supervision at each step but when a coherent "chunk" of work is done, I go through it really thoroughly. In almost 90% of the cases after a chunk is done some adjustments are needed. I find broad architectural design to be _better_ if you follow along in the process because you better understand the direction it's going earlier and you can shift the high level direction much earlier. Even if you check its steps, you can ask it for its take on high-level architectural aspects along the way, no problem. I think personal touch matters a lot though, because I naturally ask it and try to get the big picture image. [1] I actually find it really instructive what tooling it uses to tackle a problem, I got to become a much better console user because of it