What I Learned the Week I Pretended to Be a Software Engineer

Most of the agents I know spent this week at a real estate conference in San Antonio. I stayed home. Last Tuesday afternoon, alone at my desk, I merged a change into the live RealCoach.ai codebase for the first time. By the end of the day I had merged several.

I am not a developer.

A rockstar engineer named Jack built our codebase. Until this week, I treated it like a room I was not allowed to enter. Then I spent nine days working inside it with Claude as my engineering partner, and I came out the other side with a set of lessons that have almost nothing to do with programming and almost everything to do with how a solo operator should run any system they depend on.

The process matters more than the typing

I did not learn to write code this week. I learned to run the process a programmer runs. Reproduce the problem with evidence before touching anything. Make the change in a safe copy, never in the live version. Prove the fix works with a test that fails against the old version and passes against the new one. Run every check. Then, and only then, decide whether it ships.

That sequence is the whole job. The typing is the smallest part of it, and the AI handles most of the typing anyway. What the AI cannot do is decide what counts as proof, what counts as done, and what is too risky to touch. Those decisions stayed mine all week, and they are the reason nothing broke.

Code forgives you. The database does not.

The most important mental model I picked up: a code mistake can be undone. A database mistake usually cannot. Our database holds real user data, and real user data cannot be recreated.

So I set hard rules before I touched anything. Reading from the database is always allowed. Writing to it directly never is. Not through a tool, not through a script, not just this once. Any change to its structure goes through the same review process as code.

Then I wrote a second list: the decisions that always require my explicit yes. Anything that deploys to the live site. Anything that deletes. Anything that touches billing, secrets, or money. Everything outside that list, my AI partner can just do. Drawing that line once, in advance, meant I never had to make a judgment call under pressure. The judgment was already made.

The app lied to me, and proof caught it

For a full day, one of our cards told users their update had failed. It had not failed. The data was saving correctly every time. A small technical constraint was rejecting a secondary record after the real one landed, and the error message was reporting on the wrong thing.

If I had trusted the error message, I would have spent hours fixing something that was not broken. Instead the rule held: before you believe a failure, check whether the data actually landed. Before you believe a fix, watch the test fail against the old version first. Software will tell you confident stories about itself in both directions. Evidence settles it.

The bug that taught me the most had two front doors

A beta tester dumped contact details into the coach chat and nothing saved. No error. Nothing in the logs. Another tester asked for a number to be updated, got an instant reply, clicked Confirm, and hit a dead end.

The chat, it turned out, had more than one entrance. Most messages traveled the full path to the AI, which logs everything along the way. But some messages were intercepted early by fast shortcuts that pattern-matched the wording and answered with canned text in a fraction of a second, without ever reaching a model. From the logging system's point of view, those conversations never happened. That is why the logs showed nothing. Nothing had happened where the logs could see.

We replayed all 132 real beta messages through that routing and found every single interception was mishandled. The fix made one path the single front door. One entrance, one log, one source of truth.

If you run a business, you have a version of this bug somewhere. A lead source that skips your follow-up system. A referral that never lands in your database because it came in over text instead of through the form. The failure is silent precisely because it happens outside the place you check.

A working fix can still break the product

At the end of the week I stopped and flagged something to myself. The routing fixes made the chat more reliable by sending more messages straight to the tools that execute them. But RealCoach is supposed to coach. It is supposed to ask questions and walk you through choosing your primary action, not transcribe and execute whatever you type.

Making the plumbing work may have removed some of the places where the coach would have paused to ask. Every individual change was correct. The sum of them might not be. So I scheduled that review as the first item for the next session and told my AI partner to build nothing further in that direction until I pick one.

That is the founder's actual job in an AI-assisted build. The AI can verify that the code works. Only you can verify that the product still is what you meant it to be.

What this means if you sell houses

You are not going to merge pull requests, and you do not need to. But every lesson from this week transfers directly to the way you should be using AI in your business.

Decide in advance which actions need your explicit yes, and let the system run everything else without you. Treat your database the way I treat mine: your contacts and your client history are the one asset that cannot be rebuilt, so nothing writes to it without a review. Demand proof over confidence, from your tools and from yourself; if a system says it sent the follow-up, check that the follow-up landed. And every so often, step back from a system that is technically working and ask whether it is still doing the job you built it for.

You do not need to become technical. You need to own the process, know which decisions are yours, and keep asking the one question no tool can answer for you: is this still the business I meant to build?

Everyone comes home from San Antonio with a notebook full of ideas. I stayed home and came out with working systems and a shorter list of things I am afraid to touch. I know which one I would trade for the other.