Chapter 1: A Practical Workflow for LLM-Assisted Development That Doesn't Collapse After Day 2

Series: LLM Development Guide

Chapter 1 of 15

Next: Chapter 2: Planning: Plan Artifacts, Constraints, Definition of Done

What you’ll be able to do

You’ll be able to take a real development task and run an LLM through a repeatable loop that:

• Survives breaks and multi-day work.
• Produces output you can actually review.
• Includes verification steps, not just code.
• Creates a paper trail of decisions and assumptions.

TL;DR

• Treat the LLM like a senior engineer who can execute quickly, but has no durable memory.
• Externalize memory into three artifacts: plan/, prompts/, and work-notes/.
• Execute in small logical units, with verification and atomic commits.
• If you’re fighting output quality, upgrade the model or shrink the scope.
• Never paste secrets, PII, or production data.

Trust contract (read this before you paste anything)

• Security: do not paste secrets, tokens, customer data, or anything you would not publish in a public repo.
• Staleness: model names, pricing, and vendor policies change frequently. Treat examples as illustrative as of 2026-02-14.
• Prereqs: you can run tests, review diffs, and explain the change in a code review.

Table of contents

• Why most LLM-assisted development fails
• The workflow
• Quick start: copy/paste kit
• Worked example: Helm chart from a reference chart
• Verification
• Failure modes

Why most LLM-assisted development fails

Most failures are workflow failures, not “prompting” failures:

• You jump straight to implementation without a plan.
• You don’t provide reference implementations, so you get generic output.
• You lose context across sessions.
• You don’t verify output.
• You batch changes into giant commits that are hard to review or revert.

The workflow

This is the smallest loop I’ve found that stays stable after day 2:

Plan -> Prompt docs -> Work notes -> Execute -> Verify -> Commit

The artifacts are simple:

• plan/: what we’re doing and how we’ll know it’s done.
• prompts/: the reusable prompts aligned to phases.
• work-notes/: state, decisions, assumptions, open questions, and a running session log.

Quick start: copy/paste kit

This is intentionally minimal. It’s enough to make sessions resumable.

1) Create the artifact directories

mkdir -p plan prompts work-notes

2) Create a minimal plan

cat > plan/phase-1.md <<'MD'
# Phase 1: Plan

## Overview
<One sentence: what we are building>

## Goals
- <Goal 1>
- <Goal 2>

## Constraints
- <Constraint 1>
- <Constraint 2>

## Definition of done
- [ ] <Verification command + expected outcome>
- [ ] <Verification command + expected outcome>

## Out of scope
- <Thing we will not do in this phase>
MD

3) Create a phase prompt doc

cat > prompts/phase-1.md <<'MD'
# Phase 1 - Execution Prompt

## Role
You are a senior software engineer.

## Context
- Plan: plan/phase-1.md
- Work notes: work-notes/phase-1.md
- Reference implementation(s): <paths>

## Task
Implement the smallest logical unit that moves this phase forward.

## Constraints (follow exactly)
- MUST follow patterns in the reference implementation.
- MUST propose verification commands.
- MUST NOT change files outside this phase scope.

## Session management
As you work, update work-notes/phase-1.md:
- Decisions (with rationale)
- Assumptions
- Open questions
- Session log entry

## Commit discipline
After each logical unit:
1. Stop and summarize what changed.
2. Propose a commit message.
3. Wait for approval.
MD

4) Create work notes

cat > work-notes/phase-1.md <<'MD'
# Phase 1 - Work Notes

## Status
- [ ] Not started
- [ ] In progress
- [ ] Blocked
- [ ] Complete

## Decisions

## Assumptions

## Open questions

## Session log

## Commits
MD

Worked example: Helm chart from a reference chart

This example is about correctness and maintainability, not “Helm tricks”.

Scenario

Goal: create a new chart (for example, metrics-gateway) by following a reference chart (for example, event-processor) that already works in your environment.

The important part is the inputs you give the model. Don’t describe the reference chart. Paste it.

Reference inputs (what to paste)

Run these commands in your repo and paste their output into your planning prompt:

tree charts/event-processor/
sed -n '1,200p' charts/event-processor/Chart.yaml
sed -n '1,200p' charts/event-processor/values.yaml
sed -n '1,200p' charts/event-processor/templates/_helpers.tpl

Plan prompt (high-signal)

I want to create a new Helm chart for a service called `metrics-gateway`.

Reference implementation: charts/event-processor/ (this is our standard).
The new chart MUST follow the same structure and conventions.

Here are the reference inputs:
- tree output: ...
- Chart.yaml: ...
- values.yaml: ...
- templates/_helpers.tpl: ...

Please:
- Analyze the reference chart patterns.
- Produce a phased plan with verification steps.
- Call out any open questions you need answered (ports, probes, resources).

Execution prompt (phase-aligned)

Once you have the plan, generate prompt docs aligned to phases (scaffold, core templates, env overrides, validation). Each prompt should:

• Name the deliverables.
• Repeat constraints.
• Include “update work notes” instructions.
• Include verification commands.

What “done” looks like

A good end state is boring:

• The new chart is structurally identical to the reference chart.
• The values structure matches (so operators don’t re-learn config surfaces).
• helm lint and helm template succeed.
• Changes are split into reviewable commits.

Verification

You can verify you’re actually following the workflow, not just producing text:

# Artifacts exist.
test -d plan && test -d prompts && test -d work-notes

# A plan exists and is not empty.
test -s plan/phase-1.md

# A prompt doc exists.
test -s prompts/phase-1.md

# Work notes exist.
test -s work-notes/phase-1.md

If you are doing the Helm chart example:

helm lint charts/metrics-gateway
helm template charts/metrics-gateway >/tmp/metrics-gateway.rendered.yaml
test -s /tmp/metrics-gateway.rendered.yaml

Expected results:

• The commands exit with code 0.
• The rendered YAML file is non-empty.

Failure modes

• Skipping references: you get generic output that doesn’t match your repo.
• Skipping verification: you ship code that “looked right.”
• Letting sessions run too long: context drifts and you lose earlier constraints.
• Batching commits: review slows down and rollback gets painful.
• Using the wrong model: cheap models are fine for boilerplate, but can burn hours on complex reasoning.

Continue -> Chapter 2: Planning: Plan Artifacts, Constraints, Definition of Done