9 ms·

I keep wondering how people accept a nights worth of agent activity. I feel 30 minutes of planning and 30 minutes of implementation in my solo side project's r

I keep wondering how people accept a nights worth of agent activity. I feel 30 minutes of planning and 30 minutes of implementation in my solo side project's repo is too big to review. At minute 5, I may ask the AI to redo stuff even as its spitting out code.

fphilipe 5mo ago
I wonder the same. The answer I usually get from people who do manage is that they don't look at the code – or at least not in detail. Personally, I always end up tweaking something the agent produced. I wonder if I should let go of that control...
- debabrata_saha 5mo ago
  yeah
- InsideOutSanta 5mo ago
  Even the newest models, like GPT 5.5, only deliver what I want nine out of ten times. If I didn't catch the remaining 10% of misguided garbage by manually reviewing every change, it would add up really quickly.
- stavros 5mo ago
  I never look at code. It used to be that it quickly became unmaintainable spaghetti where the agent struggled to make any change at all, but in the past year (and with a three step plan/develop/review workflow), the quality is so good that I basically just don't look at the code any more. It definitely has fewer bugs than a senior developer, but it really hinges on getting the plan right. 20 minutes of planning and 20 of implementation sounds about right for my workflow as well, just make sure you have GPT as a reviewer. It's very nitpicky and finds lots of bugs.
  - materielle 5mo ago
    This brings to mind two thoughts: First, that this is challenging to scale across large orgs. Even if your plans produce high quality code, that isn’t true for everyone. I’m definitely struggling with slop code being collectively mailed to me for review my our 1,000 engineers that were told to use their AI subscription all at once. I feel like we should be taking “prompt engineering” more seriously. And when people mail me code to review, it should also include the agentic workflow and plan. So that when code isn’t up to quality, and can have a discussion about the prompts used to generate it. My second thought is related to your senior engineer comment. This isn’t surprising, because in most engineering orgs, seniority is completely unrelated to code quality. In fact, many orgs incentive the opposite: “senior” devs that push out buggy code quickly and push accountability downhill to the junior devs.
    - stavros 5mo ago
      Eh, everything is challenging to scale across large orgs. Even before LLMs, the code was a huge ball of spaghetti that barely held together. Now we just get there faster. About senior engineers, I guess that depends on the org you have experience with. My experience doesn't match yours.
    - jappgar 5mo ago
      I'm so curious to see how other people prompt but literally no one I work with will share it. They might share plans, but they never show the conversation, which is the most crucial part. Judging by how they struggle to communicate generally, I can't imagine their prompts are doing much heavy lifting.
  - jappgar 5mo ago
    20 minutes planning, 20 minutes coding, 200 minutes review and refactor (includes going for a walk and thinking about the problem deeply). I know a lot of engineers who skip the last part. They're over confident in their original plan. They're over confident the agent actually fulfilled the plan.
    - stavros 5mo ago
      You aren't treating this as a question of ROI. Is it worth spending 5x as much to make sure the plan was OK and implemented well? Or is it actually OK if we discover the bug during testing? The answer won't be the same for all software, but you're assuming it will be.
  - bogdanoff_2 5mo ago
    I'm starting to agree with you; I found the plan/develop/review workflow to work quite well, but I'm not at the point of not looking at the code at all yet. I guess you actually review and actively participate in making the plan, you just don't review the code afterwards? Could you share some more details on the specifics of your workflow? (What models/harnesses? do you use the same or different context windows? How exactly do you run the review, and how do you pass along and act upon the information from the review?) Also, how big are the changes you usually implement with one plan/develop/review cycle?
    - stavros 5mo ago
      Sure! Here: https://www.stavros.io/posts/how-i-write-software-with-llms/ https://www.stavros.io/posts/how-i-write-software-with-llms/ The changes aren't usually very big, basically what you'd put in one ticket. If I need to make large changes, I do them in self-contained stages, if that's possible, otherwise I will tell the LLM to add specific tests in the plan, and I will test thoroughly after.
lanyard-textile 5mo ago
A lot of that agent activity is combing over what was previously made, forcing constraints upon it so you have a reasonable expectation of what ends up on your desk for review. For me, strong file structure helps as well. Reviewing a 3,000 line file it just created is abysmal. I wouldn't accept that from human nor machine :) Multiple files in the right places helps reduce cognitive load. Sometimes I'll also review with the agent interactively. What is the most important file to review first, etc? I like to stage changes into a "LGTM" pile. Then if I want changes, I'll have the agent "review unstaged changes - I want something different done here."
throw03172019 5mo ago
They most likely don’t review it ;)
- JJOKOCHAA 5mo ago
  [dead]
szundi 5mo ago
Lots of people are working on repetitive simple projects like the Nth website whatever or things like that, boring stuff. This LLM era is already a very big deal for these people. Personally somehow I am working on stuff that has like 25% not trivial stuff and that is enough to have the same experience as you have. But also lots of people just don't care about quality and they might be right with their customers/audience. In these cases when someone catches one, an agent is going to iterate on it and make it (seemingly) go away, bandage applied, who cares again. This has a market, I am sure. Lots of programmer folks are just as bad.
d4rkp4ttern 5mo ago
Most of the narrative is about how AI is writing all/most code, but I’d wager that the fraction of human reviewed code is approaching zero far faster than anyone is realizing or willing to admit.
- deleted 5mo ago
  [deleted]
- londons_explore 5mo ago
  Very true. Last year I at least glanced at every line of AI generated code. Now if some AI makes a 10k line program for some one-off tasks, I run the program, glance only over the output, and move on.
  - MaKey 5mo ago
    Which one-off tasks need 10k lines of code?
    - londons_explore 5mo ago
      Calculate the engine power of a 2015 VW polo when travelling 70 mph on a flat road behind a box truck. Draw a chart of drag Vs follow distance. How significant is humidity on the result?
      - Grosvenor 5mo ago
        European or African Polo?
        metrix 5mo ago
        I don't know th- AAAAHHHH
        noduerme 5mo ago
        You're not supposed to post that you just like a comment, but this was best comment on HN in ages.
mlyle 5mo ago
So I've been in a hobby project for a few weeks -- transforming an old software modem binary to c code. I gave it the existing modem, and had it build rigging to build test vectors. I had it specify the work in the modem. And to confirm that legacy<>legacy produced the same streams as the new code. I've also recorded test vectors vs. other modems. I've since launched it on targeted refactoring and code reduction projects. I am mostly not looking at the code. There's a 100KSLOC lump of code that is much cleaner than a decompilation but a fair bit dirtier than what I would write myself. It is not factored terribly. I have some hope of getting it to trim this down to 70KSLOC that then I can accept in small blocks. It outperforms the original softmodem, hitting higher RX rates for the same line quality and using less CPU. It also has additional functionality. So, you know, I would never have written something this large for a hobby myself. And it's cost me $200 and 20-30 minutes per day for a few weeks to get a huge functional surface that I do believe I will be able to trust at the end of the process.
- Brian_K_White 5mo ago
  I don't like that there are any good sounding stories, but this sounds pretty good.
bluGill 5mo ago
That depends. When I'm working on a 1 in a million race condition in some multi-threaded code, the agent needs hours to figure out what is going on. (I would probably need weeks - I don't know as I've given up on some of these before I could point an agent at it)
siva7 5mo ago
Yes it is too big to review for you - the human - so you simply don't review code anymore. Isn't that difficult to comprehend, is it?
deleted 5mo ago
[deleted]
dakiol 5mo ago
No one is reviewing the code. Managers don't want us to review code either. It's a bottleneck. If something goes wrong (bugs) they are fixed as they come. It's a very sad era of software engineering. If there ever was some engineering in our trade, now it's mostly gone. We are guessing around, writing "skills" files with "please, do not introduce bugs" or "you are an owner, not a renter" or similar stuff. It's just very low effort, very undeterministic. Big apps out there are going down constantly because of AI slop (e.g., Github), and we are seeing it more often as well in non-so popular systems (e.g., in my company and other saas that we use). Product managers never cared about the code. Engineering managers don't care about code as much as they did when they were engineers. Directors couldn't care less about code. CTOs don't know what code looks like anymore. We are at the end of the chain, and somehow we always took pride of well written and maintainble code because we knew deep inside that good systems are built based on good code. But now we are jeopardizing ourselves, it's us the engineers who don't care anymore about code and with AI that problems is amplified.
Kwpolska 5mo ago
They don’t, they just have Claude commit and push straight to the main branch. Just like the author of this 100% slop app: https://github.com/leodavinci1/kanbots/commits/main/ https://github.com/leodavinci1/kanbots/commits/main/
SatvikBeri 5mo ago
I usually aim to have Claude end up with about 500 lines of code after a night of work. Most of what it's doing is experimenting with many different approaches, summarizing them, and then giving me a relatively small diff to review and modify.
- a1o 5mo ago
  This is the way to go. I usually play with relatively stable software where the improvements are either performance or very small niche features that are built on top of already existing ones. Big changes are undesirable by both the others working on it and its users.
BosunoB 5mo ago
Yeah the multi-agent workflow just hasn't been satisfying to me. The more chats I try to run at once, the more I got lost and overwhelmed. I trust Claude to implement a plan correctly after I've reviewed it, but if I don't review all of the plans, I will miss some small detail that it misunderstood and it'll be a pain to fix later. I'm like a 1-2 chats at a time kind of guy. I just don't see how I could keep my exact vision for the project otherwise.
- hgoel 5mo ago
  Same, on top of that multi-agent workflows just cost too much to make stopping and correcting them to feel worthwhile, compared to one or two manually managed chats
keyle 5mo ago
Those people don't review.
deleted 5mo ago
[deleted]
suralind 5mo ago
I agree, but for small tasks - <20 lines that I can understand in a minute or two - perfect. Thinking about it - I have hundreds, if not thousands of tasks that I would like to do, improving pipelines, migrating from one tool to another, but never have time. The only question is - if I don't have time to do it, do I have time to prompt it?
anhphong 5mo ago
[flagged]
digitaltrees 5mo ago
You care about code quality. Many don’t. I had someone tell me this week that a 6000 line class was ok because it was easier for the model to understand and that’s more important than human comprehension. And I get his point but that seems like a big risk to take.
- mpalczewski 5mo ago
  and it's wrong. a 6000 line class is not easier for a model to understand. the same things that help humans also help agents. I find myself adding linters that must pass and the agent muss fix that limit file size, function length, function complexity, how many files in a directory. a little more work for the agent, but the codebase is healthier and the agents write fewer bugs.
  - lukevdp 5mo ago
    I don't think the same things that help humans help agents. Simplicity helps humans, for agents parsing complexity is a breeze. Not saying code quality isn't important - it is. But I think what is described as quality code will change.
    - cjbgkagh 5mo ago
      Agents still pay a penalty for complexity even if it is a smaller one.
      - digitaltrees 5mo ago
        Parsing single file is easier than navigating a file system for an LLM. Until the models have context windows large enough to hold the entire codebase in one shot, single files will beat multiple files every time.
        bossyTeacher 5mo ago
        This. I suspect the codebases in the future will be made of a small number of gigantic source files. These will be able to be transpiled into a more human friendly that produces multiple smaller files per big file in human-debug mode.
faangguyindia 5mo ago
whenever i found a guy who uses parallel overnight agents, i asked them how many users they have. Crickets. They do not have any users. Meanwhile, i've to do code reviews and all otherwise my 12,000+ users will be pissed off if anything in their workflow breaks. This means i really cannot release more than 1 tiny feature a day. And using parallel agents, well that's good for testing but i don't think i need to add that many features to add anything.
zx8080 5mo ago
Cost of generation is low, why review? Regenerate if not working. Rinse and repeat. Maximize providers profits. What can go wrong.
toobulkeh 5mo ago
Testing
nobodywillobsrv 5mo ago
I understand and agree with the feeling but then I also feel AI is too slow and too expensive. My most successful autonomous runs have been expanding scrapers across a number of similar but different portals. I had examples and targets and it just kept searching for new ones and adding them. But even doing basic ML auto research k have found it to be surprisingly poor except at trivial but useful augmentation of models. Yes it can implement things but somehow I am required a lot even though I set up a lot of framework around it. My mental model is that it's very good at complex deterministic work like reading bad API docs and getting some connectors to work. But perhaps I care less about being stuck in a local optimum there.
JodieBenitez 5mo ago
I never review anything writtend by codex in my pet projects. It works or it doesn't and then I prompt again. I can see how it's easy to multiply agents in this case. Now when using it for my job... that's a totally different story: I review all the changes, so a single chat session with an agent can lead to a whole day of review. And it's great, sometimes the agent uses patterns and functions I don't know, so I learn a lot.
risyachka 5mo ago
No one reads code that results from this. Those who say otherwise either lie or are very bad developers which is essentially the same as not reading that code.
cold_harbor 5mo ago
the bottleneck moves from generation to review. agents parallelize, humans review sequentially — 8 parallel cards means 8x the diffs to read, none of the timelines overlap
jgalt212 5mo ago
Without agentic coding the number go up narrative dies. There's your answer.
gopher_space 5mo ago
Everything I can batch overnight locally is free.

fphilipe 5mo ago

I wonder the same. The answer I usually get from people who do manage is that they don't look at the code – or at least not in detail. Personally, I always end up tweaking something the agent produced. I wonder if I should let go of that control...

debabrata_saha 5mo ago
yeah
InsideOutSanta 5mo ago
Even the newest models, like GPT 5.5, only deliver what I want nine out of ten times. If I didn't catch the remaining 10% of misguided garbage by manually reviewing every change, it would add up really quickly.
stavros 5mo ago
I never look at code. It used to be that it quickly became unmaintainable spaghetti where the agent struggled to make any change at all, but in the past year (and with a three step plan/develop/review workflow), the quality is so good that I basically just don't look at the code any more. It definitely has fewer bugs than a senior developer, but it really hinges on getting the plan right. 20 minutes of planning and 20 of implementation sounds about right for my workflow as well, just make sure you have GPT as a reviewer. It's very nitpicky and finds lots of bugs.
- materielle 5mo ago
  This brings to mind two thoughts: First, that this is challenging to scale across large orgs. Even if your plans produce high quality code, that isn’t true for everyone. I’m definitely struggling with slop code being collectively mailed to me for review my our 1,000 engineers that were told to use their AI subscription all at once. I feel like we should be taking “prompt engineering” more seriously. And when people mail me code to review, it should also include the agentic workflow and plan. So that when code isn’t up to quality, and can have a discussion about the prompts used to generate it. My second thought is related to your senior engineer comment. This isn’t surprising, because in most engineering orgs, seniority is completely unrelated to code quality. In fact, many orgs incentive the opposite: “senior” devs that push out buggy code quickly and push accountability downhill to the junior devs.
  - stavros 5mo ago
    Eh, everything is challenging to scale across large orgs. Even before LLMs, the code was a huge ball of spaghetti that barely held together. Now we just get there faster. About senior engineers, I guess that depends on the org you have experience with. My experience doesn't match yours.
  - jappgar 5mo ago
    I'm so curious to see how other people prompt but literally no one I work with will share it. They might share plans, but they never show the conversation, which is the most crucial part. Judging by how they struggle to communicate generally, I can't imagine their prompts are doing much heavy lifting.
- jappgar 5mo ago
  20 minutes planning, 20 minutes coding, 200 minutes review and refactor (includes going for a walk and thinking about the problem deeply). I know a lot of engineers who skip the last part. They're over confident in their original plan. They're over confident the agent actually fulfilled the plan.
  - stavros 5mo ago
    You aren't treating this as a question of ROI. Is it worth spending 5x as much to make sure the plan was OK and implemented well? Or is it actually OK if we discover the bug during testing? The answer won't be the same for all software, but you're assuming it will be.
- bogdanoff_2 5mo ago
  I'm starting to agree with you; I found the plan/develop/review workflow to work quite well, but I'm not at the point of not looking at the code at all yet. I guess you actually review and actively participate in making the plan, you just don't review the code afterwards? Could you share some more details on the specifics of your workflow? (What models/harnesses? do you use the same or different context windows? How exactly do you run the review, and how do you pass along and act upon the information from the review?) Also, how big are the changes you usually implement with one plan/develop/review cycle?
  - stavros 5mo ago
    Sure! Here: https://www.stavros.io/posts/how-i-write-software-with-llms/ https://www.stavros.io/posts/how-i-write-software-with-llms/ The changes aren't usually very big, basically what you'd put in one ticket. If I need to make large changes, I do them in self-contained stages, if that's possible, otherwise I will tell the LLM to add specific tests in the plan, and I will test thoroughly after.

lanyard-textile 5mo ago

A lot of that agent activity is combing over what was previously made, forcing constraints upon it so you have a reasonable expectation of what ends up on your desk for review. For me, strong file structure helps as well. Reviewing a 3,000 line file it just created is abysmal. I wouldn't accept that from human nor machine :) Multiple files in the right places helps reduce cognitive load. Sometimes I'll also review with the agent interactively. What is the most important file to review first, etc? I like to stage changes into a "LGTM" pile. Then if I want changes, I'll have the agent "review unstaged changes - I want something different done here."

throw03172019 5mo ago

They most likely don’t review it ;)

JJOKOCHAA 5mo ago
[dead]

szundi 5mo ago

Lots of people are working on repetitive simple projects like the Nth website whatever or things like that, boring stuff. This LLM era is already a very big deal for these people. Personally somehow I am working on stuff that has like 25% not trivial stuff and that is enough to have the same experience as you have. But also lots of people just don't care about quality and they might be right with their customers/audience. In these cases when someone catches one, an agent is going to iterate on it and make it (seemingly) go away, bandage applied, who cares again. This has a market, I am sure. Lots of programmer folks are just as bad.

d4rkp4ttern 5mo ago

Most of the narrative is about how AI is writing all/most code, but I’d wager that the fraction of human reviewed code is approaching zero far faster than anyone is realizing or willing to admit.

deleted 5mo ago
[deleted]
londons_explore 5mo ago
Very true. Last year I at least glanced at every line of AI generated code. Now if some AI makes a 10k line program for some one-off tasks, I run the program, glance only over the output, and move on.
- MaKey 5mo ago
  Which one-off tasks need 10k lines of code?
  - londons_explore 5mo ago
    Calculate the engine power of a 2015 VW polo when travelling 70 mph on a flat road behind a box truck. Draw a chart of drag Vs follow distance. How significant is humidity on the result?
    - Grosvenor 5mo ago
      European or African Polo?
      - metrix 5mo ago
        I don't know th- AAAAHHHH
      - noduerme 5mo ago
        You're not supposed to post that you just like a comment, but this was best comment on HN in ages.

mlyle 5mo ago

So I've been in a hobby project for a few weeks -- transforming an old software modem binary to c code. I gave it the existing modem, and had it build rigging to build test vectors. I had it specify the work in the modem. And to confirm that legacy<>legacy produced the same streams as the new code. I've also recorded test vectors vs. other modems. I've since launched it on targeted refactoring and code reduction projects. I am mostly not looking at the code. There's a 100KSLOC lump of code that is much cleaner than a decompilation but a fair bit dirtier than what I would write myself. It is not factored terribly. I have some hope of getting it to trim this down to 70KSLOC that then I can accept in small blocks. It outperforms the original softmodem, hitting higher RX rates for the same line quality and using less CPU. It also has additional functionality. So, you know, I would never have written something this large for a hobby myself. And it's cost me $200 and 20-30 minutes per day for a few weeks to get a huge functional surface that I do believe I will be able to trust at the end of the process.

Brian_K_White 5mo ago
I don't like that there are any good sounding stories, but this sounds pretty good.

bluGill 5mo ago

That depends. When I'm working on a 1 in a million race condition in some multi-threaded code, the agent needs hours to figure out what is going on. (I would probably need weeks - I don't know as I've given up on some of these before I could point an agent at it)

siva7 5mo ago

Yes it is too big to review for you - the human - so you simply don't review code anymore. Isn't that difficult to comprehend, is it?

deleted 5mo ago

[deleted]

dakiol 5mo ago

No one is reviewing the code. Managers don't want us to review code either. It's a bottleneck. If something goes wrong (bugs) they are fixed as they come. It's a very sad era of software engineering. If there ever was some engineering in our trade, now it's mostly gone. We are guessing around, writing "skills" files with "please, do not introduce bugs" or "you are an owner, not a renter" or similar stuff. It's just very low effort, very undeterministic. Big apps out there are going down constantly because of AI slop (e.g., Github), and we are seeing it more often as well in non-so popular systems (e.g., in my company and other saas that we use). Product managers never cared about the code. Engineering managers don't care about code as much as they did when they were engineers. Directors couldn't care less about code. CTOs don't know what code looks like anymore. We are at the end of the chain, and somehow we always took pride of well written and maintainble code because we knew deep inside that good systems are built based on good code. But now we are jeopardizing ourselves, it's us the engineers who don't care anymore about code and with AI that problems is amplified.

Kwpolska 5mo ago

They don’t, they just have Claude commit and push straight to the main branch. Just like the author of this 100% slop app: https://github.com/leodavinci1/kanbots/commits/main/ https://github.com/leodavinci1/kanbots/commits/main/

SatvikBeri 5mo ago

I usually aim to have Claude end up with about 500 lines of code after a night of work. Most of what it's doing is experimenting with many different approaches, summarizing them, and then giving me a relatively small diff to review and modify.

a1o 5mo ago
This is the way to go. I usually play with relatively stable software where the improvements are either performance or very small niche features that are built on top of already existing ones. Big changes are undesirable by both the others working on it and its users.

BosunoB 5mo ago

Yeah the multi-agent workflow just hasn't been satisfying to me. The more chats I try to run at once, the more I got lost and overwhelmed. I trust Claude to implement a plan correctly after I've reviewed it, but if I don't review all of the plans, I will miss some small detail that it misunderstood and it'll be a pain to fix later. I'm like a 1-2 chats at a time kind of guy. I just don't see how I could keep my exact vision for the project otherwise.

hgoel 5mo ago
Same, on top of that multi-agent workflows just cost too much to make stopping and correcting them to feel worthwhile, compared to one or two manually managed chats

keyle 5mo ago

Those people don't review.

deleted 5mo ago

[deleted]

suralind 5mo ago

I agree, but for small tasks - <20 lines that I can understand in a minute or two - perfect. Thinking about it - I have hundreds, if not thousands of tasks that I would like to do, improving pipelines, migrating from one tool to another, but never have time. The only question is - if I don't have time to do it, do I have time to prompt it?

anhphong 5mo ago

[flagged]

digitaltrees 5mo ago

You care about code quality. Many don’t. I had someone tell me this week that a 6000 line class was ok because it was easier for the model to understand and that’s more important than human comprehension. And I get his point but that seems like a big risk to take.

mpalczewski 5mo ago
and it's wrong. a 6000 line class is not easier for a model to understand. the same things that help humans also help agents. I find myself adding linters that must pass and the agent muss fix that limit file size, function length, function complexity, how many files in a directory. a little more work for the agent, but the codebase is healthier and the agents write fewer bugs.
- lukevdp 5mo ago
  I don't think the same things that help humans help agents. Simplicity helps humans, for agents parsing complexity is a breeze. Not saying code quality isn't important - it is. But I think what is described as quality code will change.
  - cjbgkagh 5mo ago
    Agents still pay a penalty for complexity even if it is a smaller one.
    - digitaltrees 5mo ago
      Parsing single file is easier than navigating a file system for an LLM. Until the models have context windows large enough to hold the entire codebase in one shot, single files will beat multiple files every time.
      - bossyTeacher 5mo ago
        This. I suspect the codebases in the future will be made of a small number of gigantic source files. These will be able to be transpiled into a more human friendly that produces multiple smaller files per big file in human-debug mode.

faangguyindia 5mo ago

whenever i found a guy who uses parallel overnight agents, i asked them how many users they have. Crickets. They do not have any users. Meanwhile, i've to do code reviews and all otherwise my 12,000+ users will be pissed off if anything in their workflow breaks. This means i really cannot release more than 1 tiny feature a day. And using parallel agents, well that's good for testing but i don't think i need to add that many features to add anything.

zx8080 5mo ago

Cost of generation is low, why review? Regenerate if not working. Rinse and repeat. Maximize providers profits. What can go wrong.

toobulkeh 5mo ago

Testing

nobodywillobsrv 5mo ago

I understand and agree with the feeling but then I also feel AI is too slow and too expensive. My most successful autonomous runs have been expanding scrapers across a number of similar but different portals. I had examples and targets and it just kept searching for new ones and adding them. But even doing basic ML auto research k have found it to be surprisingly poor except at trivial but useful augmentation of models. Yes it can implement things but somehow I am required a lot even though I set up a lot of framework around it. My mental model is that it's very good at complex deterministic work like reading bad API docs and getting some connectors to work. But perhaps I care less about being stuck in a local optimum there.

JodieBenitez 5mo ago

I never review anything writtend by codex in my pet projects. It works or it doesn't and then I prompt again. I can see how it's easy to multiply agents in this case. Now when using it for my job... that's a totally different story: I review all the changes, so a single chat session with an agent can lead to a whole day of review. And it's great, sometimes the agent uses patterns and functions I don't know, so I learn a lot.

risyachka 5mo ago

No one reads code that results from this. Those who say otherwise either lie or are very bad developers which is essentially the same as not reading that code.

cold_harbor 5mo ago

the bottleneck moves from generation to review. agents parallelize, humans review sequentially — 8 parallel cards means 8x the diffs to read, none of the timelines overlap

jgalt212 5mo ago

Without agentic coding the number go up narrative dies. There's your answer.

gopher_space 5mo ago

Everything I can batch overnight locally is free.