The Ultimate Specification Is Hiding in Plain Sight
How I ported an iOS app to Android on a cross-country flight — without knowing the app, using the codebase as the spec
The cabin lights are off at 35,000’ somewhere over the mid-west, passengers are sleeping on our way to EWR but I’m wide awake. Claude’s building an App for me…but this time is different — Claude is cranking away but I actually don’t know what we’re building, and that’s ok. It’s by design. I have the ideal specification in hand. And the output is perfect.
Zoom out with me for a second — If you take a steel-man approach to your developer workflow you will eventually ask yourself what’s the best Requirements document possible? Or in the context of AI you might ask “What is the best Specification you could write?”
Last time I talked about the need to move towards Specifications and getting clear on what you want to build. If you take that to its extreme what’s a better specification than already working code? It doesn’t get any better than that right?
With that in mind I took an App written for iOS for which we had no Android equivalent. Using the existing iOS Swift codebase as a Specification combined with existing Android codebases from other apps as reference material (context) I was able to orchestrate creation of the Android equivalent of the iOS App.
By the time we landed I had the bones of the app complete. By the end of that weekend I’d ported 70-80% of the existing iOS app to Android. And that was whilst I was working part-time with my mind focused on playing video games (Crimson Desert).
My spec in this case was technically perfect. Steel-manned. Every screen, every interaction, every API call. Documented literally in code.
More detail than you’d ever get from a human. Each edge case. Every animation. All the error states, color tokens, every UX choice. Every single decision that dozens of engineers and designers had made over months of development — all of it, encoded in Swift, sitting right there in the repo.
Your code is no longer just a product. It’s a specification.
Documents in Prose are human-centric deliverables. They help humans understand ideas but they’re never going to be as detailed as what a machine needs.
Orchestrating in the Dark
Here’s what’s interesting — I had no idea what I was building. I carry an Android phone and don’t use an iOS device so I had only a basic understanding of the App I was trying to recreate. That didn’t matter.
I didn’t need to describe what the app should do. Any ambiguity or missing requirements I could locate in the repo and point Claude at it. The working application was the spec.
My job was orchestrator; I set the objective (recreate the App in Android) and established the guardrails and the breakage criteria for my contrarian agents to pass or fail the progress.
Context and Avoiding Slop
The iOS codebase alone wasn’t enough. I also fed my agents the Android codebases from other existing applications. It already knew what to build, but it needed to understand how we build on Android. Our team’s conventions and idioms, architecture patterns, etc.. There’s no point porting an app if the team won’t adopt it or it uses obscure patterns.
When people say “the models aren’t good enough yet”, and I hear this a lot, what they usually mean is they haven’t figured out how to give the model sufficient context and specificity. I wrote about this in my last piece on Ambiguity; AI doesn’t expose skills gaps, it exposes clarity gaps.
The iOS app was the what. The existing Android codebases were the how. Between the two of them, I had enough “specification” than any PRD I could write.
This material would be impossible for a human to grok in a reasonable timeframe but Claude can read and internalize everything from what I gave it and synthesize this information far better than I could ever describe in prose.
Have I mentioned my laziness is a Superpower?
Brain Fry and the “No Effort Involved” Fallacy
80% of the application came together in about 20% of the time because I used an Agentic workflow and paralleled a lot of it with my Claude buddies.
Vilfredo Pareto is laughing at us from beyond the grave because then the other 20% shows up and it takes 80% of the effort. The fit and finish. The edge cases. The platform differences between iOS and Android that no amount of specification can fully capture. I had to weigh in on all of that.
The other thing I noticed is that by the end of the week I was completely mentally exhausted. Running multiple agents and constantly tending to them so they are productive and not stepping on one another takes a toll. Context switching is hard on the human brain. I’ve heard this referred to as “Brain Fry”.
It makes sense though; compressing months of original work from a team of people into a multi-tasked weekend or two is gonna wear you out.
Building with AI doesn’t mean there’s no work to do. It compresses a ton of the work so dramatically that you actually have time for the hard parts. And if you’re not careful it’ll burn you out quicker than you’ve ever seen.
By the following weekend I needed a long run outdoors to reset.
The Organ Transplant
With my weekend over I showed this to my team the following Monday.
Now…this wasn’t on the roadmap. I hadn’t looped anyone in. I’d accidentally run ahead of my group and produced an Android port of an application that we hadn’t prioritized, using a workflow that most of the team hadn’t experienced yet. My goal was never to ship this, rather more of an exploration what’s possible with the best possible spec I could think of.
Some people were excited. Some people were skeptical.
This is what’s going to happen at every company across the world as this workflow takes hold. Someone is going to go off and build something unexpected but valuable in a fraction of the time, and the organizational immune system is going to kick in.
I don’t have a clean answer for this yet. I’m still figuring it out.
Activate the Swarm!
Turns out a lot of people got excited so we spun up a smol team. These were passionate folks who didn’t ask for permission or wait for a sprint planning session. They just started contributing.
Some team members were working through our homegrown Agent orchestrator. Others, like myself and a few managers who knew the codebase, worked locally with their own setups. All of us asynchronously. None of this was anyone’s day job and many of the folks involved had never touched Android development before. Again…it didn’t matter, for this type of thing Claude’s pretty capable.
We kept everything on track by adopting our team’s standard best practices, running things like Detekt scans and checking for code smells along the way and avoiding regressions with automated testing.
Within two weeks we had an internal beta that’s now in the hands of employees.
2 Bagel teams and the Dunbar Number
With everyone pitching in we quickly realised Scrum and Sprints are no longer viable. We moved to a Kanban model and processed tickets in “Flow” rather than scrum.
The more people that got involved the harder the coordination — the Dunbar number hints that there is a theoretical limit to the number of people that can meaningfully work on a project before the coordination needed to keep everyone aligned becomes greater than the actual work involved in the task.
It turns out the hardest part of shipping software was never the code — it was the coordination. And now with LLM super-powers the tickets are processed so fast you spend all your time keeping people aware of what’s happening.
In a recent discussion with a field architect from Anthropic he shared they don’t have 2-pizza sized teams of 7-8 or so. They have 2-bagel sized teams. Let that sit for a minute. 2 people, one bagel each. A team of 4 would be considered “large”.
Less people = less coordination, faster/smoother progress.
So What Do You Do Next?
Look at your existing applications differently. That “legacy” codebase your team dreads working on? It’s the most detailed product specification in your organization. All the business rules you need are locked in the repo.
Some things to consider:
Stop writing specs from scratch — If you’re building something that’s a variation on something that already exists — a new platform, a new market, a new form factor — start with the existing implementation as your specification. Let the AI read the code, understand the patterns, and generate the variant.
Brace for the burnout — The amount of work possible has expanded geometrically but there is a very real human toll to this. You will experience burnout. Get proactive with your People team and start building in breaks and pauses and touch-grass moments for your team. It’s hard to read the label from inside the bottle so they won’t come to this conclusion on their own. You need to lead from the front.
Invest in your codebase as documentation — Clean, well-structured code is no longer just easier for humans to maintain. It’s a better input signal for AI. If your code is a mess, your AI-generated output will be a mess. Garbage in, garbage out still applies — the scale of the garbage just got bigger.
Pair your “What” with your “How.” — The iOS app told the system what to build. The existing Android codebases told it how we build. You need both. A specification without style guidance produces technically correct but culturally alien code that will not be adopted. The body will reject the organ if the DNA doesn’t match.
Embrace Pareto. — Plan for 80/20. The AI will get you most of the way there shockingly fast. Budget your human effort for the last mile — the fit, the finish, the judgment calls that still require a person. This is where your team’s expertise actually matters most.
In Closing
We used to say “the best code is no code.” Maybe now the best code is code that’s already been written — not because we’ll run it forever, but because it teaches the next system what to build.
The past 6 months have changed how I think about software development entirely, from Vibe Coding to Vibe Orchestrating and now inference from Specifications. The specification is the product and vice versa.
It’s a few weeks later. The Android app that was born on a plane at 35,000’ over the midwest is all grown up and slated for field testing in the coming weeks. And the PRDs and Word docs? Those were just for us humans the whole time.
Francis here, thank you for reading. If you found this useful, consider sharing with your team. We’re all figuring this out together and I’d love to hear your stories in the comments — have you used existing code as a specification? What happened?
How did you structure your agentic workflow? How wide did you go agent wise?