Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryannouncements / 2026-08-01

Ari's Space, Rebuilt With Kimi

Behind the scenes of Ari's Space V2: Kimi for groundwork and waves, Grok for art-direct and rapid iteration, then the live desk. Process, not a product tour.

10 parts / Hover to explore. Click to read.

Behind the scenes of Ari's Space V2: Kimi for groundwork and waves, Grok for art-direct and rapid iteration, then the live desk. Process, not a product tour.

Investigate -> compare designs
                 | challenge
                 v
          written agreement
                 |
          build -> check
                 |
         live visual direction
Discovery and challenge shaped the written design before the build waves. Live art direction judged the working page after the structural work.

V2 changed much more than the face of this site. We rebuilt the design system, architecture, membership path and content pipeline, then gave them a desktop you could walk into.

Kimi did the groundwork: discovery, architecture, wave plans, money, generation and migration. Grok came in for live art direction once those parts worked. Different jobs needed different kinds of attention.

This is the account of that August 2026 rebuild. The older eight-hour V1 build is here. Read each as a record of the version it describes, rather than a claim about every later change to the site.

Define the result, write the agreement, then check the thing you actually built.

Let discovery change the plan

At the start I had a mixture of ideas: membership tiers, an image tool, a forum and a design built around a pixel rocket shaped like an A.

Before implementation, five discovery agents investigated different questions:

  1. What already existed?
  2. Would the proposed stack hold up?
  3. How could the plan fail?
  4. What would a visitor experience?
  5. In what order should the work happen?

They returned digests I could make decisions from. I worked through the main choices in about ten minutes.

Then three architecture proposals went to three adversarial judges. Two proposals were rejected. The remaining one became the basis of V2.

Night zero diagram: ideas dump into five parallel agents (map, stress, fail, visitor, sequence), digests and decide, then three architecture drafts with one survivor
Argue first. Code second. Five agents, three drafts, one survivor.

Kimi is the public model name for that lane of work. The part worth reusing is the sequence: investigate, compare possible architectures, challenge them, and write down the one you've chosen before starting the build.

Decide who the site serves

We agreed on three surfaces sharing one domain.

SurfaceJob in the V2 design
ReadingServer-rendered essays, courses, pricing and public pages that people and crawlers could reach.
LLMContext packs, llms.txt and extractable source material for agents.
WorkingSigned-in tools under /app/*, including authentication, billing, studio, generation and writes.

The shared domain let cookies stay first-party. Separate deployment paths let content changes ship without requiring a change to the product and its ledger.

Three machines on one domain: reading machine, working machine under /app, and LLM machine for context packs, all meeting at aris-space.com
Three surfaces. One domain. Different deploy rhythms.

The human page and the agent pack needed to carry the same information in different forms. Treating agents as readers was part of the architecture from the beginning.

Make the design system before the product pages

V2 used cream paper, a purple rocket and terminal-inspired details. The rule was that the decorative treatment belonged around the content. If a pixel font made the essay difficult to read, we'd got it wrong.

The design package was the first working artefact: tokens, window chrome, a showcase route and lint rules to keep decorative styling out of the MDX prose.

A few other decisions went into the written design:

  • Describe the public result without exposing private harness names.
  • Keep paid value close to the sign-in path so people can understand what they're getting.
  • Run the rocket introduction once, let people skip it, and respect reduced motion.
  • Represent credits with integer pence in a ledger, use atomic debit and idempotent webhooks, and provide reconciliation when recorded and external state differ.
  • Give agents usable source material as well as giving people readable pages.

These were decisions for that build. Writing them down gave each later wave something concrete to follow.

Change the seat when the work changes

Kimi held the longer structural work: the discovery swarm, the agreed design, identity, money, generation and content migration. That work benefited from plans and explicit completion checks.

Grok took over the art-direction work with a live page open. I gave one note at a time and looked at the next render: the cream field, window chrome, library graph, login window and guest desktop.

Two seats side by side: Kimi seat for groundwork (swarm, waves, money, gen, migrate) handing off to Grok seat for art-direct (live render, one note per round, OS desk)
Same desk. Different job for the baton.

That change of working mode is familiar from film. Some decisions need a planning conversation. Others need you to look at the frame and make one precise adjustment. I wrote more about that in I directed a website live.

Build a wave you can finish and check

V1 had taught me to keep sessions small. V2 needed another level: waves with their own definitions of done.

In that build, changes reached main through merge requests, went to preview before promotion, and left a written handoff for the next wave. A new session needed the current agreement, not an invitation to invent the project again.

Six stacked wave bars: W0 foundations, W1 identity, W2 money, W3 product, W4 content, W5 desk
Waves, not one heroic session that limps over the line.

W0: establish the foundation

We made the monorepo and design package, ported the existing context-pack validator, and drafted this announcement. We also ran a content-scale spike before committing to the migration. The corpus had to fit the delivery environment, not merely look manageable in a folder.

W1: prove identity

Authentication lived on the working surface, with users mirrored into the data plane. The public header could recognise a signed-in visitor without putting the library behind a gate.

The important experiment was one domain across two workers, dispatching /app/* with a shared cookie. Sign-in had to work before we added money to that path.

W2: follow the money through the whole loop

Orbits went onto a checkout path. Founding and standard prices appeared together, Ultra had a deliberately limited supply, and credits were represented in the ledger.

Repeated webhook delivery had to be safe. Two generation requests couldn't spend the same pence. Members needed a cancellation portal, and operations needed a way to inspect and replay events when external systems behaved unexpectedly.

I tested a full £0 loop in the browser: sign up, select a tier, apply the coupon, confirm the grant, then cancel and confirm the tier was cleared. That checked a sequence the individual parts couldn't prove on their own.

W3: connect the product

The signed-in image tool used server-side prompt enhancement and ledger caps. Community reads used the public worker; writes used the app worker. Moderation hid content above the threshold and put it in a review queue.

The first planned generation backend refused the account's credentials. We tested the actual connection, selected an alternative that responded, and kept a one-variable route to upgrade if the original access became available.

The brief had to change to match the evidence. Insisting on the planned provider wouldn't have made the tool work.

W4: carry the content and its behaviour across

The corpus included essays, a component library, interactive fidgets and a glossary runtime. Moving the Markdown alone would have left important parts behind.

We staged the migration, ported or adapted the necessary blocks, kept URL shapes one-to-one and preserved the multi-page courses. The privacy description had to match the site's actual loaders.

Context packs and llms-full became build-time static assets. The production worker couldn't depend on the local content files being present at runtime.

That distinction had already caused a failure: a route worked on the laptop and failed in production because it tried to read those files from disk. The correction was to generate and ship the payloads, then probe a route unique to the new version after deployment. Local tests hadn't established that production condition.

W5: direct the desktop

With the underlying parts working, we shaped the guest desktop: login window, menu bar, grouped windows and a library graph with topic clusters and ASCII icons.

The V2 palette was cream, purple and brown, with no greens. Whole-pixel motion kept text sharp. Essays sat in readable paper areas within the wider scene.

I directed the live render one note at a time. The agents implemented the changes; I judged the result. The final cutover made that desktop the public entrance instead of leaving it on the preview host.

Keep the lessons that transfer

Write the handoff. Record what shipped, what remains and which decisions are settled. A conversation alone isn't enough for a session arriving cold.

Give each wave a checkable finish. Smaller sessions help manage the context. Wave-level acceptance conditions help keep the product coherent across those sessions.

Use the right working mode. Structural planning and visual direction ask different things of both the model and the human.

Stage the intended files. Path-specific commits and separate deployments made it clearer what was changing. A content edit wasn't a reason to ship unrelated authentication or billing work.

Write for both readers. People got the notebook; agents got the context pack. Extracted needles had to remain verbatim. Context pack dispatch explains that part of the method.

Check the generated work before promoting it

For generation on the product surface and in my own work, I wanted two independent looks, staging before promotion, and recorded recipes so the next review could find problems.

For video, lock the still before moving to motion. My rejection rule in that build was direct: if it looked obviously AI, it failed. Producing a file wasn't enough.

The private experiments stayed private. The public essays could still teach the checking discipline, while Studio provided a place for members to use the tools.

Other checks had to reach the real environment too: webhook behaviour through the WAF, authentication with the keys in use, the absence of runtime content files, and the complete £0 billing loop. Replay and reconciliation paths mattered because external events don't always arrive neatly.

What my job was

I directed the work and made the decisions. The discovery agents brought evidence. The architecture review rejected weak proposals. The waves produced something we could test. The visual work happened against a live page.

No one model accounted for the whole result. The useful structure was knowing who investigated, who challenged a decision, who implemented it, and what evidence we needed before accepting it.

That's why this essay is a making-of. The site is the example. The process is what you can take into your own project.

Keep the free work available

V2 added a guest desktop, courses and signed-in tools. It also made packs available to agents. Those additions weren't a reason to close the teaching library.

Free essays stayed free. Skool and the Clief Notes posting cadence stayed alongside the site. Membership added Studio, generation and other working surfaces for people who wanted those tools.

Someone who only reads the free essays or stays on Skool still belongs here. That was part of the design, every bit as much as the desktop was.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 12