For decades, compiled software has worked like a locked cabinet: the code is in there, but nobody could be bothered to pick the lock. AI assistants have removed most of that effort — turning a finished program back into readable source code is now, in many cases, a couple of evenings' work. If your business quietly assumes nobody can see inside your code, it's worth asking what that business really rests on.
The protection was never a lock — it was friction
Compiling never encrypted anything. It just made reading tedious and expensive: you needed someone skilled, patient and with time to spare. That cost is exactly what AI lowers. The same logic applies to mobile apps, desktop programs and anything installed on a customer's own server. If your only protection was that nobody would bother, that protection is now considerably thinner.
The practical consequence is boring rather than dramatic: no secret shipped inside a program that reaches a customer is a secret anymore. Not API keys, not hidden endpoints, not the "temporary" admin password someone hardcoded three years ago.
What survives when the code is visible
For most small companies the advantage was never in the code anyway. It's in the data you've collected and cleaned up over years; in the working service — the integrations, the maintenance, the fact that someone answers when the system stops at night; and in the customer relationship, where you know the domain better than any competitor who unpacks your binary.
A competitor who gets your code tomorrow still doesn't get your customer base, your processes, or the reasoning behind why a feature works the way it does. We see this constantly in projects: the recurring question is not "how was this written" but "why was it decided this way". That answer isn't in the source.
Four things to review this week
First, list everything that ships to a customer's device or browser and check whether any secrets are in there. Keys belong on the server side, with access going through your own middle layer. Second, write one page on what would happen if a competitor had your complete codebase tomorrow. If the answer is "we'd have no business left", that's the first line of your risk register, not an IT topic.
Third, review your licences and contracts. A clause restricting reverse engineering doesn't make it impossible, but it gives you a legal position — and that is cheaper than a technical arms race. Fourth, if you sell installable software, think about what could move to the service side. Value that lives on your server and improves weekly is far harder to copy than value frozen on a customer's machine.
Where we'd draw the line
This doesn't mean you should panic-publish your code, or that obfuscation is pointless. Friction is still friction — it just isn't a strategy anymore. There are also business models where a specific algorithm genuinely is the product, and protection has to be both contractual and technical; in those cases keep it on the server and never ship it inside a binary at all.
Our advice is simple: stop treating code secrecy as the core defence and invest in what can't be downloaded — clean data, a dependable service, and customers who know somebody picks up the phone. None of those three get cheaper just because a machine learned to read bytecode.