To keep the answer concise, i would say if the following characteristics are visible in your code, you can be confident that the patterns are in place even if you have not made deliberate efforts (which is not an issue) towards it.

Desired Characteristics:

1. Your code base is testable at unit level
2. Whenever you are implementing any change requests then you are making changes only to relevant classes which co-related in the domain.
3. Your code base is not exhibiting software entropy.

If your still curious to identify and tag your code with the real patterns names, i would recommend a to perform following actions to get the ball rolling.

1. Reverse engineer your code base to generate a few UML daigrams.
2. Visually compare the diagrams with any ready reference of patterns reference material.

This should give you a fair idea.

You mention both design patterns and coupling. These are separate concepts so I’ll deal with them separately. The only real connection is that design patterns tend to promote loose coupling (since it’s a major aspect of good design).

Design Patterns

The concept of Design Patterns is actually quite simple: They’re just a set of templates of how to deal various common problems. There are 2 main reasons that they are popular:

1. They are ‘proven’: they have been used before many times and the benefits/drawbacks of each are generally known, in particular any subtle issues that might cause big problems are known.
2. They provide a common set of terminology, and so enable easier communication. If someone says “class X plays the role of the observer in the observer pattern” then developers who are familiar with the pattern can immediately grasp what’s going on.

How do you know that you’ve implemented it correctly? That’s a tricky one. For most patterns it’s simple – you’ve either grokked it or you haven’t. Some patterns are less clearly-defined than others – e.g. model-view-controller. Patterns like that are better used as general guidelines. The specifics of how you implement it are less important than understanding the reasons that the pattern exists and what it’s meant to accomplish.

Design patterns aren’t ‘the one true way’. Often you’ll either need to adapt them for your specific purposes, or sometimes there just won’t be any patterns which fit the requirements. Forcing a design pattern where it doesn’t fit is a bad idea; it’s like using a really good hammer when what you actually want is a screwdriver.

Coupling

This is a really important idea in computer science. Since requirements for most software projects change over time (sometimes significantly) then the ability for a design to cope with changes is important. Coupling is basically the measure of “how hard would it be to swap out this component for another one?” The ‘component’ could be a method, class, package, library, etc.

There are various types of coupling listed in this Wikipedia article.

The answer is actually the purpose that you want to write design patterns from start. Why do you want flexibility for?

That is change; requirements change. Try to change something in your requirements that reflects in code change and see how easy/difficult is to do that.

Using design patterns is a preventive action. You use design paterns to ease your work when you are scaling the application later. Of course, to ease your work later you must do a bit more work now. so the real question is how much change can you expect in the future and what this change is. If you do not need scalability and flexibility you can do away with design patterns.

Design patterns are themselves an implementation of Object Oriented Design Principles. As long as you follow these principles your applications are going to be flexible and scalable; even if you dont really have an actual design pattern. As Joachim Sauer has commented above they are common solutions to common problems.