TL;DR: AI coding agents now handle most of my implementation work. Powerful models make difficult decisions, balanced models handle normal implementation, and fast models take care of bounded changes. Skills carry workflow pathing, repository context, handoffs, and evidence thresholds between sessions. Delegated review speeds up personal projects, while work still gets the manual review it requires. Acolyte is my attempt to own that workflow instead of adapting it to one vendor's tool.
I use Claude Code in the terminal almost every day at work, with Codex and OpenCode as additional coding agents. I also use them while building Acolyte, my own terminal-first coding agent, and other products where AI is a core part of the development loop. AI does most of the implementation. I direct, inspect, and verify it.
It is the familiar software development lifecycle (SDLC) reduced to the loop I actually use:
design → build → review → ship
The skills are public at cniska/skills, and Acolyte is the coding agent I am building around that workflow. The phases stay stable while the work changes.
I route work by capability tier: powerful models handle difficult design and high-risk review; balanced models handle driving, normal implementation, and debugging; fast models handle bounded edits and mechanical work. I typically use standard reasoning to drive the work and reserve higher reasoning on powerful models when the task demands deeper judgment. Match capability, cost, and latency to the task.
I usually tell the driver to consult a powerful model when difficult design or review requires it. I do not tell the driver when to use a less powerful model for execution. The skills make that routing decision for bounded work.
I no longer routinely use a separate planning step, either the /plan skill or plan mode. I increasingly trust powerful models to produce designs directly, then move into implementation. This is faster, but I am not yet sure it is better. Skipping explicit planning may also remove useful friction.
I use MCPs instead of copy/paste when an external system has a useful interface. They keep relevant context inside the same loop and remove tab switching. GitHub stays in the workflow through the gh CLI for issues, pull requests, reviews, and checks. None of this removes responsibility. I run the verification, check the behavior, and use targeted review before treating the work as ready.
I use /handoff regularly. A handoff turns the useful state of a long session into durable startup context and lets the next session begin cleanly. Context management is part of the workflow, not an afterthought. The goal is not to minimize tokens at any cost; it is to avoid paying for stale context while keeping the decisions and constraints that matter.
Session context is only one layer. I use /agents-md to create and maintain the cross-tool rules a repository needs, and /spec when requirements deserve a separate source of truth. When I use /spec, I ask the model to use the skill to update the spec before implementing the change. Not every project needs both. I also keep documentation useful to agents and humans with /docs, shaping the architecture, workflow, and decision records around the code.
The skills themselves are part of the workflow, not a static prompt library. I have revised the applicable skills with workflow pathing, model routing, clearer handoffs, and stronger evidence thresholds. They now help the agent choose the next move and the right capability tier instead of merely describing a task.
Code review used to be the slowest part of my workflow. I use the /review meta skill at work and on personal projects, but work also requires a manual review of every change. On personal projects, I used to review every diff myself afterward too. I now use /review with /correctness-review as one of its dimensions and usually skip the manual pass there. That has sped up the workflow on personal projects. I still review high-risk changes and remain responsible for the result.
When I notice the same friction twice, I close the gap: a new skill, a sharper repository rule, a better prompt template, or a change in Acolyte itself. The workflow should get tighter over time instead of depending on memory or heroics.
Long conversations resend a lot of context, and the cost compounds across model calls. One precise prompt is usually better than five hasty ones. Prompt caching changes the economics, but it does not make irrelevant context useful. A compact usage report can also be misleading because cached input may be hidden; raw output-to-input ratios are not a quality metric.
The conversation is disposable; the durable knowledge it produces is what matters. Decisions, conventions, constraints, and things worth remembering need to outlive the session. /handoff distills that state into something portable and resets the context cleanly. Persistent repository instructions and skills do the same work at a larger scope.
A coding agent is two parts: the harness and the model. The harness provides structure through skills, MCPs, repository conventions, tools, and verification. The model provides judgment and execution. The harness should make good work easier to verify, not pretend that a wall of behavioral rules can replace judgment.
A clean response is not evidence that the work is correct. Tests, type checks, linters, security checks, integration behavior, and targeted review are the evidence. For larger or riskier changes, I use multiple review dimensions and sometimes do the final pass myself.
The model should also be able to test its changes without a human in the loop. Acolyte's /dogfood is a good example: it tells the model to use the product, capture the trace, and report only findings supported by evidence. I try to build workflows where it can run the relevant checks, observe the result, and iterate before handing me the work. If validation stops at something I have to inspect or confirm manually, the loop stops at the most expensive point.
AI tends to overengineer: extra abstractions, defensive layers, and premature flexibility. Complex systems are where that compounds into code that becomes difficult to change. Discipline matters more, not less, as the codebase grows.
Existing coding assistants are often good in short bursts, but daily work exposes their limits. They lose context, drift from constraints, and make me repeat the same instructions. I wanted a tool that could take over bounded execution while I stayed responsible for direction, decisions, and quality.
Changing how people work with coding agents means owning the stack end to end, from the user interface down to the model. I wanted a self-hosted, multi-provider tool I could observe and extend. Repositories that try to reshape an existing agent's core behavior through heavy prompt overlays are workarounds. They patch the surface, but the underlying constraints do not move. Real change comes from owning the agent itself.
Skills are different. They are structured prompts for specific tasks, not attempts to replace the agent. Mine sit at the workflow layer, not the foundation, which is why they help outside Acolyte too.
The economics push in the same direction. I use subscriptions for the main coding agents, but the underlying constraint is still the same: model vendors optimize for usage, while I optimize for useful work. Owning the agent lets me control context, caching, tools, verification, and provider choice instead of depending entirely on one vendor's interface.
- crisu.me/blog — blog posts on working with AI and building Acolyte
- Coding Agent Landscape — current map of coding agents