Comments 11
По поводу Spec-as-source - той самой статье Мартина Фаулера (на самом деле не самогó Мартина, просто опубликована на его сайте), которую даже тут на Хабре уже который раз пересказывают, уже пятый месяц пошёл, - а у Tessl не то, что прогресса в этом проекте нет, но и последние упоминания его на их сайте затерялись. Остальные известные мне SDD-фреймворки (а я изрядно упоролся в их поиске и сравнении) таких амбициозных планов и не ставят. Есть ощущение, что всё оказалось несколько сложнее. И как в той самой статье на сайте Фаулера отмечено, благородная цель генерить код полностью на автомате по спекам может оказаться столь же недостижимой, как когда-то идея генерить его по UML-диаграммам...
Идея мне, честно говоря, очень зашла.
Когда-то и кросс-платформенная компиляция под несколько ОС казалась фантастикой, а сегодня это уже обыденность. Поэтому я бы не стал так быстро списывать Spec-as-Source со счетов — возможно, мы просто находимся на очень раннем этапе развития этой парадигмы.
По поводу текущих SDD-фреймворков согласен — они пока выглядят довольно сырыми и явно не дотягивают до заявленных амбиций. Но это не значит, что сама идея нежизнеспособна. Скорее, реализация оказалась сложнее, чем ожидалось.
Как там было в одном из комиксов Дилберт? Полная и исчерпывающая спецификация программы называется «код».
Фундаментальная проблема здесь в том, что не существует «серебряной пули» борьбы с логической сложностью. Ее можно реорганизовать, структурировать, описывать с различной степенью избыточности, но от нее нельзя избавиться.
Технология LLM позволяет нам обменять часть сложности на семантическую неопределенность, недоговоренность, двусмысленность естественного языка. Но мы не можем обменивать слишком много сложности на неопределенность, поскольку тогда наш проект станет слишком хрупким.
«God-класс» на 2000 строк — это потеря контекста и неизбежные галлюцинации.
Я бы вот не сказал. Несколько дней назад занимался рефакторингом класса на ~7000 строк кода С#. Загружал старый класс и пробный вариант после рефакторинга. Итого примерно 700KB текста. Спрашивал найти отличия, что еще не перенесено. С такой задачей ChatGPT 5.2 справляется без проблем. Ни разу не было чтобы ChatGPT на что-то указал и этого действительно не было в реальности. После каждого ответа контекст сбрасывался, вносились исправления и снова отправлялись на проверку.
Интересный опыт. У меня он обратный. Часто сталкиваюсь что весь контекст не может ИИ в себя поместить и сам апи видает ошибку и ей приходиьсья читать файл кусками и при редактировании те же проблемы. Тоесть я потратил 2000 токено и потом ошибка и так 3-4 раза пока модель не поняла что нужно по 200 строк читать;
Умение хорошо писать эти файлы становится критическим навыком. Хороший
CLAUDE.mdможет быть разницей между AI-агентом, который производит код, которым вы гордитесь, и тем, который создаёт хаос, на уборку которого вы тратите часы.
Хоть кому-то это удалось? По моим ощущениям после пол года с агентами, чем чище контекст тем меньше хаоса. Сложную логику проекта агент понимает по коду сам за 1 минуту в таких деталях, что я такой инфы ему сам не соберу. Правила как надо писать код или игнорирует или выполняет странно. А вот сам при минимальном вмешательстве пишет все хорошо.
Мне удалось. Я перенес много чего в README.MD и ARCHITECTURE.MD а в CLAUDE прошу его читать эти файлы перед запросами агенту и редактирвоать их для того чтобы были актуальные
А получалось экспериментально подтвердить, что это что то улучшает? Так чтобы агент сделал без файлов плохо а с файлами хорошо?
Да. Могу с уверенностью сказать: чем подробнее и структурированнее у тебя README, тем лучше агент справляется с задачей. Это легко проверить на практике.
ИИ не “понимает проект магически” — он ориентируется на контекст. Каждый новый запрос для него - как чистый лист. По сути, README становится частью “операционной памяти” модели. Чем меньше неявных договорённостей в голове у разработчика и больше явных правил в тексте — тем лучше результат.
Тут ещё важно понимать, что такое контекстное окно. У любой модели есть ограниченный объём “памяти” в рамках сессии. Когда контекст разрастается (файлы, диффы, логи, обсуждения), он начинает занимать всё окно. И если оно забито на 60%+, модель уже начинает терять фокус. Поэтому нужно чистить контекст, начинать новые сессии для крупных задач в новом или чистом окне, не тащить в один поток 10 разных не свзязаных задач.
Какие рекомендации тем, кто не middle/senior, а intern/junior? Если в доИИшную эпоху опыта коммерческой разработки не было, есть ли смысл вообще руками кодить в учебных целях?
Роль «просто писать код руками» уже занята за $20 ИИ уже генерирует быстрее и лучше. Если ты junior и вообще не кодил руками — ты не сможешь быть «архитектором» и даже нормально проверить код модели. Чтобы валидировать ИИ, нужны знания. Без этого ты не инженер, а prompt-оператор.
Сейчас ценность не в «уметь печатать код», а в: системном мышлении, заннии архитектуры, умении читать и понимать код, готовность нести ответственности за прод и не важно кто его написал. ИИ — это только ускоритель который можно/нужно использовать чтобы быстрее прокачать свои скилы.
Код больше не ваш. Разработка в эпоху AI