How to reverse engineer an app with AI before you build it

When you ask an AI agent to build something like an app you already use, it does not know how that app works. It estimates. Then it fills each gap with something that looks right, and you find the wrong parts later, if you find them at all.

We tested a different order. Before Claude Code wrote any code, we asked it to study Apple's Passwords app with REA, an open-source reverse engineering tool. We also checked the research behind the problem. 1 thing we said on camera was wrong, and we correct it below.

REA links. Website: rea.tools. GitHub: github.com/morluto/rea. Both are free.

Why AI coding agents guess

A 2024 study tested 16 code models on 576,000 code samples. 19.7% of the software packages the models recommended did not exist (Spracklen et al., "We Have a Package for You!", June 2024). Commercial models did better, at 5.2%, but none reached zero. When the researchers ran the same prompts 10 times, 43% of the invented packages came back every time. The models were not unsure. They were wrong in the same way, again and again.

The feeling of speed is not reliable either. In a METR trial published in July 2025, 16 experienced developers did 246 real tasks. With AI tools they took 19% longer. After the study, they still believed AI had made them 20% faster.

Neither study is about copying apps. Both show the same thing: an AI answer can look right and feel fast while it is wrong.

What is REA (Reverse Engineer Anything)

REA is a free tool under the MIT licence. You can read about it on rea.tools and get the code from GitHub. Its first commit was in April 2026. When we filmed, it had just passed 130,000 stars on GitHub. On 18 October 2026 it had 312,225. It connects your agent to reverse engineering tools such as Ghidra and Hopper. These tools decompile an app, which means they turn the compiled program back into code you can read.

2 limits matter. REA reconstructs how a feature works. It does not give you the original source code. And every finding comes with an evidence ID, so you can check where a rule came from. Our build has 94 of them.

What Apple's password generator actually does

Apple publishes part of the answer. Its Platform Security guide says a strong password is 20 characters, with 1 digit, 1 uppercase letter, 2 hyphens and 16 lowercase letters, and about 71 bits of entropy (a measure of how hard the password is to predict). Apple engineer Ricky Mondello wrote in October 2024 that the current format went up from the 69 bits of the format before it.

REA found the parts Apple's pages do not list:

1. The letters come in consonant, vowel, consonant groups, so the password is easier to type.
2. There are 19 consonants. Lowercase L is not one of them.
3. The capital letter is never an O.
4. The digit sits in 1 of 5 places, each with the same chance.
5. "Without special characters" gives 15 characters from a set of 60, with no lowercase L and no capital O.

Correction. In the video we said only 1 or 2 letters are lowercase and the rest are uppercase. It is the opposite. There is exactly 1 capital letter and there are 16 lowercase letters. We also said you probably cannot make the password shorter. The "without special characters" option gives you 15 characters.

Why lowercase L is missing from Apple passwords

Lowercase L and 1, and capital O and 0, are easy to confuse when you read a password aloud or type it from another screen. People have asked generators to drop them for a long time. A Mailman bug report from 1999 asked for exactly this. 1Password staff say its generator leaves out 0, O, 1, I, l, 5 and S.

Removing characters makes a password easier to predict. Apple removes very few, and the format still reaches about 71 bits. We looked for a controlled study that measures typing errors with and without these characters, and we did not find one. So this part is an observation, not a proven result.

How to reverse engineer an app with Claude Code, step by step

1. Install REA. The project gives npx rea-agents setup. You can also download the zip from github.com/morluto/rea and ask your agent to install it. The rea.tools website has guides and showcases.
2. Pick 1 feature, not the whole app. AI already copies interfaces well. The rules inside are the hard part.
3. Write a prompt that asks for evidence for each rule, your own design system, and a test that checks the output.
4. Ask the agent to check each rule against the company's public documents. We did this against Apple's pages.
5. Make it test the build. Our page checks 100 passwords in the browser. Separately, we checked 200,000.
6. Write down what it could not copy. Apple rejects passwords that contain unwanted words, from a word list we cannot read. Our page does not have that filter, and it says so.
7. Ask your agent to turn the process into a skill, so you do not write the same prompt next time.

If your builds still come out generic, our post on how to reduce AI slop in web design covers the design side.

Is it legal to reverse engineer an app

It depends on the licence and on your country. In the UK, section 50B of the Copyright, Designs and Patents Act 1988 allows a lawful user to decompile a program only when that is necessary to make an independent program work with it. That is a narrow exception. Read the app's licence before you start, and get legal advice before you ship anything based on another company's code. We studied Apple's generator to learn. We did not open a saved password, and we do not use the result. Please don't build your own password manager.

The thing that surprised us most was not the tool. It was how many rules we would never have thought to ask about. A good prompt cannot ask for a rule you do not know exists. Looking first is the only way we know to find those rules.