EntityFramework was originally designed with the "Model-First" approach as the preferred approach to building your Data Access layer, however many software shops still seem to live in the Dark Ages where they prefer to design the schema first and then the model to accomodate it. Okay, I may be a little unfair, if you have database intensive processing where stored procedures benefit performance then it can make sense to start at the database and work your way up.
Regardless, when I played with the early release of EntityFramwork, support for refreshing the model from the database existed, however it was somewhat buggy at first. This was years ago however and I remember reading that a lot of those issues have been worked out since. I hear nothing by great things about EntityFramework being used in this way.
Is it difficult to track changes and make code work?
This all depends if you are following an appropriately layered architecture with loose coupling. Ideally if the EntityFramework model changes then changes in the Data Access and Business Logic layers should be constrained to the layers that use the EntityFramework model.
Ideally if you are practicing TDD then your unit tests should fail and indicate which areas need refactored after a model change.