What I Say When Someone Asks If I Can Actually Code

Someone asks a version of this question almost every time I mention what I build: do you actually know how to code? It comes up in IndieHackers threads, in DMs about the plugins, sometimes from people who just want to know if “built with AI” is a polite way of saying “didn’t build it.” For a while I gave a different answer depending on who was asking and how defensive I felt that day. I don’t do that anymore, mostly because I finally sat down and worked out what the honest answer actually is.

The short answer, and why I stopped using it

For a while my answer was just “no.” It’s not false. I didn’t study computer science, I didn’t come up through a bootcamp, and a couple of years ago the closest I’d gotten to writing software was formatting spreadsheets for production planning in a denim mill. “No” felt like the modest, honest answer.

The problem is that it’s not an accurate one. “No” implies I point at a product and someone else makes it appear, the way a client points at a logo and a designer makes it appear. That’s not what a day of building actually looks like for me. I write detailed specs, I review what gets built against them, I catch the parts that are wrong, and when something breaks in production I’m the one who has to work out why, with the same AI tool, usually late and usually annoyed. None of that is coding in the sense the question is asking about, but the question has no room for any of it either.

What I actually can and can’t do

How I test products I can’t read the code for already says the part that matters most, plainly: I can’t open a diff and tell you whether a function is written well. I can’t read a Supabase row-level security policy and know on sight whether it’s safe. That’s the true part of “no,” and it’s not a small part.

What I can do is trace what a product is supposed to do closely enough to notice when it isn’t doing that. I can run an n8n workflow with input designed to break it and point to exactly which node choked. I can take a bug report from a buyer, reproduce it, and describe the fix I want in enough detail that the next attempt actually lands. That’s a real skill, built over the plugins and boilerplates one bug report at a time. It just isn’t the skill the question is asking about, and answering “no” erases it along with the part I genuinely can’t do.

Why the question bothers me more than it should

Why I Keep Building New Products Instead of Fixing the Ones I Have came out of noticing a pattern in my own avoidance, and this question triggers a similar reflex. The easy move is to answer fast so the conversation moves on, either with a deflecting joke or with an overcorrected list of every technical-sounding thing I do, as if volume could stand in for precision. Both versions manage how the question makes me look more than they answer it.

The version that actually sits still long enough to be useful is the slower one: naming the specific thing I do (specify, review, test, debug through someone else’s hands) and the specific thing I don’t (write the implementation myself), without treating either half as the embarrassing one. A former textile engineer directing an AI through a feature isn’t the same job as a developer writing it line by line, and pretending otherwise wastes everyone’s time the moment something actually breaks.

Where I’ve landed

I still don’t have a one-word answer, and I’ve stopped looking for one. When it comes up now, I say I don’t write the code, and then I say what I do instead, in that order, because the second half explains the first instead of apologizing for it. Some people clearly wanted the one-word version and lose interest once I give them the longer one. That’s fine. The ones who stick around for the second half are usually the ones actually trying to work out if the same approach would hold up for them too, and that’s the conversation worth having anyway.