Should you be selling software you don't fully understand?
by•
I’m building a marketplace and AI tools without a programming background.
Claude Code and Codex do the coding. I make the decisions, test the features, catch problems, and occasionally spend hours trying to understand why something that worked yesterday suddenly doesn’t. 😂
And here’s what I’ve been thinking lately…
AI has made it possible for people like me to build things we couldn’t have built alone.
But there’s a difference between being able to build something and being able to maintain it.
What happens when your platform grows? When something breaks in production? When security or customer payments are involved?
I’m learning as I go, but I definitely don’t understand every line of code behind my own platform.
So I’m genuinely curious:
Do you think non-technical founders should learn to code while building with AI, or is knowing how to manage, test, and validate AI-generated code enough?
I’d especially love to hear from experienced developers AND non-technical founders. I have a feeling the answers will be very different. 😂
31 views
Replies
Backend dev here, about ten years in. I use Claude Code every day now and it really changed how fast I ship, especially frontend, which was never my strong side.
But the part I don't hand off is the decisions. Which approach fits the problem, what happens when that table has 10x the rows, what breaks if this job runs twice. The model will happily write something that works today and falls over in six months, and it won't warn you.
So my take: you don't need to read every line, but you should be able to explain how your system works to someone else. Where the data lives, who can touch payments, what happens when a request fails halfway. If you can't, learn that part first. The syntax you can leave to the model.
I'm a developer, and I still don't read every line the agent writes. What I do keep in my head is the shape of the system: where the money is counted, who is allowed to write which field, what happens when a request dies halfway. An example from my own past: an older app of mine let the client write its own purchase counters into the database. It worked until it didn't, and that's exactly the kind of line a founder without a coding background would never spot in a diff. In my current app credits are written only by the backend and the security rules forbid everything else. So my answer is close to Luiz's: don't learn syntax, learn the questions. Who can write this, what does a retry do, where does the secret live. Ask the model those questions about its own code and make it answer. That's more useful than reading the code yourself.
I'm somewhere in between. I wrote Perl and PHP for years, but these days I don't read the code my agents write.
For the scary parts, security and payments, what matters to me is that the rules are written down once and every product follows them, whether or not I'm watching. Every login locks after 5 failed attempts, counted per account and per IP. Secrets never go in the code. Errors from every product land in one place. Destructive database commands get blocked by a hook before they run, and that's one of 62 hooks in my agent's settings. No product ships until it passes the E2E tests in my in-house standard.
So no, I don't think you need to understand every line. You do need rules that don't depend on you remembering them.
the part thats missing here is who you call when it breaks at 2am. you dont need to read every line but before payments go live id want a dev you can actually reach who already knows the codebase, otherwise a small bug turns into days of downtime
The agent generated a data pipeline, wrote tests that passed, and reported the migration was clean. In reality it swallowed exceptions and silently dropped records. The agent being wrong was not the issue. Trusting its assurance that everything was fine is what cost a client.