Building the product
AI made the website fast. It did not make the story true.
The first homepage compiled, navigated, and looked like a portfolio. It also described almost nobody in particular. The fix was a context and evidence system—not another round of prompting.
7 min read
The first homepage introduced me as a “founder-minded product leader” and promised a journey “from first customer to scaled system.” Three boxes underneath said to find the signal, build the system, and measure the change.
None of it was false. That was the problem.
Replace the name and career categories, and the page could have belonged to thousands of people. The code worked. The links worked. The copy had compressed a résumé, a target job, and several design references into the statistical center of a product portfolio.
A finished-looking page had arrived before the system knew which parts of the story mattered.
A one-off detail can become an identity
One early note described learning ForgeCAD. It was meant to support a bounded post about using an unfamiliar tool—not to define the publication. But CAD was recent, visual, and unusually specific. It gave the model more to hold than years of work that had been compressed into résumé bullets.
The imbalance showed up quickly. Physical-product imagery began taking over the hero. Hardware language moved into the positioning. A side experiment started reading like the center of the work.
The model had no reason to know that recency was not identity. In the material it could see, the side note had texture while the career had labels.
The model was not revealing me. It was revealing the shape of its input.
That distinction changed the diagnosis. Another adjective would not fix the homepage. The missing input was a hierarchy: which experience was foundational, which stories were supporting evidence, which subjects belonged to one post, and which details should never become public positioning.
A résumé stores outcomes, not decisions
A résumé is optimized for compression. It can hold titles, scope, systems, and results. It rarely preserves the moment a team changed its mind, the alternatives that lost, the constraint that made one option viable, or the evidence that arrived after release.
The target role added a second distortion. A job description is useful as an evaluation rubric: does the work demonstrate customer judgment, technical fluency, writing, ownership, and business reasoning? Used as a voice corpus, it pulls the prose toward the company's vocabulary. The application begins to sound tailored before it sounds true.
Design references had the same boundary. They could clarify hierarchy, typography, density, and interaction. They could not decide what the career meant.
The highest-value inputs were blunt corrections: CAD is one post, not the identity. Do not turn an unreleased product into homepage positioning. If this is a blog, finished writing has to dominate the interface. Keep the evidence workflow private.
Those sounded like copy notes. They were product requirements. Each one removed an invalid interpretation of the person the site was meant to represent.
The public site needed a private half
The early site exposed its own editorial machinery. Cards carried draft and review states. Candidate case studies appeared before the facts were ready. The page explained that evidence was being assembled instead of giving the reader finished evidence.
Cleaning that up required more than deleting labels. The project needed somewhere for uncertainty to live without leaking into the publication.
| Project artifact | Decision it carries | Failure it prevents |
|---|---|---|
DESIGN.md | Defines the original visual system and the boundary around references | A useful reference turning into copied trade dress |
AGENTS.md | Defines scope verbs, privacy rules, repository boundaries, and release authority | A capable agent doing work it was never authorized to do |
SOURCE_LEDGER.md | Separates direct observation, owner-supplied claims, and inference | A résumé statement being mistaken for independent public proof |
| Private proof packets | Hold unresolved metrics, artifacts, and publication questions outside the application | Draft evidence appearing in a route, metadata record, or deployment |
publishedEssays | Names the pieces deliberately selected for the public interface | A backlog item becoming public because a component knows it exists |
This split made the public site smaller and the working system larger. That was healthy. A publication should show the reader the result of editorial judgment, not every unresolved thought that preceded it.
Context also needs decision rights
Most advice about AI context starts with knowledge: what documents, examples, and history should the model receive? Product work needs a second question: what is the system allowed to decide?
A model can know that a metric exists and still lack permission to publish it. It can read that work was co-led and quietly rewrite the sentence as “built.” It can encounter private contact information without having any reader-facing reason to use it. It can understand a product concept while lacking authority to inspect the product's source code.
Those are not stylistic edge cases. They change the claim, the ownership, or the trust boundary.
SOURCE
What supports the sentence?
SCOPE
Which part of the work was mine?
BOUNDARY
What may be named, summarized, or shown?
CLAIM
What is the strongest public sentence left?The order matters. Starting with the claim encourages the system to defend attractive prose. Starting with source, scope, and boundary makes the sentence a consequence of the evidence.
The compiler cannot catch a biography error
AI helped most where a mistake was visible and reversible. Layouts could be compared. A bad hero image could be replaced. A route could be added, tested, and removed. TypeScript could reject an invalid shape, and the production build could expose a broken import.
The dangerous errors compiled cleanly.
TypeScript cannot tell that led replaced co-led. A successful build cannot decide whether a company metric has enough context to publish. A polished portrait cannot prove that the visual emphasis matches the person. The more plausible the output looks, the easier these errors are to miss.
The release process therefore ran on two gates. The software gate checked lint, types, the production build, routes, metadata, redirects, and public access. The editorial gate checked source, ownership, confidentiality, and whether the writing sounded like a conclusion the evidence had earned.
Passing one gate said nothing about the other.
AI solved the visible half first
The pattern extends beyond this website. In a survey of 1,750 knowledge workers, product managers reported the most value from AI in PRDs, prototypes, and communication. User research and roadmap ideas sat much lower. The authors' reading was straightforward: PMs had learned to use AI for production before using it for the upstream work of deciding what to build. The full results are in Lenny's AI productivity survey.
This project failed in the same gap. It was easy to generate a page. The hard part was teaching the system which evidence deserved to shape the page, which interpretation was merely recent, and which sentence crossed a publication boundary.
The useful product work was not typing the final headline. It was designing the conditions under which a headline could be accepted or rejected for a reason.
The first draft should arrive earlier—and lose authority
The original headline now survives in Git history. It was not a disaster. It did what an early prototype should do: it made the gaps visible while revision was cheap.
The mistake would have been treating fluency as evidence that the identity work was finished.
Use AI to produce the first inspectable artifact earlier. Then remove its authority. Attach consequential claims to a source, an ownership boundary, and a publication decision. Let design variants move quickly because they can be seen and reversed. Slow down when a sentence claims a result, a role, or a definition of the person behind the page.
The page can compile before the story is ready. That makes it a useful prototype, not a verdict.