Hacker News Digest

Разработчики всё чаще пишут документацию в специальных «контекст-папках», чтобы ИИ мог самостоятельно и точно решать задачи. Это docs-driven development: кодят меньше, пишут больше, потому что ИИ теперь обязан «RTFM».

Качество ответа LLM прямо зависит от качества входных данных. Чем больше контекстное окно, тем больше релевантной информации можно подать. Поэтому инженеры учатся писать структурированные инструкции и создавать целые библиотеки контекста.

Контент-куратор — это технический писатель, который строит стратегию знаний и для людей, и для ИИ. Контекст важнее «контента»: он ограничен, релевантен и придаёт смысл. Писатели должны владеть процессами AI-документации, включая подготовку контекста (docs-as-data).

Четыре года назад я утверждал, что писатели влияют на дизайн API словами. Теперь это распространилось на всю разработку: мы можем «вызывать» программы текстом. Большинство команд уже отдают llms.txt и Markdown для ИИ, но следующий шаг — упаковывать контекст в удобные для LLM форматы (возможно, на базе DITA). Цель — сделать знания доступными и человеку, и машине.

• AI заставляет писать больше документации — скучно, но полезно и исключает оправдания прокрастинации.
• LLM плохо справляются с новыми/обновлёнными API, часто предлагают устаревший код, если явно не указать «смотри свежие доки».
• Чтобы LLM был полезен, нужно самому понимать задачу и давать точный контекст; иначе результат неточен.
• Некоторые компании уже отдают приоритет AI-читабельным форматам (llms.txt, claude.md), но это пока редкость, а не норма.
• Хорошая документация полезна людям вне зависимости от ИИ; если ИИ подталкивает улучшать её, это плюс.

• Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
• Файл-инструкция по запуску линтервов и сборки.
• Саморевью — прошу Claude проверить свой код.
• Глобальный гайд ~/.claude/CLAUDE.md с правилами: мелкие шаги, TDD, простые решения, максимум 3 попытки при ошибке.

Качество
Я вручную читаю и тестирую всё, что выходит из LLM; отвечаю за PR независимо от автора кода.

• Ключ к успеху — писать подробные спецификации: кто-то тратит 2 часа на 12-шаговый документ и получает отличный результат, другие же считают, что даже «чистые» спеки не спасают от схода с курса и бесконечных правок.
• Мнения о CLAUDE.md разделились: одни держат файл коротким (<100 строк) и минималистичным, другие вообще не видят в нём пользы из-за «context rot» и субъективных инструкций.
• Работа с большими старыми кодовыми базами по-прежнему сложна: большинство признаёт, что Claude Code лучше справляется с новыми pet-project’ами, чем с «грязными» legacy-фичами.
• Популярные тактики: шаг-за-шагом микро-PR, TDD-агент, запуск puppeteer-тестов для «замыкания цикла», code-review собственных патчей самим агентом.
• Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.

MS used to have uservoice pages. They ignored issues, no matter how highly-voted they were. I once asked someone at MS about this, and they said they take their cues from other sources, like what industry partners ask them to fix at conferences.What a waste of time to have uservo