Shipped, Not Prototyped

There is a Gap and no-one likes talking about it

Any Tom, Dick, and Harry, can log into their Claude/OpenAI chat box, and start chatting away (that too via voice -- don't get me even started on how wasteful and useless that it), and come up with an "App" that they think will completely "Disrupt" and "Change" everyone's world and life for good, forever. Literally any person with no engineering background or actual app development experience can make an "App" and it will work as they had expected it to. It will do what they had chatted about. It will look, at best, convincing. Which means that screenshots have become cheap, screen-recordings and demos have become cheap. A landing page for a product that is no better than a shady half-baked promise, is practically free today.

However, what has remained expensive -- is Shipping.

Let me show you some data on this, before you think I am some tin-foil-hat-wearing-end-is-nigh shill-hack.

Google's DORA team surveyed around 5000 tech professionals and roughly 90 percent said that they used AI in their work. While 65 percent said that they heavily relied on it. I don't think anyone was surprised with these results. If you were then you were living under a rock -- welcome to the real world buddy, the sun is harsh, the air spicy, and the water might make you vomit -- anyway, the more interesting finding here was that most of the developers, when auditing their work, found that they spent way more timing spinning, fixing, reworking, and ended up with increased recovery times - causing a high delivery instability.

Now, this to me, does not seem like a tool issue. It seems to be far more a systems issue.

In Stack Overflow's 2025 Developer Survey, with more than 49,000 respondents across 177 countries, found the same thing expressed as human frustration. To cut a super long story with a lot of numbers and horsing around short, the single biggest complaint was that AI solutions are "almost right, but not quite."

Now, for the star of the show, in terms of surveys, the one that got everyone shivering their timbers. In 2025, METR ran a randomized controlled trial with sixteen experienced open-source developers working on real issues in their own mature repositories. When they were allowed to use AI tools, they took about 19 percent longer to completer their tasks. And here's the kicker -- they thought that AI had sped them up by 20 percent. While the codebases were large, and the tools largely unfamiliar, I think it is still important to understand how a false sense of productivity can creep in with AI tools.

That brings us to -- where are we? We are here:

Generation is solved
Perception of speed is oversolved.
Reliability and Trust is currently a prio-0 issue that almost no one is considering or even talking about.

I have spent the last couple of years working on how to get to production despite where we are and where we have been. And to be honest with you, I have reached a good place. This is not a brag, or a Salesman's pitch, you will find no Gen AI Mastery in 12 Days course at the end of this article here. What you may end up with though, is evidence, and a sense of how to do it too.

I have made many apps, software, and products, on my own free time, on my own accord, needs and requirements. Some of them are games that I have always wanted to play, and though that others would enjoy. Some of them are apps that I still continue to rely heavily on a daily basis, and some of them are replacements for app that I used to rely on heavily on a daily basis but they have stopped working because the developer decided to move or the latest OS version became too much of a pain to maintain. This across multiple platforms too, MacOS, iOS, Android, Windows, Linux. If I have a need -- then I make it. If it is working well, then I shift into Production gears and release it. I want to share some of those apps with you, and you can find them below:

Live on Google Play.

EdgeCase is an Android app that draws a persistent, always-visible sliver overlay on top of every other app on the device, with its own interaction model, theming and configuration.
BOTCH is a Storyteller's companion app for the board game Blood on the Clocktower and it exists in two generations: an original build that accumulated a real install base with real players using it at real game tables, and a full native Android rewrite that shipped in August 2026.
Mach2 is the kind of entry nobody puts on a portfolio. It's an older title that had to go back onto the Play Store, which meant bringing an engine build and an ads SDK up to current platform requirements ahead of a compliance deadline, and getting through reviews.
BomberWordy is a game I started as a joke. The joke was that soon people will become so reliant on AI and Short Form content that they would not be able to read. And apocalypse would be a knowledge war. And so came the idea of dropping words as bombs, and typing them correctly to save yourself. No auto-correct is going to help you here

And the rest:

Suns - a terminal system utility for macOS in Go with a full TUI. My response to not wanting to pay 20 dollars to CleanMyMac, and also get the work done without leaving the terminal.
Anumey's Lair, this very website of course. You want production proof? Buddy, take a look around. P. S. I recommend playing around with

One thing that I want to clear up before anything, I am a professional software developer. I could do all this and more without using AI, of course, that is what I have been doing for the last 8 years anyway. However, that is not the point. The point is what I can do with AI, and how many avenues that ends up opening for me.

The last ten percent is the whole job

Here's the part that separates a demo from a product, and it's where almost all AI-assisted projects die. Let me be specific, because specificity is the only real proof of experience.

A green build tells you almost nothing. On one release, everything compiled cleanly, the release artifact was signed, and the app died before its first screen appeared. The cause: the release-mode code shrinker had removed a no-argument constructor from a generated database implementation class, because nothing in the code called it directly — the persistence framework creates it by reflection at runtime. The framework version came in transitively through an advertising SDK's dependency chain, and the consumer rules that shipped with that SDK preserved the class but not its members. Diagnosing it meant reading the shrinker's usage report rather than its symbol mapping, because I needed to know what had been removed, not what had been renamed. No test caught it. No compiler warned. The only signal was a launch crash on a device.

If your workflow's definition of done is "the build succeeded," this class of bug ships to your users. I've watched enough AI-assisted projects to say with confidence that this is the modal failure: plausible code, successful build, broken product.

Platform compliance is a moving target with hard deadlines. In the last cycle alone: a foreground-service type declaration that requires an extra manifest property from a specific target SDK onward, which appears on no checklist and produces a runtime failure rather than a build error; developer identity verification that had to be completed across every published app before a fixed cut-off date or the listings would be affected; consent-management integration so that users in regulated jurisdictions get a compliant experience before any ad loads; and a data-safety declaration that has to actually match what the binary does. None of this is interesting. All of it is mandatory. An agent will not tell you about it, because it isn't in the code.

Published claims are engineering constraints. My overlay app's privacy policy asserts specific properties of the software: that it makes no network requests of its own, that it never persists the list of installed apps, that it keeps no usage history, that it cannot read what's underneath the overlay, and that it isn't an accessibility service. Each of those is a promise a user relies on and a regulator could test. Breaking one of them fails no build and no test. It just silently makes a published legal document false. Keeping code and public claims in lockstep is a discipline, not a feature.

Devices don't care about your assumptions. A small-screen layout problem on one app looked like a simple fix: add a height qualifier and ship the compact layout under it. My first threshold was wrong, because my estimate of the vertical space consumed by a fixed element was off by nearly thirty density-independent pixels, and because Android resource qualifiers express minimums, which forces the layout logic to invert from the way you'd naturally write it. The correct threshold came from measuring on a real device, not from arithmetic. Every mature product I've shipped has a handful of numbers like that in it: measured, not derived, and documented as such so nobody "tidies" them back to the broken version.

Size, performance and stability are specified, then verified. Release builds shrunk from roughly 22 MB to under 6 MB. Cold-start and frame budgets stated as numbers, not adjectives, and checked with platform tooling rather than by feel. Game loops locked to a fixed timestep with an explicit accumulator so behaviour doesn't change with frame rate. Random number generation built on a named, high-quality algorithm with rejection sampling instead of modulo bias, split streams for independent sequences, and a project-wide ban on the convenience shuffle-and-random calls most code reaches for, including in test code. For a product whose entire premise is fairness, "it looked random" is not a standard.

Determinism where determinism is the product. My audio system's central guarantee is that the same input renders to byte-identical output every time. That single constraint dictates the architecture: which third-party code is allowed inside the boundary, how mixing and decoding are owned, and how verification works. It also makes regressions instantly visible, which is a luxury most codebases don't give themselves.

Destructive operations get a plan before they get permission. A system utility that permanently deletes things on someone's machine needs a fundamentally different design posture from an app that draws a rectangle. Mine routes every destructive action through an inspectable plan with separate confirmation and execution stages, and its filesystem deletion path is written to resist time-of-check-to-time-of-use races rather than assuming the world stays still between two calls.

That list is what "production grade" means in practice. Not a nicer UI. Not more features. It's the unglamorous, unshippable-without layer that AI is worst at, because most of it isn't visible in the code at all.

What I know that the prompt-engineering posts don't tell you

I've built a full method for this: a working system for taking a project from a raw idea to a released, maintained product using AI agents as the primary implementation labour, with quality high enough to survive store review, real users and later maintenance by someone who has forgotten everything about it.

I'm not going to publish the mechanics. The documents, formats, gates and enforcement mechanisms are the result of a couple of years of expensive trial and error across a dozen real projects, and they're the thing I bring to a team. But I'll happily state the principles, because the principles alone will tell an experienced engineer whether I know what I'm talking about, and they map directly onto the industry data above.

One. The agent has no memory, so state has to be engineered. Every session starts from zero. Anything that matters and lives only in a conversation is gone. The consequence people miss is that your project needs an explicit, verifiable representation of its own current state, and that representation has to be checked against reality rather than trusted. Almost every "the AI wrecked my codebase in week three" story is a state problem wearing a code problem's clothes.

Two. Precision has to be spent where reversal is expensive. Being maximally specific about everything is its own failure mode: Anthropic's own engineering work on long-running agent harnesses found that over-specified, wrong technical details cascade into the implementation. Being vague is a worse failure mode. The skill is knowing which decisions are effectively permanent (persisted schemas, identifiers, public formats, core algorithms, design tokens, safety invariants) and spending the precision there, while leaving implementation latitude where change is cheap.

Three. The author cannot grade its own work. Ask a model to evaluate what it just produced and it will tell you it's excellent. Anthropic's published harness experiments describe exactly this: generators are confidently generous with themselves, and the tractable fix is a separately tuned, skeptical evaluator. My workflow builds the same asymmetry in at every level, from specifications to phase reviews. It's also why a certain amount of adversarial review comes from a different model entirely.

Four. "Done" must mean evidence, not assertion. The most common agent failure in the wild is premature completion: the feature is declared finished on the strength of a passing unit test while the actual end-to-end path is broken. Anthropic reported large quality gains simply from requiring agents to test the way a real user would, with the tools to do it. The corollary is that your highest-leverage investment isn't a better prompt, it's giving the agent a check it can run itself — a test command, a launch command, a rendered screenshot, a hash comparison. Without one, you are the verification loop, and you don't scale.

Five. Rules you merely state will be broken; rules the environment enforces won't be. Prose in a project document is advisory. An agent can misread it, lose it to context compaction, or decide it doesn't apply this time. Anything that must hold every single time belongs in configuration, permissions and automated gates, not in a paragraph.

Six. More context is not better context. Independent research on long-context behaviour found that model reliability degrades as input grows, and that semantically similar but irrelevant material is actively harmful, not neutral. Newer models handle long inputs far better than 2025-era ones, but the economics and the attention problem both still favour the smallest high-signal set of information per task. Dumping your whole repository and every document into a session is a beginner move that feels thorough.

Seven. Scaffolding has a shelf life. Every workaround you build encodes an assumption about what the model can't do yet. Models improve; assumptions expire. Anthropic removed an entire orchestration layer from their own harness once a newer model handled long builds coherently. If you don't periodically test your process against the current generation of models, you end up paying for ceremony that stopped buying you anything a year ago.

Read those seven back and notice what they have in common. Not one of them is about prompts. They're all systems engineering, which is precisely what DORA concluded from 5,000 professionals: the value of AI is unlocked by the environment around the tools, not the tools themselves. The gap between an 84 percent adoption rate and a 46 percent distrust rate is a gap that gets closed by engineering practice, and it is being closed by very few people right now.

One project, end to end, at the level I can describe publicly

Take the overlay app, since it's the most recent and the most checkable.

It started as a personal irritation: I wanted a persistent, glanceable sliver of interface available on top of everything else on the phone, without it behaving like a notification, without it needing invasive permissions, and without it looking like a system component someone had bolted on. That's a product idea, and product ideas are worth very little on their own.

Making it real meant clearing a series of gates, and it's worth listing them because this sequence is the actual shape of shipping, whoever or whatever writes the code.

It had to work on top of arbitrary other applications, which on Android means the overlay window class, a special permission users grant manually, and a lifecycle that survives the system reclaiming resources. It had to do that without being an accessibility service and without the ability to read what's beneath it, which was a deliberate design constraint chosen so the privacy promise could be an architectural fact rather than a policy sentence. It needed configuration, persistence and theming, plus adaptive layout for small screens, which turned out to be the measured-threshold problem I described earlier. It needed instrumented tests that run on a device, because the classes in question depend on platform graphics types that don't exist off-device. It needed a signed, shrunk release build that actually launches, which is where the reflection-stripping crash surfaced. It needed monetisation wired in with consent handling for regulated jurisdictions. It needed a hosted privacy policy, a data-deletion path and an ads declaration on my own domain. It needed the store listing, screenshots, data-safety answers and a review pass. Then, after publishing, it needed a maintenance release within the same month for issues found by real use, plus identity verification for the developer account before a platform deadline that applied to every app I have listed.

Two published releases, a live listing, a functioning monetisation path, no outstanding policy issues.

Notice what fraction of that list is "write the feature." Maybe a fifth. The rest is the part that makes the difference between something you can show and something you can sell, and it's the part that no amount of code generation touches. Anyone can build the overlay. Comparatively few people can get the overlay through everything that stands between the overlay and a user.

How to tell whether someone can actually ship with AI

Since I'm arguing that this is a real and rare skill, it's only fair to give you the means to test the claim on anybody, including me. If you're hiring for it, or evaluating a contractor or an agency who says they build with AI, these are the questions I'd ask. They're diagnostic because the answers are hard to fake and they don't depend on trusting anyone's self-reported speed.

"Show me something live, and tell me what broke between the working build and the release." Everyone has a demo. The people who have shipped have a story about a release-mode-only failure, a store rejection, a platform deadline, an SDK that changed under them, or a device-specific layout collapse. If the answer is vague, they haven't been there.

"How does an agent know when it's finished?" The weak answer is "I check it" or "I read the diff." That means the human is the verification loop, which is the bottleneck that caps everyone's real throughput. The strong answer names concrete checks the agent can run and be judged by, and explains what counts as evidence of completion versus a claim of completion.

"Where does the project's current state live?" If the answer is "in the chat" or "in the code, obviously," expect week-three drift: the agent confidently building on stale assumptions. Anyone who has run a multi-month AI-assisted project has an explicit answer, because they've been burned into having one.

"What do you do when the specification turns out to be wrong mid-implementation?" There are only three possible behaviours: guess silently, stop and wait, or proceed under a recorded interpretation with an audit trail. The first destroys projects slowly, the second wastes the agent's autonomy entirely, and the third is what a competent human contractor does. Listen for which one they've actually built into their process.

"Which decisions in this project are irreversible, and what did you do differently because of that?" This separates engineers from generators. Schemas, identifiers, public formats, core algorithms and safety invariants aren't decisions you iterate on later. Anyone who talks about all decisions with the same weight hasn't paid for a wrong one yet.

"What does your process stop the AI from doing?" A mature answer includes prohibitions, and the reason each prohibition exists usually reveals a specific past failure. A process with no prohibitions has no history.

"What's your test story for non-visual correctness?" For anything involving randomness, money, probability, timing, concurrency or determinism, "it looked fine" is not an answer. Ask for the property being asserted and how it's checked.

I'd rather publish that list than not, even though it's a list anyone can use against me. If it's a real skill, it should survive scrutiny; if it doesn't survive scrutiny, it was never worth hiring for.

Where this is useful to you

If you're hiring, or you're building a product, or you have a team that has adopted AI tooling and is now shipping faster and breaking more, here's the concrete shape of what I do.

I take products the whole distance. Concept, technical design, implementation, store compliance, release, monetisation, analytics, and the maintenance work afterward. My personal definition of "done" is a live listing with real users on it, not a merged pull request, and I've done it repeatedly on my own products where there was nobody else to hand the hard part to.

I build the delivery system, not just the code. The reason my throughput is what it is isn't that I type fast. It's that the process around the AI produces releasable output rather than plausible output. That system is portable to a team, and it's a specific piece of work: defining how specifications are written, how state is tracked, where verification gates sit, what is enforced mechanically, and how sessions hand off to each other.

I diagnose why AI output isn't reaching production. This is a distinct engagement, and from the DORA data it's a widespread problem: throughput up, stability down. The causes are usually identifiable in a week — no runnable verification for agents, state living in chat logs, self-graded completion, specifications that under-determine the important decisions and over-determine the trivial ones, and rules that are documented but not enforced.

I do the hard-domain work, with or without AI in the loop. Cross-platform native development where the platforms genuinely differ. Randomness and probability where correctness is the product. Real-time graphics and game loops with frame budgets. Audio systems. System-level Android work such as overlays, foreground services and permission-sensitive features. Porting mature products onto new stacks without breaking the users who already depend on them.

And a note on what I don't claim, because grounded beats impressive. I'm not going to tell you AI makes engineering free; the METR result is a permanent reminder that felt speed and real speed are different quantities. I'm not going to tell you my method removes the need for an experienced engineer, since the method is experienced engineering applied to a new kind of labour. I'll also say plainly that not everything in my studio is finished: my dice and randomness app is around two-thirds built and waiting on exhaustive testing and polish, my arcade shooter is at a similar point with multiplayer and art pending, and my music system currently exists as an architecture with a hard problem still in front of it. I'd rather be checkable than shiny.

The short version

The industry crossed the "can AI write code" threshold a while ago. The threshold that still hasn't been crossed by most teams is "can AI-assisted work reliably become software that real people pay for and depend on." Nearly universal adoption sits alongside falling trust, rising delivery instability, and a two-thirds majority of developers whose main complaint is output that's almost right. Almost right is the most expensive kind of wrong, because it survives the demo and fails in production.

I've been building on the other side of that threshold for a couple of years, on shipped products with my name on the store listing, in domains where correctness is measurable: overlays and system-level Android, probability engines, real-time loops, deterministic audio, cross-platform native code, and the deeply unfashionable compliance work that decides whether any of it reaches a user at all.

To know more or discuss further, feel free to get in touch. Whether you're hiring, building a team's AI-assisted delivery process, or stuck between a working prototype and a shippable product, I'm happy to talk specifics.

— Anumey, DiceReligion · anumey.xyz · [add contact / LinkedIn / email here]

Sources

DORA / Google Cloud, 2025 State of AI-assisted Software Development (survey of ~5,000 technology professionals): https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf — see also InfoQ's summary: https://www.infoq.com/news/2025/09/dora-state-of-ai-in-dev-2025
Stack Overflow, 2025 Developer Survey (49,000+ respondents, 177 countries), as reported by InfoWorld: https://infoworld.com/article/4031673/ai-use-among-software-developers-grows-but-trust-remains-an-issue-stack-overflow-survey.html
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025)
Anthropic Engineering, Effective harnesses for long-running agents (Nov 2025): https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic Engineering, Harness design for long-running application development (Mar 2026): https://www.anthropic.com/engineering/harness-design-long-running-apps
Anthropic Engineering, Effective context engineering for AI agents (Sep 2025): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance (Jul 2025): https://research.trychroma.com/context-rot