Do not let your first agent edit land in the laptop clone. Run that first session on a remote sandbox instead. Bring back one reviewed patch after the checks pass.
You joined this repository with a thin map of its risks. A coding agent can still draft a small change for you. That speed is not a safe first pull request.
Keep the default branch untouched during this first hour. Explain every changed line before you request review. Treat the steps below as a proposal you must adapt.
1. Write the Contract Before You Open a Chat
Write a one-page brief before you open an agent chat. The brief is the only contract for this hour. If the brief feels vague, do not start the session.
Lock five facts in that brief before you type a prompt. Name the ticket and the one behavior you will change. Also name allowed paths, the CI test command, and the base SHA.
Do not ask the agent to invent those facts for you. You write them from the repository and the ticket. The agent may work only inside that written fence.
2. Record the Base Commit Before Any Agent Prompt
Your first commands should only read local repository state. They should not create an agent branch on this clone. Save the default-branch SHA where you can find it later.
git fetch origin
git status --short
git rev-parse --abbrev-ref HEAD
git rev-parse origin/main
git log -1 --oneline origin/main
Write that SHA into a note outside the work tree. If this repository uses master, record that name instead. This note is your return point if the session goes wide.
git rev-parse origin/main > "$HOME/hour-one-base.txt"
Do not commit that personal note into the repository. Do not push it to the remote by mistake either. It is a personal checkpoint, not a project file.
Confirm the work tree is clean before you continue. A dirty clone will mix your scraps with the agent patch. Stash or drop those scraps before you record the base.
3. Pick a Sandbox That Is Not Your Clone
You need a place the agent can edit without touching your clone. A free server can be that place when the offer includes one. A local virtual machine remains a valid substitute here.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
MonkeyCode is only one route to free model access and a free server. Treat both items as availability claims that you must recheck today. This article does not name models, token caps, hardware, or duration.
Those details change, and this draft did not measure them. Open the current product page before you depend on any limit. If the free server is absent, keep the same brief locally.
Use that server only for this first reviewed patch. Do not place production secrets on that remote machine. Do not point the session at private customer data.
If the repository is private, read the server terms first. If those terms are unclear, skip the remote option entirely. A company ban on outside models also ends this path.
4. Copy a Narrow Brief Onto the Sandbox
Create a file named SESSION_BRIEF.md on the sandbox before prompting. Keep that file short enough to reread in two minutes. The sample below is an unexecuted template, not a real run.
# Session brief
Ticket: https://example.test/tickets/123
Change: Adjust empty-state copy in web/src/Empty.tsx only.
Allow: web/src/Empty.tsx and web/src/Empty.test.tsx
Outside scope: workflows, lockfiles, migrations, and infra
Test: npm test -- Empty.test.tsx
Done: that test passes, and no other file changes.
Stop: if a new dependency is required, stop.
Paste the brief as your first message to the agent. Tell the agent to stop when the change leaves those files. Tell it not to push or open a pull request.
Tell it not to amend commits or rewrite history. If the agent leaves the allowed files, discard the sandbox. Do not salvage a wide diff on your first day.
Start again later with a smaller allowed file list. Watch the session for scope creep in the chat replies. A request to update a lockfile is a stop signal.
5. Export One Patch and Leave the Sandbox
On the sandbox, read status before you export anything. You want a single patch file copied to your laptop. You do not want a surprise push to the team remote.
git status --short
git diff --stat
git diff > /tmp/hour-one.patch
Copy that patch home through your normal file transfer step. Remove any secrets you typed into the sandbox session. Stop or destroy that server when the product lets you.
Do not keep a forgotten remote checkout for later experiments. Hour one ends when the reviewed patch is home. A living sandbox is not a second source of truth.
6. Apply the Patch on a Named Ticket Branch
Return to the laptop clone after the patch is home. Create a branch that names the ticket, not the tool. Test the patch with an apply check before you apply it.
git fetch origin
git switch -c ticket-123-empty-state origin/main
git apply --check /tmp/hour-one.patch
git apply /tmp/hour-one.patch
git diff --stat
If the default branch moved, do not rebase alone. Ask a human owner before you replay the patch. If the apply check fails, stop and do not hand-merge.
A confused patch is a failed hour, not a puzzle. Rerun the sandbox session with a smaller written brief. Leave the laptop clone clean while you do that rerun.
7. Run the Named Test and Read Every Hunk
Run only the test command you wrote in the brief. A full local suite can wait for CI on this pass. You need proof that this patch matches the ticket text.
npm test -- Empty.test.tsx
git diff -- web/src/Empty.tsx web/src/Empty.test.tsx
Replace that npm command with the one CI already runs. Do not invent a friendlier command just for the agent. If CI uses a task runner, pin that exact task in the brief.
Write a reviewer note in your own words after the test. Use the checklist below before you open any pull request. The checklist is an unexecuted proposal, not a team form.
- [ ] I can name the user-visible change in one sentence.
- [ ] I can name the test that now covers that change.
- [ ] No lockfile, workflow, or migration file changed.
- [ ] No new dependency appeared in the diff.
- [ ] I can delete this branch without touching main.
If you cannot check a box, do not open the pull request. Shrink the patch or drop it and restart from the brief. Silence is better than a review you cannot defend.
8. Use a Decision Table Before You Continue
This table is a proposal, not an official team policy. Read the row that matches the diff you actually have. Then do that action, even if the agent sounded confident.
| What you see | What you do |
|---|---|
| Only allowed files changed, and the named test passes | Open a draft pull request |
| The patch touches files outside the brief | Discard the sandbox result and restart |
| A new dependency or workflow edit appears | Stop and ask the code owner |
| The patch does not apply on the base | Do not hand-merge; rerun a smaller brief |
| You cannot explain one hunk | Do not request review |
Confidence in the chat transcript is not evidence for you. The diff on disk is the evidence you can defend. Your short note is what the reviewer will actually trust.
9. Open the First Pull Request as a Draft
Push only the ticket branch from the laptop clone. Open the pull request as a draft, not as ready review. Paste the brief, the test command, and the base SHA.
git push -u origin HEAD
Write that body yourself after you finish reading the diff. Do not paste the agent transcript as the description text. Reviewers need the change, the test, and the risk.
They do not need the full chat log in the body. They need to see that you understood each hunk. A short body beats a long generated summary every time.
Request review only after the draft checks are green. If CI uses a different command, trust the pipeline. Update the brief, rerun that command, and then ask.
Do not argue with the pipeline on your first day. Do not weaken a check just to make the patch green. Ask the code owner before you touch any workflow file.
10. Close a Bad Draft Without Extra Story
Some drafts should die before anyone spends review time. Close the pull request and delete the ticket branch. Then confirm your clone still matches the fetched default branch.
git switch main
git fetch origin
git status --short
git push origin --delete ticket-123-empty-state
git branch -D ticket-123-empty-state
Do this when the patch grew past the written brief. Do this when a reread still leaves one hunk unexplained. A closed draft is a clean outcome, not a failure story.
If you already merged, follow your team revert rule instead. This article does not invent a revert policy for shared history. Ask the owner before you rewrite commits on the default branch.
Confirm the default branch SHA before you delete local work. If origin main moved, fetch and read the new log first. Never reset a shared branch to your hour-one note.
Respect Limits Before You Trust Free Access
This workflow fits a small, reversible text or copy change. It does not fit migrations, auth changes, or billing code. It does not fit code you cannot place on a third-party server.
Skip the free server when private-repo terms are still unclear. Skip free model access when your company bans outside models. A local editor plus the same brief is enough in that case.
Free access can change or disappear without prior notice. Do not plan a week of work on an unpaid server. Do not assume a token grant, machine size, or time limit.
Verify those facts on the current product page yourself. The sample test command is generic on purpose here. Your repo may use pytest, go test, or a task runner.
Pin the command your CI configuration already runs today. Do not invent a new command so the agent looks fast. A green command that CI ignores is not a valid signal.
The template paths are fiction for this teaching example. Replace them with a real file named in your ticket. If you have no ticket, do not invent work for the agent.
Skip This Path When the Fit Is Wrong
Skip this path if you cannot read a unified diff yet. Pair with a human before you invite an agent in. An agent does not replace that first reading hour.
Skip this path for production hotfixes and incident channels. Skip it for mass edits across issues you do not understand. A first contribution still needs the project guide and the license.
Skip the remote sandbox if it would hide work from review. The patch still comes home to your laptop clone. Your name stays on the pull request either way.
Do not use this flow to bypass code owner rules. Do not use it to skip a required design note. If the ticket lacks checks, write them with your mentor first.
Try One Ticket and Then Stop Cold
If those free options are still listed, try exactly one ticket. Keep the written brief tighter than the prompt you want. If that offer is gone, use a local virtual machine instead.
Stop after one reviewed draft leaves your laptop. Hour one builds a habit, not a batch of agent pulls. Tomorrow, repeat the brief before you touch a second file.
Top comments (0)