Bikes of Bentang Jawa: testing my AI workflow on something I wanted to use

I’ve given up on the one-shot prompt. Two or three prompts is my current target.

I wanted to see whether that would be enough to build a small project with my current setup: Claude Code paired with Codex, shared memory through Hindsight, and a bunch of MCP servers and skills around them.

Bentang Jawa gave me a reason to try it. When the race was getting exciting, I wanted to look at the bikes people were riding and find inspiration for an ultra setup. Tyres, gearing, bags, lights.

I’ve put miles into cycling, but my FTP still looks like a beginner’s and my longest ride so far is 100 km. Excellent qualifications for ultra, obviously. 🚲 I still wanted to try, so I wanted somewhere to compare what other riders were using.

That became Bikes of Bentang Jawa, where you can browse riders’ setups and explore equipment trends. The project repository is currently private while I prepare it for a public release. I wanted to use the site myself, so I had a reason to care about the result.

What I wanted to test

Ideally, this would be a productive afternoon for everyone except me: I’d explain the idea, let the agents use the context they already had, and come back to inspect the implementation.

There was already preparation behind those few prompts. The agents needed access to the project and its tools, along with working conventions and decisions from earlier sessions. I also wanted them to hand work to each other without me copying conversations between windows.

The target counted my high-level instructions. The agents could still make tool calls and go through review loops. Later revisions would add more work too.

I still wanted the agents to be disciplined about scope, even if I had turned looking at bike parts into a workflow experiment.

Pairing Claude Code with Codex

OpenAI’s Codex plugin for Claude Code lets you ask Codex to review changes or take on a task from inside Claude Code. That leaves me available for the demanding job of occasionally checking in. 🙃 The plugin uses the local Codex installation, so both agents work with the same repository checkout on that machine.

To set it up, run these commands inside Claude Code:

1/plugin marketplace add openai/codex-plugin-cc
2/plugin install codex@openai-codex
3/reload-plugins
4/codex:setup

The setup check tells you whether you need to install or sign in to Codex. The plugin uses the local Codex CLI and its authentication on that machine.

To try a review in the background:

1/codex:review --background
2/codex:status
3/codex:result

For implementation or investigation, /codex:rescue delegates a task to Codex. /codex:transfer lets you continue a Claude Code session in Codex. The plugin README documents the commands and their options.

For me, the appeal is the handoff. One agent can implement something and another can review it against the task and the repository. I still read the changes and decide what to keep. I just have less conversation to move around myself.

Giving both agents shared memory

I also want to start a fresh session or switch machines without explaining the project again.

I use Hindsight for that. Coming back after a break and asking where we left off, with the confidence of someone who remembers any of it, is part of the appeal. I call it permanent memory because it keeps useful context beyond a chat’s context window. What comes back still depends on what the workflow saved and what it retrieves.

Hindsight has operations to retain information, recall it, and reflect over stored knowledge. Through its MCP server, agents can access a particular memory bank.

To share project memory, connect both agents to the same Hindsight service and project bank. For example, the documented endpoint pattern is:

1https://<your-hindsight-host>/mcp/<project-bank>/

Replace the host and bank with your deployment’s values and use its authentication. Hindsight also has coding-agent integrations for Claude Code and Codex, with current installation instructions.

The agents need to recall relevant context before working and retain useful decisions afterward. Connecting the tool alone leaves you with another tool sitting there unused.

I use the repository to check what exists and shared memory to carry the reasoning between sessions. The files can change, so I still want the agents to check recalled context against them.

MCP and skills around the work

MCP servers give the agents access to tools and information. Skills give them instructions for recurring work, such as inspecting a project, following its conventions, reviewing changes, and checking the result.

Much of my preparation goes into those instructions and connections. Somewhere in a plan to look at tyres, I gave myself an orchestration setup to maintain. 😅 By the time I write a short prompt, I want the agents to have enough context to work with the project.

Superpowers skills have been especially useful for planning, testing, reviewing, and verifying work. I also use Claude Code’s built-in /loop and /goal:

• /loop repeats a prompt at an interval, which helps with recurring checks.
• /goal keeps Claude iterating toward a stated completion condition, with a limit on the number of turns.

The skills help describe how to do the work and check it. The commands help keep that work going without me writing another prompt for each check or iteration. Anthropic’s guide to loops explains the distinction. /loop still needs the machine running it to stay on.

How Bikes of Bentang Jawa is built

The current repository has two parts: the website people browse and the pipeline that prepares its data. Design specs, implementation plans, and ADRs live alongside the code. The project instructions separate design, planning, and implementation into thinker, planner, and executor sessions.

Appwrite holds the database. I had set out to compare bicycle parts and acquired a database to look after, but at least the website doesn’t need to call it when someone opens a page. SvelteKit builds from the exported JSON files instead.

The data takes this path:

 1DotWatcher scrape / Instagram harvest
 2                 |
 3        Raw files / review queue
 4                 |
 5           Human curation
 6                 |
 7          Curated records
 8                 |
 9       Appwrite -> JSON snapshot
10                         |
11                  SvelteKit build
12                         |
13                 Cloudflare Pages

There is also a local export directly from the curated records to the JSON snapshot, which needs no database credentials. CI builds from the committed snapshot and gates deployment on the site and pipeline checks. Pull requests get preview deployments; pushes to main deploy to production.

The third-party services do different jobs:

• DotWatcher and public Instagram posts supply bike-check material. Apify handles Instagram harvesting, with Bright Data as an additional path for filling gaps. Candidates go through human review before joining the curated data.
• OpenRouter supports an optional extraction step that suggests structured equipment fields from captions. Those suggestions still need validation and curation.
• Appwrite stores the curated data. Its API credentials belong to the pipeline, and the static site builds without them.
• Instagram’s official embed displays Instagram media; DotWatcher images stay linked to their source. The project keeps source credits and doesn’t rehost the photographs.
• Tally hosts the correction and bike-submission forms. RideWithGPS supplies the public race-route export used to generate the committed route data.

GitHub Actions and Cloudflare Pages handle the build and delivery. Those collection and extraction services are separate from browsing the site: a visitor doesn’t trigger an Apify harvest or an OpenRouter call. Instagram embeds and the hosted forms still depend on their providers.

The site shows where equipment details are missing through its coverage indicators. I use the setups for inspiration; they don’t tell me which part will be best for someone else.

Moving the work beyond my laptop

I initially used Herdr. I wanted the agents to keep working while I’m sipping my cola on Nusa Dua beach in Bali. 🥤 That meant being able to run them outside the laptop I was carrying, whether on my second laptop, a home server, or a cloud VM.

That led me toward Orca. It has SSH worktrees for running agents on remote machines and a mobile companion for checking their progress and sending instructions from a phone.

Herdr’s current documentation describes remote access too. Orca fit what I was looking for: managing remote agents and checking in from my phone.

The remote machine still needs to stay available and have the repository, tools, and access the agents need. Shared memory carries context between sessions, while Git carries code changes. The process itself runs on that machine while I am away.

What I can say so far

Bikes of Bentang Jawa gave me a small project I cared about and a live result I can browse, share, and ask other cyclists about. For now, my contribution to ultra cycling is something I can browse sitting down; the ride longer than 100 km is still on the to-do list.

I didn’t run the same task with and without Hindsight, pairing, MCP, or skills, so I can’t say how much each contributed. I want to keep testing whether the setup helps me spend less time repeating context and moving work between agents. Two or three prompts is the target I’ll keep trying for.

I’ll write a separate post going deeper into the options for shared memory between agents and the orchestration tools I’ve tried. I’ll share what worked for me, what I’d recommend, and why.

On the cycling side, I am curious what still feels confusing or unnecessarily difficult when preparing to ride. Choosing parts, planning a route, or something else? That might give me a reason for the next experiment. 👀

References:

• Bikes of Bentang Jawa: the live project and its equipment coverage.
• Project repository (currently private): implementation, data pipeline, and curation process.
• Codex plugin for Claude Code: pairing setup, reviews, delegation, and session transfer.
• Hindsight: persistent memory, with MCP access and coding-agent integrations.
• Orca: agent workspace with SSH worktrees and a mobile companion.
• Herdr: the tool I initially used to manage the workflow.
• Superpowers: skills for planning, implementation, testing, review, and verification.
• Anthropic’s guide to loops: how /loop and /goal keep work going and when each fits.