The Essence graphical representation language allows to describe various project management practices in software development. At the moment, the Practice Library describes the most popular development methodologies, but work with various risks, such as code smells or antipatterns, which may be cause of future problems, is not represented. This article presents an extension for the Practice Library of the Essence language in the form of a practice for working with antipatterns. To represent antipatterns in the system, the Antipattern subalpha, its states and checkpoints are proposed. Antipatterns states and checkpoints: 1. Detected: о Signs of poor-quality design or implementation of the Software System have been found. о The boundaries of the low-quality area in the Software System have been defined. о Work Products associated with the inferior part of the Software System have been defined. 2. Identified: о The Software System Elements included in the Antipattern have been determined. о The type of antipattern has been determined. о Dependencies of the Software System on the antipattern elements have been determined. о The impact of the antipattern on the Software System has been estimated. 3. Refactoring Method Defined: о Possible options for refactoring have been identified. о The cost of the refactoring options has been assessed. о The most suitable refactoring method has been selected. 4. Fixed: о The Software System elements included in the antipattern are completely covered by tests. о The antipattern has been refactored. о Tests confirm that the Software System remains operational. о The Work Products related to the changed part of the Software System have been updated. 5. Closed: о Tests, reviews or other appropriate activities have been undertaken to ensure that the antipattern has been corrected or shown not to actually be a fault or flaw. о The antipattern management has been finalized. о Technical debt has decreased. To record data about an antipattern, the work product Antipattern Report and its levels of details with checkpoints are proposed. Levels of details and checkpoints are: 1. Antipattern detected: о The components of the Software System included in the antipattern are defined. 2. Antipatterns properties are determined: о An antipattern type has been defined. 3. Antipattern influence determined: о The cost of antipattern fixing was estimated. о An assessment of possible losses associated with the presence of an antipattern was carried out. о The antipattern is recognized as mandatory for elimination. 4. Antipattern eliminated — optional: о Refactoring completed. о Testing showed the correct work of the components included in the antipattern. о Antipattern elimination activity completed. To analyze the architecture of the system, the Inspect Architecture activity is proposed. The Fix Architecture activity represents actions to fix architecture flaws. Code analysis is presented as a Review the Code activity, and correction of deficiencies found during the analysis is presented as a Refactor the Code activity. The influence of subalpha on the state of the Software System alpha is analyzed. Recommendations were given on the proposed activities. Information about activities is presented in the form of diagrams in the Essence language. The proposed practice allows to record information about the found flaws in the code, process them correctly and avoid problems with the project in the future. It is an example of working with entities that negatively affect the progress of the project.