Christoffer Niska cniska

My Workflow

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.

The workflow

A repeatable loop

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 v

name	handoff
description	Summarize the session and reset context to save costs. Use when the context is getting long or before switching focus.

Handoff

Summarize what matters, clear the noise, and continue without paying for stale tokens.

Workflow

Coding Agent Landscape

Updated July 2026

Open Source

Agent	Category	Lang	License	Notes

name	plan
description	Design a feature or behavior change through dialogue. Use when asked to plan, scope, design, or break down work before coding.

Plan

Design a feature or behavior change through dialogue. The plan emerges from the conversation, not in isolation.

If an issue number is given, fetch it with gh issue view $ARGUMENTS and use it as the starting point.

Acolyte Benchmarks

Measured comparisons of Acolyte against prominent open-source AI coding agents. All metrics are from source code analysis — no opinions, just counts.

Metrics extracted with benchmark.sh

Projects Compared

Setting Up Codex

Prerequisites

Codex installed
Recommended: install Codex via Homebrew for easy updates
GitHub CLI authenticated (gh auth login)
Copy config.toml to ~/.codex/config.toml

	#!/usr/bin/env bash
	# wt — one task, one worktree, one tmux window, one agent.
	#
	# Convention: task worktrees live at <repo>/.claude/worktrees/<branch>, the same
	# path Claude Code's EnterWorktree and a manual `git worktree add` use. Set
	# WT_AGENT to launch something other than `claude`.
	#
	# On fresh creation, wt runs an optional repo hook — scripts/worktree-setup.sh —
	# so a new worktree arrives with dependencies installed. The hook is opt-in per
	# repo (skipped if absent) and non-fatal (a failed install still leaves a usable

	#!/usr/bin/env bash
	# Claude Code statusline: dir[/subdir] · worktree · branch[*↑↓] · model[↓] effort · pct%/size · $cur[ $tot] · ↑tok-in ↓tok-out
	# dir is the repo name (cwd basename if not a repo); subdir/worktree/branch are optional.
	# In a repo, if cwd is below the working-tree root, the cwd basename rides dim on dir (proj/subdir).
	# The three fold left to right: a name already shown drops.
	# Input: JSON on stdin (see https://docs.claude.com/en/docs/claude-code/statusline)
	#
	# One function per segment, each reading the parsed globals and echoing its rendered
	# string (empty when there's nothing to show). main parses stdin, then joins the
	# non-empty segments. Sourcing the script (the test suite) defines the helpers and

	import { type EffectCallback, useEffect, useRef } from "react";

	/**
	* Run an effect exactly once on mount. This is the only sanctioned way to
	* call `useEffect` in chat-layer code — prefer derived state, event handlers,
	* or render-time adjustments for everything else.
	*/
	export function useMountEffect(effect: EffectCallback): void {
	const effectRef = useRef(effect);
	effectRef.current = effect;

	#!/usr/bin/env bash
	set -euo pipefail

	# Validate a commit message against project conventions.
	# Usage: check-commit-message.sh <subject> [body]
	#
	# Rules:
	# - Conventional Commit format: type(scope): description
	# - Allowed types: feat, fix, refactor, docs, test, chore
	# - Single-line subject, no body