Once, it was just failing to build simple flows for complex business logic getting added to existing complex business logic. It was more efficient for me to just spend a few hours and handcode it to get clean code.
Second time is partially my fault. I had a spec with about 10 stages. I let it run stage 1 and it got overzealous and finished the project. Reviewing, tweaking, and testing the massive change took me several days. I should have just wiped it and started over. It would have been much faster. I had maxed out my weekly usage already so I didn't want to redo it.
No it's not slowing us down at all. For fresh codebases it's several orders of magnitude faster, but also for legacy/existing codebases it has been a BOON to our development.
First thing we do is to map out an existing codebase (or a piece of a codebase if it's a monorepo). We have the models synthesize what's in there and document the architecture AND the intent of the app (retroactively building a PRD based on codebase). We use n-dx for this and it has worked very well. There's still bugs and plenty of improvements to be made with the tool (n-dx), but it's open-source so it's easy to make improvements whenever it falls short during a set of tasks
I think "operate at a higher level of abstraction" is sometimes backwards.
The problem with legacy systems is that the low-level details are the requirements. Things that look like implementation details often encode 20 years of business rules.
An AI agent doesn't know which weird-looking piece of code is accidental complexity and which weird-looking piece of code is keeping a $10M customer from breaking.
So I don't think the answer is necessarily to give the agent higher-level instructions. Sometimes the answer is to give it less autonomy.
When I hit a problem like that, I do most myself and just get the AI to do the bits where I'd normally get stuck because of boredom. Bits that I can't be bothered to write as they're easy but laborious.
And then get it to review the code, where it'll pickup a few edge cases.
But I don't really get the attitude that we shouldn't write code anymore, for me it's often quicker to write the code than to explain to the AI how to write it.
Sometimes when I'm.sitting there watching it chug away for 5 minutes over what should be a three line change, I'll just stop it and do it myself, and then at that point I'll often take over completely for a while.
This is sort of my approach as well, but is your team on the same page as you? or are they far more AI-pilled? everyone around me is much more AI-pilled so this mismatch in approach to AI is making it hard to collaborate
AI speeds up my personal work a bit, because I don't use it for anything that isn't effective. I am in control of how much or little I use it.
Where I get slowed down by AI is when working with others. My current main gig is one of the places where they are pushing everyone to use AI for everything, and tying compensation to how much you use it. So people have stopped talking - they paste AI responses back and forth at each other. It is bizarre, dysfunctional, and dystopian, and I am so looking forward to the end of this contract.
I don't buy that. If I give AI a high-level task and expect it to fill in the blanks on the lower level details, it makes horrendous decisions, trust me I tried. I tried treating my agents as a team of engineers and I am a "high level" engineering manager. It quickly built broken features.
Not usually.
I've had AI slow me down twice.
Once, it was just failing to build simple flows for complex business logic getting added to existing complex business logic. It was more efficient for me to just spend a few hours and handcode it to get clean code.
Second time is partially my fault. I had a spec with about 10 stages. I let it run stage 1 and it got overzealous and finished the project. Reviewing, tweaking, and testing the massive change took me several days. I should have just wiped it and started over. It would have been much faster. I had maxed out my weekly usage already so I didn't want to redo it.
No it's not slowing us down at all. For fresh codebases it's several orders of magnitude faster, but also for legacy/existing codebases it has been a BOON to our development.
First thing we do is to map out an existing codebase (or a piece of a codebase if it's a monorepo). We have the models synthesize what's in there and document the architecture AND the intent of the app (retroactively building a PRD based on codebase). We use n-dx for this and it has worked very well. There's still bugs and plenty of improvements to be made with the tool (n-dx), but it's open-source so it's easy to make improvements whenever it falls short during a set of tasks
I think "operate at a higher level of abstraction" is sometimes backwards.
The problem with legacy systems is that the low-level details are the requirements. Things that look like implementation details often encode 20 years of business rules.
An AI agent doesn't know which weird-looking piece of code is accidental complexity and which weird-looking piece of code is keeping a $10M customer from breaking.
So I don't think the answer is necessarily to give the agent higher-level instructions. Sometimes the answer is to give it less autonomy.
I am using AI to vibecode and I am far more productive (at least in term of speed up)!
@tox9cc - FYI you're flagged as dead. Not sure why, your past comments all seem valuable to the discussions.
Their comment in this thread is clearly AI-generated. The rest also show many of the tells. That's against the HN rules.
When I hit a problem like that, I do most myself and just get the AI to do the bits where I'd normally get stuck because of boredom. Bits that I can't be bothered to write as they're easy but laborious.
And then get it to review the code, where it'll pickup a few edge cases.
But I don't really get the attitude that we shouldn't write code anymore, for me it's often quicker to write the code than to explain to the AI how to write it.
Sometimes when I'm.sitting there watching it chug away for 5 minutes over what should be a three line change, I'll just stop it and do it myself, and then at that point I'll often take over completely for a while.
This is sort of my approach as well, but is your team on the same page as you? or are they far more AI-pilled? everyone around me is much more AI-pilled so this mismatch in approach to AI is making it hard to collaborate
AI speeds up my personal work a bit, because I don't use it for anything that isn't effective. I am in control of how much or little I use it.
Where I get slowed down by AI is when working with others. My current main gig is one of the places where they are pushing everyone to use AI for everything, and tying compensation to how much you use it. So people have stopped talking - they paste AI responses back and forth at each other. It is bizarre, dysfunctional, and dystopian, and I am so looking forward to the end of this contract.
You need to operate at a higher level of abstraction.
I don't buy that. If I give AI a high-level task and expect it to fill in the blanks on the lower level details, it makes horrendous decisions, trust me I tried. I tried treating my agents as a team of engineers and I am a "high level" engineering manager. It quickly built broken features.
The thing is its all a sliding spectrum between vibe-coding and manually coding and there are trade-offs at every point
On one end is huge productivity but bad quality
The other end is normal productivity but good quality
I land closer to the manual coding side with agents, its more productive but I do have to heavily micromanage them
I would guess around 1.3-1.5x productivity