Building with Claude Code (without touching the keyboard much)

Over the last year or so I’ve built seven or eight web apps (of which only one is actually still running...), a number of analysis projects with Claude Code and a wide range of Codex supported Product Manager "tasks" of varying complexity at work, without writing much code myself – but very much acting as Product Manager, evaluator, and the one pressing the buttons.

Giuseppe Destefanis just published a white paper on building a full data analysis platform with Claude Code in five days, and it felt uncannily like reading an exquisitely detailed field report from my own brain.

I want to use his experiment as a backdrop to show how I work with Claude Code day to day, as a non‑developer who through the sheer virtue of working with great engineers for a couple of decades have absorbed some of the thinking I have come across.

The white paper I wish I had a year ago

Giuseppe’s project is a modular web-based platform for supporting researchers working on large datasets extracted from software repositories. Several modules, loads of Python files, REST endpoints, vast unit test coverage, Tailwind UI – the kind of thing that would normally require a small team for a considerable amount of time.

He did it in five days, across 12 Claude Code sessions and 552 prompts, without manually writing a single line of code. The important bit is not “AI can write lots of code” (we all know that by now), but how he made it work:

• He spent the first 98 prompts just on requirements, architecture and sprint planning – no coding.
• He forced Claude to read documents and confirm understanding before doing anything.
• He worked module‑by‑module with explicitly “phased” instructions. Delivering the work in chunks, with his input and feedback along the way, and not proceeding until satisfied: “now let’s move to the comparison tab”.
• He separated thinking from doing with hard gates: “we are brainstorming here, don’t start coding until we agree a strategy”. Telling the LLM to stay in thinking mode is something I find myself doing quite a lot, especially with Codex...
• He used role‑based sessions (architect, evaluator, developer) and treated documentation and sprint plans as Claude’s guardrails. This sounds similar to how I have set up skills to run separate sessions for creation and review.

By the time I finished his conclusions my main reaction was: “this is exactly what it feels like when it works.”

My input: less “prompt pusher”, more “fuzzy product owner”

One of Giuseppe’s key observations is that almost 15% of his prompts were direct technical interventions: logic reasoning in plain language, root cause analysis, domain‑specific corrections based on his knowledge. He never wrote code, but he absolutely did do engineering work.​

That matches how I work with Claude Code:

• My local setup is tightly controlled using a number of CLAUDE.md files and documentation reference files that aim to set clear boundaries.
• When starting something new I’ll ask it to read the project docs first, then start talking about what outcome I want, working towards a "specification" document that clearly outlines what will need to change.
• When it misreads the situation or falls into some gap that is not covered by my reference documents, I push back with the reality that I know.
• I regularly tell it to update the relevant CLAUDE.md files and the reference documentation so a new instance of Claude (including future‑me) can read up on changes and create a clean mental model of the part of the system we are working on.

Giuseppe’s white paper calls this out explicitly: “without writing a single line of code” does not mean “without technical contribution”; he still provides systems thinking, domain knowledge and quality judgement. That’s exactly the space I occupy when I’m working with Claude Code.

Patterns I use, described in the white paper

What the white paper does beautifully is name the patterns I’ve been ambling towards through trial and error. Three in particular resonate:​

• Architecture‑first
  I’ve learned that if I skip straight to “build this feature”, things unravel later. Giuseppe spends the first phase getting Claude to produce a 68‑page architecture doc and a sprint plan before coding. To be honest, that sounds a bit too much "waterfall" for me. :D I do a lightweight version of the same thing: have Claude read existing relevant docs, draft or refine a specifications note, push it through my "review team" to get extra eyes on security and architecture, and only then start making changes.​

• Outcome‑oriented prompts
  Instead of dictating implementation, I describe outcomes: “I want to be able to change the UI without touching the rest” is one of the examples by Giuseppe, or in my case a starting prompt could be like “I want to understand how X and Y changes over time for the cohorts A, B and C, in a map based visualisation”. The white paper shows that when you state clear outcomes, Claude is surprisingly good at picking appropriate patterns and technology decisions on its own.

• Pattern replication, not reinvention
  Giuseppe’s line “do it exactly like you did with plots, without ruining the existing code” is one I could happily steal. Once Claude has something working, I constantly refer back to it: “follow the same structure as X”; “extend the tests you just wrote for Y”; "base the layout and styles for this visualisation off the project we did last week that you find in @path_to_project".

Seeing those habits across Giuseppe's work validates what I’ve been doing by instinct.

Managing the AI, not the code

Giuseppe spends an entire section on managing Claude’s behaviour: stopping it from over‑engineering, preventing regressions, pushing it to be honest, and shutting down repeated bad diagnoses (like blaming browser cache for everything) where he just knows the AI is wrong.

Again, this mirrors my day‑to‑day:

• When working through a security‑sensitive change, I’ll ask it to research trade‑offs and then make an explicit risk call for an MVP, with clear technical debt notes for future research and tests.
• I use it as an evaluator as much as a generator: “read this PR review, what should we do next?”, “is this architecture over‑kill for what I’m doing? What makes you say that?”

The white paper frames this as behavioural management being a core skill in AI‑assisted development, not a side‑effect. That’s exactly how it feels: you’re collaborating with a very capable but opinionated junior team who will happily do the wrong thing very fast unless you keep them on a tight brief.

Why this matters for me

If you’re a technically literate PM or “Claude Code power user” sitting on the sidelines because you don’t write production code, Giuseppe’s experiment and my own experience point to a clear opening:

• You don’t need to understand and write syntax, but you do need to think in terms of outcomes, structure, constraints.
• You can absolutely build and evolve serious systems for internal use if you’re willing to be the architect, tester, and behavioural wrangler for your AI pair.
  • I emphasise "internal use": making things available online, exposed to the public internet, always comes with serious risks - don't go there if you are not confident or have someone to help. I would for example not feel comfortable creating and launching some multi user system with any kind of service for end users on my own.
• Documentation and process stop being bureaucratic overhead and become the levers you pull to keep the AI on‑track.
  • Also, creating and maintaining documentation in this AI fuelled world becomes almost zero cost (from a time perspective, maybe not so much tokens...).

The white paper is the most concrete, granular description I’ve seen of this style of working – 550+ prompts worth of interactions, broken down into phases, patterns, and anti‑patterns.

If any of this resonates with how you already use Claude Code, it’s well worth a read; if it doesn’t, it might just give you a new way to think about your role in an AI‑assisted team.