If you’re on the same journey of making your work with agents more productive and enjoyable, I hope this gives you a head start and shortcuts some of your own exploration.
How do you think about cognitive debt? If agents are writing and reviewing all the code, then you don't have a mental model of the codebase in your head, meaning you will start to make more and more sub-optimal design decisions, right?
The 68% bug rate buried in the validation section is the most honest thing in this entire post and deserves way more attention than it got.
He built gnhf, no-mistakes, treehouse, and a full parallel orchestration setup essentially because agents ship broken code more often than not. The tooling is impressive, but what he is actually describing is an elaborate error-correction pipeline wrapped around a fundamentally unreliable code generator.
The manager framing is compelling until you stop reading diffs entirely. That is when you lose the ability to catch architectural drift, and no E2E screenshot will show you that your codebase is quietly becoming unmaintainable.
Code becomes unmaintainable when the AI can no longer ship features, and the number of bugs keeps climbing.
But AI is also good at changing the architecture without altering functionality, provided tests are in place, and you're guiding the architectural direction.
So, much like with a junior engineer, you should schedule an architecture session with it, both at the start of the project and periodically as it progresses.
That is a fair point and the tests caveat is doing a lot of work there.
The problem is that architectural drift rarely shows up in tests because tests validate behaviour not structure. You can have green CI and a codebase where every abstraction has quietly collapsed into one giant service class that nobody planned.
The architecture session idea is right but it requires the human to still have a mental model sharp enough to catch what the AI is normalising. That is exactly the muscle that atrophies when you stop reading diffs.
Going from "writing code" to "managing a team of agents" is the big shift. Curious which piece broke first when you scaled to 5–10 parallel tasks: review or your own context-switching?
The pattern of using git worktrees to parallelize agent tasks is one I’ve been experimenting with too. The coordination overhead at the merge step is real, especially when agents are touching overlapping abstractions. Curious how the Meta setup handled that.
The setup matters less than the discipline around it. I get the most out of agents when I keep a running decision log and feed the recent entries back in, otherwise it drifts on anything multi-step. Curious if his workflow handles context the same way.
How do you think about cognitive debt? If agents are writing and reviewing all the code, then you don't have a mental model of the codebase in your head, meaning you will start to make more and more sub-optimal design decisions, right?
What’s the cost to ship this project so far?
The 68% bug rate buried in the validation section is the most honest thing in this entire post and deserves way more attention than it got.
He built gnhf, no-mistakes, treehouse, and a full parallel orchestration setup essentially because agents ship broken code more often than not. The tooling is impressive, but what he is actually describing is an elaborate error-correction pipeline wrapped around a fundamentally unreliable code generator.
The manager framing is compelling until you stop reading diffs entirely. That is when you lose the ability to catch architectural drift, and no E2E screenshot will show you that your codebase is quietly becoming unmaintainable.
The question is what counts as unmaintainable.
Code becomes unmaintainable when the AI can no longer ship features, and the number of bugs keeps climbing.
But AI is also good at changing the architecture without altering functionality, provided tests are in place, and you're guiding the architectural direction.
So, much like with a junior engineer, you should schedule an architecture session with it, both at the start of the project and periodically as it progresses.
That is a fair point and the tests caveat is doing a lot of work there.
The problem is that architectural drift rarely shows up in tests because tests validate behaviour not structure. You can have green CI and a codebase where every abstraction has quietly collapsed into one giant service class that nobody planned.
The architecture session idea is right but it requires the human to still have a mental model sharp enough to catch what the AI is normalising. That is exactly the muscle that atrophies when you stop reading diffs.
Going from "writing code" to "managing a team of agents" is the big shift. Curious which piece broke first when you scaled to 5–10 parallel tasks: review or your own context-switching?
pretty cool! its always fun seeing what real powerhouses do / use ai for. lots of lessons learned when these release for sure.
The pattern of using git worktrees to parallelize agent tasks is one I’ve been experimenting with too. The coordination overhead at the merge step is real, especially when agents are touching overlapping abstractions. Curious how the Meta setup handled that.
The setup matters less than the discipline around it. I get the most out of agents when I keep a running decision log and feed the recent entries back in, otherwise it drifts on anything multi-step. Curious if his workflow handles context the same way.