Engineering / Structured AI generation
From an AI brief to a reviewed code delivery.
A structured website generation workflow that connects source evidence, a server-owned compiler, bounded repair and human review to a traceable GitHub delivery.
- Context
- Kahla / AI website generation
- Contribution
- Founder / Product & integration engineering
- Project type
- Engineering case study
Scope
A bounded four-page website blueprint and delivery workflow.
Contribution
Structured generation, validation, review and integration controls.
Verification
Source and test evidence for compiler and delivery boundaries.
01 / The problem
Generated output needs a controlled path into code.
A website brief mixes business intent, source material and design choices. An LLM can propose an implementation, but plausible output is not enough to establish that its claims are supported or its code is safe to deliver.
Forge narrows that problem into a structured, bounded workflow. The model produces a website blueprint. Server-owned code compiles that blueprint, checks the source and evidence, and makes a saved revision available for review before delivery.
Evidence has a boundary
Generated copy needs a connection to the material supplied for the project.
Repair needs a limit
An invalid result should not trigger an open-ended generation loop.
Delivery needs a record
A reviewed revision and a GitHub result must remain traceable to one another.
02 / My contribution
Building the workflow around the model.
My work connects structured LLM generation to a server-owned compiler, source and evidence validation, bounded repair, saved revision review, protected previews and GitHub draft pull request delivery receipts.
The implementation uses TypeScript, Next.js, React and Node.js, with Zod for structured output, the AI SDK and AI Gateway, PostgreSQL, GitHub integrations and Vercel protected previews. The model is one part of that system; compilation, review and delivery controls define what its output can become.
Define the generation contract
Represent a bounded website as structured data that the server can validate and compile.
Make revisions reviewable
Save revisions and connect review to the specific output being considered for delivery.
Trace the handoff
Connect a GitHub draft PR delivery to its saved revision and delivery receipt.
03 / How it works
A proposal becomes a delivery through explicit stages.
Explore the generation, review and delivery boundaries. These models explain the workflow rather than reproduce a private application screen.
Brief → Blueprint → Compiler
Keep the model inside an inspectable contract.
Separate the model’s proposed content from the server’s responsibility for producing an implementation.
Brief & evidence
The brief and supplied source material establish the context for the website. Evidence validation checks the relationship between generated output and those inputs.
Conceptual models reconstructed for the portfolio. They contain no private project inputs, credentials or operational records.
Read all model notes
Generate & validate
- Brief & evidence — The brief and supplied source material establish the context for the website. Evidence validation checks the relationship between generated output and those inputs.
- Structured blueprint — The model produces a blueprint within a constrained four-page scope. A schema makes the expected shape inspectable instead of treating arbitrary generated code as the contract.
- Compiler & checks — The server owns the compiler and validation path. This keeps implementation rules outside the model’s discretion and creates a defined place to reject invalid output.
- Bounded repair — Validation failures can enter a bounded repair path. The limit prevents repeated attempts from being mistaken for progress or for permission to broaden the requested scope.
Review a revision
- Save revision — Saved revisions give the workflow a concrete unit of review. A later generation does not silently become the same object as the one a person inspected.
- Protected preview — Protected previews support review without presenting every generated artifact as a public release. This portfolio shows a conceptual diagram, not an operational preview or a functioning product demo.
- Human review — A person reviews the saved output before the delivery step. The workflow preserves that relationship so a review is not treated as a blanket approval of future generated changes.
Deliver to GitHub
- Select reviewed output — The saved revision is the delivery input. That boundary connects what was inspected with what is being handed into the repository workflow.
- Draft pull request — The delivery path produces a GitHub draft pull request. A draft PR is a reviewable handoff, not evidence that changes were merged or promoted to production.
- Delivery receipt — A delivery receipt makes the GitHub result traceable to the saved revision. It gives the handoff a concrete outcome without implying that later release actions happened.
Choose a perspective, then select a stage. Keyboard: arrow keys switch perspectives.
04 / Key decisions
The choices behind the solution.
Compile structured output on the server.
Why it mattersA stable implementation boundary makes validation and output rules inspectable.
The tradeoffThe supported website scope is narrower than arbitrary application generation.
Bound the repair path.
Why it mattersInvalid output should reach a clear stopping condition.
The tradeoffSome requests need intervention or a revised brief instead of another automatic attempt.
Deliver a reviewed revision as a draft PR.
Why it mattersThe repository handoff stays connected to the artifact a person reviewed.
The tradeoffReview, merge and production release remain separate responsibilities.
05 / What it produced
An inspectable path from brief to repository handoff.
The implementation connects a structured LLM blueprint, server-owned compilation, source and evidence checks, bounded repair, saved revision review, protected previews and GitHub draft PR delivery receipts. Private source and test evidence supports these engineering boundaries.
The scope is a bounded four-page website workflow. This study does not claim arbitrary server-code execution, automatic merges or production promotion. The diagrams are portfolio reconstructions, and no private repository or protected preview is presented as a public demo.
Generation contract
Structured output and compiler rules define the supported website surface.
Reviewable revisions
Saved results and protected previews connect review to a concrete artifact.
Delivery receipts
GitHub draft PR outcomes remain associated with the reviewed revision.
The workflow is the engineering work.
Useful generation depends on what surrounds the model: the input contract, validation rules, stopping conditions, review boundary and evidence of delivery. Those controls make an AI-assisted result easier to inspect and support.
Project context & references
2026 · Engineering case study
Implementation and test materials were reviewed privately for this case study. Public diagrams are conceptual reconstructions; source code, private inputs, protected previews and operational records are not published here.
Next / Measure Joy