How I manage AI as a Non-Developer - Max's Substack

Max's Substack

SubscribeSign in

How I manage AI as a Non-Developer<br>The tools and methodology that actually works (for me)

Max<br>Jul 14, 2026

Share

If you try to build anything more complex than a basic chat prompt with AI, you hit a complexity wall fast.<br>You ask for a feature. The AI writes the code and it works.<br>You ask for a second feature, and the AI quietly breaks the first one.<br>You try to get it fixed, the AI starts guessing instead of checking, and within a couple of hours you’re staring at a 2,000-line file of spaghetti code that you don’t have the skills to untangle. The context window is full, the AI is confused, and you have no clean way to backtrack.<br>As a non-developer, I had to accept that my job isn’t to write code. My job is to be the tech lead, the product manager, and the QA tester, all at once.

It’s basically the job I did leading teams at Capgemini Engineering, minus the technical expertise I used to lean on to sanity-check my own team.<br>To do that without losing control of the project, I built a fairly rigid tool stack and a management method to go with it.<br>Here’s what that looks like, and here’s where it’s already bitten me.<br>The stack : building a real developer environment

If you treat an LLM like a chat window, you get chat-window results: fine for a one-off script, unusable for a real product. To get something reliable, you need to give the AI a structured local environment. Here’s the setup I run before any coding starts:<br>Claude Code (the engine): Anthropic’s command-line tool, running directly in my terminal. It reads files, runs the test suite, and executes commands on its own, instead of me copy-pasting code back and forth from a chat window.

A dedicated developer account: I don’t run Claude Code on my personal account. It runs on a separate account with its own integrations, its own skills, and its own SMTP so it can send email under its own identity, not mine.

OpenProject (the brain): This is where the project structure actually lives: epics, task groups, individual tasks, subtasks, bugs. Claude has direct API access, so it pulls its own task list, updates its own progress, and logs bugs as it finds them. It can (and must by defined requirements) also assign tasks to the humans on the project (UX validation, legal sign-off, PR merging) instead of pretending it can do those itself.

GitHub (the vault): Every clean step gets committed and pushed. If something breaks, we roll back to the last known-good commit immediately rather than trying to patch our way out.

Obsidian (the viewer): Claude Code works natively with Markdown, so I keep Obsidian open on a second screen to read, link, and skim the documentation the AI generates as it works. I also have a small end-of-session skill that checks every project document has a symlink into my Obsidian vault, so nothing important is ever just sitting orphaned in a repo I’ll forget to open.

The methodology: Waterfall not Agile

Here’s my genuinely held opinion after a year of doing this : you cannot run a pure “agile” process with an AI. Agile works because humans have judgment and can pivot mid-sprint on gut feel. An AI doesn’t have that. It needs strict, sequential guardrails, or it will confidently wander off in a direction nobody asked for. So I use a hybrid: upfront design, then disciplined execution. Nothing gets coded until we’ve walked the full path below.<br>1. Functional specifications

We write down exactly what the software needs to do: every user flow, every edge case. I lean hard on examples from other websites or apps to anchor the request in something concrete, because “make it intuitive” means nothing to an LLM. We also set the “boring-but-critical” requirements up front: accessibility, interoperability, target devices, target users, OWASP rules, GDPR Compliances....<br>2. Constraints and compliance

We set the technical fences. My hard rule: open-source only, and only if the license is genuinely compatible with commercial use (permissive licenses like MIT or Apache, never restrictive copyleft like GPL). We also check the library is actually maintained. A stale, half-abandoned open-source package is a liability whether or not the license checks out.<br>3. Architecture and design

The functional spec (around 60 pages, in its final form) gets broken down into a technical architecture document (roughly 20 pages). From there, a design pass carves the work into discrete, coherent technical blocks, sequenced in OpenProject.<br>Early on, I had a rule that every single block, no matter how small, got a full review pass from a specialized Architect agent plus either a UX/UI or Legal agent. It felt rigorous. It also turned out to be a mistake I had to walk back (more on that below).<br>4. Test-driven development (TDD)

We don’t write application code first. We write the tests. Claude generates the test suite for a task, runs it to confirm it fails, and only then writes the minimal code...