I regularly hear about how AI driven development doesn’t work. That’s BS. No, you aren’t going to build a full enterprise application with a single prompt. But you can absolutely build good working software with AI. I recently created Pagelively to host Single Page HTML, Markdown, static sites, etc. on Cloudflare without having to handle a git repo, deployments, etc. It makes it super easy and can be deployed entirely from the cloud without needing to know a single CLI command.

I realized the other day that while it did a good job of taking Markdown and hosting it as HTML that it didn’t have the ability to host just raw Markdown. You could expose the Markdown source from the HTML but couldn’t have a slug/url that returned the plain text Markdown. And I wanted to do that to create a link from my blog post on documentation.

I’ve been using OpenCode as my coding harness for Pagelively. I also wanted to try out the Ox Alpha model that OpenCode Zen is now providing free access to for a limited time.

Original Prompt:

You are the orchestrator, you orchestrate this work you do not do the work.

Feature request: As a user I want the ability to host raw markdown without it being converted to HTML. When the user vists a raw markdown page (slug url/cdn url) they should be served the raw markdown only as text.

That was all I gave it. I didn’t have to give it more because it already

My response:

Accept your recommendations. Defere the convert rendered to/from raw, that is not a planned feature.

And three hours and nineteen minutes later (while I went off and slept) it was done.

My follow-up prompt was to merge and do a release. Did I test it first? Not in this case, because I was fairly confident and it’s my own project and I can do what I want, but usually we would merge to development and then test it from deployment before doing the release.

merge to development and push it. Then do a versioned release on main.

And with that release v1.4.0 is available on the Pagelively repo on GitHub.

You can see everything that it did by comparing v1.3.0 to v1.4.0 (since I didn’t have any other changes since the last release.)

Why does it work?

This is just my opinion, obviously, but I think there are a few reasons:

• It was a single feature of a well defined limited scope: This is just really good development practice but often because the agents never push back we forget it. Have an overly complex feature in a human refinement session and the humans will tell you its too big and that it need to be broken up, but agents don’t usually say that (although I’ve see the new models from Anthropic do it a bit in planning.) We, the humans, need to really be doing this well and that means you need to understand what is actually happening when software is being coded.
• It was an existing application with a well define pipeline process: When I built Pagelively I made sure it had really well defined process and structure around testing. Everything requires two independent testing passes, the one the implementer agent does and the one the verifier agent does. That’s right, the verifier agent writes their own tests - and, yes, it does occasionally catch things the implementer missed.
• A robust planning and documentation process with independent agents: Pagelively doesn’t officially follow my Trellis Playbook but it was a big part of the inspiration for creating Trellis and lot of the input for Trellis. Pagelively has strong documentation requirements and standards. Those documentation standards force agents to actually do the full reasoning, just like with people (although without the whining of people) being required to write out your plan with structure and document decisions forces better thinking.

Conclusion

Nothing here is secret. I’ve shared with you the prompt. The repo is public. You can deploy it if you want to see it work. You can visit https://pages.nicknow.net/ to see a page hosted. You can visit https://pages.nicknow.net/ai-ready-documentation-prompt/ to see raw markdown returned.

I did this on a Sunday night and wrote this up on Monday morning after dropping my kiddo off for her first day of school. It’s all doable. It doesn’t require some set of miracles or millions of dollars. You can take ideas and make them come to life with AI, if you are willing to invest the time to learn to build software….but that last part is important, you aren’t going to succeed here just because you have a random idea. Ideas are cheap, smart execution is expensive. Luckily AI is making it easier to get smart. Good luck!

From the AI

I asked the model to write up it’s own summary of the work it did and the time/tokens it took, here is what it said:

Session Summary: Raw Markdown Hosting Feature (v1.4.0)

1. What I was asked to do

Acting as lead engineering orchestrator for the pagelively repo (a Cloudflare Workers + R2 + D1 static content publisher), implement this feature request:

As a user I want the ability to host raw markdown without it being converted to HTML. When the user visits a raw markdown page (slug url/cdn url) they should be served the raw markdown only as text.

Then, in a follow-up instruction: merge the work to development, push it, and produce a versioned release on main.

Constraints governing the work (from .ai/team-brief.md / repo process):

• Orchestrate only — delegate all implementation/validation/review to specialized subagents (@planner, @implementer, @validator, @reviewer)
• Test-first vertical slices; every slice closes only when the full gate suite is green
• Never touch real Cloudflare resources; everything proven on local workerd/Miniflare emulation
• Stop for human approval at design gates

2. What I did

Phase 1 — Context & Planning

• Read the authoritative docs (product-spec.md, team brief, knowledge-management) and surveyed the mature brownfield codebase (v1.3.0, slices S01–S23 complete)
• Identified that the request conflicts with spec §7 (“markdown is always rendered to HTML”) — surfaced as a human-approval gate rather than deciding silently
• Delegated planning to @planner: produced slice plan S24-A…D, open questions OQ-27…33 with recommendations, and a risk register
• Stopped for human approval. You approved all seven recommendations and ruled that rendered↔raw conversion is rejected, not deferred

Phase 2 — Implementation (four slices, full loop each)

Each slice ran the loop: restate acceptance criteria → failing tests first → minimum code → all gates → independent validation → quality review → conventional commit. The loop caught real issues along the way:

• S24-A: validator caught a format-check failure; reviewer caught invalid TypeScript introduced into a doc code block (semicolon mid-union)
• S24-C: reviewer required the dead-CDN-URL caveat be captured before it was lost in disposable scratch
• S24-D: the validator accidentally reverted the uncommitted UI file mid- mutation-testing and reconstructed it — I flagged this to the reviewer, who then verified the reconstruction hunk-by-hunk against the committed API surface before approving
• Validators independently added 5 genuine gap-tests (zero-file precedence, meta-PATCH rev-bump pin, .markdown extension, no-JS radio default, branch-scoped showSource absence)

Final state: 1746/1746 tests passing (+47 over baseline), coverage 98.53% stmts / 95.82% branch, typecheck/lint/format/build all green, zero skipped tests.

Phase 3 — Release

• Merged to development (1c01724) and pushed
• Version bump chore: bump version to 1.4.0 (8b90dd8): CHANGELOG entry, README status line, package.json
• Caught a Prettier violation in my own changelog edit post-commit; fixed as a follow-up style commit (96acdb9) rather than amending pushed history
• Merged development → main (94ac9d6), pushed annotated tag v1.4.0, published GitHub Release v1.4.0 – Raw Markdown hosting

3. Inference time & token consumption

Honest caveat first: the harness does not expose exact per-call token counts or latency figures to me, so precise numbers aren’t available. What follows is a structural accounting plus clearly-labeled estimates.

Measurable activity (exact)

Estimated token consumption (ballpark, not measured)

Estimated wall-clock inference time

Subagent tasks each ran multi-turn agentic loops including long test suites; individual delegations ranged from ~2–15 minutes of agent runtime. Total session elapsed time including all inference, tool execution, and test runs is realistically in the range of 2–4 hours, of which roughly 30 minutes is attributable to deterministic test execution and the rest to LLM inference and tool round-trips.

Treat all figures in this section as estimates; if you need audited numbers, they would have to come from the OpenCode harness’s own usage logs rather than from me.