Saying it was easy. Once I actually had to work this way every day, the questions got concrete: AI writes code fast — but where does information come from? Who decides on the design? How is the output verified? What is a human still in charge of? After running this way for a year, my understanding has gone through several rounds of change; my focus slowly shifted from “writing code fast” to the whole chain of information, development, delivery, and toolchain.

This post describes how I currently work (as of the end of August): how I process information, how I write code, how I put the toolchain together, and the judgments I’ve formed after running this way for the better part of a year.

My background is Infra, Kubernetes, and PaaS; my main language lately is Go. Everything below comes from my own practice, not a survey of methodologies. This is not an operations manual for any particular product or team process, and I’m not going to argue that AI can replace the humans who make decisions.

AI Native × Work

How my understanding evolved:

• February: Code Typing is unnecessary — the thrill of writing code fast, typing away until 2 a.m. every day
• May: AI amplifies execution; humans own judgment — from 2–3 agents in parallel to 7–8 agents in parallel
• August: information, development, delivery, toolchain

What exactly is our work, in form and in substance?

Problem analysis → Solution design → Product building → Launch & operations → Feedback reinforcement

The core carrier: the artifact.

Why is “translation-style” work the easiest to replace? Because an artifact is more static, more structured, and occupies a smaller semantic space. The complexity of software engineering is what makes this chain relatively long.

Documents, code, meetings, reports — these are just different forms of work.

The work itself:

1. Organizing, structuring, refining, and developing information; shaping proposals that others can understand and accept.
2. Turning proposals into products: writing code, verifying, shipping, running.
3. The hidden line: improving the toolchain to raise efficiency.

Summary: the forms — documents, code, meetings, reports — will change; the work itself is still these three lines. The rest of this post, on information, AI coding, and toolchain, basically follows these three lines.

What Does AI Native Add?

We keep talking about AI Native. What is it, really?

My understanding: putting the reasoning power of AIGC into every aspect of work.

• Decision-making
• Content production
• Artifact production
• And the environment and platform that support this way of working

Not a point tool. A way of working.

Real-world information and task goals enter the AI workspace; after analysis, generation, and checking, they hand over to a human for judgment on priority, boundaries, trade-offs, and responsibility; then shippable, acceptable artifacts come out. Artifacts generate feedback and new goals, and the loop returns to the start.

Summary: AI has entered every step of analysis, generation, and checking, so the loop spins faster. But the human judgment in the middle hasn’t been removed — precisely because the loop spins faster, it binds tighter. This is exactly the May insight: AI amplifies execution; humans own judgment.

How I Process Information Today

From Information to Insight

Image via the web

Data has no value on its own; connected, it becomes knowledge; connected correctly, it becomes insight. The goal of information processing is not to store material away, but to keep it workable — ready for further processing.

My Workflow

Every day I open 10+ PRs against my own knowledge repositories.

Local writing, meetings, all kinds of documents, IM messages — everything flows into the agent. The agent opens a worktree, edits files, commits, pushes a branch, opens a PR. I do exactly one thing: read the diff and decide whether to merge.

I keep two knowledge repositories locally, one new and one old, with two different ways of working:

The minds Repository

minds manages the information produced through AI collaboration: the material is messy and needs repeated processing. Most of my recent posts were finished here. I manage this repository with mind-forge, which I wrote myself.

GitHub - alswl/mind-forge: Forge minds into articles.

One repository holds several projects, and each project has four zones:

• sources/ — the input zone, read-only; raw material is never modified once it lands
• docs/ — the article zone; long posts are split into section fragments named NN-title.md, each iterable on its own
• outputs/ — build artifacts generated by mf build, never hand-edited
• prompts/ and thinking/ record goals, constraints, and reasoning

The point of this structure: material, work-in-progress, and published output stay separated. Agents can touch docs/ without polluting sources/; when I review, I read the diff of docs/.

At the repository root there are a few more things: a CLAUDE.md stating collaboration principles and red lines, a glossary that standardizes proper nouns and dictation corrections, and a set of skills that take over repetitive actions. Conventions live in the repository, not in conversations we re-explain every time.

The repository root also uses minds.yaml to register projects; shared information is managed through the glossary and cross-project thinking, while articles, sources, and configuration are maintained inside each project.

The my-kms Knowledge Base

my-kms is the personal knowledge base I’ve kept for years. The product has changed several generations (back in 2010 I wrote My Knowledge Management System); later it settled on Obsidian (task management moved in with it, see From Toodledo to Obsidian Tasks). Content is still entered mostly by hand — at minimum dictated by me. Only a small number of meeting summaries are handed to AI for entry.

My daily information flow:

Meeting transcripts → summaries → daily notes → daily report → proposals, posts, and talks

Every meeting produces a transcript and a summary; every day closes into a daily report. Material doesn’t stay in chat windows — it lands in a repository where it can be revisited, searched, and processed further.

Both repositories are hosted on a self-hosted Forgejo running on my own machine. The benefit is concrete: private data never leaves the machine, yet I still get branches, PRs, diffs, and history — meaning every change an agent makes is reviewable and revertible.

How I Keep the Human Touch

Both quality and efficiency improve. More importantly, my own viewpoints survive in the content.

Here’s a conversation with a colleague from operations about my writing output:

“I can’t see any trace of AI in it at all.”

“It’s all AI-generated.”

“Wait, you hand-craft it?” “Whoa — man, could you share how?” “How can AI write something this alive and this professional?” “Forever in your debt.”

“I write the framework, AI generates. Plus I leave a lot of annotation feedback — like a professor marking a student’s paper. I write the framework, AI generates, then I give plenty of margin notes. The human touch doesn’t come from AI imitating a human; it’s there because the framework and the opinions were mine to begin with.”

Summary

My information practices boil down to three rules:

1. Material goes into the repository, not chat windows;
2. Agents do the carrying and the processing; changes go through PRs, and I decide by reading the diff;
3. Framework and opinions come from me; AI does the expansion and the polish.

AI involvement is 90%+ in one repository and 5% in the other — a big gap — but in both, the material ends up in a repository that can be revisited and reviewed.

How I Do AI Coding Today

Compared with before, three changes stand out.

1. Spec-Driven: From Personal Choice to Team Requirement

Specification, boundaries, acceptance criteria: the starting point of development.

It’s now mandatory: use speckit, superpowers, or any well-known spec framework. What used to be a personal choice became a team requirement — the most visible change this year.

2. Line-Level Code: Less and Less Eyes-On, But Not Ignorable

In systems with a stable structure, people genuinely pay less and less attention to detailed code. The code-review experience and knowledge accumulated over the years, ironically, needs to keep being distilled into constraints.

I keep these constraints in a single set of guides, pinning down “what to look at, what to skip, and when you must look”:

GitHub - alswl/guides

The public version is v0.0.1-alpha1, with these guides so far:

Each guide picks exactly one stack and fixes one project structure; rules are written as imperatives. They are written for both humans and AI coding tools, so every rule must be short and checkable — no “it depends”. Usage is simple: reference the corresponding file in the project’s CLAUDE.md / AGENTS.md and let the agent follow it while writing code. I wrote a separate post about the story behind the frontend one: How to Organize High-Density Pages.

3. Self-Testing Agent Verification

AI coding makes delivery density explode. Testing resources can hardly expand at the same pace.

My answer is a self-testing agent whose core pipeline is:

Specification → Layered verification → Verdict → Write-back to acceptance

The specification is both the starting point of development and the source of assertions. Verification is layered from cheapest to most expensive, fail-fast:

The last step is verdict and write-back: instead of dumping a pile of logs, it produces a conclusion backed by run evidence and writes it back into the work item’s acceptance criteria.

Summary

Seen together, the three changes form one line: specifications set the starting point, constraints watch the details on your behalf, and layered verification delivers verdicts. Less and less code needs a human watching line by line; what to build, what to build it by, and what counts as done, on the other hand, need to be written down more clearly than ever.

My Personal Toolchain

Engineers fundamentally strengthen their management, work efficiency, and output speed through better tools. In this era, tools genuinely matter more than they used to.

I’ve invested quite a bit of time building my own toolchain. The ones I’m happy with so far:

• mind-forge (knowledge base manager)
• a skills collection
• skm, a manager that keeps SKILLs in sync across machines and deploys them quickly to remote hosts
• a review editor that works for me (I chose Vim)

GitHub - alswl/skm: a tiny local-first AI Skill Manager

The skills I use most, some from the community:

• speckit — the spec-based suite
• grilling — interrogates me
• humanizer — makes me sound human

Some I wrote myself:

• spec-report-html — turns the current spec into a one-page report
• spec-status / spec-update — update spec status
• session-retro — reflects on the current session to improve local SKILLs
• chat — IRC-based agent collaboration
• distill-memory — distills local jsonl memory
• repo-analyzer — quick repository analysis, similar to deepwiki
• mf-cli — the companion SKILL for mind-forge

Earlier I said work itself has three lines, and the third is the “hidden line”: improving the toolchain to raise efficiency. This list is my investment on that line.

Some Opinions

Efficiency Gains Will Hit a Bottleneck Soon

• Execution density is rising
• Decision density: the new bottleneck
• Information, judgment, consensus: cannot be skipped

AI’s WoW Time Is Passing

• New concepts: short-lived excitement
• Lasting value: how to land it
• Real business, real systems, real users — you have to fight for real

Meetings Matter More

• AI accelerates output
• Disagreements surface faster
• Building consensus: higher value than ever
• Decisions, commitments, responsibility: these need humans

Creation = “Originate” + “Produce”

• AI excels at “producing”: generating, expanding, polishing
• Humans own “originating”: questions, judgment, expression
• People will tire of purely AI-generated content
• Keep your opinions, experience, and personal edges

Closing Notes

From February’s “Code Typing is unnecessary”, to May’s “AI amplifies execution; humans own judgment”, to August’s connecting information, development, delivery, and toolchain into one line — what kept changing over these months was my understanding of where the human stands.

AI excels at “producing”: generating, expanding, polishing. The “originating” is still yours: raise the questions, make the calls, and keep your own opinions, experience, and edges.

Update 2026-10-05: due to scheduling conflicts, my internal talk was postponed by a month, so this post came out a month late too. Agentic development moves fast — my latest practice has already moved a step beyond this article, touching the threshold of Stage 8. That said, I still recommend engineers walk through the stages one by one; in times changing this fast, experiencing it hands-on is a completely different feeling.

Wait for my next post.

Further Reading

• alswl/mind-forge: the knowledge-forging CLI behind the minds repository
• alswl/skm: a tiny tool for managing SKILLs across machines
• alswl/guides: development guides written for humans and agents to read together
• github/spec-kit, obra/superpowers: the two spec frameworks mentioned above
• 2025 Year in Review — At the Tipping Point
• How to Organize High-Density Pages: A Guide to Presenting Information
• From Toodledo to Obsidian Tasks — My GTD Best Practices
• My Knowledge Management System

Recently I started building the frontend for an infrastructure project myself. AI can put a page together in no time — CRUD, filters, status badges, nothing missing — and at first glance it even looks the part.

But once you actually use it, the awkward parts show up: the page is full of information, yet you don’t know what to look at first; related resources, context, and status are scattered everywhere; and figuring out what to do next is on you, pieced together from a pile of fields.

The components weren’t the wrong choice. The problem was that I treated it as a CRUD page from the start: list the fields first, then bolt on filters and actions, and only at the end realize the user still doesn’t know where to begin. The data was all there, but the page never helped the user order understanding and action.

Later I organized the judgments I would make myself into a page-organization guide. Tables, kanban boards, calendars — the basic ways of organizing information — I collectively call “expression skeletons” in the guide.

When Everyone Starts Writing Product Pages

My work has always been backend-heavy. I’m interested in frontend and other technologies and experiment with them now and then, but what I actually put my hours into was the backend. Recently the team’s frontend capacity shrank, and I started owning frontend projects myself.

This time I didn’t set out to design a component spec from scratch; I chose Ant Design plus Ant Design Pro as the foundation. The reason is practical: the tables, forms, layouts, navigation, and descriptive details common in enterprise backends all have fairly mature off-the-shelf solutions, and it’s easy to keep page shells and component behavior consistent. With the basics handed to the component library, I can spend my time on how information is organized and what users see first.

That spec doesn’t make decisions for the page. It just fixes the starting point of implementation so that every page doesn’t reopen the discussion of colors, spacing, and component styles. What still needs judgment is which object the page centers on, and what users intend to do with the information.

This brought me back to an old problem: code written doesn’t mean the page is designed. The gap is especially visible when AI writes the frontend. It can supply components, styles, and interactions, but it doesn’t know what a user should understand first upon arriving, what to judge, or what to do next.

I wanted to pull out my solutions and judgments in this area so the rest of the team could use them too. A page “looking off” is usually just a feeling; only when you can say concretely that the primary information doesn’t hold up, related information is scattered, or actions are misplaced can you discuss it together — or hand it to AI to fix.

This page-organization guide is one part of that. It’s my own checklist when writing frontend, and I hope it becomes a shared set of judgment criteria for the team when applying AI to frontend projects.

How to Organize the Information Architecture

When I look at a high-density page, I usually don’t go hunting for components first. Get the three questions below clear, and everything after becomes much easier.

1. What matters most for the user to see when they open the page?
2. To understand that primary information, which related resources, models, and context also need to be visible?
3. After reading, what reaction or action should the user take, or what should they keep thinking about?

mindmap
  root((Page information architecture))
    Primary info[Primary info]
      What the user sees first(What the user sees first)
    Related info[Related info]
      Resources(Resources)
      Models(Models)
      Context(Context)
    User actions[User actions]
      Judgment(Judgment)
      Operations(Operations)
      Next step(Next step)

Walking through these three questions first at least tells me what the user is here to do. Once that’s clear, coming back to table vs. kanban vs. calendar rarely goes far wrong.

The current demo is built with Ant Design. The judgment itself has nothing to do with the component library; on another stack, the concrete components need adapting to the project.

From List and Detail Toward Richer Ways of Organizing Information

CRUD is great at data operations, and list and detail pages remain useful. They mainly answer “how do I create, read, update, delete this record”, though — not what the user should look at first after arriving, what feedback they need, or which information a decision should rest on.

The API only hands over data and operations; the page still has to lay out the relationships between them: what the user looks at first, what they compare next, and where they finally act.

A Worked Example: GitHub Projects’ Information Layout

GitHub Projects’ layout documentation makes a great comparison. The same project item can go into a table, a board, or a timeline-style roadmap. The data hasn’t changed; the way the user reads it has.

Take a batch of pending dev tasks and hold them against these layouts, and each of the three views pulls attention somewhere different:

When planning the next round of work, I put priority and owner in fixed columns, sort, then read down the rows for the split of work. With cards, the same field no longer sits in a stable spot, and comparing means hunting back and forth. The value of a table here is simple: comparison happens in a fixed place.

When tracking progress, I care about “what’s still in progress”. Laying tasks into columns by status — find the stage first, then the items inside it — matches that motion. If you can drag a card to advance its status, the page’s layout and the operation click together too.

When scheduling delivery, knowing “in progress” isn’t enough. Put start and end dates on a timeline and overlaps between work items show up immediately. Whether they genuinely can’t be staffed still comes back to owners and workload.

A backend page doesn’t need all three views. If the page mainly serves one task, get that one right first; add a view only when there really are multiple high-frequency uses. Every extra view adds maintenance cost to filters, statuses, and actions.

Notion’s database views are a similar example. When preparing to publish a batch of content, switch to gallery to pick covers, switch to calendar to check publish dates. The calendar shows me the distribution of dates, but it won’t tell me on its own whether resources conflict; answering that needs time ranges and resource occupancy.

I also watch how other products handle similar problems. What strikes me most about GitHub is that it always unfolds around one core object, in no rush to cram everything in. Twitter is more like taking the same object and handling it in different contexts. Taobao faces enormous data volume, yet products and trading actions always stay prominent. Douban has many data types, yet each of its pages has its own organization. You can’t copy their styles directly, but when I look at these pages, I pay attention to what the user is actually there to do.

So now I first state clearly what the page is for: when users arrive, what exactly should they understand, compare, or advance? That finds direction more reliably than starting from “build a modern admin”.

How to Choose the Right Information Structure

Section 2.2 of the guide draws this selection process as a complete path: first see what objects and relationships exist in the system, then what the user needs to accomplish, then judge the inherent structure of the information, and only then land on a concrete form of expression.

flowchart TD
    A[Confirm the user, trigger scenario, and success outcome] --> B{Does it need a standalone page?}
    B -->|No independent address, permission, or ongoing task| B1[Fold into an existing page or task flow]
    B -->|Needs sharing, recovery, wide space, or independent permissions| C[Determine the single primary task]
    B1 --> C
    C --> D{Primary task intent}
    D -->|Find, locate| D1[Collection / hierarchy / space]
    D -->|Understand, judge| D2[Single object / relationship / document]
    D -->|Compare, analyze| D3[Collection / diff / metrics]
    D -->|Advance, process| D4[Queue / process state / config rules]
    D -->|Trace, collaborate| D5[Event sequence / discussion & collaboration]
    D1 --> E[Choose one primary information model]
    D2 --> E
    D3 --> E
    D4 --> E
    D5 --> E
    E --> F{Expression that directly answers the primary question}
    F -->|Field-by-field comparison| F1[Table]
    F -->|Identify and enter a resource| F2[List / resource catalog]
    F -->|Image is the recognition anchor| F2B[Card grid]
    F -->|Parent-child or path| F3[Tree / tree table]
    F -->|Dependency or impact| F4[Adjacency list / relationship graph]
    F -->|Object identity and current state| F5[Object summary / sectioned detail]
    F -->|Stage and next step| F6[Steps / status workspace]
    F -->|Stage flow, moving is the action| F6B[Kanban / swimlanes]
    F -->|What already happened| F7[Timeline / activity feed / log]
    F -->|Who said what and how it was answered| F7A[Discussion thread / review thread]
    F -->|What changed, before vs after| F7B[Diff view]
    F -->|Trend, distribution, or anomaly| F8[Metrics / chart / analytics drill-down]
    F -->|Location, boundary, or spatial distribution| F8A[Map / spatial canvas]
    F -->|When is it occupied, when does it conflict| F8B[Calendar / scheduling]
    F -->|Policy and constraints| F9[Grouped form / rule table / matrix]
    F -->|Continuous reading and section navigation| F10[Document body / table of contents]
    F -->|What to work on next| F11[Queue / inbox]
    F1 --> G{How to maintain task context?}
    F2 --> G
    F2B --> G
    F3 --> G
    F4 --> G
    F5 --> G
    F6 --> G
    F6B --> G
    F7 --> G
    F7A --> G
    F7B --> G
    F8 --> G
    F8A --> G
    F8B --> G
    F9 --> G
    F10 --> G
    F11 --> G
    G -->|Repeatedly switching objects or evidence| G1[Master-detail split / workbench]
    G -->|Supporting content is light and transient| G2[Expandable section / Drawer]
    G -->|Content is shareable or needs wide space| G3[Standalone page]
    G -->|Short confirmation or minimal input| G4[Modal / Popconfirm]
    G1 --> H[Add the necessary supporting models to form the page type and skeleton]
    G2 --> H
    G3 --> H
    G4 --> H

Don’t build a table just because the API returned an array, and don’t default to a detail page just because there’s an ID in the route. The same object may need a list when users are searching, a status flow when they’re processing, and a discussion thread when they’re collaborating.

The full decision tree in the guide keeps probing the primary task and primary question. Field-by-field comparison suits a table; when images are the recognition anchor, a card grid works; stage transitions suit a kanban; only time occupancy and conflicts call for a calendar. A record having a date only means the data contains a date — it doesn’t by itself decide which structure the page should use.

After choosing, I walk through the real operations once more: is the most-compared information placed together, is the most common action right there beside it. If the user still has to reopen details repeatedly, memorize the previous record and come back to compare, the structure and field arrangement probably need another look.

When List and Detail Aren’t the Answer: Cards, Kanban, Calendars, Dashboards, and More

The demo turns these judgments into several sets of pages you can open directly. When looking at a page, I mainly ask: if the user needs to recognize by image, advance status, schedule time, or spot anomalies, which information should appear first?

The demo code lives in the fe-page-guide-antd-demo directory of the alswl/guides repository. It’s a runnable companion project: built with Vite + React 18 + TypeScript, page fundamentals handled by Refine, UI in Ant Design v5 and Ant Design Pro’s ProComponents. The data is in-memory mocks; each of the 19 expression skeletons maps to one route, so opening it shows exactly what each page looks like.

These pages share one stack, which makes it easier to see in comparison that the differences come from how information is arranged, not from a swapped component library.

Card Grid: When Recognizing the Object Comes First

When picking assets or templates, users usually look at the thumbnail first to confirm it’s what they’re after. Images should be the main entry at moments like this. If fields like price and specs also need comparing, a table may be less effort.

With templates, I usually recognize the layout first, then read the name. Shrinking the preview into a tiny image on the far left of a table squeezes out exactly what matters for recognition. Cards put the preview in a prominent spot with the name and other fields arranged around it. If every choice requires checking a pile of parameters, big images alone won’t carry it.

Kanban: Making Stages Visible at a Glance

What matters most in a kanban is what the columns mean and how cards move between them. Users read the distribution of stages first, then decide how to advance. If you’re just filtering tasks by owner, a list is already enough — no need to force it into a board.

Column names like “To do, In progress, Done” express progress through position itself. Keeping identifying information — title, owner — on the card is enough. If a column is just a filter with another name, users will find it tiring to read and not necessarily faster to operate.

Calendar and Scheduling: Spreading Time Occupancy Out

Calendars suit things genuinely about time occupancy — shift scheduling, meeting room booking. If you only want to know whether an approval was submitted or approved first, a timeline is more direct.

When booking a meeting room, the user needs to know immediately whether a slot is taken — start and end times can’t hide in a detail page. Approval records are different: the point is event order, and a timeline laid out chronologically is enough.

Dashboard: Organizing Metrics by Question

Dashboards most easily become a pile of equal-sized cards. What should be seen first is how the metrics relate to each other, and the order in which users go from overview into detail.

If every metric sits in an identical card, users still have to guess which ones belong together. I group by question first: which numbers detect anomalies, which trends explain changes, where the drill-down entry belongs. Plenty of information doesn’t mean every block should fight for attention.

Hierarchy Tree: Preserving Where Objects Belong

Trees fit information where “I need to know what it belongs to”. Org structures and category directories need parent-child relationships preserved; if users often search across levels, add a list or a search box.

When drilling down through a directory, a tree preserves the sense of “which level am I on”. When the name is known and the goal is quick location, search is faster. Both entries can coexist — don’t make users expand the whole tree level by level to find an item they already know.

Status Wall: Spot the Anomaly First, Details Second

A status wall first answers a very practical question: where exactly is the anomaly. A monitoring page can be dense, but colors, decoration, and status markers must not fight each other.

The user locates the object that needs attention, then digs in for the cause. Object names and statuses must be easy to tell apart; detailed logs can wait for the next step. Color does help scanning, but pair it with text or other markers, otherwise users will struggle to say precisely what they’re looking at.

Reference Table: Nineteen Ways to Present Information

Here are the remaining pages side by side; click any image to open the full-size original.

Expression skeleton	Expression skeleton
Sectioned detail	Two-way comparison table
Catalog & discovery	Card grid
Hierarchy tree	Relations list
Step wizard	Trace drill-down
Kanban	Status wall
Event timeline	Discussion thread
Continuous document	Side-by-side compare
Map & canvas	Calendar scheduling
Dashboard	Master-detail workbench
Config form

Handing the Guide Directly to an Agent

The guide can go straight into a project repository as a reference when AI reviews frontend pages. The human starts from the business — think through what users are here to accomplish — then decides the information structure and expression skeleton; AI builds on those judgments to fill in proposals, find inconsistencies, and make the changes.

You can hand the following directly to an agent:

Page organization guide URL:

https://github.com/alswl/guides/blob/master/fe-page-guide-antd.md

First read the page organization guide and inspect the current project’s directory structure. Following the project’s existing documentation conventions, copy the guide to an appropriate location; if there’s no better directory, put it at docs/fe-page-guide-antd.md. After copying, tell me the actual saved path — don’t just treat the remote URL as a reference.

Review the current project’s task management page. This page is mainly used to compare task priority and owner, while also showing the stage each task is in.

Combining the requirements, the page source, and the actual page, produce a review of the information architecture and page expression along with improvement suggestions: list the primary information, related information, and the actions the user needs to complete; state whether the current expression skeleton fits, what the concrete problems are, which parts of the guide they violate, and what page structure you recommend. Flag any business intent that can’t be determined from the available material.

Send me the review findings and the improvement plan first, and wait for my confirmation before changing the page. Preserve existing business functionality, permissions, and data interactions, and keep the project’s component library. After the changes, run the project’s existing checks, verify field comparison, status transitions, and similar operations in the page, and provide before/after screenshots plus any issues that still need human judgment.

Swap in your own business for the page and task descriptions. AI can list candidate options, but the main skeleton and the order of information can’t rest on its output alone — the business starting point must be set by a human.

Review reports must land on specifics. Saying only “the information hierarchy is unclear” isn’t much use; state which information belongs together, where it’s currently scattered, and how you plan to fix it. Only then can you tell whether AI solved the real problem.

Putting the guide in the repository only gives AI a reference. You also need to tell it the page entry point and the main task. If AI can only see the source, do a source-level review first; once the page runs, add screenshots and real interaction verification.

At acceptance, I still walk the real task end to end: is information easier to find, is the next action clearer, do the original filters, permissions, and data interactions still work.

The guide and demo repository holds the complete rules and examples. As for whether a page is actually good to use — that still takes a real pass through the concrete business.