No, there is no way to directly do what you propose. Think about your proposal for a minute - when using an ASG, the whole idea is that your instances are ephemeral. Any of them should be able to be killed at any time without negatively affecting your application. In your proposal, how would the ASG "know" which instance is the most up-to-date at any one time? It can't.
When creating your ASG, you need to specify an AMI which will be used for the group instances. There are generally two patterns which are used to ensure that the ASG AMI is up-to-date.
- Create a script that runs on boot which updates your application code on each new ASG instance before putting it into service behind the load balancer.
- As part of your code deployment automation, build a new AMI for each release and then modify the ASG configuration to include the new AMI.
If you're able to deploy your application code and necessary configuration quickly, say in under a minute or two, I'd go with option #1. If it takes longer than that, door #2 may be more appropriate.
For either of these cases, though, the single most important thing is that you are using some sort of configuration management to do your server builds. If manual steps are involved, things will get missed and you will end up with incorrectly-configured ASG instances.