Building a Python backend without ever having used Python

Today I set up a Python backend for playitsmart.nl. Three hours of work, foundation in place, it can talk to the database. And to be honest: I barely understand it.

I have practically never worked with Python in my life. Today I didn't either, really. What I did was sit at my terminal for three hours, pasting commands while Claude delivered them one by one. And after each command I asked: what are you actually doing? What's the effect? Am I taking a risk if this goes wrong?

That's a strange way of working. To be honest, also a bit scary.

What I do know

Before we started today, Claude and I had worked out an architecture document together. It describes which components the system has, how they communicate with each other, and why we made the choices we made. Which database (Supabase). Which language (Python). Which broker (Interactive Brokers). Which data feed (Financial Modeling Prep). Which rules the system uses to evaluate stocks. Which phasing we follow until we go live.

I understand that document. Every choice in it is deliberate. Pros and cons weighed, options compared, and decisions made about what fits. That's my work: structure, phasing, making decisions based on what we want to achieve.

What I don't know

But then comes today. We're turning that structure into actual code. A working back end that can talk to the database. A first step toward the automated trading system I want to build.

And that's where the part begins where I understand nothing. Which libraries you need, how to set up a virtual environment, why Python in this project needs to be a different version than on the rest of my Mac, what a service role key does, and why the database wouldn't let me read at first even though everything seemed correctly set up.

This is not false modesty. I don't know what I'm doing.

How it worked anyway

The approach was simple but strict: step, check, step, check. One command at a time. After each command a verification that it was actually what we wanted. When in doubt, ask follow-up questions.

Claude gave me three pieces of information each time:

First: what the command does. Not in depth, but understandable.

Second: how long it takes. "This takes five to ten minutes on your Mac, get comfortable." Or: "This is half a second." That's surprisingly important. A terminal that's doing nothing looks the same as a terminal that's broken. Knowing that it's normal to wait a few minutes makes a huge difference.

Third: which errors you might encounter, and what the next step is then.

And it went wrong. Three times today an error suddenly appeared on my screen that I didn't understand. Three times Claude calmly picked it up, made a diagnosis, gave one command to fix it, and we moved on.

At one point I had to have a kind of security token decoded to check whether it was the right one. I really have no idea what I was doing there. But it worked.

The risk I do have to deal with

At the end of the day, there's a working back end. It talks to the database, reads data, returns the correct answer. I built that myself, with Claude alongside.

And I don't really understand it at its core.

That's a bit risky. Because soon this system has to start investing my real money. Ten thousand euros to start, possibly more later. If something goes wrong in production later on, I can't dive into the log files myself to find the cause. I'm dependent on Claude to help me understand what's happening.

There's no easy answer to that. What I do do: ask as many questions as possible while building, so that at least I understand the structure behind each piece. Not the code itself, but why it does what it does. That distinction matters. If in a live situation I know which step the system should be doing at which moment, I can at least flag when something deviates from the plan, even if I can't read the code myself.

But it works

Even though I don't understand everything, today I set up something that wouldn't exist in three months without Claude. Maybe not at all.

That's what fascinates me about this era. I can build things I don't have the knowledge for at heart, provided that I do understand the structure behind them, and provided that I have the discipline to work step by step and not get ahead of myself.

The architecture document is my anchor. The step-by-step approach is my discipline. Claude is my co-pilot. Together we're building something neither of us could have made alone.

Tomorrow we're doing the first call to Financial Modeling Prep to bring in real data. There too, I don't know how it works in Python. There too, we'll do it step by step.

And in a few weeks, when everything is in place, there will be a system that buys and sells on the stock market by itself. Completely without me ever having written a line of Python.