|
| 1 | +# AI-Assisted Authoring with Hype |
| 2 | + |
| 3 | +<details> |
| 4 | +slug: ai-authoring-workflow |
| 5 | +published: 03/15/2026 |
| 6 | +author: Cory LaNou |
| 7 | +seo_description: Learn how to combine AI coding assistants like Claude with Hype's build-time validation to write technical documentation faster while keeping every code example correct. |
| 8 | +tags: tutorial, ai, authoring, workflow, claude, hype |
| 9 | +</details> |
| 10 | + |
| 11 | +AI assistants are transforming how we write code. But when it comes to technical documentation, there's a trust problem: AI can generate plausible-looking code examples that don't actually work. Hype solves this by validating everything at build time — making AI-generated content trustworthy through automated verification. |
| 12 | + |
| 13 | +This guide shows how to combine AI authoring with Hype's validation to write better documentation, faster. |
| 14 | + |
| 15 | +## The Trust Problem |
| 16 | + |
| 17 | +When an AI generates a code example for your documentation, it might: |
| 18 | + |
| 19 | +- Use an API that was renamed two versions ago |
| 20 | +- Import a package that doesn't exist |
| 21 | +- Show output that doesn't match what the code actually produces |
| 22 | +- Use syntax that's almost right but won't compile |
| 23 | + |
| 24 | +In a regular Markdown file, these errors are invisible until a reader tries the code. In a Hype document, the build catches them immediately. |
| 25 | + |
| 26 | +## The Workflow |
| 27 | + |
| 28 | +The AI-assisted Hype authoring workflow has three phases: |
| 29 | + |
| 30 | +1. **Generate** — AI writes the prose and code examples |
| 31 | +2. **Validate** — Hype builds the document, catching errors |
| 32 | +3. **Iterate** — AI fixes what the build caught |
| 33 | + |
| 34 | +This is fundamentally different from the "generate and ship" workflow that produces unreliable documentation. |
| 35 | + |
| 36 | +### Phase 1: Generate the Structure |
| 37 | + |
| 38 | +Start by asking your AI assistant to create the document structure with real source files. The key instruction: **code examples must be separate `.go` files, not inline code blocks.** |
| 39 | + |
| 40 | +For example, ask Claude: |
| 41 | + |
| 42 | +> "Write a tutorial about Go's context package. Create the example code as separate Go files in a src/ directory, and reference them with Hype's include syntax." |
| 43 | +
|
| 44 | +The AI generates: |
| 45 | + |
| 46 | +``` |
| 47 | +context-tutorial/ |
| 48 | +├── hype.md |
| 49 | +└── src/ |
| 50 | + ├── basic/main.go |
| 51 | + ├── timeout/main.go |
| 52 | + ├── cancel/main.go |
| 53 | + └── values/main.go |
| 54 | +``` |
| 55 | + |
| 56 | +Each source file is a complete, runnable program. The `hype.md` references them with `<code>` and `<go>` tags. |
| 57 | + |
| 58 | +### Phase 2: Build and Catch Errors |
| 59 | + |
| 60 | +Run the build: |
| 61 | + |
| 62 | +```bash |
| 63 | +hype export -format markdown -f hype.md > /dev/null |
| 64 | +``` |
| 65 | + |
| 66 | +The build might fail with something like: |
| 67 | + |
| 68 | +``` |
| 69 | +Error: filepath: hype.md |
| 70 | +document: Context Tutorial |
| 71 | +execute error: src/timeout/main.go:15: |
| 72 | + ctx.WithTimeout undefined (type context.Context has no method WithTimeout) |
| 73 | +``` |
| 74 | + |
| 75 | +The AI used `ctx.WithTimeout()` instead of `context.WithTimeout()`. A plausible mistake that a human reviewer might miss, but the compiler catches instantly. |
| 76 | + |
| 77 | +### Phase 3: Fix and Rebuild |
| 78 | + |
| 79 | +Give the error back to the AI: |
| 80 | + |
| 81 | +> "The build failed. `context.WithTimeout` is a package-level function, not a method on Context. Fix src/timeout/main.go." |
| 82 | +
|
| 83 | +The AI fixes the code. You rebuild. The cycle continues until the build succeeds, at which point every code example in the document is verified correct. |
| 84 | + |
| 85 | +## Practical Example: Writing a Package Tutorial |
| 86 | + |
| 87 | +Let's walk through writing a complete tutorial using this workflow. |
| 88 | + |
| 89 | +### Step 1: Set Up the Project |
| 90 | + |
| 91 | +```bash |
| 92 | +mkdir errors-tutorial && cd errors-tutorial |
| 93 | +mkdir -p src/{wrapping,sentinel,custom,unwrap} |
| 94 | +``` |
| 95 | + |
| 96 | +### Step 2: AI Generates the Content |
| 97 | + |
| 98 | +Ask the AI to write the tutorial. Provide these constraints: |
| 99 | + |
| 100 | +- Each concept gets its own subdirectory under `src/` |
| 101 | +- Every Go file must be a complete `package main` with a `main()` function |
| 102 | +- Use `<go>` tags to both show the code and run it |
| 103 | +- Use snippets to highlight specific parts |
| 104 | + |
| 105 | +The AI generates `hype.md`: |
| 106 | + |
| 107 | +```markdown |
| 108 | +# Effective Error Handling in Go |
| 109 | + |
| 110 | +## Wrapping Errors |
| 111 | + |
| 112 | +The `%w` verb in `fmt.Errorf` wraps an error, preserving the |
| 113 | +original for inspection: |
| 114 | + |
| 115 | +<go src="src/wrapping" run="." code="main.go#wrap-example"></go> |
| 116 | + |
| 117 | +## Sentinel Errors |
| 118 | + |
| 119 | +Define package-level sentinel errors for conditions callers |
| 120 | +need to check: |
| 121 | + |
| 122 | +<go src="src/sentinel" run="." code="main.go#sentinel-def"></go> |
| 123 | + |
| 124 | +## Custom Error Types |
| 125 | + |
| 126 | +Implement the `error` interface for errors that carry |
| 127 | +structured data: |
| 128 | + |
| 129 | +<go src="src/custom" run="." code="main.go"></go> |
| 130 | + |
| 131 | +## Unwrapping and Checking |
| 132 | + |
| 133 | +Use `errors.Is` and `errors.As` to inspect wrapped errors: |
| 134 | + |
| 135 | +<go src="src/unwrap" run="." code="main.go"></go> |
| 136 | +``` |
| 137 | + |
| 138 | +And the source files: |
| 139 | + |
| 140 | +```go |
| 141 | +// src/wrapping/main.go |
| 142 | +package main |
| 143 | + |
| 144 | +import ( |
| 145 | + "errors" |
| 146 | + "fmt" |
| 147 | +) |
| 148 | + |
| 149 | +// snippet: wrap-example |
| 150 | +func readConfig(path string) error { |
| 151 | + err := errors.New("file not found") |
| 152 | + return fmt.Errorf("readConfig(%q): %w", path, err) |
| 153 | +} |
| 154 | +// snippet: wrap-example |
| 155 | + |
| 156 | +func main() { |
| 157 | + err := readConfig("/etc/app.conf") |
| 158 | + fmt.Println(err) |
| 159 | + fmt.Println("Unwrapped:", errors.Unwrap(err)) |
| 160 | +} |
| 161 | +``` |
| 162 | + |
| 163 | +```go |
| 164 | +// src/sentinel/main.go |
| 165 | +package main |
| 166 | + |
| 167 | +import ( |
| 168 | + "errors" |
| 169 | + "fmt" |
| 170 | +) |
| 171 | + |
| 172 | +// snippet: sentinel-def |
| 173 | +var ( |
| 174 | + ErrNotFound = errors.New("resource not found") |
| 175 | + ErrUnauthorized = errors.New("unauthorized access") |
| 176 | + ErrRateLimit = errors.New("rate limit exceeded") |
| 177 | +) |
| 178 | +// snippet: sentinel-def |
| 179 | + |
| 180 | +func findUser(id int) error { |
| 181 | + if id <= 0 { |
| 182 | + return fmt.Errorf("findUser: %w", ErrNotFound) |
| 183 | + } |
| 184 | + return nil |
| 185 | +} |
| 186 | + |
| 187 | +func main() { |
| 188 | + err := findUser(-1) |
| 189 | + if errors.Is(err, ErrNotFound) { |
| 190 | + fmt.Println("User not found (expected)") |
| 191 | + } |
| 192 | +} |
| 193 | +``` |
| 194 | + |
| 195 | +### Step 3: Build |
| 196 | + |
| 197 | +```bash |
| 198 | +hype export -format markdown -f hype.md |
| 199 | +``` |
| 200 | + |
| 201 | +If everything compiles and runs, you have a validated tutorial. If not, the error tells you exactly what to fix. |
| 202 | + |
| 203 | +### Step 4: Review and Refine |
| 204 | + |
| 205 | +With the code validated, focus your review on: |
| 206 | + |
| 207 | +- **Prose quality** — is the explanation clear and accurate? |
| 208 | +- **Pedagogical flow** — do concepts build on each other logically? |
| 209 | +- **Completeness** — are edge cases covered? |
| 210 | + |
| 211 | +You don't need to manually verify that code examples work. The build already did that. |
| 212 | + |
| 213 | +## Tips for AI-Assisted Hype Authoring |
| 214 | + |
| 215 | +### Give the AI the Right Constraints |
| 216 | + |
| 217 | +The most important instruction is to keep code in separate files: |
| 218 | + |
| 219 | +> "Write code examples as standalone Go files in src/ subdirectories. Each must be a complete program that compiles and runs. Reference them with Hype `<go>` and `<code>` tags in the markdown." |
| 220 | +
|
| 221 | +### Use Snippets to Focus |
| 222 | + |
| 223 | +AI-generated examples often include boilerplate. Use snippets to show only the relevant part: |
| 224 | + |
| 225 | +> "Add snippet markers around the key function so the tutorial can show just that function while the full file still compiles." |
| 226 | +
|
| 227 | +### Let the Build Be the Reviewer |
| 228 | + |
| 229 | +Don't spend time manually checking code examples. Build the document. If it passes, the code is correct. If it fails, the error message tells you exactly what's wrong. |
| 230 | + |
| 231 | +### Iterate Quickly |
| 232 | + |
| 233 | +The AI → build → fix cycle is fast: |
| 234 | + |
| 235 | +1. AI generates or modifies a file |
| 236 | +2. `hype export` runs in seconds |
| 237 | +3. Error goes back to the AI |
| 238 | +4. Repeat until green |
| 239 | + |
| 240 | +A typical tutorial with 5-10 code examples goes from first draft to fully validated in a few minutes. |
| 241 | + |
| 242 | +### Version Pin Your Examples |
| 243 | + |
| 244 | +When the AI generates code, ask it to use specific versions: |
| 245 | + |
| 246 | +> "Use Go 1.22's range-over-func feature. Make sure the go.mod specifies go 1.22." |
| 247 | +
|
| 248 | +This ensures the examples are reproducible and won't break with Go version changes. |
| 249 | + |
| 250 | +## Stabilizing Dynamic Output |
| 251 | + |
| 252 | +AI assistants often produce examples with dynamic output (timestamps, UUIDs, etc.). Use Hype's replace attributes to stabilize: |
| 253 | + |
| 254 | +```html |
| 255 | +<cmd exec="go run ./src/timestamp" |
| 256 | + replace-1="\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}" |
| 257 | + replace-1-with="2024-01-15T10:30:00"></cmd> |
| 258 | +``` |
| 259 | + |
| 260 | +The command runs (validating it works), but the output is deterministic in the final document. No more noisy diffs from regenerating docs. |
| 261 | + |
| 262 | +## CI Integration |
| 263 | + |
| 264 | +Add validation to your CI pipeline so AI-generated docs are checked on every push: |
| 265 | + |
| 266 | +```yaml |
| 267 | +name: Validate Documentation |
| 268 | +on: [push, pull_request] |
| 269 | + |
| 270 | +jobs: |
| 271 | + validate: |
| 272 | + runs-on: ubuntu-latest |
| 273 | + steps: |
| 274 | + - uses: actions/checkout@v4 |
| 275 | + - uses: actions/setup-go@v5 |
| 276 | + with: |
| 277 | + go-version-file: go.mod |
| 278 | + - run: go install github.com/gopherguides/hype/cmd/hype@main |
| 279 | + |
| 280 | + - name: Build all tutorials |
| 281 | + run: | |
| 282 | + for doc in */hype.md; do |
| 283 | + dir=$(dirname "$doc") |
| 284 | + echo "Building ${dir}..." |
| 285 | + (cd "$dir" && hype export -format markdown -f hype.md > /dev/null) |
| 286 | + done |
| 287 | +``` |
| 288 | +
|
| 289 | +This catches regressions: if a Go update breaks an example, the CI build fails and you know exactly which document needs updating. |
| 290 | +
|
| 291 | +## What This Unlocks |
| 292 | +
|
| 293 | +The combination of AI authoring speed and Hype validation changes what's practical: |
| 294 | +
|
| 295 | +- **Write a tutorial in minutes, not hours** — AI generates the structure and examples, Hype verifies correctness |
| 296 | +- **Update docs with confidence** — regenerate after dependency changes, the build catches every broken example |
| 297 | +- **Scale documentation** — producing 10 validated tutorials is only slightly more work than producing 1 |
| 298 | +- **Trust AI-generated content** — the compiler is the reviewer, not a human scanning for plausible-but-wrong code |
| 299 | +
|
| 300 | +## Key Takeaways |
| 301 | +
|
| 302 | +- **AI generates, Hype validates** — plausible-looking code is verified by the compiler |
| 303 | +- **Separate files, not inline code** — keep examples as real Go files that compile independently |
| 304 | +- **Fast iteration cycles** — generate, build, fix, repeat until green |
| 305 | +- **Focus human review on prose** — let the build handle code correctness |
| 306 | +- **CI catches regressions** — automated builds surface broken examples from dependency changes |
| 307 | +- **Stabilize dynamic output** — replace patterns keep regenerated docs diff-friendly |
| 308 | +
|
| 309 | +## Get Started |
| 310 | +
|
| 311 | +```bash |
| 312 | +brew install gopherguides/tap/hype |
| 313 | + |
| 314 | +mkdir my-tutorial && cd my-tutorial |
| 315 | +mkdir -p src/example |
| 316 | +``` |
| 317 | + |
| 318 | +Write your first AI-assisted tutorial. Ask the AI to create a Go example as a separate file, reference it with a `<go>` tag, and build. When the build passes, you have documentation you can trust. |
0 commit comments