Есть случай, где я бы отдал базу агенту без сомнений: документация по коду. Наша вики жила пять лет, 200 с лишним статей, и к концу не верил ей никто, любая страница требовала перепроверки по коду. Сейчас статьи собираются из коммитов каждый день, а всё, что по коду подтвердить нельзя, помечено отдельным блоком. Читаешь и видишь, где гарантия, а где память команды.
Но это как раз ваш «склад», а не мышление: там нечего понимать, там нужно не врать. Для личной базы граница, похоже, проходит там же. Факты и связи между ними пусть собирает агент, а пересказ своими словами остаётся тем, что вы называете шрамом.
Хочу спросить про depends_on: сколько заметок прожило с этим полем до того, как вы его выкинули?
Ваш случай с коммитом чужих файлов у нас повторился почти дословно, только с правками одной фичи. Отдавали агенту мелкие доработки по одной, за шесть итераций набралось около 2000 строк диффа там, где хватило бы 300. Дешевле оказалось переписать, чем разобрать наслоения.
Из практик сработала одна: агент не пушит в основную ветку, каждую правку проверяет другая модель по списку закрытых зон, без её статуса ничего не едет. Не сработало ревью правил самим агентом: он пишет «так делать нельзя» в свой же файл правил и на следующей сессии делает.
Про «агент сделает любую задачу, но не скажет, что она не нужна» подпишусь. У нас это единственная функция, которую до сих пор выполняет только человек.
Инструкция для нетехнического коллеги, который дорабатывает внутренний инструмент (что спросить у сеньора до первой правки, шаблон постановки задачи агенту, что делать, когда агент отказывается), лежит в закрепе канала, ссылка в конце статьи.
Интересно услышать обратные случаи: заменили подписку своим кодом и вернулись обратно. Через полгода напишу, что стало с нашими четырьмя, включая цифры по правкам, которые внесли не разработчики.
Соблазн понятен, но в моих кейсах LLM встала на место человека, а не алгоритма. SQL по вопросу аналитика раньше писал разработчик, и это тоже был вероятностный процесс, просто вероятность пряталась в человеке: один и тот же вопрос двум разработчикам даёт два разных запроса. Детерминированно эту задачу не решили за тридцать лет, поэтому её и не автоматизировали вовсе.
Дальше вопрос в обвязке. Когда нужна предсказуемость, формулировка задачи для модели меняется с «сгенерируй ответ» на «выбери из закрытого списка или верни: не нашёл». В боте поддержки у меня так и сделано, и он единственный прошёл все ловушки аудита без выдумок. Там, где модель оставлена свободной, она уверенно сочиняла.
Так что граница проходит не между задачами, а внутри системы: вероятностное ядро и детерминированная рамка вокруг него. Проведёшь её явно, получишь рабочий инструмент, оставишь неявной, получишь генератор правдоподобного мусора.
Чек-лист целиком в статье, ядро промта аудита под спойлером там же. Полная версия промта, с форматом карточки и правилами честности аудитора, лежит в закрепе канала: https://t.me/n_cto
Если прогоните аудит на своём проекте, напишите сюда счёт и самый неожиданный факт. Моя гипотеза: пункты «владелец» и «цена запроса» провалены у большинства. Через месяц выложу повторный аудит своих трёх и посмотрим на дельту.
Хороший вопрос. Короткий ответ: спор в отделе был про три варианта, которые у нас уже существовали, а скила не существовало. Длинный: ветка C с енамами — это по сути и есть автоматически собранный скил (DDL плюс смыслы значений, вытащенные парсером из кода), только без ручной курации.
Следующий шаг ровно такой, как вы описываете: курируемый файл знаний о схеме, куда дописаны описания и бизнес-правила, которых нет ни в базе, ни в енамах. Роль партнёра из статьи, которую не нашёл никто, включая меня, — как раз такое знание. Подозреваю, скил закрыл бы часть из 8 нерешённых вопросов.
Останавливает цена: руками описывать 253 таблицы дорого, и это протухает. Рабочий план: генерировать черновик скила из кода, курировать только горячие таблицы. Если у вас есть опыт со скилом над схемой такого размера — покажите цифры, очень интересно.
Собрал в один файл всё, чтобы повторить эксперимент у себя: методику (execution accuracy, правила зачёта, шаблоны обратной связи), промты веток, скрипт сравнения result set'ов и чек-лист «инварианты для каждой метрики». Лежит в закрепе канала: https://t.me/n_cto
Вопросы по методике задавайте здесь, отвечу. Особенно интересно, если у кого-то MCP-ветка ведёт себя иначе — покажите конфигурацию.
Про чёрный ящик поправлю: код агент как раз читал, из него и собиралось ТЗ. UI-прогон был вторым каналом, чтобы сверить «как написано» с «как работает». Кода не читал человек, в этом и был эксперимент.
Про этапы вы правы, и делали мы именно так, просто в статье это слиплось: в промпте первого этапа улучшения запрещены, сначала as-is и сходство один в один, фичи отдельным заходом после валидации ТЗ с заказчиком. Возьму на заметку, что это стоило проговорить жирнее.
Кейс с потерянными исходниками жёсткий, тут наш метод честно упирается в границу: реверсить можно только поведение и то, что осталось от артефактов. 1000 ошибок компиляции после восстановления звучит как отдельная статья. Прайс выше в 30 с лишним раз: ровно та экономика, из-за которой такие системы лежат нетронутыми годами, пока совсем не прижмёт.
Справедливо, WordPress нейронке знаком до последнего хука, это упрощало дело. Но токены тут ест не «прочитать весь код разом», а пофичный разбор: инвентаризация, домен, потом фича за фичей со сверкой по UI, и в контексте живёт один кусок за раз. На наших двух проектах всё уложилось в стандартную подписку без выжигания лимитов. Самопись на PHP 5.6 с логикой в шаблонах выйдет дороже, спорить не буду, но подозреваю разницу в разы, а не на порядки: UI-сверка дисциплинирует разбор не хуже популярного движка.
Есть случай, где я бы отдал базу агенту без сомнений: документация по коду. Наша вики жила пять лет, 200 с лишним статей, и к концу не верил ей никто, любая страница требовала перепроверки по коду. Сейчас статьи собираются из коммитов каждый день, а всё, что по коду подтвердить нельзя, помечено отдельным блоком. Читаешь и видишь, где гарантия, а где память команды.
Но это как раз ваш «склад», а не мышление: там нечего понимать, там нужно не врать. Для личной базы граница, похоже, проходит там же. Факты и связи между ними пусть собирает агент, а пересказ своими словами остаётся тем, что вы называете шрамом.
Хочу спросить про depends_on: сколько заметок прожило с этим полем до того, как вы его выкинули?
Ваш случай с коммитом чужих файлов у нас повторился почти дословно, только с правками одной фичи. Отдавали агенту мелкие доработки по одной, за шесть итераций набралось около 2000 строк диффа там, где хватило бы 300. Дешевле оказалось переписать, чем разобрать наслоения.
Из практик сработала одна: агент не пушит в основную ветку, каждую правку проверяет другая модель по списку закрытых зон, без её статуса ничего не едет. Не сработало ревью правил самим агентом: он пишет «так делать нельзя» в свой же файл правил и на следующей сессии делает.
Про «агент сделает любую задачу, но не скажет, что она не нужна» подпишусь. У нас это единственная функция, которую до сих пор выполняет только человек.
Инструкция для нетехнического коллеги, который дорабатывает внутренний инструмент (что спросить у сеньора до первой правки, шаблон постановки задачи агенту, что делать, когда агент отказывается), лежит в закрепе канала, ссылка в конце статьи.
Интересно услышать обратные случаи: заменили подписку своим кодом и вернулись обратно. Через полгода напишу, что стало с нашими четырьмя, включая цифры по правкам, которые внесли не разработчики.
Показать не могу, и это честное ограничение псевдонима: два проекта внутренние, живут в корпоративном контуре, третий пока в раннем доступе для своих.
Соблазн понятен, но в моих кейсах LLM встала на место человека, а не алгоритма. SQL по вопросу аналитика раньше писал разработчик, и это тоже был вероятностный процесс, просто вероятность пряталась в человеке: один и тот же вопрос двум разработчикам даёт два разных запроса. Детерминированно эту задачу не решили за тридцать лет, поэтому её и не автоматизировали вовсе.
Дальше вопрос в обвязке. Когда нужна предсказуемость, формулировка задачи для модели меняется с «сгенерируй ответ» на «выбери из закрытого списка или верни: не нашёл». В боте поддержки у меня так и сделано, и он единственный прошёл все ловушки аудита без выдумок. Там, где модель оставлена свободной, она уверенно сочиняла.
Так что граница проходит не между задачами, а внутри системы: вероятностное ядро и детерминированная рамка вокруг него. Проведёшь её явно, получишь рабочий инструмент, оставишь неявной, получишь генератор правдоподобного мусора.
Чек-лист целиком в статье, ядро промта аудита под спойлером там же. Полная версия промта, с форматом карточки и правилами честности аудитора, лежит в закрепе канала: https://t.me/n_cto
Если прогоните аудит на своём проекте, напишите сюда счёт и самый неожиданный факт. Моя гипотеза: пункты «владелец» и «цена запроса» провалены у большинства. Через месяц выложу повторный аудит своих трёх и посмотрим на дельту.
Спасибо за обратную связь! Будут результаты—расскажу на примере
Хороший вопрос. Короткий ответ: спор в отделе был про три варианта, которые у нас уже существовали, а скила не существовало. Длинный: ветка C с енамами — это по сути и есть автоматически собранный скил (DDL плюс смыслы значений, вытащенные парсером из кода), только без ручной курации.
Следующий шаг ровно такой, как вы описываете: курируемый файл знаний о схеме, куда дописаны описания и бизнес-правила, которых нет ни в базе, ни в енамах. Роль партнёра из статьи, которую не нашёл никто, включая меня, — как раз такое знание. Подозреваю, скил закрыл бы часть из 8 нерешённых вопросов.
Останавливает цена: руками описывать 253 таблицы дорого, и это протухает. Рабочий план: генерировать черновик скила из кода, курировать только горячие таблицы. Если у вас есть опыт со скилом над схемой такого размера — покажите цифры, очень интересно.
Собрал в один файл всё, чтобы повторить эксперимент у себя: методику (execution accuracy, правила зачёта, шаблоны обратной связи), промты веток, скрипт сравнения result set'ов и чек-лист «инварианты для каждой метрики». Лежит в закрепе канала: https://t.me/n_cto
Вопросы по методике задавайте здесь, отвечу. Особенно интересно, если у кого-то MCP-ветка ведёт себя иначе — покажите конфигурацию.
Про чёрный ящик поправлю: код агент как раз читал, из него и собиралось ТЗ. UI-прогон был вторым каналом, чтобы сверить «как написано» с «как работает». Кода не читал человек, в этом и был эксперимент.
Про этапы вы правы, и делали мы именно так, просто в статье это слиплось: в промпте первого этапа улучшения запрещены, сначала as-is и сходство один в один, фичи отдельным заходом после валидации ТЗ с заказчиком. Возьму на заметку, что это стоило проговорить жирнее.
Кейс с потерянными исходниками жёсткий, тут наш метод честно упирается в границу: реверсить можно только поведение и то, что осталось от артефактов. 1000 ошибок компиляции после восстановления звучит как отдельная статья. Прайс выше в 30 с лишним раз: ровно та экономика, из-за которой такие системы лежат нетронутыми годами, пока совсем не прижмёт.
Справедливо, WordPress нейронке знаком до последнего хука, это упрощало дело. Но токены тут ест не «прочитать весь код разом», а пофичный разбор: инвентаризация, домен, потом фича за фичей со сверкой по UI, и в контексте живёт один кусок за раз. На наших двух проектах всё уложилось в стандартную подписку без выжигания лимитов. Самопись на PHP 5.6 с логикой в шаблонах выйдет дороже, спорить не буду, но подозреваю разницу в разы, а не на порядки: UI-сверка дисциплинирует разбор не хуже популярного движка.