alekstret

In my project, I pay a general price for using agent quota. For me, it's not about saving money but about being sure that I have full control over the usage limits. My product provides a pool that depends on the plan (100 or 500 requests per paying account per month), and when these credits are used, I offer a backup option to bring your own AI key to use. And last but not least, I want to be sure that users' data won't be used to train models.

Here is my working flow, confirmed by more than 400 pr merged over the last 4 months. More than half of them were following my current strategy:

1. My agent writes code.

2. Then it creates tests and verifies that all of them actually work, not just pass. To do this, my agent writes the test, then it deletes the code it covers, reruns the test, confirms it goes red, and finally puts the code back.

3. I receive the ready-to-test code and environment setup.

4. I check that the business logic works as I expected it to be on a working product. Here we usually do several iterations of coding and bug fixing.

5. When the manual part is finished, the agent starts an external review using /code review skill. At that stage, it makes some additional fixes and corrections to the tests.

6. Finally, a branch is ready to be merged. We start CI/CD and wait until the run finishes successfully.

That's what I actually use because it generally works.

Note about only docs PRs: I just ask the agent to make the changes, then it runs the / code review skill, and then we merge the branch into main without CI running.

Most of the time it works as you said, but I implemented one rule that fixed these issues for me: my agent doesn't count a test until it has watched it fail.

The process works the following way: the agent writes the test, then it deletes the code it covers, reruns the test, confirms it goes red, and finally puts the code back.

Here is what made me start doing this. An e2e test for a touch gesture was green for weeks. I deleted the gesture handler, and the test stayed green, because Playwright's synthetic touch isn't actually a touch, so the test had never once exercised the thing it was named after. Reading it would never have shown me that.

It's discipline, not tooling. I don't run mutation testing; it's manual and only around whatever I just changed. And to be straight about your first question: it's the agent reading that test code, not me. Which is exactly why I don't rely on reading to catch this. Breaking the code and watching the test go red doesn't care who read it.

This morning, when I woke up, I checked the phone notifications. I saw some alerts from the LastQuake app that a major earthquake occurred on Flores. I didn't feel it here in Bukit, Bali, where I currently reside.

"Make mistakes cheaper" part works until you make irreversible changes. As I'm building solo with an agent's help, I always try to control what the agent actually can or can't do.

For instance, all DB migrations and access policies are applied by me. In this case, feature flags don't help because if the read policy is too permissive, the data will be out by the time you notice it.

Before I figured it out, I shipped to issues.

The first of them was a policy that was letting anyone read a board's member list.

The second was a "with check" in the policy that pinned a column's value, so any other user's unrelated updates on that row started failing, and neither was visible in the diff. The first one showed up only in a test that asserts the attacker fails. The second one only in a test that asserts a different legitimate user still succeeds.

As for now, I pass reversible stuff to the agent, and the sensitive changes I apply myself. Also, I ask the agent to cover negative cases and make a security review before applying sensitive changes.

That's it.

I'm building solo and am extensionally using Claude Code for development and testing. The following scheme finally works great for me.

First of all, the agent writes code. After that, it creates tests and verifies that all of them work correctly by cracking the checks and rerunning the test suite.

Secondly, it gives me the ready to test code + set up environment (stage). I'm checking that the code actually works, and if not, we are making some fixes until I'm fully satisfied with the result.

Thirdly, the agent starts an external review using skill for code review and usually makes some additional fixes to codebase and corrects tests again.

After all, we are ready to commit and push the feature to the main branch. Before merging, we start CI/CD - which is important because it does a type check - and wait until the run finishes successfully.

That's how it happens in my case.

Quick note: this plan was built after many iterations of coding and testing, and it has finally proved that it works.

I also recently launched my product and am still struggling to gain a user base. But one week ago, I started posting my app on specific platforms, such as SaaSHub. I think that over time it will deliver results because it not only anchors your product in a software DB but also provides your website with dofollow links. These links help to upvote the domain rating, which leads to better visibility in Google search results.

I work as QA during the day, but at night I become a B̶a̶t̶m̶a̶n̶ solo founder. I started to work like this at the end of April and have had almost no days off. With the day job, it is around 12-14 hours per day till now. It's not 996 hours per year, and nobody forced me, but the internal willingness to finish the main development asap. Yeah, that was quite intensive, but I already accomplished most of the task, and now I am gonna slow the pace.

It's hard to advise without a specific example, but from my perspective, this process is something natural for all companies. If you have analytics, you can proceed with future movement, such as focusing on one product/feature and making it the main point of application of effort. Nevertheless, don't forget to track your "why" now, because future "you" will be grateful for this info; it's really important to track it.