Claude Code Workflow: Build Real Apps With AI

Leon van Zyl opens his recent tutorial with a provocation: "Most people use Claude Code one prompt at a time. That might work for toy demos, but it falls apart when you're building real apps."

He's right. And if you've spent any time watching AI-generated codebases collapse into dependency hell or drift into design incoherence by the third feature, you already know it. Van Zyl — a software engineer who claims nearly two decades of experience, though that's self-reported in the video — demonstrates a Claude Code workflow that treats agentic coding as an engineering discipline rather than a chat session. The structural discipline required to make AI agents actually useful at scale is exactly what most tutorials skip. This one doesn't.

The workflow has several interlocking pieces. Reusable "skills" stored in a GitHub repo handle project scaffolding — one command installs your entire preferred stack, asks clarifying setup questions, and eliminates the repetitive work of configuring the same dependencies for the fifteenth time. A design system gets locked in early, before back-end complexity makes iteration expensive. A detailed spec, broken into phased task files, feeds Claude's Goal command — which runs an implementation loop until completion criteria are met. And parallel sessions in Claude's Agent View handle different concerns simultaneously: one session building, others auditing and refining.

The parallelization piece is where Claude's task orchestration stops being a demo feature and starts being something architecturally interesting. Van Zyl's coordinator agent doesn't implement features itself — it spawns sub-agents to run in waves. "Wave one has two agents in it, and wave two has about three different agents in it, all running in parallel," he explains. The main agent governs; the sub-agents execute. The distinction matters more than it might seem, and it's the reason most people use Claude Code wrong — they collapse orchestration and implementation into a single thread and wonder why it gets confused.

The Security Loop: Meaningful Practice or Comfort Feature?

Here's where I have to actually engage with what van Zyl is doing, because it's the part of this workflow that most coverage will breeze past.

He sets up a recurring security audit using Claude Code's loop command — his demo shows it firing every 10 minutes during active development, though these intervals appear to be his own configuration choices rather than any default. The loop pulls in a "security scanner skill" and resolves flagged issues in a parallel session while the main implementation thread keeps running.

The question I'd ask any developer considering this: what is that scanner actually checking?

An AI security scanner operating on a live codebase mid-build is most likely catching surface-level issues — hardcoded credentials in files it can read, obvious injection vectors, missing input sanitization on newly created routes, dependency versions with known CVEs if it's configured to check package files. Those are real catches. Finding a hardcoded API key before it gets committed is worth the compute cost alone.

What it almost certainly won't catch: business logic vulnerabilities, insecure direct object references (IDOR) where the auth model is technically implemented but structurally broken, race conditions in concurrent operations, or subtle privilege escalation paths that only emerge from understanding how the whole system fits together. Those require either human review or purpose-built SAST/DAST tooling with deep context — not a prompted AI running on a 10-minute clock.

The more interesting operational question is what happens when the security agent flags something real while the implementation agent is mid-wave. Van Zyl doesn't fully address this in the tutorial. If both agents share the same codebase, a security fix touching an auth module while a build agent is actively writing against that same module is a potential conflict. Git checkpoints help — van Zyl's "checkpoint command" creates commits after each phase, giving you rollback points — but concurrent writes to overlapping code are exactly the scenario where agentic workflows need explicit coordination logic, not just parallel execution.

So: is a 10-minute automated audit loop meaningful security practice? Yes, conditionally. It's genuinely better than no security review, and catching credential exposure or missing auth checks during development is much cheaper than catching them in production. But treat it as a first-pass filter, not a security clearance. If you're building anything with user authentication, stored personal data, or payment flows — which van Zyl's demo app has in the form of multi-user auth and persisted article libraries — you still need a human security review before shipping.

The Threat Model Nobody's Talking About

There's a question sitting underneath this entire workflow category that van Zyl doesn't raise, and I think it's worth naming directly.

This workflow gives an AI agent persistent, autonomous, loop-running access to a full codebase — including auth logic, database schemas, and environment files containing API credentials. The agent is operating in "dangerously skip permissions mode" for the parallel sessions, which means it's not pausing for human approval on individual actions. That's a reasonable trade-off for development velocity. It's also a real trust decision you're making.

The threat model isn't that Claude is malicious. It's that an autonomous agent with broad codebase access, operating in loops, touching security-sensitive files, and potentially making changes faster than you can review them, is a system where mistakes propagate quickly. An implementation agent that misunderstands the auth spec and writes broken session management, then a security agent that doesn't flag it because the code is syntactically valid — those errors can compound before any checkpoint catches them.

The mitigation is exactly what van Zyl builds in: phase-gated commits, explicit spec files that define expected behavior, Playwright end-to-end tests that validate actual functionality. The checkpoint skill isn't just a convenience — it's your blast radius limiter. If you run this workflow without those checkpoints, you lose the ability to cleanly roll back to a known-good state.

One more thing: van Zyl's demo app includes credentials in a .env file that the agents have access to during the session. He handles this responsibly in the demo — setting credentials off-screen, using environment variables rather than hardcoding. But if you're adapting this workflow, make sure your security scanner skill is explicitly instructed to flag any plaintext credentials it encounters. That's a configuration choice, not an automatic behavior.

What to Actually Take From This

The upfront investment of building reusable skills and a locked design system before writing a single line of application code is the entire bet van Zyl is making. That investment pays back on the second project, and compounds from there. If you're building one-off demos, skip it. If you're building anything you might iterate on, or anything with real users, the scaffold is load-bearing.

Here's what I'd actually change about this workflow before adopting it:

Give your security scanner skill an explicit checklist of what to look for, rather than a general "audit the app" instruction. At minimum: hardcoded secrets, SQL injection vectors in any raw query construction, missing auth checks on new API routes, and IDOR risks in any endpoint that takes a user-supplied ID. A prompted AI with a specific checklist performs dramatically better than one operating on vibes.

Set up your parallel sessions with file-scope separation where possible — implementation agent owns feature files, security agent operates in read mode unless fixing a specific issue, UI agent owns component files. This isn't always clean in practice, but reducing the overlap surface reduces the conflict risk.

And read the spec Claude generates before you run the Goal command. Van Zyl says this explicitly: "I do encourage you to actually read through it." An AI building from a misunderstood spec is running fast in the wrong direction — and the parallel architecture means it's running fast in the wrong direction across multiple sessions simultaneously.

The workflow van Zyl demonstrates is genuinely more sophisticated than most agentic coding tutorials. But sophistication doesn't substitute for the human in the loop — it just changes when and where that human needs to be paying attention.

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.