Vibe Coding Your Productivity Tools Is Fine

In my software factory series, I turn observations about where my attention goes into tools. My approach is straightforward: define the inputs and expected result, let an agent build a useful version, and improve it through real work. I’m comfortable keeping the implementation rough and vibe coded in a controlled environment.

These tools exist to help me deliver work. I want them to save effort and stay easy to change or throw away. Extra architecture and polish have to repay the time they take from that work. Clear expectations, useful feedback, and basic hygiene are enough to start; I add more engineering when an actual problem calls for it.

That gives me a few rules.

1. Start with work you actually want to finish. Build around a recurring obstacle: preparing a simulator, collecting results, or making a slow command faster. Try the tool on that work immediately. You can discover its broader potential after it has helped with something concrete.

2. Be precise about what goes in. Give the tool the worktree, files, target, or question it needs. For an agent, those inputs should be easy to provide explicitly. Every assumption it has to guess is another reason for you to get pulled back into the task.

3. Decide what a useful result looks like. “Run the app” might mean a process started, or it might mean the expected screen appeared on the correct simulator. Say which you need. Ask for a short result, evidence, and a path to details when something fails. Incomplete work should be visible as incomplete.

4. Let the implementation be rough. A wrapper around an existing command is fine. So are a few mise tasks and code you would happily replace next month. Spend engineering effort where failure has consequences or where complexity is already hurting. A hypothetical future audience can wait.

5. Make it easy for an agent to use. Give it an obvious command, predictable arguments, and output it can act on. Avoid repeated prompts and pages of logs just to answer a simple question. Include a small example of a successful run and what to do when it fails.

6. Collect feedback while the work happens. Log events: what ran, how long it took, whether it worked, and when you had to intervene. A local event file and a way to record “this result was wrong” can be enough. You need enough evidence to find the next improvement; the recorder should add little overhead.

7. Keep changes cheap. When you discover a bad assumption, you should be able to show an agent the input, the actual result, and what you expected instead. Save useful failure examples so you can check the next version against them. Keep the tool small enough that fixing it remains an ordinary task.

8. Use the cheapest worker that does the job well. Exact rules often need only code. Smaller models and cheaper agents can handle bounded tasks; Jev has been useful to me for inexpensive classification. Try them on your own examples. Paying for a stronger model makes sense when it improves the result enough to justify the cost, including retries and your correction time.

9. Keep your domain knowledge inside a controlled boundary. Local tools are a practical starting point, provided their dependencies and outbound calls are understood. Keep private code, credentials, and business context out of public uploads, shared logs, and unfamiliar services. Any remote model or agent should receive only the context you are comfortable sending to that environment.

10. Respect the machine doing the work. Check whether the tool saves time under normal use, including several agents running at once. Bound parallel work and retries. A helper that exhausts memory or competes with every build can slow the whole workflow even when its own task finishes quickly.

11. Clean up after yourself. Logs, caches, screenshots, temporary builds, and abandoned simulators accumulate. Give generated files a known home and a sensible lifetime. Let the tool remove resources it owns safely. Saving a few minutes today is less useful if tomorrow starts with a full disk.

12. Keep your own judgment. A filtered code-review view still leaves you responsible for reviewing the relevant change. If it hides important context, fix the tool and check what you missed. Knowing about the gap is a reason to act on it.

13. Be willing to throw it away. If maintaining the tool costs more than it saves, simplify it, replace it, or delete it. It has no claim on your time just because you built it.

The application also needs an architecture these tools can work with efficiently. The companion guide, Modular iOS Architecture for Agentic Coding, covers the boundaries, dependency wiring, focused workspaces, and selective tests that keep app changes manageable.

You can see concrete examples in Pitcrew on GitHub, where I keep the tools I use for local review, repository checks, per-worktree simulators, and shared development sessions. Use a tool directly, copy a useful piece, or give your agent a reference for building a version that fits your own work.

I’m comfortable accepting rough edges in a helper I can inspect, control, and change. I still owe the application I’m building the same quality and craft. The tool earns its place by helping me deliver that work with less effort. Clear expectations and a short feedback loop give me a way to improve it without turning it into another product to maintain.