The AES key is hard coded in the code.
This is the problem. But, no, encrypting the key with another key (which would be hard coded in the code) does not substantially improve matters.
What you must do is the following: write down the attack model. You are doing encryption for a reason: you believe that some evil individual will try to do... what exactly ? That's the point of the attack model: to define what the supposed attacker can do, and what he will want to achieve. Only with a clearly defined attack model can you begin to think about what security algorithms and protocols will help you.
For instance, encryption is a good tool for confidentiality: that's when the attacker wants to read some data, but you don't want him to succeed. Encryption does not solve confidentiality; it just concentrates the problem: with encryption, the problem of keeping the data confidential becomes the problem of keeping the key confidential. Since the key is shorter, this may (or may not) make the problem easier to deal with. An important point is to decide who should be able to access the data.
To make the story short: if the data is supposed to be decrypted on the attacker's machine (e.g. the attacker is the user, and you want to prevent him from accessing the raw data as part of some sort of licensing or DRM scheme), then, to put it bluntly, you lose. You cannot reliably and consistently prevent someone from accessing data which flows on his own hardware. That's because reverse engineering works well. If you pile up encryption layers (key is encrypted with another key which is encrypted with another key, and so on, up to an initial key which is hard coded), you just increase both the development time and the reverse engineering time; chances are that it will cost more time for you than for the attacker.