How I Use AI as a Developer Without Losing My Judgment
My own writing got flagged as 100 percent AI-generated. Rewriting it by hand taught me more about AI than any prompt ever did.
The day after I published it, I ran the article through Pangram, the AI-analysis tool Substack uses. It came back flagged: AI generated, 100 percent. AI-assisted, zero. Human, zero.
I did not argue with the result. I reread the article and realized the detector was right in the way that actually matters.
Not because a machine wrote it. Because the writing was so clean, so balanced, so symmetrical, that no real person would own it. Every section matched the section before it. Every argument had its counterweight. Every paragraph was the same polite length, and the conclusion tied everything in a neat bow. It was polished, and polished is anonymous. There was nothing in it that proved someone lived the ideas.
This article is that rewrite. I am doing it by hand, slowly, on purpose. Because the experience is the best example I have of the thing I keep telling my students about AI and judgment, and I refused to explain it the same way I got flagged for.
The Debugging Story I Keep Coming Back To
A few months ago I was debugging a database issue late at night. The error message was vague. I pasted it into an AI tool and asked for an explanation. It gave me a confident, well-structured answer. I implemented the fix. It did not work.
I gave it more context, the query, the schema, the whole thing. Same confident answer, same failure. Two rounds of that and I was tired and a little embarrassed, because I had done exactly what I warn people about.
What finally worked was boring. I turned off the AI. I opened the database client and traced through the logic myself, table by table, function by function, until I saw what was actually happening. The fix itself took about thirty seconds once I understood. The understanding took the rest of the night.
That is the whole argument of this article in one incident. When I understand the problem deeply, AI makes me faster. When I am confused, AI hands me fluent nonsense dressed as expertise. The tool does not know the difference. I have to.
I have repeated this pattern often enough that I no longer trust my first instinct to trust the answer. I trust it only after I can trace the reasoning myself.
Why Understanding Comes First
I did not learn this from a book. I learned it by building software from Nigeria, where the context around the code matters in ways that are hard to explain until you live them.
Here, the internet drops. The power goes. Payment providers behave differently. A library that works smoothly in a tutorial does something unexpected under these conditions. You learn that the tool is a tool, and the environment is real, and the two are not the same thing. AI amplifies whatever you already understand, and if you do not understand the environment your code runs in, amplification does not help you.
I have built and deployed enough small products, including 4orm4orge, my form-building platform, to know that the hardest problems are rarely in the feature you are excited about. They live in deployment, in authentication, in infrastructure decisions. I made one of those decisions for 4orm4orge in an afternoon and paid for it over months. The payment was the part the AI could not see coming, because the AI did not have to live with the choice. AI can generate the feature code. It cannot feel the weight of a hosting decision you now have to live with.
That is the part that keeps me honest. The skills that moved from the margin to the center of my work, reading code carefully, debugging systematically, understanding system behavior, evaluating whether a proposed solution fits the actual constraints, are the skills you cannot get from a chat interface. They only come from doing the work and sitting with the failure.
The Students Who Made Me Uncomfortable
The clearest version of this is in my teaching. I run CTROTECH and Ctrotech Tutor Insights, and I have taught over two hundred students how to code.
Last term I noticed a pattern that unsettled me. Some students were submitting correct solutions to coding assessments. When I asked them to walk me through the logic, they could not. They had the right answer and no process. The AI had written the solution, and the moment I changed the problem slightly, one small detail, they were lost.
I am not angry about this. I am worried about them, and I recognize the feeling because I have done the same thing myself with that database bug. The difference is that I got caught by the world pushing back. They have not been caught yet, and I am not sure what will catch them.
The students who do well are not the ones who never touch AI. They are the ones who use it and then can explain, in their own words, why the code works. The explanation is the skill. The code is just the artifact.
What I Actually Use AI For
Let me be concrete about my actual workflow, because it is less dramatic than the headlines.
Research. AI is excellent here. It summarizes documentation, compares approaches, and surfaces details I would miss in an hour of clicking. When I am comparing two ways to do something in 4orm4orge, that first pass is fast now. I still verify against the primary source before I trust it.
Debugging. Useful and unreliable, both at once. I use it to generate hypotheses and test cases. I never apply a diagnosis without tracing it myself. The database night taught me that, and I changed my behavior because of it. I chose to trust the tracing, not the answer.
Architecture. AI is a thinking partner. I describe the problem and my proposed approach, and it challenges assumptions. The final call is mine, and it stays mine because I am the one who will debug it at 1 a.m. when it breaks. That is not a principle. It is a consequence of being the one who deploys the thing.
Writing. This is where I changed my mind. I used to treat AI as a first draft generator. Then I spent days rejecting fluent, polished text that said nothing personal, rewriting sentence after sentence until it sounded like me. That experience is why this article exists. Now I use AI to catch structural problems in a draft I have already shaped, and I never let it write the parts that carry my point of view.
Code generation. AI handles the straightforward parts, the glue, the boilerplate, the code I would have written anyway. The parts that require judgment, the tradeoffs, the decisions with consequences, those are mine.
The common thread is not that I am in control in some philosophical sense. It is simpler than that. I am the one who will live with the result, in production, in front of students, in my own reputation. That changes what I am willing to trust.
The Things I Keep Doing, Even When They Are Slow
I have a few practices that look inefficient and are not.
I read code I did not write, including AI code, line by line, until I can explain it to someone else. This is the bug that was fixed in thirty seconds and understood in hours. The fix was easy. The understanding is what prevents the next bug.
I delete things I was excited about. The feature I was most proud of in one product is the feature I eventually removed. Deleting it made the product better. AI never suggests the delete, because the delete is not an addition.
I keep my fundamentals sharp. I can still write code, debug, and design systems without AI. I do not need to do these every day. But I need to be capable of them, because the day I stop being capable is the day AI stops being a tool and becomes a crutch I cannot set down.
I make the final call and own it. Architecture, teaching, what gets published: the last decision belongs to a person who can be wrong.
A Framework, The Way I Actually Use It
I get asked for a framework, so here is the one I have settled into. It is not abstract. These are things I do.
Know what you want before you ask. If I cannot describe the problem without AI, AI cannot solve it for me. The clearest prompts come from the clearest thinking, not the other way around. I notice this every time I sit down to ask a tool something: the good questions are the ones I could almost answer myself.
Treat AI as a collaborator, not an oracle. It is wrong often enough, especially on nuanced problems. I ask for possibilities, not verdicts, and I reserve the verdict for myself.
Verify everything that matters. Trivial code gets a quick check. Important decisions get full verification. I started doing this properly after the database night, when a confident answer cost me the evening. There is no shortcut here, and pretending there is one is how the confident nonsense gets deployed.
Use AI to learn, not just to produce. When AI writes something I do not understand, I stop and figure it out. That moment of confusion is where the growth lives. Skipping it feels efficient and is not. It is the one rule I break when I am tired, and it is the one I watch my own students break first.
Understand before you amplify. This is the whole thing. AI is a multiplier. It multiplies what is already there. If I have done the work, it multiplies my judgment. If I have not, it multiplies my confusion with better grammar. I know this from the inside, because I have watched myself do both.
What Has Not Changed
I used to think AI would rewrite everything about being a developer. It has changed real parts of my workflow. The fundamentals, the parts I was most worried about, have barely moved.
Understanding the problem still matters more than writing the solution. Reading code is still the skill that separates people who maintain systems from people who fear them. Systematic debugging is worth more now, not less, because the easy problems are automated and the ones left are the ones AI cannot handle. Teaching and mentoring, caring about quality, making honest tradeoffs: none of these are threatened by AI. They are made more valuable by it.
The developers who struggle will not be the ones who use AI. They will be the ones who outsource their thinking to it, including the thinking about what they publish under their own name.
The Real Question
So here is the question I am actually living with, after this week: the problem is not whether AI makes developers obsolete. The problem is whether I keep investing in the judgment that makes me effective.
I rewrote this article by hand because the version written mostly with AI was too clean to be mine. That was a deliberate choice, and it is the same choice I am asking my students to make. That is a strange thing to discover about your own writing, and I am still processing it.
I am not sure I have this fully figured out. I am still making mistakes, like that night with the database, and I will make more. But I know this much: the tools do not create judgment. They reveal what I already have, and they reveal what I have stopped building. I am choosing to keep building.
If you have thoughts on how you keep your judgment sharp while using AI, I would like to hear them. Reply to this email or leave a comment. I am genuinely interested in how other people handle this.
Cross-links:
I Taught 200+ Beginners to Code. Here Is What It Taught Me About Writing Better Software: on engineering clarity
AI Architecture Partners: How I Design Systems with AI (upcoming)
Further reading:
Using AI for Debugging: A Practical Guide (upcoming)
AI Architecture Partners: How I Design Systems with AI (upcoming)