Разработчик, который годами писал на C и C++ в Microsoft и Google, спроектировал сотни систем и провёл тысячи код-ревью, описал проблему Claude Code, с которой столкнулся на практике.
Плохой код он чувствуюет примерно так же, как некоторые чувствуют запах дыма.
В первую неделю с Claude ему казалось, что он просто взломал систему. Фичи выкатывались, все проверки проходили, и он впервые начал рано ложиться спать.
А потом каждый исправленный баг начал порождать ещё два. Работа резко замедлилась.
Правишь checkout — ломается биллинг. Чинишь биллинг — отваливаются уведомления. "Быстро поменять одно поле" — и уже развалились три модуля.
Это всё тот же спагетти-код, который лентяи-разработчики писали годами. Просто Claude пишет его в 200 раз быстрее.
Anthropic обучила гения на свалке из Stack Overflow и корпоративной Java-разработки и назвала это полезным ассистентом.
Обращение через цепочки объектов. Чрезмерный DRY. Хуки "на будущее". Деревья наследования. Один файл делает пять разных вещей. God functions.
Решение существует ещё с 1994 года.
Просто вставьте это в
AGENTS.md:
# Вечные ограничения, а не чек-лист
Если два принципа конфликтуют, выбирай тот, который сильнее снижает будущую стоимость изменений ИМЕННО в этой кодовой базе.
ЖЁСТКОЕ ПРАВИЛО: сначала отрефактори код под принцип, и только потом меняй поведение.
1. Separation of Concerns — одна категория работы на одну часть системы: UI / domain / persistence / infra. Базовый принцип.
2. Encapsulation / Information Hiding — небольшой стабильный контракт, внутренности скрыты.
3. High Cohesion + Loose Coupling — то, что меняется вместе, должно жить вместе; независимые части общаются через узкие интерфейсы.
4. DRY — одно авторитетное представление для каждого знания, а не для каждой похожей строки. Не переусердствуй с DRY.
5. KISS — самая простая архитектура, которая работает. Сложность — это долгосрочный налог.
6. Single Responsibility — одна причина для изменения.
7. Depend on Abstractions — политика не зависит от деталей; и то и другое зависит от контрактов.
8. YAGNI — никаких спекулятивных фич, фреймворков и хуков «на потом».
9. Composition over Inheritance — собирай систему из компонентов, а не выращивай хрупкие иерархии.
10. Open/Closed, но с дисциплиной — расширяй систему через стабильные границы и только там, где одно и то же изменение уже понадобилось дважды.
Также полезно: Law of Demeter · fail fast / illegal states unrepresentable · optimize for deletion · Unix-принцип «делай одну вещь и хорошо» + композиция.
Относись к этому как к ограничениям. Если здравый смысл требует нарушить лозунг — нарушай.
👉
@Cpportal
