Michael Shimeles’s Four-Step AI Coding Workflow Keeps a Human in the Loop

Michael Shimeles, also known as Ras Mic, is skeptical of a fully autonomous “software factory”: a wrong assumption at the start can propagate through a long run. He instead uses the term for a set of workflow instructions, skills and engineering preferences that guide an agent while he remains involved.

His workflow is intended to work across models and tools. An AGENTS.md file explains how he wants the agent to work, while separate skills handle stages. He says models can inspect the repository themselves for many structural details.

The first stage isolates a new feature or fix in a Git worktree branched from the main branch. This lets him run several agents on separate tasks without having them edit the same files. He demonstrates several agents working in terminal tabs.

His worktree skill also tells the agent to fetch and verify the repository state. It warns that worktrees isolate files, not shared resources such as development-server ports or a shared database. Shimeles says he used AI to help write the Git instructions.

The build stage calls a code-structure skill. Shimeles favors a service-layer pattern: actions and boundaries coordinate business rules and timing, while reusable mechanics live in services with explicit inputs and structured results.

He chose the structure partly so that he or another developer can read the code later. Consistent function names also give agents clues about existing behavior and may reduce duplicated helpers. He acknowledges that engineers differ on architecture choices.

During the prove stage, an evidence-driven skill attempts to reproduce a reported bug before the fix and capture the result afterward. On supported setups, it can record video of the behavior. This helps distinguish a reproducible defect from a report that cannot yet be confirmed.

For visual changes, a before-and-after skill can capture screenshots. For a performance change that cannot be shown in an image, he shows measurements instead: in one example navigation times fell from roughly 815 milliseconds to about 60 milliseconds. He uses these artifacts to assess the claimed improvement.

If there is no prior bug to reproduce, the agent may record only the resulting behavior. Shimeles says the evidence step sometimes causes an agent to notice that a change did not improve the result and continue working. Some recording tools depend on the operating system and installed software.

Some models follow all stages automatically in his experience, while another sometimes needs a reminder to run a review loop. He has not determined whether the cause is the model or his instructions. The workflow is therefore something he monitors, not a guarantee that every step ran.

Shimeles still tests features himself, particularly when other people use the software. For client work, developers on his team also review the code. For a small personal utility, he may accept a faster and less formal process if it works for him.

He describes splitting work across machines: a Linux computer handles some tasks, while he uses a Mac for user-facing work and computer-use testing. He also wants to work from his phone and switch between models, which shapes his setup.

The shipping stage uses an automated pull-request reviewer, Greptile. When the reviewer leaves actionable feedback or a confidence score below his target, the coding agent revises the code, repeats appropriate evidence checks, pushes changes and requests another review.

The loop stops when it reaches the target or an iteration limit; his version allows up to ten iterations. He then receives the pull request and evidence to inspect. The review score is part of his process, while he still decides what to test and merge.

Shimeles summarizes the chain: isolate, build to a structure, prove the bug or result, then submit a pull request and respond to review. Yang observes that the last two stages emphasize verification. Shimeles says he does not trust an agent to make every decision correctly in one pass.

For a personal screenshot utility or image-sharing tool, he may skip the full chain because the consequence of a mistake is lower. Yang notes that even a personal overnight run can waste effort when an early assumption is wrong. Shimeles agrees that communication matters before the agent runs far ahead.

For planning, Shimeles talks through an idea with the agent for several minutes. The conversation becomes the immediate specification. When there are setup steps he needs to return to later, he asks the agent to write a Markdown file in the relevant project directory.

Asked whether a personal project needs worktrees and pull requests, he says speed and experimentation can be more important when the stakes are low. A developer can choose a stricter process when practicing skills or building for other users.

On model choice, he says one model has been useful in his own performance audits, security reviews and computer-use tests. He gives an example of a payment application where an audit surfaced a serious issue, and urges people operating applications for real users to review security.

For interface design, he finds that visual references improve results. He says another model often writes code he prefers, while his preferred auditing model is stronger for some other tasks in his experience. These are observations from his own workflow, not a universal ranking.

He uses terminal tools partly because they make switching between agents and models familiar. Since the strongest subscriptions can be expensive, he suggests choosing a model appropriate to the work and using smaller models for routine tasks where they are sufficient.

For client applications, Shimeles runs scheduled security checks. He is also building an agent workspace across machines in a home lab. Yang notes that scheduled jobs can become hard to track when spread across devices and cloud services.

A recent cleanup revealed thousands of worktrees on Shimeles’s machine. Both discuss the need to keep track of accumulated resources. The same flexibility that enables parallel agents can create operational clutter.

Shimeles expects parts of his workflow to disappear as tools incorporate better defaults, while instructions reflecting how he personally works may remain useful. When a new model arrives, he first tries it without his usual instruction files and then adds the workflow back.

Yang cautions that advice from model labs may assume access to more compute than ordinary users have. Shimeles agrees that cost and resource limits affect practical choices, and says he values open models that can be run locally as an alternative.