I do not write code. Here is what I shipped anyway.

I am an engineer by training, a Ph.D. and a P.E., but I have never been a software developer. I do not write the code. For about a year now I have run a real software operation anyway, with Claude doing the writing and me doing the deciding. This is a plain account of what that actually produced, including the parts that did not work.

The scoreboard, stated at the confidence it deserves

More than thirty services run in production today, doing business development, customer research, technical analysis, and document generation. Separately, and more checkable by a stranger, more than twenty fixes I authored have been merged into open-source projects I do not own, across sixteen different codebases in fields from reactor physics to ocean modeling to bioinformatics. Another sixty-odd are open and under review. Every one carries my name and a real reproduction, not a bot signature. You can go read them.

What the job actually is

When you are not typing the code, the work moves up a level. My day is scoping a problem so it can be handed off cleanly, deciding which of three approaches is worth trying, reading a diff for the thing that will break in production, and saying no to the plausible-but-wrong answer. The model is fast and tireless and occasionally very confidently mistaken. My job is to be the judgment in the loop. That turns out to be a full-time job, and it is a different one than writing the code myself would have been.

The failure rate, out loud

Here is the part most demos skip. I built a scanner that hunts for a recurring class of bug across open-source scientific code, then has a large model read the suspect files and rate its findings. Even the findings it rated at maximum confidence were wrong forty to fifty percent of the time. The model rubber-stamps anything that looks surgical. The only thing that reliably separated a real bug from a convincing hallucination was boring: clone the repository, reproduce the failure, run the test suite, read the surrounding code. Not one fix went upstream without passing that gate, and I threw away more than a dozen confident-looking candidates that did not survive it.

The rejections count too

I opened a pull request to a project whose maintainer simply did not want the change. He said so, and he was right to. Some communities have decided they do not accept AI-assisted contributions at all, and the correct response is to respect that and walk away, even when the bug is real. A contribution that ignores what a maintainer asked for is worse than no contribution. Volume is not the goal. A few careful, disclosed, human-owned fixes to people who want them beats a flood every time.

The one habit that made it hold up

If there is a transferable lesson, it is this. The model is a strong negative filter and a weak positive one. It is very good at telling you something is definitely wrong, and unreliable at telling you something is definitely right. So I stopped trusting any answer that had not survived contact with reality: a test that runs, a page that loads, a customer who used it. State claims at the confidence the evidence supports, and leave the people around you more capable than you found them. That is most of it. The rest is showing up every day and deciding well.