What I have found: all that stuff that was evolving over the last 30 years: roadmap definition, sprint planning, unit tests, regular independent code reviews, etc. etc. etc. that those of us who “knew what we were doing” mostly looked down on as the waste of time that it was (for us), well… now you’ve got these tools that spew out 6 man-months of code in a few hours, and all those time-wasting code quality improvement / development management techniques… yeah, they apply, in spades. If you do all that stuff, and iterate at each quality gate until you’ve got what you’re supposed to have before proceeding, those tools actually can produce quality code - and starting around Opus 4.6 I’m not feeling the sort of complexity ceiling that I was feeling with its predecessors.
Transparency is key. Your code should provide insights to how it is running, insights the agent can understand (log files) insights you can understand (graphs and images, where applicable), if it’s just a mystery box it’s unlikely to ever do anything complex successfully, but if it’s a collection of highly visible white boxes in a nice logical hiearchical structure - Opus 4.6 can do that.
Unit tests seem to be well worth the extra time invested - though they do slow down progress significantly, they’re faster than recovering from off-rails adventures.
Independent reviewer agents (a clear context window, at a minimum) are a must.
If your agent can exercise the code on the target system, and read all the system log files as well as the log files it generates, that helps tremendously.
My latest “vibe tool” is the roadmap. It used to be “the plan” - but now the roadmap lays out where a series of plans will be deployed. As the agent works through a plan, each stage of the plan seems to get a to-do list… Six months ago, it was just to-do lists, and agents like Sonnet 3.5 would sometimes get lost in those. Including documentation, both developer facing architecture and specifications (for the tests), and user facing, and including updating of the documentation along with removal of technical debt in the code at the end of each roadmap plan stage also slows things down, and keeps development on track much better than just “going for delivery.” So, instead of 6 months of output in a day, maybe we’re making 2 months of progress, in a day, and generating about 10x the tests and documentation as we would have in those 2 months traditionally - in a day of “realtime” with the tool. 40:1 speedup, buried under 500:1 volume of documents created.
roadmap definition, sprint planning, unit tests, regular independent code reviews, etc. etc. etc. that those of us who “knew what we were doing” mostly looked down on as the waste of time that it was
Not really, for humans a lot of this stuff feels like busywork that sorta helps for certain scales of work, but often times managers went WAY too hard on it and you end up with a 2 dev team that spends like 60% of their time in meetings instead of… developing.
But this changes a lot with AI Agents, because these tools that help reign in developers REALLY help reign in agents, it feels… like a surprising good fit
And I think the big reason why is you wanna treat AI Agents as junior devs, capable, fast, but very prone to errors and getting sidetracked
So you put these sorts of steering and guard rails in and it REALLY goes far towards channelling their… enthusiasm in a meaningful direction.
What the fuck are you talking about, thats not what the poster said, you’ve done weird contorting of what they said to arrive at the question you are asking now.
While some tests make sense, I would say about 99% of tests that I see developers write are indeed a waste of time, a shit tonne of devs effectively are writing code that boils down to
Assert.That(2, Is.EqualTo(1+1));
Because they mock the shit out of everything and have reduced their code to meaningless piles of fakes and mocks and arent actually testing what matters.
Do you do code reviews in meetings?
Honestly often… yes lol
Do you think testing and reviewing code was a waste of time before “AI”?
I would say a lot of it is, tbh, not all of it, but a huge amount of time is wasted on this process by humans for humans.
What the poster was getting at is a lot of these processes that USED to be INEFFICIENT now make MORE sense in the context of agents… you have vastly taken their point out of context.
What I have found: all that stuff that was evolving over the last 30 years: roadmap definition, sprint planning, unit tests, regular independent code reviews, etc. etc. etc. that those of us who “knew what we were doing” mostly looked down on as the waste of time that it was (for us), well… now you’ve got these tools that spew out 6 man-months of code in a few hours, and all those time-wasting code quality improvement / development management techniques… yeah, they apply, in spades. If you do all that stuff, and iterate at each quality gate until you’ve got what you’re supposed to have before proceeding, those tools actually can produce quality code - and starting around Opus 4.6 I’m not feeling the sort of complexity ceiling that I was feeling with its predecessors.
Transparency is key. Your code should provide insights to how it is running, insights the agent can understand (log files) insights you can understand (graphs and images, where applicable), if it’s just a mystery box it’s unlikely to ever do anything complex successfully, but if it’s a collection of highly visible white boxes in a nice logical hiearchical structure - Opus 4.6 can do that.
Unit tests seem to be well worth the extra time invested - though they do slow down progress significantly, they’re faster than recovering from off-rails adventures.
Independent reviewer agents (a clear context window, at a minimum) are a must.
If your agent can exercise the code on the target system, and read all the system log files as well as the log files it generates, that helps tremendously.
My latest “vibe tool” is the roadmap. It used to be “the plan” - but now the roadmap lays out where a series of plans will be deployed. As the agent works through a plan, each stage of the plan seems to get a to-do list… Six months ago, it was just to-do lists, and agents like Sonnet 3.5 would sometimes get lost in those. Including documentation, both developer facing architecture and specifications (for the tests), and user facing, and including updating of the documentation along with removal of technical debt in the code at the end of each roadmap plan stage also slows things down, and keeps development on track much better than just “going for delivery.” So, instead of 6 months of output in a day, maybe we’re making 2 months of progress, in a day, and generating about 10x the tests and documentation as we would have in those 2 months traditionally - in a day of “realtime” with the tool. 40:1 speedup, buried under 500:1 volume of documents created.
You sound insane.
Not really, for humans a lot of this stuff feels like busywork that sorta helps for certain scales of work, but often times managers went WAY too hard on it and you end up with a 2 dev team that spends like 60% of their time in meetings instead of… developing.
But this changes a lot with AI Agents, because these tools that help reign in developers REALLY help reign in agents, it feels… like a surprising good fit
And I think the big reason why is you wanna treat AI Agents as junior devs, capable, fast, but very prone to errors and getting sidetracked
So you put these sorts of steering and guard rails in and it REALLY goes far towards channelling their… enthusiasm in a meaningful direction.
Do you write your tests in meetings? Do you do code reviews in meetings?
Do you think testing and reviewing code was a waste of time before “AI”?
What the fuck are you talking about, thats not what the poster said, you’ve done weird contorting of what they said to arrive at the question you are asking now.
While some tests make sense, I would say about 99% of tests that I see developers write are indeed a waste of time, a shit tonne of devs effectively are writing code that boils down to
Assert.That(2, Is.EqualTo(1+1));Because they mock the shit out of everything and have reduced their code to meaningless piles of fakes and mocks and arent actually testing what matters.
Honestly often… yes lol
I would say a lot of it is, tbh, not all of it, but a huge amount of time is wasted on this process by humans for humans.
What the poster was getting at is a lot of these processes that USED to be INEFFICIENT now make MORE sense in the context of agents… you have vastly taken their point out of context.
Insane, yet reliably employed in the field for 30+ years - first and current job for more than a decade.