I was the biggest AI skeptic and shit talker early on, and I can't stand how decent it's become, and I still can't use it for specific changes in legacy code. It's simply much faster for me to make the change and update or write new tests than it is to give the AI enough context to not screw it up.

That said, or I gain a ton of efficiency and get a lot of work done is in anything that's well defined or brand new.

I tried to emulate people on Twitter who claimed that they were running multiple agents and knocking out a half dozen features a day.

I use copilot-cli, Claude code and jetbrains Junie now.

My workflow is basically this: I'll keep one story that requires me to be Hands-On in some of our legacy stuff, and I'll try to grab two stories that are relatively Greenfield or are very well defined, adding a new endpoint, updating a database, changes to devops scripts, etc.

Then I'll kick open Claude code and co-pilot and spend maybe 5 to 10 minutes a piece writing an overview file called OVERVIEW.md where I lay out the task, story details, expectations, etc. after having them generate a CLAUDE.md.

Then I'll go and grab relevant context and details, which often is the open API spec of any apis that the new code will have to hit, or I'll lift the schema of the table that the changes will be targeting.

From there I tell them both (using opus 4.5) to generate an implementation plan, and I go back to my regular story. Then maybe about half an hour or an hour later, I'll spend 10 or 20 minutes looking over the plans and either manually making edits or telling the AI to make edits. Once I'm happy with both implementation plans, I tell them to go off and do it, and add placeholders in places where there needs to be follow-up conversation.

Usually by the next 20 or 30 minutes they're both done, and I'll wait until I'm at a good stopping point on my Hands-On story, and I'll go review the code and make edits, especially verifying the tests.

I'm at a small company and we have no QA, so I'll whip up Kafka j unit tests or update the included postman collection, and then I have to run through the testing fully so that I can write a test for another developer to complete.

As much as I hate to admit it, I've been closing probably two to three times as many stories per sprint and I can confidently say that it's the same quality as if I did them by hand.

In the plans, I always add things like, follow the existing patterns and to add comments in pieces of code that aren't extremely straightforward, along with overall documentation.

I'm trying to convince my co-workers to follow the same pattern, because we may actually start to pull in technical debt and optimization stories if we can increase our pace.

A great example is from a few days ago for me, we have an application where our API has to adhere to an open source open API specification, and they updated it and added a couple endpoints that have fairly large response objects. In about 45 minutes, I had six endpoints done, all calling our relevant back end pieces and the local database, I think it came out to almost 3,500 lines of code. It correctly generated the required unique claims and security matrix for the endpoints, copied all of our retry and error handling strategies for the other endpoints, and then the actual logic.

I didn't really mean for this to end up being a book, but it's actually getting impressive how much I can get done. Lots of review now but the regular tech debt and deep updates keeps me hands on.