Understanding Software

July 2026 · Weekend project · Design, development, and AI workflow

A blue technical field guide titled Understanding Software

Understanding Software started as a weekend clone of Dan Hollick's Making Software website. I loved his work and wanted to see whether I could recreate that technical field-guide style myself.

There was no larger product idea at first. It was a design problem. I worked closely with an AI agent, gave it very specific visual instructions, reviewed what it produced, and kept iterating until the page felt right.

It started as a clone

Making Software gave me the basic reference: dense editorial layouts, blue technical drawings, grid paper, numbered figures, and explanations that treat diagrams as part of the writing.

I did not begin by trying to invent another educational platform. I wanted to understand how that visual system worked by rebuilding something similar. The clone was the exercise.

The Making Software website by Dan Hollick with blue technical diagrams and editorial columns
Making Software by Dan Hollick was the design reference for the original clone.
The Understanding Software field guide with blue technical diagrams of software layers
My version began as an attempt to rebuild the same technical field-guide feeling.

The design was the hardest part

The design is still the part I am most proud of. Getting the page to feel technical without becoming unreadable took a lot of iteration. The typography, spacing, diagrams, borders, labels, and small annotations all had to work together.

My agent wrote much of the implementation, but it was not a one-prompt build. I directed the work, pointed out what felt wrong, and asked for specific changes. We kept going back and forth until the page matched the idea in my head. A lot of designers I know have seen or used the landing page, and the design is usually what they respond to first.

Making Software diagrams explaining Gaussian blur, Bezier curves, and rasterisation
The reference mixes dense prose with diagrams that carry part of the explanation. Screenshot from Making Software by Dan Hollick.

How I worked with the agent on the original clone

Reference
Making SoftwareLayout, typography, diagrams, and annotations
Direction
Specific instructionsWhat to reproduce and what felt wrong
Visual reviewSpacing, hierarchy, labels, and density
Agent work
Page implementationNext.js, React, and CSS
Technical diagramsCustom SVG figures and annotations
Iteration
Compare and correctRepeat until the page matched the intended feeling
The agent produced much of the code. I directed the visual decisions and the repeated corrections.

Then the clone became a product idea

While building the clone, I realized the format could explain more than one fixed set of topics. That became the Artifact Studio. A reader asks a software question. The agent plans a field guide with two to eight sections, decides whether diagrams would help, writes the sections, generates the figures, and assembles everything into one live document.

Revisions preserve sections and figures that still work instead of rebuilding the entire guide. Three section writers and two figure jobs can run at the same time. The finished artifact can be copied or downloaded as Markdown or an editable Word document.

The exports are useful if someone wants to keep or change the guide. They are also a marketing experiment for my Markdown-to-Docx package. This is not a startup or a finished educational product. It is a weekend project I made for my own satisfaction.

From one question to a finished field guide

01Ask

The reader brings a software question.

02Plan

The agent defines the sections and useful figures.

03Write and draw

Section writers and figure jobs run together.

04Stream

The document assembles while the work finishes.

05Review

The reader inspects the prose, structure, and diagrams.

06Revise

Useful sections and figures keep their stable IDs.

07Export

Copy it or download Markdown or DOCX.

The studio keeps the document visible instead of hiding the work behind a loading screen.
reader actionstudio mechanism
ask a question
Structured artifact planTwo to eight sections and up to four figures
approve the plan
Parallel generationThree section writers and two figure jobs
watch the document
Streamed artifact stateSections appear while other jobs continue
request a revision
Stable section and figure IDsUnaffected work does not regenerate
finish
Copy, Markdown, or DOCXThe document can leave the site
The studio keeps the document structure visible while the work runs.
DOCX exportroute.ts
const buffer = await convertMarkdownToArrayBuffer(markdown, {
  documentType: "document",
  imageHandling: {
    dataUrls: { enabled: true },
    maxImageBytes: 10_485_760
  }
});

npm run dev

The final artifact can leave the site as an editable Word document.