Hi Bill,
As with most methods of development, you need to maintain control of what gets taken live. With Serverless, if you have a production environment you deploy to, then you should never make changes to the Serverless service and only add, remove or alter existing resources using the serverless.yml file for the service. That way, if you are the only developer deploying to that service, then when you deploy changes, your service will change to be exactly what it is you deploy.
If what you are after is some way to test your code locally before deploying, then I would recommend considering using a setup involving unit tests locally. Lambda functions are just basic functions that receive a specially structured event object as a parameter from some external trigger such as API Gateway, S3, SNS, SQS or a multitude of other events. So in order to execute your code locally, you need someway to call your function with an event object that matches the event object of the trigger you are expecting to call your function.
The serverless-mocha-plugin makes this easier by combining mocha (a unit testing module) and your function together. You can then build the event object you need to send to the function and see that your code works as intended. I have found this AWS documentation has some great event object examples. Once you have a test event object, mocha lets you run your function repeatedly while you are developing to make local development easier.
Now you can execute your functions locally. But they will still attempt to make calls to AWS services that you may be using. To help with this I have found the aws-sdk-mock plugin to be very useful. It allows you to capture calls to AWS services like S3, DynamoDb, etc and return your own custom responses; even errors. So now you can test handling specific responses from these AWS services.
Let me know if this makes sense or you want further clarification.