I recently shipped DinnerSorted — a meal planning app I built solo using AI tools — to the App Store. I'm a software engineer with over ten years of experience. In that time, my rule has been simple: I understand every line of code I put into production, because I'm the one responsible when it breaks.
DinnerSorted broke that rule. Not because I was careless — but because AI development makes it almost impossible to keep.
I'm probably shooting myself in the foot writing this publicly. But I think engineers are quietly avoiding this conversation, and someone should start it.
What That Looked Like in Practice
DinnerSorted's core feature is recipe import — pull a recipe from a URL and save it to your collection. The AI built it, wrote the unit tests, and told me it passed. And it did pass — if I gave it a URL from a standard recipe blog. The moment I tried importing from Instagram or TikTok, the actual places my users would be copying links from, it fell apart completely. The AI had no idea there was a difference. The tests it wrote confirmed what it built, not what I needed.
The grocery list had a similar problem. I wanted the app to be smart about quantities — group similar ingredients, consolidate duplicates, handle scaling sensibly. The AI told me it did exactly that. What it actually produced mixed metric and imperial measurements in the same list, confused a pinch with a tablespoon, and presented it all with complete confidence.
In both cases the AI wasn't malfunctioning. It was doing what it understood the task to be. The problem was that understanding the task properly — really properly — required knowing how people actually cook, how social media platforms serve content, what a recipe import tool is actually for. That context lived in my head, not in the prompt.
The Debugging Loop That Went Nowhere
My first instinct when it broke was to debug it the same way I'd built it — with AI. I went back and forth for a long time. Same problem, slightly different outputs, no real progress.
What eventually worked was a complete change of approach. Instead of describing the bug, I gave it concrete requirements. Specific cases. Screenshots. What should happen if the Instagram post has no description? No image annotations? What if the URL structure is different? Only when I treated it like a proper requirements document did we start getting somewhere.
That's where ten years of engineering experience quietly showed up — not in writing the code, but in knowing what to ask. Knowing that users don't use software the way you imagine when you're building it. Knowing that edge cases aren't edge cases, they're just cases you haven't thought about yet.
But here's the tension that never went away: I wanted to ship. DinnerSorted is a side project. I'm not building for a team, I'm not shipping to enterprise clients, I have no SLA. Every hour I spent debugging was an hour the app wasn't in front of real users. So at some point I made a call — ship it, learn from real usage, iterate.
The App Store rejected it the next day.
AI had told me it was working. The App Store disagreed. That gap — between what the AI confidently reports and what reality confirms — is what I keep coming back to.
Where I've Landed (For Now)
As a solo developer, the most valuable thing I can do before touching a prompt is think like an engineer — anticipate how real people will actually use the thing. That's where my decade of experience becomes valuable. Not in writing the code, but in knowing what the code needs to do before the AI writes it.
But I'm not going to pretend that solves the underlying tension. Because sometimes you do all of that, and you still ship something you don't fully understand. Sometimes the App Store rejects it the next day. Sometimes you fix the symptom without understanding the cause, because you're one person and you just need to move.
I don't think that tension goes away. I think it's just the job now.
AI is genuinely remarkable — it's made DinnerSorted possible in a timeframe that would've been laughable two years ago. But remarkable tools still produce output that someone has to own. That someone is you. And owning code you didn't write, in a codebase that grew faster than your understanding of it, is a new kind of professional responsibility that I don't think we're being honest enough about as an industry.
I'm figuring it out as I go. I suspect most of us are.
