[paulhodge]

I've had days where it really does feel like 5x or 10x...

Here's what the 5x to 10x flow looks like:

1. Plan out the tasks (maybe with the help of AI)

2. Open a Git worktree, launch Claude Code in the worktree, give it the task, let it work. It gets instructions to push to a Github pull request when it's done. Claude gets to work. It has access to a whole bunch of local tools, test suites, and lots of documentation.

3. While that terminal is running, I go start more tasks. Ideally there are 3 to 5 tasks running at a time.

4. Periodically check on the tabs to make sure they're not stuck or lost their minds.

5. Finally, review the finished pull requests and merge them when they are ready. If they have issues then go back to the related chat and tell it to work on it some more.

With that flow it's reasonable to merge 10 to 20 pull requests every day. I'm sure someone will respond "oh just because there are a lot of pull requests, doesn't mean you are productive!" I don't know how to prove to you that the PRs are productive other than just say that they are each basically equivalent to what one human does in one small PR.

A few notes about the flow:

- For the AI to work independently, it really needs tasks that are easy to medium difficulty. There are definitely 'hard' tasks that need a lot of human attention in order to get done successfully.

- This does take a lot of initial investment in tooling and documentation. Basically every "best practice" or code pattern that you want to use use in the project must be written down. And the tests must be as extensive as possible.

Anyway the linked article talks about the time it takes to review pull requests. I don't think it needs to take that long, because you can automate a lot..

- Code style issues are fully automated by the linter.

- Other checks like unit test coverage can be checked in the PR as well.

- When you have a ton of automated tests that are checked in the PR, that also reduces how much you need to worry about as a code reviewer.

With all those checks in place, I think it can pretty fast to review a PR. As the human you just need to scan for really bad code patterns, and maybe zoom in on highly critical areas, but most of the code can be eyeballed pretty quickly.

[samtp]

What type of software are you building with this workflow? Does it handle PII, need data to be exact, or have any security implications?

Because I might just not have a great imagination, but it's very hard for me to see how you basically automate the review process on anything that is business critical or has legal risks.

[paulhodge]

Mainly working on a dev tool / SaaS app right now. The PII is user names & email.

On the security layer, I wrote that code mostly by hand, with some 'pair programming' with Claude to get the Oauth handling working.

When I have the agent working on tasks independently, it's usually working on feature-specific business logic in the API and frontend. For that work it has a lot of standard helper functions to read/write data for the current authenticated user. With that scaffolding it's harder (not impossible) for the bot to mess up.

It's definitely a concern though, I've been brainstorming some creative ways to add extra tests and more auditing to look out for security issues. Overall I think the key for extremely fast development is to have an extremely good testing strategy.

[samtp]

I appreciate the helpful reply, honestly. One other question - are people currently using the app?

I think where I've become very hesitant is a lot of the programs that I touch has customer data belonging to clients with pretty hard-nosed legal teams. So it's quite difficult for me to imagine not reviewing the production code by hand.

[paulhodge]

No this app isn't launched yet. And yeah, customer data is definitely a very valid thing to be concerned about.