# How to Use AI Coding Agents on a Side Project Without the Mess
> Use AI coding agents on a side project without a mess: small specs, a short AGENTS.md, tests and git as guardrails, diff review, and safe dependencies.

```yaml
url: "https://sidehunt.io/studio/how-to-use-ai-coding-agents-on-a-side-project"
markdown: "https://sidehunt.io/studio/how-to-use-ai-coding-agents-on-a-side-project.md"
title: How to Use AI Coding Agents on a Side Project Without the Mess
slug: how-to-use-ai-coding-agents-on-a-side-project
category: Growth
tags:
  - AI coding agents
  - side projects
  - vibe coding
  - AGENTS.md
  - Claude Code
  - Cursor
  - GitHub Copilot
  - developer tools
  - slopsquatting
  - Growth
published_at: "2026-10-14T11:05:52.473Z"
updated_at: "2026-10-14T11:05:52.817Z"
featured_image: "https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx934picG1duKC2cTLjUHtkW4FmRlen8BZa9JpY"
```

## Article

Using AI coding agents on a side project without making a mess comes down to five habits: give the agent one small, written task at a time, keep a short rules file in the repo it reads every session, make tests and git your safety net, review the diff yourself before anything ships, and keep agents away from auth, payments, production data and secrets. Do that and a tired weeknight can still end with a finished feature.

This guide is for people with a day job who want to use AI coding tools for side projects without losing control of the code: where agents help, where they hurt, an evening loop, a sample rules file, guardrails, and when to stop prompting. Tool facts were checked against vendor docs in October 2026. No prices on purpose; plans change too often.

## What counts as an AI coding agent?

An assistant suggests code while you type. An agent takes a task, reads files, edits several of them, and often runs commands like your test suite. Most side project builders end up with one of three shapes:

- Editor agents. Built into your code editor, working on the files you have open and the rest of the repo. Cursor and GitHub Copilot in your editor are common examples.
- Terminal agents. You run them in a shell inside the project folder and they read, edit and run commands from there. Claude Code, the OpenAI Codex CLI and Aider work this way.
- Cloud or background agents. You hand over a task, the agent works on a copy of the repo on a remote machine, and you get a branch or pull request back. GitHub, Cursor, OpenAI and Anthropic all offer some version of this.

Pick one and learn it properly. The habits below matter more than the brand.

## Where do agents genuinely save your evenings?

Agents are best at work that is tedious, well understood and easy to check. On a side project that usually means:

- Boilerplate. A settings page like the other three, form validation, config files.
- CRUD screens and endpoints. List, create, edit, delete for a model you already designed.
- Tests. Writing the dull cases you know you should have, especially around code that already works.
- Migration scaffolding. Drafting a schema change and its rollback for you to read, not to run on real data.
- Refactors with tests around them. Renaming, splitting a 600-line file, moving logic into a function. The tests tell you whether behaviour changed.
- Reading unfamiliar libraries. "Explain how this library handles retries and show me where we call it" saves an hour of docs.

The common thread: you can tell in a few minutes whether the result is right.

## Where do agents cost you more than they save?

The expensive mistakes cluster in code where a bug is silent, rare, or hard to undo:

- Authentication and permissions. A missing check on one endpoint looks fine in a demo and leaks other users' data in real life.
- Payments and webhooks. Agents happily write a webhook handler that works once in test mode. Retries, duplicate events and ordering are where it breaks, which is exactly what the DEV write-up on [how Stripe webhooks that pass in test mode break in production](https://dev.to/posting-dude/your-stripe-webhook-works-in-test-mode-heres-how-it-breaks-in-production-198) walks through. Write it yourself or review every line.
- Anything that deletes data. Account deletion, cleanup jobs, "remove old records" scripts.
- Migrations on production data. Let the agent draft them. You run them, after a backup, when you are awake.
- Anything you can't review. If you don't understand the diff, you can't judge it. Keep changes small enough that you can.

The agent can write it, but you have to be able to explain it.

## What does a good evening session with an agent look like?

Most mess comes from giant, vague prompts like "add teams support." This loop fits in 60 to 90 minutes after work:

- Pick one small task. Something you could describe in a single issue and review in ten minutes. If your backlog is a wall of big features, cut it down first using the SideHunt guide on [scoping a side project MVP you can ship on weekends](https://sidehunt.io/studio/how-to-scope-a-side-project-mvp-you-can-ship-on-weekends).
- Write the task as an issue-sized spec. Four short parts: what to build, which files are likely involved, acceptance checks ("clicking Snooze hides the reminder for 2 days; the existing reminder tests still pass"), and what is out of scope.
- Commit or stash first. Start from a clean working tree so you can throw the whole attempt away in one command.
- Ask for a plan before code. "Read the relevant files and tell me your plan. Don't edit anything yet." Many tools have a plan mode for exactly this. A bad plan costs you two minutes. A bad 14-file diff costs your evening.
- Let it work, then review the diff, not the chat. The chat summary tells you what the agent thinks it did. git diff tells you what it actually did. Read every changed file.
- Run it. Run the tests, then click through the feature yourself. Agents are good at code that compiles and passes its own tests while doing the wrong thing.
- Commit small with a real message. One task, one commit, so next month's bug hunt is short.

Only have 45 minutes? Write the spec tonight and run it tomorrow.

![](https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx93QFIPd1duKC2cTLjUHtkW4FmRlen8BZa9JpY)

## What should go in your project rules file?

Every session starts with a fresh memory, so agents read a rules file from your repo to learn how your project works. The names differ by tool:

- AGENTS.md is an open format that the [AGENTS.md project site](https://agents.md/) describes as a README for agents. Its FAQ says the closest file to the code being edited wins, and explicit chat prompts override everything.
- Cursor supports project rules in .cursor/rules as .mdc files, and also reads AGENTS.md in the project root and subdirectories, per [Cursor's rules docs](https://cursor.com/docs/rules).
- Claude Code reads CLAUDE.md at the start of each session. [Claude Code's memory docs](https://code.claude.com/docs/en/memory) say it can also read AGENTS.md when there is no CLAUDE.md , or you can import it by putting @AGENTS.md in a CLAUDE.md .
- GitHub Copilot uses .github/copilot-instructions.md for repository-wide instructions, and [GitHub's docs on repository custom instructions](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions) say its agents also use AGENTS.md files.

For a solo side project, one `AGENTS.md` in the root is usually enough. Keep it short. Claude Code's docs suggest staying under 200 lines per file and Cursor's suggest keeping rules under 500, but a side project rarely needs more than 15. Here is a sample, written for the made-up project later in this post:

```
`# AGENTS.md (Leaflane, a made-up example) - Stack: SvelteKit + Postgres. Use pnpm, never npm. - Tests: pnpm test. They must pass before you say you're done. - One task per session. Ask before touching more than 5 files. - Don't edit src/lib/auth/ or src/lib/billing/ without asking first. - Never add a dependency without naming it and saying why. - Never run migrations, deploys or anything against production. - Never delete or skip a failing test. Fix the code or ask me. - New pattern? Add 3 lines to docs/decisions.md explaining it.`
```

Both Claude Code's and Cursor's docs suggest adding a rule when the agent repeats a mistake, not before. And a rules file is guidance, not a lock: Claude Code's docs say these files are treated as context, not enforced configuration. Your real guardrails are tests, git and your own review.

## How do tests keep an agent honest?

Tests turn "looks right" into "is right."

- Ask for a failing test first. "Write a test that shows the snooze bug. Run it and show me it fails. Then fix the code." If the test never failed, it isn't testing your bug.
- Keep one fast test command. Put it in the rules file. If your suite takes eight minutes, the agent (and you) will skip it. Aim for something that runs in under a minute for the part you are touching.
- Watch for test tampering. When a test fails, some agents "fix" it by changing the expected value, adding a skip, or deleting it. Scan the diff for changes under your test folder every time.

No tests yet? Make "add tests for the code we're about to change" its own first task.

## What git habits make agent mistakes cheap?

Git is your undo button.

- One branch per task. git switch -c snooze-button before you start. If the attempt goes sideways, delete the branch and nothing on main changed.
- Commit before every agent run. Even a messy "wip" commit. Then git diff shows only what the agent did, and git restore . throws it away.
- Check the size first. git diff --stat before reading anything. If you asked for a button and 19 files changed, stop and ask why.
- Revert freely. Throwing away 40 minutes of agent output beats keeping a change you don't understand.
- Treat agent pull requests like a stranger's. Merge only what you have read.

![](https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx9VpTwhpPBih5yfX9OMeJWDoBSaqZ2rt3YzmTP)

## How do you keep agents from leaking secrets or installing junk?

A few rules cover most of the risk on a side project:

- Never paste production secrets into a prompt. Use test keys locally. If the agent needs a value, it can read a variable name, not the value.
- Keep .env out of git. Add it to .gitignore before your first commit. [GitHub's guide to ignoring files](https://docs.github.com/en/get-started/git-basics/ignoring-files) also notes that a file already checked in must be untracked with git rm --cached before the ignore rule applies. If a secret ever landed in your history, the SideHunt guide on [checking a repo's git history for secrets before it goes public](https://sidehunt.io/studio/how-to-open-source-your-side-project-without-regretting-it) covers scanning and rotation.
- Check every new dependency. Models sometimes suggest packages that don't exist. In the ["We Have a Package for You!" study](https://arxiv.org/abs/2406.10279), researchers generated 576,000 Python and JavaScript code samples with 16 models and found 19.7% of the suggested packages did not exist, including 205,474 unique made-up names. Commercial models averaged 5.2% and open-source models 21.7%. Those were 2024-era models and newer ones may do better, but attackers can register fake names with malware inside. That attack is called slopsquatting; per [Andrew Nesbitt's write-up on slopsquatting](https://stewardshiplab.org/ideas/slopsquatting-meets-dependency-confusion/), the name came from a conversation with Seth Larson in April 2025. Before installing anything new, open its registry page and repo and check the exact spelling, age, and real usage.
- Read shell commands before you approve them. Keep the tool's approval prompts on for anything that deletes files, installs packages, or touches the network. "Always allow" is for the test command, not for everything.
- Use least-privilege tokens. The [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) says the least privilege principle should be applied to secrets access. For you, that means a cloud agent gets access to one repo, not your whole account, and never your deploy or billing keys.
- Keep agents off production databases. Give them a local or seeded copy. There is no prompt clever enough to make DELETE on real customer data a good idea at 11pm.

## How do you keep the codebase understandable after a two-week break?

Side projects pause for work crunches, trips and colds. The risk is coming back to code that works but that nobody, including you, understands.

- Ask for short design notes. Any time the agent introduces a pattern (a new folder, a caching trick, a background job), have it add three lines to a decisions file: what, why, and what was rejected.
- Delete dead code as you go. Agents often leave the old version next to the new one "for safety." Ask "what is now unused?" at the end of each task and remove it.
- Run a 10-minute "explain this file back to me" check. Once a week, pick a file the agent touched and explain it in a note without help. Then ask the agent to explain it and compare. Where you were wrong is where to read more.

## How do you keep agent usage costs from creeping?

If any tool you use bills by usage or has paid overage, set a monthly spending cap or budget alert in its billing settings on day one. Check usage once a week, on the same day. Small tasks burn less usage than big vague ones.

## When should you stop prompting and write it yourself?

My rule of thumb: **if the agent has failed the same task three times, stop prompting.** Three failed attempts usually mean the task is too big, the spec is unclear, or the problem needs a decision only you can make. Pick one:

- Split the task in half and try the smaller part.
- Write the first ten lines yourself so the agent has a pattern to follow.
- Close the agent and code it by hand. It is your project. You are allowed to just write it.

Also stop when you catch yourself approving changes without reading them.

## A made-up example: Imogen and Leaflane

Everything in this example is made up: the person, the product, and every number.

Imogen works full time as a data analyst and builds **Leaflane** on weeknights: a watering schedule for people with too many houseplants. She wants a "snooze 2 days" button on reminders, and she has one free evening.

At 8pm she writes the spec in a GitHub issue: add a Snooze button to the reminder card, store the snooze date on the reminder, hide snoozed reminders until that date, existing reminder tests must still pass, notification emails are out of scope. She commits her work in progress and creates a branch.

She asks her agent for a plan first. The plan touches four files and adds a new date library. She says no to the library (the project already has one) and approves the rest. The agent writes a failing test, then the code. `git diff --stat` shows five files. One of them is the test file, where the agent had changed an old assertion to make it pass. She spots it in the diff, reverts that line, and asks for a real fix. Second try passes.

She clicks through the feature, snoozes a fern, checks it vanished, commits, and writes two lines in her decisions file. By 9:20pm it is merged. A week later the agent fails three times on the reminder email template, so she writes it herself in 25 minutes.

## A weekend setup checklist

Times below are planning guesses, not measurements.

When

Task

Done when

Saturday (30 min)

Pick one agent tool and turn on its approval prompts for commands

You know how to approve, deny and stop a run

Saturday (20 min)

Write a 10-15 line `AGENTS.md` with stack, test command and no-go folders

File committed in the repo root

Saturday (15 min)

Check `.env` is in `.gitignore` and only test keys live locally

`git status` never shows `.env`

Saturday (45 min)

Get one fast test command working, even with three tests

It runs in under a minute

Sunday (15 min)

Set a usage cap or budget alert on any usage-billed plan

Cap visible in billing settings

Sunday (60-90 min)

Run the full evening loop on one small task

One reviewed, tested, merged commit

Sunday (10 min)

Start a decisions file and write the first entry

File exists with one real note

## Common traps

- The giant first prompt. "Build me a SaaS for X" produces lots of code and little product.
- Reviewing the chat instead of the diff. The summary is the agent's opinion of its work.
- Letting it touch auth and billing "just this once." Those are the files where small bugs get expensive.
- Accepting every new package. Each one is code you now trust. Check it exists and is the one you meant.
- A 300-line rules file nobody maintains. Short and current beats long and stale.

## FAQ

### Is vibe coding fine for a side project?

The term, usually credited to Andrej Karpathy, means curating AI output instead of writing the code yourself. For a throwaway prototype or a weekend toy, sure. For anything with real users, logins or payments, no. The moment someone else's data or money is involved, you need to understand and review what ships. Vibe code the prototype, then rebuild the parts that matter with the loop above.

### Will an AI agent leak my code?

Your prompts, and whatever code the agent reads into them, go to the model provider to be processed, even when the agent runs on your laptop. [Claude Code's data usage page](https://code.claude.com/docs/en/data-usage), for example, says it sends prompts and model outputs over the network, and that on consumer plans you choose whether your data can be used to improve future models, while commercial plans are not trained on unless the customer opts in. Other vendors have their own rules and privacy settings. Before you open a repo with anything sensitive, read the data-use and privacy settings for your tool and plan, and keep secrets out of the repo either way.

### Which AI coding tool should I start with?

The one that fits where you already work. If you live in your editor, try an editor agent. If you live in the terminal, try a terminal agent. Give it two weeks with these habits before judging it. Most frustration comes from task size and missing tests, not the tool.

## Where to start this weekend

Write a short `AGENTS.md`. Get one fast test command working. Put `.env` in `.gitignore`. Then run one small task through the full loop: spec, plan, diff, tests, commit. That one clean commit teaches you more about using AI coding agents on a side project than a month of giant prompts.

When the project is ready for its first real users, launch it on [SideHunt](https://sidehunt.io/), where other builders with day jobs share what they shipped on nights and weekends.

## Links

- [Studio post (HTML)](https://sidehunt.io/studio/how-to-use-ai-coding-agents-on-a-side-project)
- [AI-friendly Markdown](https://sidehunt.io/studio/how-to-use-ai-coding-agents-on-a-side-project.md)

## Explore

- [Studio index](https://sidehunt.io/studio)
- [Blog](https://sidehunt.io/blog)
- [Launches](https://sidehunt.io/launches)

_HTML version: https://sidehunt.io/studio/how-to-use-ai-coding-agents-on-a-side-project_