Useful Things Agents Can Do That Are Not Writing Code

The dis­course is abuzz with the won­der­ful (and hor­ren­dous) things you can do when you al­low an AI cod­ing agent to write code. Peo­ple who al­low an agent (née clanker) to write all the code in an ap­pli­ca­tion are of­ten called “vibe-coders”. This ar­ti­cle is not about vibe cod­ing. In fact, this ar­ti­cle is about all the things you can do with an AI agent that are sep­a­rate from writ­ing code.

With each of these, I’ll go through the use-case, then in­clude the lat­est ver­sion of the pi prompt that I use.

I do not be­lieve you should use my prompts pre­cisely. I am not sug­gest­ing that you copy my work­flow. The beauty of many of these tools is that they are flex­i­ble and can be adapted to your style of work. I of­fer my prompts as in­spi­ra­tion. Maybe there are things you could be us­ing an agent for that are not writ­ing code.

Fix Merge Conflicts

I of­ten find my­self need­ing to fix merge con­flicts for my PRs be­cause ei­ther my­self or an open-source con­trib­u­tor has mod­i­fied the code up­stream. Al­most al­ways, these con­flicts are for­mat­ting or boil­er­plate changes that do not need my full at­ten­tion. In other words, it’s the per­fect job for a clanker.

Here is my prompt:

---
description: Fix a merge conflict in a PR.
argument-hint: "<PR NUMBER>"
---

I want you to fix the merge conflict in PR #$@.
If I have not provided a valid number, please ask me for it.

Do so by checking out the PR using the `gh` command, and perform the merge.
DO NOT push your changes until I have a chance to review them myself.

In pi, I can call this like a func­tion:

/fix-pr-conflict #4222

It does not mat­ter if I have the rel­e­vant PR down­loaded and checked out. The clanker fig­ures it all out non-de­struc­tively.

Locate Relevant Issues

When work­ing on open source soft­ware, I of­ten pri­or­i­tize fix­ing bugs that I find an­noy­ing and in­tro­duc­ing fea­tures that make my own life bet­ter. That’s nat­ural. When I do, I want to know if I am ac­ci­den­tally solv­ing some­one else’s prob­lem at the same time. If so, I can link the is­sue in my PR de­scrip­tion or reach out to the per­son di­rectly.

To find these rel­e­vant is­sues, I use this pi com­mand:

---
description: Find any issues relevant to this branch or a given PR number.
argument-hint: "<PR NUMBER>"
---

Please locate all issues that might be relevant to the current branch (unless a PR number is provided below).
Please list:

- If the issue is solved by this PR.
- The link to the issue.
- Who wrote it.

If not the current branch, look at PR #$@.

Again, this can be called like a func­tion:

/fd-issue

GH Actions Failures

90% of the time a GitHub Actions work­flow fails, it is not due to a bug. It’s be­cause I for­got to run my for­mat­ter or my sta­tic analy­sis tools (think Prettier or tsc).

In this case, it is not a piece of func­tional code that is bro­ken, but an an­no­ta­tion or miss­ing car­riage re­turn. It is an easy one-line fix. Why not make the clanker do it?

When a GitHub Actions run fails, I can use an agent with the fol­low­ing prompt to get it fixed tout suite.

---
description: Diagnose any existing GitHub Actions failures for this branch.
argument-hint: "<BRANCH>"
---

Diagnose any existing GitHub Actions failures for this branch, unless there is a different branch provided below.
Once you have taken a look to identify the possible underlying problem, offer a plan to fix it. Do not implement this plan without express approval.

If not the current branch, look at $@

It can be run as a com­mand in­side of pi:

/diagnose-action-failure

Wrap-Up

I of­fer these prompts as in­spi­ra­tion. Are there things that you could au­to­mate? If so, please let me know!