Сам сталкивался с таким эффектом - читаешь, понимаешь что генерация, ценность падает, больше читать не хочется. Потому что не знаешь, что здесь мысли автора, а что галлюцинации нейронки.
Ещё столкнулся с "высушенным" слогом. Я такой получал, когда просил писать документацию покороче, а нейрокна просто сносила связки между словами. На хабре полно таких статей, например 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 нет. Таблица вообще не трогается.
В запястье этой роборуки скрыта передача, которую в 1955 году придумал инженер американской обувной компании.В основании стоит редуктор, запатентованный немецким инженером, который еще до Второй мировой продал лицензию в Японию....
Кармак крутой
Сам сталкивался с таким эффектом - читаешь, понимаешь что генерация, ценность падает, больше читать не хочется. Потому что не знаешь, что здесь мысли автора, а что галлюцинации нейронки.
Ещё столкнулся с "высушенным" слогом. Я такой получал, когда просил писать документацию покороче, а нейрокна просто сносила связки между словами. На хабре полно таких статей, например https://habr.com/ru/articles/1064006/
Ещё бывают какие-то странные метафоры, типа
Всё просто: люди без всего этого могут работать, а нейронки - нет.
Когда у меня был проект с большой текучкой, на проекте была идеальная документация на анбординг. Но потом всё устаканилось, команда стабилизировалась, а документация потихоньку протухла.
Агент анбордится в каждом новом чате и человек по неволе задумывается, как бы ему не объяснять одно и тот же каждый раз.
Меня этот кусок зацепил. Делается неявное предположение, что если агенту будет удобно ориентироваться в проекте (т.е. комфортно), то метрика будет 100%. Т.е. агент всегда может справиться с задачей. Но это вообще-то отдельно доказывать надо.
А самое прикольное, что человек тоже обучается и со временем начинает давать задачи с которыми агент справляется и метрика идёт к 100% чисто на чуйке пользователя.
Очень сжато написано, можно человеческим языком, в чём суть?
Всё верно
А он и тесты переписал. И только глазки человека позволили это заметить :D
Верно. И тут мы развиваем интуицию, что можно давать агенту выбирать, а что нужно фиксировать. Но бывают вещи, про которые ты не подумал, а агент не сказал и там может быть что угодно.
Неправда. Мы тут топим каждый за своё. Ты за противоречия, типа пиши без противоречий. А я за полноту. Агент не путается и не делает заплатки, он уточняет понимание до бесконечности пока спецификация не станет похожей на код. Поэтому и я сказал, что процесс нужно когда-то остановить.
У меня уже сформировалась "чуйка", что агент может сделать, а что нет, какого уровня задачи ему можно давать и какая должна быть детализация постановки. Моя метрика - это усилия. Если понимаю, что проще руками - делаю руками, если быстрее через ИИ - то через ИИ.
А где-то там есть прекрасный мир где "оно само", но я пока смотрю на со скепсисом, т.к. не чувствую, что нейронка может выдать результат нужного качества, сколько её не промтируй.
Не значит. Это только одна из причин. А другая - вероятностная суть моделей. Самое просто: разные имена ендпоинтов от запуска к запуску. Или разное поведение внутри обработчика, потому что какие-то граничные случаи не были описаны. Т.е. код не эквивалентный по поведению.
А такие бывают? их можно проверять другой моделью
У меня полно авто-тестирования, но мы не знаем того, чего не знаем. Из последнего: из дева приехали изменения, которые влияют на текущую задачу, а ИИ просто переписывает эти изменения под сценарии, которые сделал человек. Поняли на странном коде на ревью.
Делаю такое, происходит бесконечное уточнение спецификации :) Тут важно вовремя остановиться и начать писать код, т.к. код тоже спецификация сама по себе.
P.s. "тот же корень" - нейронка писала или просто много общался ЛЛМ?
Звучит заманчиво, но у меня не получается так, чтобы я дал задачу абстрактно и получил результат. В проекте просто нет и не может быть всех данных для решения проблемы. И конвенции не спасают. А делаю бэкенды, если что.
Фиксануть какой-то мелкий баг - обычно без проблем (хотя иногда с проблемами). А вот сделать новую фичу - уже так просто не получается. Приходится писать дизайн-документ, который кроме "что мы хотим" содержит кучу технических решений. Иначе модель нафигачит "как она видит" при том по разному от запуску к запуску. Документ уточняется по мере реализации.
Я пытался собирать в кучу места, где модель косячит и столкнулся с тем, что процесс походу бесконечный. Правил становится всё больше и конца не видать. А ещё чем больше правил, тем модели сложнее: она пытается учесть все правила, даже самые неважные и уходит в сложные рассуждения.
Гейты штука хорошая, но они не закрывают проблем в случае, если модель сделала не то или какую-то фигню. При этом гейты молчат, валидация другой моделью тоже.
В общем кодогнератор и ревьюер полезный, но как ему доверить разработку и не смотреть в код - я хз
А если Ill, то вообще туши свет
Я всё понимаю, просите нейронку писать покороче, в информационном стиле. Но поиграйте с промтами, невозможно же читать такую рубленную подачу.
На цитате выше я сломался и бросил статью
Начиная с 11 постгреса (уже 8 лет) используется fast default, когда данные о значении по умолчанию пишутся в метадату таблицы в колонку pg_attribute.attmissingval. Это всё ещё требует эксклюзивной блокировки, но никакой проверки на количество строк в Orders нет. Таблица вообще не трогается.
Поправил
Что-то ваша архитектура не справилась с вычиткой
Хитрюги: не просто мимикрия под steam, но ещё и используют несуществующее слово
Если будет 2 ручки, то всё по заветам физиков
А всё почему?
Потому что инженеры вместе - сила!
Проходит, что это было? https://detector404.ru/github
Просто используй легаси диалог
Точно не диффузная модель? Это они такое любят, особенно ранние типа StableDiffusion 1.5