Kerckhoffs's principle states:
A cryptosystem should be secure even if everything about the system,
except the key, is public knowledge.
Therefore if AES is broken, your homebrew algorithm is likely to be much easier and would have been broken already.
I realise part of your original question stated:
provided they do not have the algorithm
However, as this violates Kerckhoffs's principle your home brew approach is in itself flawed and insecure.
The main reason this is a problem is that it is unquantifiable how much more security it adds to your system. I refer you to Thomas Pornin's answer to a similar question here:
An additional twist is that algorithm obscurity can harm security.
What I explain above is that obscurity cannot be trusted for security:
it might increase security, but not by much (and you cannot really
know "how much"). It turns out that it can also decrease security. The
problem is the following: it is very hard to make a secure
cryptographic algorithm. The only known method is to publish the
algorithm and wait for the collective wisdom of cryptographers around
the world to gnaw at it and reach a conclusion which can be expressed
as either "can be broken that way" or "apparently robust". An
algorithm is declared "good" only if it resisted the onslaught of
dozens or hundreds of competent cryptographers for at least three or
So therefore you should use another algorithm if you are worried that AES may soon be broken (that or don't use AES at all). I'm assuming the rest of your system isn't 100% secure - so instead of wasting time, effort, energy and resource on creating a home brew algorithm this effort should be spent elsewhere, where it can be quantifiable that it is actually increasing security. All code has a cost, and it is not just the salary of the junior developer that is creating it. It needs to be maintained and understood by everybody - and each extra person that learns how it works is an extra avenue for the algorithm to be leaked. Don't waste your time.