Про это знать надо. Внезапно, оказывается, что инженерные навыки всё ещё нужны, а инструкция для агента - это не программа.
Некоторые люди до сих пор верят, что если агент творит дичь, то они просто написали плохие спецификации.
А ещё бывает, что в меленьких проектах у разрабов есть доступ ко всему и нормально живут. Эту же логику повторяют для агентов, а потом удивляются. Для агентов нужно сразу нормально делать.
А потом говорят, что это просто язык более высокого уровня и ничего страшного, что недетерминированный, люди же тоже недетерминированные. А оно вот оно как оказывается.
Мы попали в странный мир, где использование нейронки сразу задаёт вопрос: что тут мысли автора, а что галлюцинации?. Может пора вместе со статьёй промт под спойлер выкладывать? Кривой, корявый, но по нему хотя бы можно сверить что автор на самом деле говорил (:
А вообще, вычитывать надо, чтобы не было таких странных "это не галочка, это их ограничение"
Сам сталкивался с таким эффектом - читаешь, понимаешь что генерация, ценность падает, больше читать не хочется. Потому что не знаешь, что здесь мысли автора, а что галлюцинации нейронки.
Ещё столкнулся с "высушенным" слогом. Я такой получал, когда просил писать документацию покороче, а нейрокна просто сносила связки между словами. На хабре полно таких статей, например https://habr.com/ru/articles/1064006/
Сегодня про background jobs в.NET: Hangfire, Quartz, Worker Service и тот неловкий момент, когда job “почти точно выполнилась”, но система не уверена.
Ещё бывают какие-то странные метафоры, типа
Фреймворк видит exception. Бизнес видит второй счет клиенту. Разница небольшая, примерно как между «инцидент» и «созвон через 10 минут».
Всё просто: люди без всего этого могут работать, а нейронки - нет.
Когда у меня был проект с большой текучкой, на проекте была идеальная документация на анбординг. Но потом всё устаканилось, команда стабилизировалась, а документация потихоньку протухла.
Агент анбордится в каждом новом чате и человек по неволе задумывается, как бы ему не объяснять одно и тот же каждый раз.
Agent Comfort - свойство среды: насколько агенту удобно ориентироваться в контексте, применять доступные инструменты и проверять свою работу. Измеряется оно метрикой First-Prompt Success Rate:
Меня этот кусок зацепил. Делается неявное предположение, что если агенту будет удобно ориентироваться в проекте (т.е. комфортно), то метрика будет 100%. Т.е. агент всегда может справиться с задачей. Но это вообще-то отдельно доказывать надо.
А самое прикольное, что человек тоже обучается и со временем начинает давать задачи с которыми агент справляется и метрика идёт к 100% чисто на чуйке пользователя.
переписывает эти изменения под сценарии” сломало бы эти тесты.
А он и тесты переписал. И только глазки человека позволили это заметить :D
имя эндпоинта это контракт, его лучше фиксировать в отдельной задаче
Верно. И тут мы развиваем интуицию, что можно давать агенту выбирать, а что нужно фиксировать. Но бывают вещи, про которые ты не подумал, а агент не сказал и там может быть что угодно.
Бесконечное уточнение спецификации это опять-таки пример, когда вместо поиска и удаления противоречий ставятся заплатки.
Неправда. Мы тут топим каждый за своё. Ты за противоречия, типа пиши без противоречий. А я за полноту. Агент не путается и не делает заплатки, он уточняет понимание до бесконечности пока спецификация не станет похожей на код. Поэтому и я сказал, что процесс нужно когда-то остановить.
У меня уже сформировалась "чуйка", что агент может сделать, а что нет, какого уровня задачи ему можно давать и какая должна быть детализация постановки. Моя метрика - это усилия. Если понимаю, что проще руками - делаю руками, если быстрее через ИИ - то через ИИ.
А где-то там есть прекрасный мир где "оно само", но я пока смотрю на со скепсисом, т.к. не чувствую, что нейронка может выдать результат нужного качества, сколько её не промтируй.
Не значит. Это только одна из причин. А другая - вероятностная суть моделей. Самое просто: разные имена ендпоинтов от запуска к запуску. Или разное поведение внутри обработчика, потому что какие-то граничные случаи не были описаны. Т.е. код не эквивалентный по поведению.
Правила, которые ничем не проверяются - кандидаты на удаление, а не на пополнение
А такие бывают? их можно проверять другой моделью
По дизайн-документу попробуйте сценарии, которые прогоняются - тогда “сделал не то” краснеет сразу.
У меня полно авто-тестирования, но мы не знаем того, чего не знаем. Из последнего: из дева приехали изменения, которые влияют на текущую задачу, а ИИ просто переписывает эти изменения под сценарии, которые сделал человек. Поняли на странном коде на ревью.
агент в режиме максимального думания ищет противоречия в вашем контексте.
Делаю такое, происходит бесконечное уточнение спецификации :) Тут важно вовремя остановиться и начать писать код, т.к. код тоже спецификация сама по себе.
P.s. "тот же корень" - нейронка писала или просто много общался ЛЛМ?
Звучит заманчиво, но у меня не получается так, чтобы я дал задачу абстрактно и получил результат. В проекте просто нет и не может быть всех данных для решения проблемы. И конвенции не спасают. А делаю бэкенды, если что.
Фиксануть какой-то мелкий баг - обычно без проблем (хотя иногда с проблемами). А вот сделать новую фичу - уже так просто не получается. Приходится писать дизайн-документ, который кроме "что мы хотим" содержит кучу технических решений. Иначе модель нафигачит "как она видит" при том по разному от запуску к запуску. Документ уточняется по мере реализации.
Я пытался собирать в кучу места, где модель косячит и столкнулся с тем, что процесс походу бесконечный. Правил становится всё больше и конца не видать. А ещё чем больше правил, тем модели сложнее: она пытается учесть все правила, даже самые неважные и уходит в сложные рассуждения.
Гейты штука хорошая, но они не закрывают проблем в случае, если модель сделала не то или какую-то фигню. При этом гейты молчат, валидация другой моделью тоже.
В общем кодогнератор и ревьюер полезный, но как ему доверить разработку и не смотреть в код - я хз
А в базе это уже конкретная DDL-операция с блокировками, перепроверкой данных и неприятным вопросом: “а сколько строк в Orders?”
Начиная с 11 постгреса (уже 8 лет) используется fast default, когда данные о значении по умолчанию пишутся в метадату таблицы в колонку pg_attribute.attmissingval. Это всё ещё требует эксклюзивной блокировки, но никакой проверки на количество строк в Orders нет. Таблица вообще не трогается.
z.ai удалил glm-5.1 из подписки и я попробовал 5-flash.
Так вот, иногда агент всё же тупой
Потому что умолчания. Если стоит по умолчанию, то выше шанс того, что кто-то будет пользоваться. А если можно снести - это же хорошо.
Про это знать надо. Внезапно, оказывается, что инженерные навыки всё ещё нужны, а инструкция для агента - это не программа.
Некоторые люди до сих пор верят, что если агент творит дичь, то они просто написали плохие спецификации.
А ещё бывает, что в меленьких проектах у разрабов есть доступ ко всему и нормально живут. Эту же логику повторяют для агентов, а потом удивляются. Для агентов нужно сразу нормально делать.
А потом говорят, что это просто язык более высокого уровня и ничего страшного, что недетерминированный, люди же тоже недетерминированные. А оно вот оно как оказывается.
Мы попали в странный мир, где использование нейронки сразу задаёт вопрос: что тут мысли автора, а что галлюцинации?. Может пора вместе со статьёй промт под спойлер выкладывать? Кривой, корявый, но по нему хотя бы можно сверить что автор на самом деле говорил (:
А вообще, вычитывать надо, чтобы не было таких странных "это не галочка, это их ограничение"
Нейронка это
А потом у тебя какая-нибудь неидемпотентная интеграция с системой, которую не ты писал и никак повлиять не можешь :)
Кармак крутой
Сам сталкивался с таким эффектом - читаешь, понимаешь что генерация, ценность падает, больше читать не хочется. Потому что не знаешь, что здесь мысли автора, а что галлюцинации нейронки.
Ещё столкнулся с "высушенным" слогом. Я такой получал, когда просил писать документацию покороче, а нейрокна просто сносила связки между словами. На хабре полно таких статей, например https://habr.com/ru/articles/1064006/
Ещё бывают какие-то странные метафоры, типа
Всё просто: люди без всего этого могут работать, а нейронки - нет.
Когда у меня был проект с большой текучкой, на проекте была идеальная документация на анбординг. Но потом всё устаканилось, команда стабилизировалась, а документация потихоньку протухла.
Агент анбордится в каждом новом чате и человек по неволе задумывается, как бы ему не объяснять одно и тот же каждый раз.
Меня этот кусок зацепил. Делается неявное предположение, что если агенту будет удобно ориентироваться в проекте (т.е. комфортно), то метрика будет 100%. Т.е. агент всегда может справиться с задачей. Но это вообще-то отдельно доказывать надо.
А самое прикольное, что человек тоже обучается и со временем начинает давать задачи с которыми агент справляется и метрика идёт к 100% чисто на чуйке пользователя.
Очень сжато написано, можно человеческим языком, в чём суть?
Всё верно
А он и тесты переписал. И только глазки человека позволили это заметить :D
Верно. И тут мы развиваем интуицию, что можно давать агенту выбирать, а что нужно фиксировать. Но бывают вещи, про которые ты не подумал, а агент не сказал и там может быть что угодно.
Неправда. Мы тут топим каждый за своё. Ты за противоречия, типа пиши без противоречий. А я за полноту. Агент не путается и не делает заплатки, он уточняет понимание до бесконечности пока спецификация не станет похожей на код. Поэтому и я сказал, что процесс нужно когда-то остановить.
У меня уже сформировалась "чуйка", что агент может сделать, а что нет, какого уровня задачи ему можно давать и какая должна быть детализация постановки. Моя метрика - это усилия. Если понимаю, что проще руками - делаю руками, если быстрее через ИИ - то через ИИ.
А где-то там есть прекрасный мир где "оно само", но я пока смотрю на со скепсисом, т.к. не чувствую, что нейронка может выдать результат нужного качества, сколько её не промтируй.
Не значит. Это только одна из причин. А другая - вероятностная суть моделей. Самое просто: разные имена ендпоинтов от запуска к запуску. Или разное поведение внутри обработчика, потому что какие-то граничные случаи не были описаны. Т.е. код не эквивалентный по поведению.
А такие бывают? их можно проверять другой моделью
У меня полно авто-тестирования, но мы не знаем того, чего не знаем. Из последнего: из дева приехали изменения, которые влияют на текущую задачу, а ИИ просто переписывает эти изменения под сценарии, которые сделал человек. Поняли на странном коде на ревью.
Делаю такое, происходит бесконечное уточнение спецификации :) Тут важно вовремя остановиться и начать писать код, т.к. код тоже спецификация сама по себе.
P.s. "тот же корень" - нейронка писала или просто много общался ЛЛМ?
Звучит заманчиво, но у меня не получается так, чтобы я дал задачу абстрактно и получил результат. В проекте просто нет и не может быть всех данных для решения проблемы. И конвенции не спасают. А делаю бэкенды, если что.
Фиксануть какой-то мелкий баг - обычно без проблем (хотя иногда с проблемами). А вот сделать новую фичу - уже так просто не получается. Приходится писать дизайн-документ, который кроме "что мы хотим" содержит кучу технических решений. Иначе модель нафигачит "как она видит" при том по разному от запуску к запуску. Документ уточняется по мере реализации.
Я пытался собирать в кучу места, где модель косячит и столкнулся с тем, что процесс походу бесконечный. Правил становится всё больше и конца не видать. А ещё чем больше правил, тем модели сложнее: она пытается учесть все правила, даже самые неважные и уходит в сложные рассуждения.
Гейты штука хорошая, но они не закрывают проблем в случае, если модель сделала не то или какую-то фигню. При этом гейты молчат, валидация другой моделью тоже.
В общем кодогнератор и ревьюер полезный, но как ему доверить разработку и не смотреть в код - я хз
А если Ill, то вообще туши свет
Я всё понимаю, просите нейронку писать покороче, в информационном стиле. Но поиграйте с промтами, невозможно же читать такую рубленную подачу.
На цитате выше я сломался и бросил статью
Начиная с 11 постгреса (уже 8 лет) используется fast default, когда данные о значении по умолчанию пишутся в метадату таблицы в колонку pg_attribute.attmissingval. Это всё ещё требует эксклюзивной блокировки, но никакой проверки на количество строк в Orders нет. Таблица вообще не трогается.
Поправил