Last year I wrote about prompting GenAI for better coding outcomes. More recently, I wrote about what building an agentic architecture taught me about the future of software development — AI-assisted engineering at enterprise scale, with a team, inside governance guardrails, judged by business deliverables.
This post is the same question run at the opposite end of the spectrum. What happens when it’s just you — one person, nights and weekends, no guardrails except your own standards — using AI to build something real, carry it all the way through App Store review, and put it in front of actual users?
So I decided to find out. Over the past several months, I’ve been building a simple iOS app called Unashamed Games. On the surface, it’s a collection of classic games: Tic-Tac-Toe, Checkers, Solitaire, Sudoku, and Word Search. But for me it became something else entirely: a laboratory for exploring what AI-assisted software engineering looks like when you’re trying to ship a real product, not just generate impressive snippets.
Why a game? I deliberately chose something that wasn’t an enterprise application. Games have surprisingly demanding requirements — graphics, animation, state management, monetization, platform services, localization, App Store review — but the scope is small enough that one person can actually ship one. That made Unashamed Games an ideal place to learn what AI-assisted software engineering feels like from idea to production.
The first surprise wasn’t how much code the AI wrote. It was how quickly I stopped thinking about writing code at all. Somewhere around the third or fourth feature, I realized I was spending most of my time reading, questioning, refining, and deciding. The keyboard wasn’t where the engineering was happening anymore.
The six lessons below all trace back to that moment.
1. AI Made Implementation Cheap. Judgment Became Expensive.
The first thing you notice when building with AI is speed. Features that would have taken me a weekend took an evening. Unashamed Games grew from an idea into a shipped App Store application over the course of several months of evenings and weekends. I wouldn’t claim AI wrote every line of code — there were plenty of places where I stepped in — but it produced the overwhelming majority of the implementation.
The second thing you notice is subtler: implementation was never really the hard part. It just used to be the slow part, which hid how much of software engineering is actually judgment.
When AI can produce three plausible implementations of a Solitaire dealing algorithm in the time it takes to describe one, the bottleneck moves. Which approach fits the architecture? Which one will be maintainable when I add the next game? Is this the right feature to build at all? None of those questions got cheaper. If anything, they got more expensive, because I was making more of those decisions per hour than I ever have in my career.
In my experience, this is the single biggest shift AI brings to the profession. It doesn’t remove the engineering from software engineering. It concentrates it.
2. Shipping Exposes Problems AI Can’t Anticipate
Everything I generated compiled. Most of it passed tests. And none of that mattered the first time the app met the real world.
Detecting “no moves remaining” in Solitaire is a good example. The AI produced game logic that dealt cards correctly, enforced the rules, and even handled scoring. But determining that a game is actually unwinnable turned out to be an entirely different problem. It’s not enough to check whether there are obvious moves — you have to consider every legal move across the tableau, foundation, waste pile, and stock, while accounting for the fact that cycling the stock can create opportunities that didn’t exist a moment earlier.
I didn’t discover the bug by reading code. I discovered it by playing the game and realizing it kept encouraging me to keep searching long after there was nothing left to find. No prompt would have surfaced it, because I didn’t know to ask.
Checkers had its own version of this. The generated move validation handled ordinary moves just fine. The problems appeared around chained captures and the transitions between turns. The implementation would correctly recognize an initial capture, but the rules around whether another jump was mandatory required careful orchestration of game state that only became obvious after playing full games. The code wasn’t “wrong” in the traditional sense. It simply wasn’t complete enough to satisfy the way real people experience the game.
Then there was everything that had nothing to do with code at all. At one point the App Store simply refused to display my application icon correctly, even though Xcode validated the asset catalog and every required image was present. The eventual fix had nothing to do with algorithms or Swift. It came down to understanding Apple’s asset catalog expectations and how App Store Connect processed the upload. AI helped me investigate possibilities, but the debugging itself took experience, experimentation, and more patience than I’d like to admit.
Privacy disclosures, App Tracking Transparency for AdMob, and making sure the “Remove Ads” in-app purchase complied with Apple’s review guidelines were all engineering tasks, even though very little of them involved writing code. They required understanding platform policies every bit as much as understanding APIs.
Game Center achievements and localization were similar. Neither was technically difficult, but both required understanding the conventions and expectations of Apple’s ecosystem. Translating the text into multiple languages was the easy part; making the experience feel native everywhere took far longer.
TestFlight was perhaps the best reminder that users don’t think like developers. Family and friends found confusing interactions within hours that I’d completely overlooked after staring at the application for months. None of the bugs were spectacular. They were exactly the kinds of small usability issues that accumulate until a product feels unfinished.
AI is trained on code, and code is the part of shipping that’s already well documented. The friction lives everywhere else: in review guidelines, platform quirks, user behavior, and the gap between “works” and “feels right.” A model can help you respond to those problems once you’ve found them, but it can’t find them for you. Shipping does that.
This is also why I’ve become skeptical of AI productivity claims measured on code generation alone. Looking back, writing code accounted for much less of the project than I expected. Designing, polishing, testing, complying with platform requirements, iterating on feedback, and preparing for release consumed at least as much time as implementation — probably more.
3. Small Products Are the Best AI Laboratories
I could have run this experiment at work. I’m glad I didn’t.
Enterprise AI adoption is hard for reasons that have nothing to do with AI: risk, governance, legacy systems, stakeholders, budgets, politics. Every pilot project has to navigate all of them at once, which means most of what you learn is about your organization, not the technology. A small personal product strips all of that away. You learn the technology instead of the organization.
That’s not a knock on enterprise guardrails. In the agentic architecture post I argued that governance constraints produce better agentic systems, and I stand by that. But the two experiments teach different curricula. The accelerator taught me how to deploy this technology responsibly inside an organization. The game taught me what the technology itself can and can’t do. Try to learn both at once and the organizational lessons drown out the technical ones — which is exactly what happens in most enterprise AI pilots.
And you learn it across the entire lifecycle. The stakes are low, so you can let the AI take approaches you’d never risk in a production codebase, just to see what happens. The scope is complete — design, implementation, testing, release, monitoring, iteration — so you find out where AI helps beyond the coding phase. And the feedback loop is fast: you feel the consequences of every decision within days, not quarters.
There’s a leadership takeaway here too. The people in your organization who understand AI best probably aren’t the ones giving presentations about it. They’re the ones quietly shipping small things at night. Find them. Better yet, be one of them. The cost of running this experiment yourself is a few months of evenings, and the judgment you build is not something you can delegate.
4. My Role Changed from Developer to Reviewer to Editor
In my prompting post, I suggested treating generated code the way you’d treat a pull request from a junior developer. Building this app, that stopped being a metaphor. It became my job description.
I spent less time writing code and more time evaluating whether the outcome matched my intent. My days looked like a continuous code review: reading generated implementations, spotting the subtle misunderstanding of a requirement, deciding when “close enough” was actually good enough.
But “reviewer” turned out to be a transitional title too. Somewhere along the way I noticed I wasn’t really approving or rejecting code anymore. I was continuously reshaping it until it reflected the product I had in mind. That’s editing, not reviewing, and the distinction matters: a reviewer checks work against a standard, while an editor steers work toward a vision. The second one is a much bigger job, and it’s the one AI hands you.
What I didn’t expect is that this is harder than writing, and most engineers get far less practice at it. When you write code yourself, understanding comes free — you built the mental model as you went. When you edit AI-generated code, you have to construct that mental model from the outside, quickly, over and over, without the luxury of assuming the author understood the requirements.
It’s the same muscle I described in the agentic architecture post — reviewing outcomes instead of diffs — just exercised one conversation at a time instead of across hours of unattended agent work. The game is where that muscle gets built at a scale where mistakes are cheap. The skills that mattered most were the ones we traditionally treat as secondary: reading code critically, writing precise specifications, and knowing what questions to ask.
If I were designing an engineering career ladder today, I’d weight those skills very differently than most ladders currently do.
5. AI Didn’t Replace Craftsmanship. It Amplified It.
I expected AI-assisted development to push me toward “good enough.” It did the opposite.
When implementation is cheap, there’s no excuse for the rough edges you used to tolerate because fixing them wasn’t worth the effort. The animation that’s slightly off, the inconsistent spacing between game screens, the error state you never styled — all of those became fifteen-minute fixes instead of “someday” backlog items, which meant the only reason for them to remain in the product was that I didn’t care enough.
AI removes the alibi.
For most of my career, the honest answer to “why does this rough edge exist?” was some version of “we didn’t have time.” That answer is disappearing. The quality ceiling of a product is no longer set by how much time you have, but by your standards and your attention. Craftsmanship used to be partly about skilled execution; now it’s mostly about knowing what good looks like and refusing to ship until you get there.
6. Experience Became More Valuable, Not Less
I went into this project expecting to learn about AI. The most unexpected lesson was about me.
Ironically, thirty years of engineering experience became more valuable in this workflow, not less. The models could generate implementations — endlessly, patiently, in any style I asked for. What they couldn’t do was recognize elegance, notice unnecessary complexity, or decide that the simpler solution was better because the clever abstraction would cost more than it paid. Every one of those decisions still belonged to me, and I was making them constantly.
If you’ve been worried that AI devalues the judgment you’ve spent a career building, my experience points the other way. That judgment is the scarcest input in the whole workflow. AI just finally made it the thing you spend most of your day using.
Where This Leaves Us
What gives me confidence in these conclusions is that I’ve now reached them twice, from opposite directions. The accelerator was enterprise-scale: a team, governance guardrails, business stakeholders, an agentic loop running unattended for hours. Unashamed Games was the smallest scale software can be: one person, a chat window, evenings, and an App Store listing. The two projects had different constraints, different tools, and different stakes, and they still landed in the same place. Implementation got cheap. Judgment, specification, and review became the job.
Twenty years ago, the engineers who grew the fastest were the ones who wrote the most code. I don’t think that’s true anymore. I think the engineers who will grow the fastest over the next decade are the ones who learn to make the best decisions with AI as their collaborator.
Building Unashamed Games didn’t teach me that AI is replacing software engineering. It taught me that software engineering itself is evolving — and that the parts of it I value most are the ones that still require a human.
Next Step
Pick something small — weekend-project small — and commit to shipping it with AI as your primary implementation partner. Not a prototype: shipped, in front of strangers, with all the review requirements and edge cases and rough edges that entails. Pay attention to where the AI carried you and where it couldn’t. Those gaps are the most accurate picture you’ll get of what this technology means for how you work.
And if you happen to like classic games, Unashamed Games is on the App Store. Android is coming soon.
Resources
- What Building an Agentic Architecture Actually Taught Me About the Future of Software Development — the enterprise-scale counterpart to this post: the same shift, observed on a real team inside real guardrails
- Master GenAI Prompting for Better Coding Outcomes — the chat-workflow loop this project was built with, and the post that prompted the experiment
- What I Actually Look for When Hiring Software Developers — the hiring lens on the review-and-judgment skills this post argues are becoming the job
