Claude Code Building Software with AI

WHO AM I

Damien Guard

Locally educated software engineer

WHO AM I

My AI journey

WHO AM I

My AI journey — by the numbers

Key insight

The AI breakthrough: Using tools

Key insight

Leveraging Claude Code successfully

Three levels of granularity. The right one depends on what you're building and what you can meaningfully review.

Getting started

Installing Claude Code

Desktop app

Download from claude.ai — Mac & Windows. GUI interface, no terminal needed.

IDE plugins

Official

• VS Code / Cursor — native chat, inline diffs, checkpoint rewind
• JetBrains — IntelliJ, WebStorm, PyCharm, GoLand

Community

• Zed — via ACP protocol
• Neovim — claude-code.nvim
• Emacs — claude-code.el

Command line interface

# Mac / Linux
curl -fsSL https://claude.ai/install.sh | bash
# Windows
irm https://claude.ai/install.ps1 | iex

Getting started

First session in 60 seconds

# 1. Create a project folder
mkdir my-project && cd my-project

# 2. Initialise git (Claude needs this)
git init

# 3. Fire up Claude in auto mode
claude --permission-mode auto

# 4. Start typing!
> Build me a REST API in Node.js with Express
  that serves a list of Guernsey beaches
  with name, parish, and coordinates.

Auto mode lets Claude run safe actions — file edits, reads, builds — without asking permission every time. Risky actions still require approval.

What can I use it for?

What can I use it for?

Scaffolding a new project

You know what you want to build but not which stack, which database, or where to deploy it.

> I want to build a task management API with auth. It needs to be type-safe, cheap to host, and easy to deploy. What are my options?

Here are three approaches depending on your priorities:

Cheapest:  Hono + SQLite (Turso) on Cloudflare Workers — near-zero cost, edge-deployed, but limited to HTTP workers
Most flexible:  Express + Drizzle + Postgres on Fly.io — real server, full control, free tier generous
Fastest to ship:  Next.js API routes + Prisma + Supabase — managed Postgres, built-in auth, one deploy target

All three give you end-to-end TypeScript. What matters most — cost, flexibility, or speed?

> Flexibility. Go with Fly.io. Set it all up.

Created package.json, tsconfig.json, drizzle.config.ts
Created src/index.ts, src/db/schema.ts, src/routes/tasks.ts, src/middleware/auth.ts
Created tests/tasks.test.ts, docker-compose.yml, fly.toml
Run     pnpm install && pnpm test — 4 passed

What can I use it for?

Example: Global Income Tax Calculator

11 prompts, ~15 minutes:

1. Scaffold a single-page HTML with 30 countries, tax brackets, salary input, sortable table
2. Add Guernsey, Jersey and Isle of Man
3. Drop average effective column, show tax in salary currency
4. Double check all the tax calculations and brackets
5. Drop top rate and tax (local) columns
6. Add social contributions column with bands per country
7. Add social % column
8. Default currency to GBP
9. Default sort to take-home descending
10. Drop summary row, shorten subtitle
11. Move salary input to top-right layout

What can I use it for?

Example: Global Income Tax Calculator

What can I use it for?

Coding new features

You need a rate limiter. You know the requirements. You just don't want to spend the afternoon writing it.

> Add rate limiting middleware to the Express API. Use a sliding window algorithm, 100 req/min per API key, stored in Redis. Return 429 with retry-after header when exceeded.

Created src/middleware/rateLimiter.ts    Sliding window with Redis MULTI/EXEC, configurable limits per route group
Updated src/app.ts                       Registered middleware before routes
Created tests/rateLimiter.test.ts        12 tests: normal flow, exceeded, reset, multi-key, Redis failure
Run     npm test                         12 passed

What can I use it for?

Reviewing code

The new auth module needs a thorough review. The more eyes the better — and different models find different things. Run the same review through Claude, Copilot, and GPT. Their findings rarely overlap completely.

> Review src/auth/ for security issues. Check for injection, broken access control, token handling, and timing attacks. Be thorough and harsh.

CRITICAL tokenService.ts:47   JWT secret loaded from env without fallback check — starts with empty string in dev, tokens are unsigned

WARNING  login.ts:23          Password comparison uses === not crypto.timingSafeEqual — vulnerable to timing attacks

WARNING  session.ts:91        Session ID generated with Math.random not crypto.randomUUID

What can I use it for?

Partner for critical design

You're designing a notification system and want to think through the tradeoffs before committing.

> I need to add real-time notifications. Considering WebSockets vs SSE vs polling. We have ~5K concurrent users, Node backend, Redis already in the stack. What would you recommend and why?

For your setup I'd recommend SSE:

Why SSE over WebSockets:  You're doing server→client only. SSE works through proxies/CDNs. Built-in reconnection & event IDs. Half the complexity of WS.

Architecture:  Redis Pub/Sub for cross-instance fan-out. SSE endpoint per user session. Fallback to polling for legacy clients.

When to reconsider:  If you later need client→server (chat, collaborative editing) then upgrade to WebSockets.

What can I use it for?

Understanding existing code

You've inherited a billing module with no docs. 4,000 lines across 12 files. You need to understand it before making changes.

> Read everything in src/billing/ and explain how the invoicing pipeline works end-to-end. Include the data flow, key decision points, and anything that looks like a bug.

Invoice pipeline:
  1. Cron triggers generateInvoices() at midnight UTC
  2. Queries unbilled usage from usage_events table
  3. Groups by customer + plan tier, applies discounts from coupons
  4. Writes to invoices table, queues email via notifyQueue

Possible bug line 847  Discount calc uses Math.floor before currency rounding — customers losing fractional cents on every invoice

What can I use it for?

Refactoring next level

A single file has grown out of control and nobody wants to touch it.

Tip: Smaller, well-structured code also means more re-use and fewer tokens spent on similar features. Schedule refactoring reviews regularly — your AI budget will thank you.

> Invoicing.cs is too big at 1,400 lines. How can we break it down? Just propose a plan.

I've analysed Invoicing.cs and identified 5 logical groupings. Here's how I'd split it:

InvoiceGenerator.cs        ~320 lines   Core pipeline: usage aggregation, line item creation, tax calculation
InvoiceValidator.cs        ~180 lines   Validation rules, duplicate detection, date range checks
DiscountEngine.cs          ~240 lines   Coupon application, tiered pricing, promotional rules
InvoiceNotifier.cs         ~160 lines   Email queueing, PDF generation, webhook dispatch
InvoiceRepository.cs       ~280 lines   All database access — queries, inserts, status updates
InvoicingHelpers.cs        ~120 lines   Currency rounding, date utilities, formatting

The remaining ~100 lines are using statements and shared constants — those move to a shared file.
Want me to proceed with this breakdown?

What can I use it for?

Writing tests

You've shipped a feature but test coverage is thin. Or you're about to refactor and want a safety net first.

> Read src/billing/DiscountEngine.cs and write comprehensive tests. Cover happy paths, edge cases, and anything that looks risky. Use the existing test conventions in tests/.

Created  tests/DiscountEngineTests.cs  — 34 tests

Covered:
  Percentage & fixed discounts, stacking rules, expiry edge cases
  Zero & negative amounts, currency rounding, missing coupon codes
  Tiered pricing boundaries, promotional cap enforcement

34 passed  — also caught a rounding bug on line 214

Tip: Works the other way too — write the tests first, then ask Claude to implement until they pass.

What can I use it for?

Evaluating what to create

Before writing a line of code — is this worth building? What already exists?

> I want to build a local-first markdown note app with backlinks and graph view. What's already out there? Is there room for something new?

Established players:  Obsidian (dominant, plugin ecosystem, free for personal), Logseq (open source, outliner-based), Notion (cloud-first, different audience)

Gaps I see:
  • Obsidian plugins are fragile — no official API stability guarantee
  • None handle structured data well (tables, databases, schemas)
  • Collaboration is bolted on, not native
  • Mobile experience is weak across all of them

Where there's room:  A local-first app focused on structured knowledge (not just freeform notes) with real-time collaboration could carve out a niche. Think "Obsidian meets Notion meets Linear."

Worth considering:  The note app market is crowded. Your differentiator needs to be sharp. What's the specific pain point you're solving?

How it works

CLAUDE.md

A README for Claude, loaded every session. Initialize with /init. Three levels:

Tip: Ask Claude to review your CLAUDE.md — tell you what it finds useful, what's just noise, and what's duplicated or unhelpful. It will tell you honestly.

How it works

Permissions & trust

How it works

Git as your safety net

Claude Code expects a git repo. Without one, you have no undo button. Not using version control is setting up for disaster.

Skills

What if you could teach Claude your workflow?

Skills

Skills are markdown files

A skill is a .md file that gives Claude Code a structured recipe for a task. It lives in your repo and gets loaded into context when invoked.

No server. No runtime. No deployment. Just a well-written document.

Skills

Anatomy of a Skill

---
name: test-all
description: Build and run tests against all three EF version targets
argument-hint: "[optional: test filter] [--model haiku|sonnet]"
allowed-tools: Bash(dotnet *), Bash(docker *), Read, Glob, Grep, Agent
---

# Then structured markdown with phases, rules, and examples

Skills: real world example

Parallel test runner: test-all

## Phase 2: Parallel Build & Test

Spawn three sub-agents in parallel
(one per EF version: EF8, EF9, EF10)
using the Agent tool.

Set the model parameter on each
agent to the parsed model from args.

Each agent runs:
  1. dotnet build $SLN -c "Debug EF{v}"
  2. dotnet test  $SLN -c "Debug EF{v}"

Report: build status, pass/fail/skip counts,
any failed test names + error messages.

Skills: real world example

The complete test-all skill

---
name: test-all
description: Build and run tests against all three EF version targets (EF8, EF9, EF10)
argument-hint: "[optional: test filter or project name] [--model haiku|sonnet|opus]"
allowed-tools: Bash(dotnet *), Bash(docker *), Read, Glob, Grep, Agent
---

# Test All EF Versions

`$SLN` refers to the solution file path: `{working directory}/MongoDB.EFCoreProvider.sln`

## Arguments

Parse `$ARGUMENTS` for:
1. --model <model> — If present, extract and remove it.
   Use as the `model` parameter when spawning agents. If absent, use `haiku`.
2. Remaining text — Optional filter:
   - If empty, run all tests across all three versions.
   - If it looks like a project name (e.g. "UnitTests"), run only that project.
   - If it looks like a test filter, pass it via `--filter` to `dotnet test`.

## Phase 1: Pre-flight Checks (MUST pass before anything else)

1. net10.0 SDK — Run `dotnet --list-sdks` and verify a 10.x SDK is installed.
   If missing, stop with: "net10.0 SDK is not installed."

2. Database connectivity — Check that either:
   - Docker is available (`docker info` succeeds), OR
   - `MONGODB_URI` environment variable is set.
   If neither: stop with: "No database available."

## Phase 2: Parallel Build & Test via Sub-agents

Spawn three sub-agents in parallel (one per EF version: EF8, EF9, EF10)
using the Agent tool. Set the `model` parameter on each agent.

Each agent's prompt must include the full build and test commands:

  1. Build:  dotnet build {sln} -c "Debug EF{version}" -v quiet
  2. Test:   dotnet test  {sln} -c "Debug EF{version}" --no-build
                   --logger "console;verbosity=normal" -v quiet

## Important Rules

- Always use absolute paths — never `cd` into directories.
- Quote configuration names — they contain spaces ("Debug EF8").
- Parallel is safe — each EF version builds into a separate output dir.
- Continue on failure — if one version fails, still report the others.

## Phase 3: Console Summary

| Version | Build  | Passed | Failed | Skipped |
|---------|--------|--------|--------|---------|
| EF8     | OK     | 142    | 0      | 3       |
| EF9     | OK     | 145    | 2      | 1       |
| EF10    | OK     | 148    | 0      | 0       |

If any version had failures, list failing test names grouped by version.

Tools

What if custom tools had very little cost?

Tools

Purpose-built tools

Have Claude write its own tools instead of chaining shell commands. Solves two problems at once:

# Instead of approving each:
grep -Pboa ...   # allow?
xxd | sed ...    # allow?
awk | xxd -r     # allow?

# One tool, one permission:
python tools/patch_binary.py

# curl/wget get blocked by
# AI-sniffing CDNs & WAFs

# Have Claude write:
python tools/get_url.py $URL
# Normal user-agent, no blocks
# Handles redirects, encoding

# .claude/settings.json
"allow": [
  "Bash(python *)",
  "Bash(dotnet *)",
  "Bash(node *)"
]
# All Python tools run freely
# Permission fatigue: gone

CLAUDE.md can steer Claude toward this pattern: "write Python tools, not bash chains"

Tools: real world example

Python tool: check_clobber.py

A static analysis tool that catches Z80 register clobbering bugs. Claude wrote it, Claude runs it.

> Write the disk read routine

Created src/bios/disk.asm
Run     python3 tools/check_clobber.py

WARNING disk.asm:47
  call ReadSector clobbers A,
  but line 49 reads it: or a

Updated src/bios/disk.asm:47
  Added push af / pop af around call
Run     python3 tools/check_clobber.py
  No clobber issues found.

MCP

What if Claude could control a live running system?

MCP

MCP Servers: live tool providers

When Claude needs to interact with a running system — an emulator, an API, hardware — you build an MCP server. It's a process that exposes tools over JSON-RPC.

MCP

Anatomy of an MCP tool

Each tool is a function with a name, description, schema, and handler. Claude reads the description to decide when to use it.

// Server setup
const server = new McpServer({
  name: 'zx84', version: '1.0.0',
});

// -- find --
server.tool(
  'find',
  'Search all 64KB of memory for a byte sequence. Returns up to 64 matches.',
  { hex_bytes: z.string().describe('Hex byte string to search for, e.g. "CD0050"') },
  async ({ hex_bytes }) => {
    const hex = hex_bytes.replace(/\s/g, '');
    if (hex.length % 2 !== 0) return text('Hex string must have even length');
    const needle = new Uint8Array(hex.length / 2);
    for (let i = 0; i < needle.length; i++)
      needle[i] = parseInt(hex.slice(i * 2, i * 2 + 2), 16);
    return text(doFindBytes(addr => spec.memory.readByte(addr), needle));
  },
);

~20–35 lines per tool. The whole zx84 server is ~1,700 lines for 30+ tools.

MCP: real world example

zx84 — built with Claude Code

Every panel you see here has a corresponding MCP tool. The debugger, the drives, the display — Claude controls all of it.

MCP: real world example

ZX Spectrum emulator: zx84 MCP

run         N frames
step        N instructions
continue    until breakpoint
step_frame  one frame exactly

breakpoint      set/list
port_watchpoint I/O traps
disassemble     Z80 mnemonics
registers       full CPU state
trace           full/portio/zxtl

memory    hex dump
peek poke read/write bytes
find      byte sequence search
port_in   read I/O port
port_out  write I/O port

key   press key for N frames
type  type a string
      handles symbols, shift
      combos, enter, etc.

load   TAP TZX SNA Z80 SZX DSK
save   SZX snapshots
model  switch 48k/128k/+3
eject  tape or disk

ocr  read the screen
     Claude can "see" what
     the Spectrum is showing
     → debug tool → feature

30+ tools in ~700 lines of TypeScript. Claude gets full control of a running Spectrum.

Measuring success

How does Claude know if it worked?

Measuring success

Know when to be in the loop

Human in the loop

Spectrum Analyzer: expose the knobs

Claude gets the math right

FFT, frequency binning, stereo separation — all correct first time

But it looks wrong

Claude can't judge aesthetics. "Make it look better" is a dead-end prompt

Expose the internals as controls

Glow, HF Boost, Input Gain, band count, colour schemes — all tuneable by a human

Debug tool → product feature

The controls shipped to users. They love tweaking them too

Get out of the way

Sound Chip Emulation: close the loop

// The iteration loop:

1. Load reference song via MCP
2. Emulate → record to WAV
3. Analyse WAV (frequency content,
   envelope shapes, timing)
4. Compare against reference WAV
5. Identify delta → adjust emulation
6. Repeat

// Without the MCP + WAV recording,
// this loop doesn't exist.
// Claude is flying blind.

Risk

Can I trust AI development?

Risk

Lost access

What happens when the AI isn't available?

Risk

Code quality

The daily risks of AI-assisted development.

Risk

Security & legal

The risks that keep lawyers and security teams up at night.

Wrapping up

Next steps

Wrapping up

Thank you

I'll be around after the talk if you'd like to chat, ask questions, or see a demo.

Overtime

Alternatives

Skills & MCP servers are portable across most of these.

CLI tools

IDE integration

Models

Overtime

Context window & token drift

Everything Claude reads and writes consumes tokens from a finite window. CLAUDE.md costs context on every session.

/compact summarize & compress
/clear   wipe & start fresh

Overtime

Agentic search

Claude Code doesn't have a pre-built index of your codebase. It searches actively — like a developer exploring unfamiliar code.

Overtime

Claude optimized itself

// Before (real-time):
play_song("commando.sid")
record_to_wav()  
// ⏱ 3 minutes...
stop_recording()

// After (Claude's addition):
render_to_wav("commando.sid", {
  duration_ms: 180000,
  sample_rate: 44100
})
// ⏱ ~200ms

Overtime

What is swarm mode?

Instead of one agent working sequentially, multiple agents work in parallel on the same problem.

Overtime

The Ralph Wiggum Loop

When Claude gets stuck in a cycle of failed attempts — each one confidently wrong.

Overtime

Practical tips

Overtime

Future talks

Topics I'm exploring. Let me know what interests you.