9 ms·

Tight feedback loops are the key in working productively with software. I see that in codebases up to 700k lines of code (legacy 30yo 4GL ERP systems). The bes

Tight feedback loops are the key in working productively with software. I see that in codebases up to 700k lines of code (legacy 30yo 4GL ERP systems). The best part is that AI-driven systems are fine with running even more tight loops than what a sane human would tolerate. Eg. running full linting, testing and E2E/simulation suite after any minor change. Or generating 4 versions of PR for the same task so that the human could just pick the best one.

deleted 1y ago
[deleted]
OvbiousError 1y ago
I don't think the human is the problem here, but the time it takes to run the full testing suite.
- Byamarro 1y ago
  I work in web dev, so people sometimes hook code formatting as a git commit hook or sometimes even upon file save. The tests are problematic tho. If you work at huge project it's a no go idea at all. If you work at medium then the tests are long enough to block you, but short enough for you not to be able to focus on anything else in the meantime.
- diggan 1y ago
  It is kind of a human problem too, although that the full testing suite takes X hours to run is also not fun, but it makes the human problem larger. Say you're Human A, working on a feature. Running the full testing suite takes 2 hours from start to finish. Every change you do to existing code needs to be confirmed to not break existing stuff with the full testing suite, so some changes it takes 2 hours before you have 100% understanding that it doesn't break other things. How quickly do you lose interest, and at what point do you give up to either improve the testing suite, or just skip that feature/implement it some other way? Now say you're Robot A working on the same task. The robot doesn't care if each change takes 2 hours to appear on their screen, the context is exactly the same, and they're still "a helpful assistant" 48 hours later when they still try to get the feature put together without breaking anything. If you're feeling brave, you start Robot B and C at the same time.
  - abdullin 1y ago
    This is the workflow that ChatGPT Codex demonstrates nicely. Launch any number of «robotic» tasks in parallel, then go on your own. Come back later to review the results and pick good ones.
    - diggan 1y ago
      Well, they're demonstrating it somewhat, it's more of a prototype today. First tell is the low limit, I think the longest task for me been 15 minutes before it gives up. Second tell is still using a chat UI which is simple to implement, easy to implement and familiar, but also kind of lazy. There should be a better UX, especially with the new variations they just added. From the top of my head, some graph-like UX might have been better.
      - abdullin 1y ago
        I guess, it depends on the case and the approach. It works really nice with the following approach (distilled from experiences reported by multiple companies) (1) Augment codebase with explanatory texts that describe individual modules, interfaces and interactions (something that is needed for the humans anyway) (2) Provide Agent.MD that describes the approach/style/process that the AI agent must take. It should also describe how to run all tests. (3) Break down the task into smaller features. For each feature - ask first to write a detailed implementation plan (because it is easier to review the plan than 1000 lines of changes. spread across a dozen files) (4) Review the plan and ask to improve it, if needed. When ready - ask to draft an actual pull request (5) The system will automatically use all available tests/linting/rules before writing the final PR. Verify and provide feedback, if some polish is needed. (6) Launch multiple instances of "write me an implementation plan" and "Implement this plan" task, to pick the one that looks the best. This is very similar to git-driven development of large codebases by distributed teams. Edit: added newlines
        diggan 1y ago
        > distilled from experiences reported by multiple companies Distilled from my experience, I'd still say that the UX is lacking, as sequential chat just isn't the right format. I agree with Karpathy that we haven't found the right way of interacting with these OSes yet. Even with what you say, variations were implemented in a rush. Once you've iterated with one variation you can not at the same time iterate on another variant, for example.
- londons_explore 1y ago
  The full test suite is probably tens of thousands of tests. But AI will do a pretty decent job of telling you which tests are most likely to fail on a given PR. Just run those ones, then commit. Cuts your test time from hours down to seconds. Then run the full test suite only periodically and automatically bisect to find out the cause of any regressions. Dramatically cuts the compute costs of tests too, which in big codebase can easily become whole-engineers worth of costs.
  - tele_ski 1y ago
    It's an interesting idea, but reactive, and could cause big delays due to bisecting and testing on those regressions. There's the 'old' saying that the sooner the bug is found the cheaper it is to fix, seems weird to intentionally push finding side effect bugs later in the process because faster CI runs. Maybe AI will get there but it seems too aggressive right now to me. But yeah, put the automation slider where you're comfortable.
- tlb 1y ago
  Yes, and (some near-future) AI is also more patient and better at multitasking than a reasonable human. It can make a change, submit for full fuzzing, and if there's a problem it can continue with the saved context it had when making the change. It can work on 100s of such changes in parallel, while a human trying to do this would mix up the reasons for the change with all the other changes they'd done by the time the fuzzing result came back. LLMs are worse at many things than human programmers, so you have to try to compensate by leveraging the things they're better at. Don't give up with "they're bad at such and such" until you've tried using their strengths.
  - HappMacDonald 1y ago
    You can't run N bots in parallel with testing between each attempt unless you're also running N tests in parallel. If you could run N tests in parallel, then you could probably also run the components of one test in parallel and keep it from taking 2 hours in the first place. To me this all sounds like snake oil to convince people to do something they were already doing, but by also spinning up N times as many compute instances and run a burn endless tokens along the way. And by the time it's demonstrated that it doesn't really offer anything more than doing it yourself, well you've already given them all of your money so their job is done.
    - abdullin 1y ago
      Running tests is already an engineering problem. In one of the systems (supply chain SaaS) we invested so much effort in having good tests in a simulated environment, that we could run full-stack tests at kHz. Roughly ~5k tests per second or so on a laptop.
- abdullin 1y ago
  Humans tend to lack inhumane patience.
- 9rx 1y ago
  Unless you are doing something crazy like letting the fuzzer run on every change (cache that shit), the full test suite taking a long time suggests that either your isolation points are way too large or you are letting the LLM cross isolated boundaries and "full testing suite" here actually means "multiple full testing suites". The latter is an easy fix: Don't let it. Force it stay within a single isolation zone just like you'd expect of a human. The former is a lot harder to fix, but I suppose ending up there is a strong indicator that you can't trust the human picking the best LLM result in the first place and that maybe this whole thing isn't a good idea for the people in your organization.
yahoozoo 1y ago
The problem is that every time you run your full automation with linting and tests, you’re filling up the context window more and more. I don’t know how people using Claude do it with its <300k context window. I get the “your message will exceed the length of this chat” message so many times.
- diggan 1y ago
  I don't know exactly how Claude works, but the way I work around this with my own stuff is prompting it to not display full outputs ever, and instead temporary redirect the output somewhere then grep from the log-file what it's looking for. So a test run outputting 10K lines of test output and one failure is easily found without polluting the context with 10K lines.
- the_mitsuhiko 1y ago
  I started to use sub agents for that. That does not pollute the context as much
- abdullin 1y ago
  Claude's approach is currently a bit dated. Cursor.sh agents or especially OpenAI Codex illustrate that a tool doesn't need to keep on stuffing context window with irrelevant information in order to make progress on a task. And if really needed, engineers report that Gemini Pro 2.5 keeps on working fine within 200k-500k token context. Above that - it is better to reset the context.
latexr 1y ago
> Or generating 4 versions of PR for the same task so that the human could just pick the best one. That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality. Why are we doing this to ourselves and embracing it? A few years ago, it would have been seen as a joke to say “the future of software development will be to have a million monkey interns banging on one million keyboards and submit a million PRs, then choose one”. Today, it’s lauded as a brilliant business and cost-saving idea. We’re beyond doomed. The first major catastrophe caused by sloppy AI code can’t come soon enough. The sooner it happens, the better chance we have to self-correct.
- bonoboTP 1y ago
  If it's monkeylike quality and you need a million tries, it's shit. It you need four tries and one of those is top-tier professional programmer quality, then it's good.
  - agos 1y ago
    if the thing producing the four PRs can't distinguish the top tier one, I have strong doubts that it can even produce it
    - solaire_oa 1y ago
      Making 4 PRs for a well-known solution sounds insane, yes, but to be the devil's advocate, you could plausibly be working with an ambiguous task: "Create 4 PRs with 4 different dependency libraries, so that I can compare their implementations." Technically it wouldn't need to pick the best one. I have apprehension about the future of software engineering, but comparison does technically seem like a valid use case.
  - deleted 1y ago
    [deleted]
  - layer8 1y ago
    The problem is, for any change, you have to understand the existing code base to assess the quality of the change in the four tries. This means, you aren’t relieved from being familiar with the code and reviewing everything. For many developers this review-only work style isn’t an exciting prospect. And it will remain that way until you can delegate development tasks to AI with a 99+% success rate so that you don’t have to review their output and understand the code base anymore. At which point developers will become truly obsolete.
bandoti 1y ago
Here’s a few problems I foresee: 1. People get lazy when presented with four choices they had no hand in creating, and they don’t look over the four and just click one, ignoring the others. Why? Because they have ten more of these on the go at once, diminishing their overall focus. 2. Automated tests, end-to-end sim., linting, etc—tools already exist and work at scale. They should be robust and THOROUGHLY reviewed by both AI and humans ideally. 3. AI is good for code reviews and “another set of eyes” but man it makes serious mistakes sometimes. An anecdote for (1), when ChatGPT tries to A/B test me with two answers, it’s incredibly burdensome for me to read twice virtually the same thing with minimal differences. Code reviewing four things that do almost the same thing is more of a burden than writing the same thing once myself.
- abdullin 1y ago
  A simple rule applies: "No matter what tool created the code, you are still responsible for what you merge into main". As such, task of verification, still falls on hands of engineers. Given that and proper processes, modern tooling works nicely with codebases ranging from 10k LOC (mixed embedded device code with golang backends and python DS/ML) to 700k LOC (legacy enterprise applications from the mainframe era)
  - bandoti 1y ago
    Agreed. I think engineers though following simple Test-Driven Development procedures can write the code, unit tests, integration tests, debug, etc for a small enough unit by default forces tight feedback loops. AI may assist in the particulars, not run the show. I’m willing to bet, short of droid-speak or some AI output we can’t even understand, that when considering “the system as a whole”, that even with short-term gains in speed, the longevity of any product will be better with real people following current best-practices, and perhaps a modest sprinkle of AI. Why? Because AI is trained on the results of human endeavors and can only work within that framework.
    - abdullin 1y ago
      Agreed. AI is just a tool. Letting in run the show is essentially what the vibe-coding is. It is a fun activity for prototyping, but tends to accumulate problems and tech debt at an astonishing pace. Code, manually crafted by professionals, will almost always beat AI-driven code in quality. Yet, one has still to find such professionals and wait for them to get the job done. I think, the right balance is somewhere in between - let tools handle the mundane parts (e.g. mechanically rewriting that legacy Progress ABL/4GL code to Kotlin), while human engineers will have fun with high-level tasks and shaping the direction of the project.
elif 1y ago
In my experience with Jules and (worse) Codex, juggling multiple pull requests at once is not advised. Even if you tell the git-aware Jules to handle a merge conflict within the context window the patch was generated, it is like sorry bro I have no idea what's wrong can you send me a diff with the conflict? I find i have to be in the iteration loop at every stage or else the agent will forget what it's doing or why rapidly. for instance don't trust Jules to run your full test suite after every change without handholding and asking for specific run results every time. It feels like to an LLM, gaslighting you with code that nominally addresses the core of what you just asked while completely breaking unrelated code or disregarding previously discussed parameters is an unmitigated success.
layer8 1y ago
> Tight feedback loops are the key in working productively with software. […] even more tight loops than what a sane human would tolerate. Why would a sane human be averse to things happening instantaneously?

deleted 1y ago

[deleted]

OvbiousError 1y ago

I don't think the human is the problem here, but the time it takes to run the full testing suite.

Byamarro 1y ago
I work in web dev, so people sometimes hook code formatting as a git commit hook or sometimes even upon file save. The tests are problematic tho. If you work at huge project it's a no go idea at all. If you work at medium then the tests are long enough to block you, but short enough for you not to be able to focus on anything else in the meantime.
diggan 1y ago
It is kind of a human problem too, although that the full testing suite takes X hours to run is also not fun, but it makes the human problem larger. Say you're Human A, working on a feature. Running the full testing suite takes 2 hours from start to finish. Every change you do to existing code needs to be confirmed to not break existing stuff with the full testing suite, so some changes it takes 2 hours before you have 100% understanding that it doesn't break other things. How quickly do you lose interest, and at what point do you give up to either improve the testing suite, or just skip that feature/implement it some other way? Now say you're Robot A working on the same task. The robot doesn't care if each change takes 2 hours to appear on their screen, the context is exactly the same, and they're still "a helpful assistant" 48 hours later when they still try to get the feature put together without breaking anything. If you're feeling brave, you start Robot B and C at the same time.
- abdullin 1y ago
  This is the workflow that ChatGPT Codex demonstrates nicely. Launch any number of «robotic» tasks in parallel, then go on your own. Come back later to review the results and pick good ones.
  - diggan 1y ago
    Well, they're demonstrating it somewhat, it's more of a prototype today. First tell is the low limit, I think the longest task for me been 15 minutes before it gives up. Second tell is still using a chat UI which is simple to implement, easy to implement and familiar, but also kind of lazy. There should be a better UX, especially with the new variations they just added. From the top of my head, some graph-like UX might have been better.
    - abdullin 1y ago
      I guess, it depends on the case and the approach. It works really nice with the following approach (distilled from experiences reported by multiple companies) (1) Augment codebase with explanatory texts that describe individual modules, interfaces and interactions (something that is needed for the humans anyway) (2) Provide Agent.MD that describes the approach/style/process that the AI agent must take. It should also describe how to run all tests. (3) Break down the task into smaller features. For each feature - ask first to write a detailed implementation plan (because it is easier to review the plan than 1000 lines of changes. spread across a dozen files) (4) Review the plan and ask to improve it, if needed. When ready - ask to draft an actual pull request (5) The system will automatically use all available tests/linting/rules before writing the final PR. Verify and provide feedback, if some polish is needed. (6) Launch multiple instances of "write me an implementation plan" and "Implement this plan" task, to pick the one that looks the best. This is very similar to git-driven development of large codebases by distributed teams. Edit: added newlines
      - diggan 1y ago
        > distilled from experiences reported by multiple companies Distilled from my experience, I'd still say that the UX is lacking, as sequential chat just isn't the right format. I agree with Karpathy that we haven't found the right way of interacting with these OSes yet. Even with what you say, variations were implemented in a rush. Once you've iterated with one variation you can not at the same time iterate on another variant, for example.
londons_explore 1y ago
The full test suite is probably tens of thousands of tests. But AI will do a pretty decent job of telling you which tests are most likely to fail on a given PR. Just run those ones, then commit. Cuts your test time from hours down to seconds. Then run the full test suite only periodically and automatically bisect to find out the cause of any regressions. Dramatically cuts the compute costs of tests too, which in big codebase can easily become whole-engineers worth of costs.
- tele_ski 1y ago
  It's an interesting idea, but reactive, and could cause big delays due to bisecting and testing on those regressions. There's the 'old' saying that the sooner the bug is found the cheaper it is to fix, seems weird to intentionally push finding side effect bugs later in the process because faster CI runs. Maybe AI will get there but it seems too aggressive right now to me. But yeah, put the automation slider where you're comfortable.
tlb 1y ago
Yes, and (some near-future) AI is also more patient and better at multitasking than a reasonable human. It can make a change, submit for full fuzzing, and if there's a problem it can continue with the saved context it had when making the change. It can work on 100s of such changes in parallel, while a human trying to do this would mix up the reasons for the change with all the other changes they'd done by the time the fuzzing result came back. LLMs are worse at many things than human programmers, so you have to try to compensate by leveraging the things they're better at. Don't give up with "they're bad at such and such" until you've tried using their strengths.
- HappMacDonald 1y ago
  You can't run N bots in parallel with testing between each attempt unless you're also running N tests in parallel. If you could run N tests in parallel, then you could probably also run the components of one test in parallel and keep it from taking 2 hours in the first place. To me this all sounds like snake oil to convince people to do something they were already doing, but by also spinning up N times as many compute instances and run a burn endless tokens along the way. And by the time it's demonstrated that it doesn't really offer anything more than doing it yourself, well you've already given them all of your money so their job is done.
  - abdullin 1y ago
    Running tests is already an engineering problem. In one of the systems (supply chain SaaS) we invested so much effort in having good tests in a simulated environment, that we could run full-stack tests at kHz. Roughly ~5k tests per second or so on a laptop.
abdullin 1y ago
Humans tend to lack inhumane patience.
9rx 1y ago
Unless you are doing something crazy like letting the fuzzer run on every change (cache that shit), the full test suite taking a long time suggests that either your isolation points are way too large or you are letting the LLM cross isolated boundaries and "full testing suite" here actually means "multiple full testing suites". The latter is an easy fix: Don't let it. Force it stay within a single isolation zone just like you'd expect of a human. The former is a lot harder to fix, but I suppose ending up there is a strong indicator that you can't trust the human picking the best LLM result in the first place and that maybe this whole thing isn't a good idea for the people in your organization.

yahoozoo 1y ago

The problem is that every time you run your full automation with linting and tests, you’re filling up the context window more and more. I don’t know how people using Claude do it with its <300k context window. I get the “your message will exceed the length of this chat” message so many times.

diggan 1y ago
I don't know exactly how Claude works, but the way I work around this with my own stuff is prompting it to not display full outputs ever, and instead temporary redirect the output somewhere then grep from the log-file what it's looking for. So a test run outputting 10K lines of test output and one failure is easily found without polluting the context with 10K lines.
the_mitsuhiko 1y ago
I started to use sub agents for that. That does not pollute the context as much
abdullin 1y ago
Claude's approach is currently a bit dated. Cursor.sh agents or especially OpenAI Codex illustrate that a tool doesn't need to keep on stuffing context window with irrelevant information in order to make progress on a task. And if really needed, engineers report that Gemini Pro 2.5 keeps on working fine within 200k-500k token context. Above that - it is better to reset the context.

latexr 1y ago

> Or generating 4 versions of PR for the same task so that the human could just pick the best one. That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality. Why are we doing this to ourselves and embracing it? A few years ago, it would have been seen as a joke to say “the future of software development will be to have a million monkey interns banging on one million keyboards and submit a million PRs, then choose one”. Today, it’s lauded as a brilliant business and cost-saving idea. We’re beyond doomed. The first major catastrophe caused by sloppy AI code can’t come soon enough. The sooner it happens, the better chance we have to self-correct.

bonoboTP 1y ago
If it's monkeylike quality and you need a million tries, it's shit. It you need four tries and one of those is top-tier professional programmer quality, then it's good.
- agos 1y ago
  if the thing producing the four PRs can't distinguish the top tier one, I have strong doubts that it can even produce it
  - solaire_oa 1y ago
    Making 4 PRs for a well-known solution sounds insane, yes, but to be the devil's advocate, you could plausibly be working with an ambiguous task: "Create 4 PRs with 4 different dependency libraries, so that I can compare their implementations." Technically it wouldn't need to pick the best one. I have apprehension about the future of software engineering, but comparison does technically seem like a valid use case.
- deleted 1y ago
  [deleted]
- layer8 1y ago
  The problem is, for any change, you have to understand the existing code base to assess the quality of the change in the four tries. This means, you aren’t relieved from being familiar with the code and reviewing everything. For many developers this review-only work style isn’t an exciting prospect. And it will remain that way until you can delegate development tasks to AI with a 99+% success rate so that you don’t have to review their output and understand the code base anymore. At which point developers will become truly obsolete.

bandoti 1y ago

Here’s a few problems I foresee: 1. People get lazy when presented with four choices they had no hand in creating, and they don’t look over the four and just click one, ignoring the others. Why? Because they have ten more of these on the go at once, diminishing their overall focus. 2. Automated tests, end-to-end sim., linting, etc—tools already exist and work at scale. They should be robust and THOROUGHLY reviewed by both AI and humans ideally. 3. AI is good for code reviews and “another set of eyes” but man it makes serious mistakes sometimes. An anecdote for (1), when ChatGPT tries to A/B test me with two answers, it’s incredibly burdensome for me to read twice virtually the same thing with minimal differences. Code reviewing four things that do almost the same thing is more of a burden than writing the same thing once myself.

abdullin 1y ago
A simple rule applies: "No matter what tool created the code, you are still responsible for what you merge into main". As such, task of verification, still falls on hands of engineers. Given that and proper processes, modern tooling works nicely with codebases ranging from 10k LOC (mixed embedded device code with golang backends and python DS/ML) to 700k LOC (legacy enterprise applications from the mainframe era)
- bandoti 1y ago
  Agreed. I think engineers though following simple Test-Driven Development procedures can write the code, unit tests, integration tests, debug, etc for a small enough unit by default forces tight feedback loops. AI may assist in the particulars, not run the show. I’m willing to bet, short of droid-speak or some AI output we can’t even understand, that when considering “the system as a whole”, that even with short-term gains in speed, the longevity of any product will be better with real people following current best-practices, and perhaps a modest sprinkle of AI. Why? Because AI is trained on the results of human endeavors and can only work within that framework.
  - abdullin 1y ago
    Agreed. AI is just a tool. Letting in run the show is essentially what the vibe-coding is. It is a fun activity for prototyping, but tends to accumulate problems and tech debt at an astonishing pace. Code, manually crafted by professionals, will almost always beat AI-driven code in quality. Yet, one has still to find such professionals and wait for them to get the job done. I think, the right balance is somewhere in between - let tools handle the mundane parts (e.g. mechanically rewriting that legacy Progress ABL/4GL code to Kotlin), while human engineers will have fun with high-level tasks and shaping the direction of the project.

elif 1y ago

In my experience with Jules and (worse) Codex, juggling multiple pull requests at once is not advised. Even if you tell the git-aware Jules to handle a merge conflict within the context window the patch was generated, it is like sorry bro I have no idea what's wrong can you send me a diff with the conflict? I find i have to be in the iteration loop at every stage or else the agent will forget what it's doing or why rapidly. for instance don't trust Jules to run your full test suite after every change without handholding and asking for specific run results every time. It feels like to an LLM, gaslighting you with code that nominally addresses the core of what you just asked while completely breaking unrelated code or disregarding previously discussed parameters is an unmitigated success.

layer8 1y ago

> Tight feedback loops are the key in working productively with software. […] even more tight loops than what a sane human would tolerate. Why would a sane human be averse to things happening instantaneously?