I Don’t Read My Own Specs Anymore

A three-agent workflow for a product manager who can only type with one hand

I’m a former Facebook product manager. A few years ago I had a stroke. I have left-sided paralysis and aphasia. I can only type with one hand.

I’m also building an automated ML trading bot that trades 15 different forex pairs — a Double Dueling DQN for entries, XGBoost for stop-loss and take-profit, running live on a Windows Virtual Private Server. It’s not a small project. It has roughly 25 technical indicators per pair, an ML system making buy and sell decisions, 2 different ML models, a walk-forward validation system for the ML models, a currency-concentration gate, and a long list of things still broken.

Here’s the part I want to be honest about up front: I don’t know how to build ML systems at all. I’m a product manager by background, not a machine-learning engineer. I can’t sit down and design a reinforcement learning architecture from scratch. I also can’t do serious DevOps — wiring up EC2 instances to brokers over WebSocket with the kind of reliability live trading actually needs is not something I could pull off on my own.

But Claude can. And that’s the whole point of this post.

Three agents, three roles

The setup is three agents:

1. Me — the operator. Product manager, decision-maker, screenshot-taker.
2. Claude.ai — the architect. Writes specs, reviews outputs, makes recommendations, holds the long-term context of the project.
3. Claude Code — the coder. Reads specs, executes them, ships code, runs experiments, writes back result reports.

The three of us talk through a shared Google Drive folder.

The obvious way to use an AI coding assistant is to open one instance, describe what you want, watch it code, and review. That’s how I started — I went straight to Claude Code and typed out specs myself. It worked for small things. For anything complex it fell apart fast, partly because typing long prompts with one hand is brutal, and partly because I didn’t even know how to write good specs for a machine learning system. There was also no second pair of eyes. Bad designs or poor specs would become four hundred lines of committed code before anybody caught them.

So I made a change. I moved the spec-writing job to a separate Claude.ai instance — the architect — and let Claude Code stay focused on execution. Two different Claudes, different contexts, different jobs.

That single change made everything else possible.

Why the architect is the magic

The architect is infinitely better at writing specs than I am. Not because it’s smarter than me on any individual point. Because it’s thorough in a way I am not.

When I describe a problem in two sentences — “make an automated ML trading bot that’s profitable” — the architect comes back with the right questions. What instruments? What model class? What’s the risk budget? What broker API? What’s the eval methodology? What does “profitable” even mean numerically? Then it writes the spec: architecture diagram, feature engineering choices, training loop, validation strategy, acceptance criteria, edge cases, scope limits, things to not do.

Those specs are eight to ten times more detailed than anything I would have written, and they cover things I literally would not have known to ask about. Concrete example: when I told the architect I wanted to expand the bot beyond gold to trade more instruments, it didn’t just pick the next obvious pairs. It proposed a set of 15 forex pairs, and then surfaced a risk I hadn’t even considered — that those 15 pairs concentrated exposure to USD, JPY, and GBP in ways that could blow up the portfolio if one of those three currencies moved hard. The spec it wrote included a currency-concentration gate that caps how much of the portfolio can ride on any single currency at once. I had never even thought about currency-level concentration. And I wouldn’t have. But the architect knew the issue existed and built the guardrail into the spec before a single line of code got written.

That’s one example. There are dozens more. The architect knows that a reinforcement learning system with DDQN can’t output continuous SL/TP values, so the spec calls for a hybrid with XGBoost. It knows that without walk-forward validation a 94% win rate on training data means almost nothing, so the spec carves out a test set. It knows that a futures-based CFD has rollover artifacts that will confuse an RL feature, so the spec specifies a back-adjusted source. I would have shipped a much worse system in much more time if I had tried to write any of this myself.

The same is true for DevOps. The architect spec’d out the credential refresh signaling between threads, the 30-second cooldown, the cutover from 96 daily browser logins to 29, the Friday-5pm-PT maintenance window. I couldn’t have designed any of that. Claude can build truly robust systems. I can’t.

Google Drive as the communication bus

The three of us — operator, architect, coder — needed a shared workspace. Slack-style chat doesn’t work because Claude.ai and Claude Code don’t natively talk to each other. Local files require me to physically copy them between machines.

Google Drive solved it. It gives both Claude.ai and Claude Code full CRUD access to a shared Drive folder. The structure is dead simple:

AutomatedTrader/
├── Prompts/ ← architect writes spec docs here
├── Outputs/ ← coder writes result reports here
└── Design Notes/ ← architect maintains running design docs

When the architect writes a spec, it lands in Prompts/ as a dated markdown file. Claude Code reads the spec, executes it on the EC2 instance, and writes a result report to Outputs/. The architect reads the report and writes the next prompt. The loop continues.

Everything is persistent and searchable. Six weeks later the architect can open a prompt and the matching result report side by side and reconstruct exactly what was decided and why.

The part where I admit I don’t read anything

This is the most ridiculous part of the workflow, and also the most important.

I don’t read the specs. When the architect finishes writing a spec, it also hands me a copy-pasteable prompt — usually something like

Read the specs in Prompts/20260516_walk_forward.md on Google Drive and implement them.

I copy that prompt, paste it into Claude Code, hit enter. That’s it. I never open the spec document. The architect wrote it for the coder, not for me.

I don’t read the output reports either. When Claude Code finishes, it prints a high-level summary in the terminal — what it did, what it tested, what passed, what failed, and a link to the full result report on Drive. I take a screenshot of that terminal. I drop the screenshot into the architect’s chat window. The architect reads the terminal summary, follows the link to the full report on Drive, digests it, and tells me in three or four sentences what happened and what to do next.

I am not in the loop on the actual content of the specs or the reports. I am in the loop on decisions.

The architect surfaces tradeoffs — do you want to spend $20 of EC2 time on a full walk-forward run, or should we shortlist first? — and I make calls. That’s my whole job.

It sounds like I’ve been cut out of my own project. It is the opposite. I’m more in command of this project than I’ve been of anything since the stroke, because I’m spending my limited time budget on the decisions that actually need a human, not on reading technical artifacts I would barely understand anyway.

Screenshots instead of typing

This is the single biggest accessibility win, and the one I want most other developers to steal.

The old workflow for sharing Claude Code’s terminal output with another AI tool would have been: select the text, copy it, switch tabs, paste it. Four clicks minimum, more if the output is long, and your working memory takes a hit every context switch.

The new workflow is: cmd-shift-4, drag, drop into the chat.

I do this constantly. Claude Code terminal screenshots, training loss curves, error tracebacks, MetaTrader charts, broker UI screenshots, log files, model evaluation tables — all of it goes to the architect as screenshots. The architect reads them as well as it reads pasted text. Often better, because the visual context (which line is highlighted in red, which column matters) comes for free. It can even parse the most important parts of the image on its own.

This is the difference between “I’ll deal with it tomorrow” and “let’s iterate one more time before bed.”

The role split

The reason all of this works isn’t really that there are “two Claudes.” It’s that each of the three of us is doing only what we’re uniquely capable of doing, and nothing else.

• I focus on the business. What‘s the goal. What risks are acceptable. Whether to spend $200 on a feature ablation or $2,000 on a walk-forward run. Whether the project is even worth continuing.
• The architect focuses on product and interpretation. Translating my one-sentence goals into rigorous specs. Designing the ML architecture. Choosing the validation methodology. Reading the result reports. Translating findings from ML tests back into recommendations I can act on.
• The coder focuses on execution. Writing the code. Building the ML systems. Running the ML experiments. Hitting the broker APIs. Producing the reports.

None of us is doing the others’ jobs. The architect isn’t deciding the project’s direction; that’s my job. I’m not writing or reading specs; that’s the architect’s job. The architect isn’t typing the bash commands or writing code; that’s the coder’s job. The coder isn’t interpreting results in business terms; that’s the architect’s job.

It’s the same reason human software teams have separate product, engineering, and design roles. Same brain doing all three is faster on tiny tasks but worse on anything complex.

The time savings

I haven’t measured this rigorously, but my rough sense:

• Spec-writing time: roughly 95% reduction. The architect drafts much faster and much more thoroughly than a human can; I don’t even read the results. An hour of typing has become five minutes of answering clarifying questions.
• Report-reading time: also dramatically lower. I screenshot the terminal; the architect digests; I get a three-sentence summary.
• Iteration cycles: three to five times faster. The bottleneck used to be me, transcribing things between tools. Now I can run four to six full spec-to-code-to-review cycles in a session instead of one or two.

The accessibility piece deserves its own line. There are workflows that are nice-to-have for typical users and load-bearing for users like me. This is one of them. If you can snap screenshots rather than typing, you can drive a complex software project with very little typing at all.

What I’d tell someone trying this

1. Let the architect write the specs — and let the architect write the prompts you’ll send to the coder. Your job is to be the courier and the decision-maker, not the technical writer.
2. Use screenshots liberally. Don’t transcribe. The model reads and interprets complicated images.
3. Set up clear communications channels for the different agents. Doing this is critical to facilitate communications between the architect and the coding agents. The Prompts / Outputs / Design Notes pattern works because each folder has a clear role and the two agents know where to look.
4. Be honest about what you don’t know how to do. I can’t build ML prediction systems or production DevOps on my own. Claude can. Pretending otherwise would have me struggling with code I can’t really debug instead of making product decisions only I can make.

The trading system is still a work in progress. The reinforcement learning DDQN is in training, the walk-forward validation is finally getting wired up, and I have a long backlog of improvements. But the workflow feels solved. That’s a strange thing to say about an in-progress project, but it’s true: the tools are no longer the bottleneck. The work is.

If you’re building something complex with one or both hands tied behind your back — literal or otherwise — I’d love to hear how you’ve adapted your workflow. The accessibility frontier in AI coding tools is wide open and most of us are figuring it out in public.