curated randomnessby Rahil Chamola
Share
Portable context

Take this page to your AI.

Nothing is sent automatically. Copy or download a clean Markdown packet, then choose what you share with your own agent.

Your context, your choice. Review the packet before giving it to any model or agent.

All writingbuilding × ai × product
Making Curated Randomness / part 1

The website was not the prompt

I did not need an AI that could make a website. I needed a process that could tell a plausible website from mine.

The first version of this story would be easy to tell badly. I asked an AI to make a personal website. It generated code quickly. After enough prompting, a polished interface appeared.

That account would be factually adjacent and practically useless. Modern models can produce a competent website before I have finished explaining what I want. Competence was never the hard part. The hard part was preventing competence from averaging away the argument, the taste, and the small decisions that made the site mine.

01 / RECOVERY

Recover the argument before the pixels

I already had an old public website and several later redesign attempts. That did not make the job easier in the obvious way. It created competing sources of truth: the checked-out site, a more advanced redesign branch, prototype HTML screens, later implementations, screenshots, and memories of what had felt right. Copying the nearest code would have preserved whichever version happened to be easiest to find.

The recovery work separated visual evidence from runtime instruction. The shared console stylesheet and polished prototype screens were authoritative for the approved look. The handoff and decision records were authoritative for intent. A later Next.js implementation was useful behavioral evidence, but it had drifted visually. Private personality files and unrelated Neo history were explicitly out of bounds.

Recover the argument before recovering the pixels.

That distinction matters well beyond websites. When an agent inherits a mature project, more context is not automatically better. Old code, abandoned experiments, and confident documentation can all be locally correct and globally stale. The first job is provenance: which artifact proves appearance, which records a decision, which demonstrates behavior, and which is merely nearby.

02 / TASTE

Turn taste into conditions that can fail

“Make it beautiful” is a real desire and a terrible acceptance test. The useful work was translating reactions into constraints precise enough to reject an implementation.

  • No persistent sidebars. They consume the reading canvas and make a personal publishing site feel like administration software.
  • No decorative vertical accent rails. A category color can identify meaning; it should not become a repeated piece of console costume.
  • Beautiful and expressive, not default-minimal, dashboard-like, or dense for the sake of looking technical.
  • Atkinson Hyperlegible for reading. Typography is an accessibility and identity choice, not a late coat of polish.
  • Light and dark modes begin together. Light mode is not a mechanical inversion performed after the dark interface is complete.
  • Tags are bounded objects: links or controls with borders, not metadata words floating without affordance.
  • The console-coder language appears only when it clarifies state, provenance, sequence, or action.
  • Navigation can be playful, actions can be dynamic, and feedback can have character; none of them may become ambiguous.
  • Mobile is a deliberately composed primary viewport. Hover cannot be required, targets remain touchable, and horizontal overflow is a defect.

These were micro-decisions, but they were not minor. Together they formed the acceptance boundary. An agent could still propose variations in color, rhythm, composition, or motion. It could not negotiate the site back into a sidebar, a component dashboard, or illegible console theatre because those patterns were convenient to generate.

03 / SYSTEM

A component catalogue cannot prove a website

Starting with the system was still right. It established the visual roles and interaction states before pages multiplied. The catalogue also exposed a trap: components can look complete while avoiding composition.

Rows of specimens were clean and internally consistent. They also looked too much like one another. Feedback components repeated the same cyan treatment. Analytics cards displayed illustrative numbers without enough provenance. The “architecture map” had boxes but no real graph semantics. A sequence diagram understood only one hand-written grammar. The state machine was a dressed-up stepper. The decision tree was positioned by hand. Several controls looked interactive before they actually changed anything.

The correction was to make the real homepage the system's hardest test. Instead of asking whether a button, tag, chart, note, or project tile looked good in isolation, the composition had to prove that they could coexist without turning the page into a component museum. When the homepage needed a contract the system did not have, the system grew. When a catalogue pattern weakened the page, the pattern changed.

04 / BEHAVIOR

If it implies computation, it has to compute

The most important visual correction was not aesthetic. It was epistemic. A chart asks the reader to believe a comparison. A state diagram claims that only certain transitions are legal. A decision tree claims that edges lead somewhere. A sequence diagram claims that events occur in an order. Drawing the appearance of those things without implementing their logic borrows credibility the page has not earned.

  • Recharts renders analytical views whose sample, period, source, and definition are visible, with an accessible table as the fallback.
  • React Flow and Dagre provide real nodes, edges, layout, selection, and navigation for decision tools.
  • XState makes publication states and legal transitions executable instead of decorative.
  • Mermaid handles sequence and architecture grammar while preserving the text source as a fallback.

I used public libraries for graph layout, statecharts, charts, and diagram parsing. The original work is the explanation: what readers can manipulate, which evidence they can inspect, and what changes in their understanding.

05 / BROWSER

The rendered interface is the argument

Source review did not catch the most embarrassing failures because the source contained the right words and components. The browser revealed that a dropdown could open without behaving like a finished control, feedback states were visually undifferentiated, mobile composition collapsed into long container stacks, and controls could advertise actions that produced no observable result.

Those were not polish defects. A dead affordance breaks the product's truthfulness. Once that became an explicit quality rule, interaction tests stopped checking only whether the page loaded. They clicked theme controls, changed sliders with a keyboard, opened and closed dialogs, dismissed notifications, selected filters, exercised the publication state machine, loaded provider media only after consent, and verified that the graphs and Mermaid diagrams produced their real runtimes.

The same browser suite checks horizontal overflow and serious accessibility violations on both the homepage and the system workbench. It is not complete accessibility certification. It is a repeatable floor. Mobile overflow or an unusable interaction now fails the suite.

06 / COLLABORATION

Give agents roles, evidence, and an acceptance boundary

Different critical lenses were useful because they were not asked to agree by default. A visual lens could object to container repetition. A data-visualization lens could challenge a dishonest comparison. An engineering lens could find dead controls. A content-archaeology lens could distinguish a real provider integration from a convincing mock. Their job was to produce inspectable disagreement, not a synthetic consensus paragraph.

The shared unit was not a private transcript or a giant personality profile. It was project evidence: requirements, decisions, source paths, screenshots, tests, and a current handoff. This kept the work portable and made criticism traceable. An agent could say which file or rendered behavior supported a claim. It could also mark an inference instead of laundering it into fact.

My role was not to out-type the agents. It was to own the thesis and the acceptance boundary. “never these disgusting sidebars” was not an implementation suggestion. My rejection of half-baked analytics, metric cards, and fake graphs reopened the product logic, not just the colour palette. “why is the drop down not programmed” established that apparent interaction without behaviour was unacceptable. The final veto stayed human because the site would carry my name and point of view.

07 / ARCHITECTURE

Keep the reading surface simpler than the making process

A complicated build process does not justify a complicated page. Curated Randomness uses Next.js, but the intended public reading surface is static semantic HTML by default. Theme controls, graphs, reactive models, provider embeds, and other stateful explanations become narrow client-side islands only on pages that use them. The content layer exposes typed records rather than database rows so storage can change later without rewriting the public contracts.

That architecture also keeps the site indexable. A crawler does not have to operate the interactive instrument to receive the article, its title, byline, dates, canonical URL, relationships, and static explanation. JavaScript can deepen the argument without becoming the only place the argument exists.

08 / METHOD

A reusable build loop

  1. Locate the authoritative evidence before generating a replacement.
  2. Separate observed facts, owner decisions, interpretations, and unknowns.
  3. Translate taste into constraints that can reject plausible work.
  4. Build semantic primitives, then pressure-test them in a real composition.
  5. Use mature public runtimes for behavior whose credibility depends on correctness.
  6. Give independent critics narrow lenses and require source-backed findings.
  7. Exercise the rendered interface with touch, keyboard, light mode, reduced motion, and small screens.
  8. Keep the human thesis, privacy boundary, consequential decisions, and publication veto on the critical path.
  9. Record the decision and exact restart point so the next session does not depend on remembered conversation.

AI made this website possible faster than I could have built it alone. It also produced more plausible mistakes and more decisions per hour. The work became better only when the system made those decisions visible enough to challenge.

The website was not the prompt. It was the evidence, the constraints, the arguments, the browser, and the decision to say no until the thing on screen felt true.

Sources / further reading

Follow the evidence.

  1. Neo evidence register
    Neo evidence registerRahil Chamola
  2. Product requirements
    Curated Randomness product requirementsRahil Chamola
  3. Decision 0004
    Website as the design-system driverRahil Chamola
  4. Council review
    Council review: design system correction
  5. Application architecture
    Curated Randomness application architecture
  6. Browser acceptance suite
    Curated Randomness Playwright and Axe acceptance suite
Creator / sourceWritten and published by Rahil Chamola on Curated Randomness.

If this page informs your work or your agent's answer, please retain the creator and canonical source link.