AI can produce the document. Who helps you review it?

AI can now produce a business case, an architecture proposal, an implementation plan or a technical report in minutes. That part is becoming ordinary.

The harder question arrives immediately afterwards: how does a person review the work properly?

Most teams still rely on a weak feedback loop. The agent produces a long Markdown response, a document or a screenshot. A reviewer then writes comments such as "change the diagram in the middle", "this section does not reflect our environment" or "move the security controls closer to the data layer". The agent has to infer which element the reviewer means, what context applies and whether the change affects the rest of the artifact.

That is manageable for a short note. It becomes expensive when the output is an architecture assessment, an audit report, an operating model, a proposal, a transformation roadmap or an interactive technical plan. The reviewer spends their energy describing where the problem is instead of what is wrong with it, and the agent spends its next attempt guessing.

CloudNala's position is simple. The quality of AI-assisted work will be decided less by how fast the first draft appears and more by the quality of the review loop around it. This series, Evidence Before Autonomy, is about that loop: how people inspect, challenge, evidence and approve work that machines now produce cheaply.

Silverleaf Brokers is fictional, and its systems and figures are illustrative. It is a Durban short-term insurance broker whose advisers use an AI assistant to draft client review packs: a summary of cover, a comparison of renewal options, risk notes and a recommendation. A pack used to take an adviser most of a morning. A draft now takes a few minutes. The new bottleneck is the senior adviser who has to check each one before it goes to a client.

The generation problem is being replaced by a review problem

For most of the software era, producing a polished artifact was expensive. A report needed writing, formatting and design. A prototype needed a designer and a developer. An architecture diagram needed a specialist tool and careful manual layout.

Generative AI has compressed that production effort. An agent can combine narrative, diagrams, tables, code examples and interactive controls in a single HTML file, and revise the whole thing repeatedly without anyone rebuilding the visual elements by hand.

That shifts the bottleneck to the human ability to:

• understand what the agent produced;
• identify exactly what is wrong or incomplete;
• trace claims back to evidence;
• assess the implications of a proposed change;
• communicate feedback without ambiguity; and
• verify that the revision fixed the issue without creating another one.

This is familiar territory in engineering. Code has pull requests, line-level comments, automated tests and version history. Design tools support comments pinned to specific frames. Documents have tracked changes. AI-generated artifacts need a comparable review model, and most teams have not built one.

At Silverleaf the symptom was obvious within a month. The senior adviser's comments came back as paragraphs: "the second table is wrong for the commercial clients", "the excess you quote does not match what we agreed", "the recommendation should mention the motor fleet". Each comment cost the agent another full regeneration, and each regeneration risked changing something that had already been checked.

Why HTML works as a review format

Markdown remains valuable. It is readable, portable, easy to version and well suited to structured text. CloudNala uses it extensively as the durable working format for analysis, architecture decisions, audit evidence and handover packs, and agents read it well.

Markdown becomes constraining when the reader needs more than a document. HTML can combine structured narrative, responsive layout, diagrams, collapsible detail, tables with filters, evidence panels, calculators, scenario comparisons and links between findings, risks, decisions and recommendations. The browser already knows how to render all of it, on any operating system, without a proprietary editor.

So HTML has a useful role between source material and final publication. It is not a replacement for either.

"HTML is the new Markdown" is a deliberately provocative line. The more useful reading is narrower: HTML is becoming the review and interaction layer for work that is too visual or dynamic for plain text, while Markdown stays the source and PDF stays the record.

What Lavish changes in the loop

Lavish is an MIT-licensed open-source project that takes exactly this view. Its own tagline is "HTML is the new markdown", and it describes itself as an editor for the HTML artifacts that agents generate. We checked the repository on 27 October 2026; what follows reflects it on that date, and the project is moving quickly.

In practice it works like this:

• An agent (or a person) runs the command-line tool through npx, pointing it at an HTML file. It opens the file in a local browser interface and keeps session state on the reviewer's own machine.
• The reviewer can annotate specific elements or selected text ranges and send messages to the agent from inside the page.
• The agent picks up queued feedback by polling for it, and replies. Notes show simple delivery states, so the reviewer can see whether the agent has seen the comment, is working on it or has finished.
• Mermaid diagrams can, when the user asks for it, be opened as editable whiteboards. Flowcharts, sequence, class, entity-relationship and state diagrams become shapes the reviewer can move and change; other diagram types become images that can be drawn on.
• The tool also flags detected layout problems in a separate inbox, and those only reach the agent when the reviewer chooses to queue a fix.
• It ships as an agent skill and can be wired into several coding agents, including Claude Code, Codex and GitHub Copilot's command-line tool.

The most valuable feature is not visual polish. It is feedback precision. With an element-aware review surface, the reviewer points at the actual item, and the agent receives the selected content with its context. The distance between the reviewer's concern and the agent's next action gets much shorter.

Editable diagrams matter more than they first appear to. Architecture conversations often fail because the diagram is treated as a finished picture. If a reviewer can drag the security boundary to where it belongs and hand that back, the diagram becomes part of the conversation instead of decoration added at the end.

The same principle applies to reports. A reviewer should be able to challenge one claim, ask for its evidence, flag an assumption, change the priority of a risk or request an alternative recommendation without rewriting the whole instruction.

The human remains accountable throughout. The interface simply makes the review more specific, and that alone removes a surprising amount of wasted regeneration.

Where this could help

Architecture reviews. A target architecture can carry expandable decision records, technology options, security boundaries, cost assumptions and dependencies. Stakeholders comment on the element they understand rather than trying to interpret one dense diagram.

Technology audits. Findings can link to evidence, risk ratings, affected systems, owners and proposed remediation. Reviewers challenge a finding in context, and the final report is still issued as a controlled PDF.

Cloud cost and solution estimates. An interactive artifact can show how workload assumptions, architecture choices, effort and consumption combine, so a decision-maker sees why the number moves, not only the final total.

Proposals and statements of work. Scope, exclusions, assumptions, deliverables and acceptance criteria can be reviewed as connected elements, which helps with the familiar problem where one paragraph changes and the pricing, plan and responsibilities do not.

Workshops. An HTML artifact can be the shared working surface during a discovery session, with decisions and open questions captured against the relevant section instead of reconstructed from notes afterwards.

At Silverleaf, the first useful change was modest. The assistant produced each review pack as HTML, the senior adviser pinned comments to the specific table row or sentence, and the agent revised only the affected element. Regeneration of already-checked sections stopped.

A better interface does not make the content correct

An attractive HTML report can still contain unsupported claims, missing risks, weak architecture or invented evidence. The ease of producing polished artifacts creates a specific danger: presentation quality gets mistaken for analytical quality. Part 2 is about exactly that.

Any serious use of this model needs controls around the artifact.

Evidence. Material claims should identify their source, and reviewers need to tell verified facts, assumptions, recommendations and open questions apart. A polished page must never make an uncertain conclusion look settled.

Versioning. The artifact, its sources and the resulting decisions need to be versioned together. A comment on an earlier version must not silently apply to a later one whose assumptions have changed. Part 3 covers this in detail.

Security. Local-first is useful, but local does not automatically mean safe. Running a tool through npx fetches and executes a package at that moment, which is a software supply-chain decision, not a convenience. An organisation adopting it should pin an approved version, review the package and its dependencies, and run it in a controlled environment. Note, too, that at the time of writing the tool sends basic usage telemetry by default when run through npx (the command, version and platform), and documents an environment variable to turn it off. Read what a tool sends before it touches client material.

Data classification. Lavish keeps its core loop on the local machine, but it also offers an explicit share command that publishes a page to a third-party host, public by default unless a password option is used. The documentation notes a password cannot be removed afterwards and that there is no delete endpoint, only an unpublish placeholder. That is reasonable for public explainers and unacceptable for a client's risk register. Hosted sharing should require a deliberate decision under your classification rules, never become the convenient default. Our article on what may enter which AI service sets out a simple way to decide.

Approval. A reviewer's comment is not approval. The workflow needs a named decision-maker, a clear status and a record of exactly which version was approved.

Accessibility and portability. Important information should not exist only inside an interaction that disappears on export. Exported pages from the tool inline local assets but keep links to any remote fonts and libraries, so a reader on a locked-down device may not see what the reviewer saw.

Long-term readability. HTML, CSS and JavaScript dependencies change. Records that must last need a durable form, which is another reason to keep a structured source and issue a PDF when formal retention is required.

A practical pilot

The sensible next step is a controlled pilot, not adoption across every engagement. Choose a non-confidential artifact, such as an architecture explainer or a sanitised audit report, and run the whole workflow:

1. Produce the evidence-based analysis in Markdown.
2. Generate a self-contained HTML report from it.
3. Open it locally for review, with telemetry and sharing settings decided in advance.
4. Review the narrative, tables and diagrams.
5. Capture element-level feedback.
6. Revise the artifact and confirm each comment is resolved.
7. Export the approved version to PDF with its version identifier.
8. Record time taken, review cycles, defects found and how reviewers found it.

The pilot should answer practical questions. Does element-level feedback reduce ambiguity? Do reviewers engage more deeply? Are diagram edits useful to non-technical stakeholders? Does the process preserve evidence and version history? Is the exported version accessible? What information must never enter the tool? How are comments, decisions and approvals retained?

If the answers are positive, a tool like this becomes one component in a broader artifact workflow, alongside Markdown sources, source control, evidence registers, automated checks and document generation. It does not replace any of them.

The broader lesson

The next stage of enterprise AI will not be won by the organisation that produces the most content. It will be won by organisations that can inspect AI-generated work, challenge it, connect it to evidence, make decisions and keep accountability, without slowing every task back down to a fully manual process.

Lavish is interesting because it works on that overlooked part of the system. It treats the human review loop as something that can be designed and improved. That is the right instinct, and it is the thread through the rest of this series: what makes an output trustworthy, how review becomes a record, what an audit of an AI system should examine, and how a secure reference architecture keeps humans in the decisions that matter.

AI can generate the artifact. The real work is establishing whether the artifact deserves to be trusted.

Next: Part 2, A polished AI output can still be wrong. All parts are on the series page. For how CloudNala treats prompts and outputs as part of the record, see The prompt is part of the evidence.

How CloudNala can help

We help teams design the review loop around AI-assisted work: which formats carry which job, how comments and approvals are recorded against versions, what evidence each claim must carry, and which tools may touch which classes of data. We can run a short pilot on a non-confidential artifact with your reviewers and give you an honest view of whether the workflow earns a wider rollout.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Assurance Review or write to us at consult@cloudnala.co.za