Да я не спорю. Помню и на Москвич газовые амортизаторы.
Но, как по мне, жто для специфических целей типа гонок. Не для обычной езды. Я такое отношу к "тюнинг", от которого ожидаются более высокие характеристики за существенно большие деньгши. В то время как "неоригинал" подсознательно воспринимаю как "может чуток и похуже, но существенно дешевле".
На роботе нельзя было. На нынешней не особо экспериментировал. Сразу орет, ругается.
В принципе я ее понимаю - на нейтрали с принудительно выключенным двигаетелем - зачем? Явно ведь чтобы перемещать, вероятно на тросе. С заблокированным рулем - плохая идея, даже если не полностью заблокирован, а просто без ГУР. Стоит того, чтобы посопротивляться и потребовать доказательств, что я в своем уме, и правда очень надо.
Вспоминается классика: "Вы, Шариков, чепуху говорите, и возмутительнее всего то, что говорите ее безапелляционно и уверенно".
"чаще всего они дороже оригинала или сравнимы"
И зачем же тогда покупают (и производят) ломучий дорогущий неоригинал? Не могу понять вашу картину мира.
и люди покупают их на свой страх и риск. По ценам оригинала, какие они были несколько лет назад
Да, цены выросли, сейчас "неоригинал" стоит дороже, чем когда-то оригинал. А китайский автомобиль сейчас стоит дороже, чем когда-то немецкий.
И что? Какую вашу мысль должно подтвердить такое сравнение?
P.S. Моему авто почти 10 лет. Деньги на новый есть, но менять не собираюсь. Обслуживаюсь у тех же официалов, что и этот новый обслуживал, и предыдущий новый (и уже после окончания гарантии). Разумеется, и скидку дают, и сами предлагают варианты в т.ч. с неоригиналами. И подсказывают - вот этот узел критичный, нагруженый, здесь лучше вот это, а тут нет смысла переплачивать...
У меня машинка хоть и старая, почти 10 лет, но даже она имеет защиту от дурака. Например, не дает переключаться на ходу в режим "Ракета". И заглушить двигаетель на ходу - тоже. Орет благим матом даже если просто оставил на скорости, педаль на тормозе, и пытаешься заглушить не в положении Паркинг. И на Нейтрали тоже орет, потому как знает, что машина может покатиться, опасно это.
На предыдущей была роботизированая коробка. Аналогичные приколы. Можно, конечно, буксировать на нейтрали. Но для этого надо волшебную кнопку на консоли хорошо так нажать, чтобы коробку разблокировать.
Делать такое ради "протолкнуть машину три метра" - спасибо, нафиг.
Вы заплатили з/п тем программистам, которые делают комбайн
Даже если так, вы уж определитесь. Я - ленивая жопа (поленился поменять таксиста несмотря на возросшее неудобство от комбайна). Или я попросил сделать это комбайн (проявил активность, не поленился).
"Поленился наказать изготовителей комбайна, а мендежеры воспользовались моей пассивностью ради своих KPI" - OK.
Но переформулировать это в "менеджеры исполнили мою просьбу" - слишком сильно, надо бы обосновать.
---
Возможно вы выбираете сервис такси ориентируясь исключительно на приложение. Я - нет. Я плачу за сервис такси, в котором приложение - очень незначительный фактор.
Возможно вы выбираете банк ориентируясь исключительно на приложение. Я - нет. Я выбираю банковские услуги.
"Сделали иконку не того цвета/размера, пойду в другой банк" - для меня это из серии "назло маме отморожу уши".
В сервисе такси для меня главное - сервис такси. Приложение вторично.
Мне кажется странным "сервис, конечно, говно, зато приложение в точности, как я хочу, и пофиг, что могут кинуть, заказ отменить и повезти, главное, что размещаю заказ удобно". Ну нет же! Я буду чертыхаться, нажимая лишние кнопки, продираюсь через неудобное меня, но буду пользоваться, покуда уверен, что в большинстве случаев получу то, что мне надо. Однако можно ли называть это "я проголосовал за приложение-комбайн"?
Вы же утверждаете, что коли я не прекратил пользоваться сервисом такси, когда они сделали комбайн из приложения, значит я проголосовал за этот комбайн.
Не просто смирился, а именно проголосовал за него!
Ну вот прямо так вы и писали, и сейчас подтвержаете свою мысль:
попросили именно потребители, которые выбирают банк, в котором в программе три блока рекламы.
Не "терпят 3 блока рекламы, потому что банковские сервисы устраивают", а "выбирают банк не за сервисы, а зе эти 3 блока рекламы".
Это просто пруфы, что я не выдумал историю. Разумеется, вникать туда незачем.
Я лишь хотел продемонстрировать, что ИИ вполне может помогать в том числе в поиске ошибок в логике, когда код сам по себе выглядит вполне правильно и человек, не знающий, что этот код должен делать, ошибку не найдет.
У меня есть два подозрения, почему вы считаете поиск такого бага сложным:
Константа в другом файле (партнера).
баг - не crash, не "совсем неправильные данные", а ошибка, которая маскируется под нормальное поведение. На code review такие чсложно найти, поскольку код выглядит "правильно" на первый взгляд.
В первом случае LLM имеет даже преимущества, она по умолчанию проверяет связанное, когда готовит сама себе контекст для анализа
Во втором - ну вот мой пример. Как мне кажется, этот "котенок с дверцей" показывает, что LLM учитывает логику, реализуемую кодом.
Много букв
▎ SPI-TR3 is 01:00 start + 05:00 duration = active 01:00–06:00 UTC. At 12:15 it should be inactive. The bug is in the backend resolver. Let me read it.
---
▎ Found the bug. Line 52 + 119: DEFAULT_RANGE: str = “SPI-TR3” … return active_ranges or [cls.DEFAULT_RANGE] # ← fallback when nothing matches At 12:15 UTC, nothing is active (correct), but the code falls back to [“SPI-TR3”] — so the log is honest, it’s just reporting the fallback, not a real active range. The system then finds 0 locations for SPI-TR3 → 0 candidates, which is actually the right end result. But the log is very misleading. The fix: when no range is active, return [] and let the caller handle it as “nothing to do”:
---
▎ The full picture is clear. Three things to fix: 1. resolve_all line 119: stop falling back to DEFAULT_RANGE when nothing matches — return [] 2. resolve() line 133: guard against empty list 3. Caller line 1345: when list is empty, emit a clear “Outside all scheduled time ranges” message and stop — currently it only stops at step 2 (no locations) with a misleading path through the fallback
---
▎ The second caller handles [] naturally — get_codes_for_ranges([]) returns [] immediately (line 181 guard), then returns empty candidates. No change needed there.
---
▎ Clean. Now the log at 12:15 will show: Outside all scheduled time ranges — no push scheduled Found 0 candidates Instead of the misleading Active time ranges: SPI-TR3. Ready to commit whenever you are.
Причем что в дополнительный плюс записываю - он проверил другие вызовы, связанные с изменением. Возможно вы тоже проанализировали "где используется другие константы партнеров" (вряд ли она была единственной), но LLM в любом случае быстрее подсветила бы вам, куда еще глянуть.
Если честно, я бы в качестве примера скорее race conditions приводил. Брейкпойнты не особо помогут, даже логи дополнительные могут поведение изменить.
Был прикольный случай, когда я просил его задокументировать, что мой модуль делает. И он в процессе написания документа (когда анализировал, что в какой последловательности модуль делает) нашел:
There is no locking inside the plugin itself (no asyncio.Lock, no DB row locks, no unique-constraint-based guard) protecting a run from overlapping with another run. Two concurrent invocations (e.g. via CLI and API at the same time) can race on disk reads/writes and database commits.
The Scheduler plugin’s own single-concurrent-execution guard (per-job is_running flag) only prevents overlapping scheduled runs of the same job — it does nothing to stop a manually-triggered CLI or API run from overlapping with a scheduled run.
Да, запустить параллельно ту же задачу через cli - в жизни такое вряд ли произошло бы, поскольку это механизм скорее для отладки и исключительных ситуаций (доступен только через podman exec). Однако ж если можно поправить - надо поправить Спасибо, Клод.
Ну или вот: я пришел с запросом: "No spinner, I see “running” forever, even when completed".
Клод:
Two problems: the trigger call returns immediately (job runs async), so the spinner dies right away; and there’s no auto-refresh while a job is running. Fix: poll every 3s while any job shows running, and keep the Trigger button spinning while last_run.status === “running”.
---
Fix: auto-poll + persistent spinner
<кусок кода для фронтенда>
---
Я проверил - стало лучше, но не совсем
Interesting. I see a small spinner on “trigger” button now. And once in a few seconds a “flash” with a bigger spinner in the middle of the page.
---
The “flash” is the table’s loading spinner firing on each poll refresh. Easy fix — suppress it during background polls:
<добавил флаг...>
---
Как по мне, frontend/backend timing race (бэкенд запускает job асинхронно, фронтенд не знает когда он завершится, и без polling’а статус «running» застывает навсегда) - сложно тем, что две команды должны согласовано чинить. А Клод понимает код как фронтенда, так и бэкенда.
Понятно, что "своя рубашка ближе к телу", и ваш баг суперсложный, а мои - "сам дурак, что такое допустил". Однако ж, мне кажется, они демонстрируют, что ИИ может быть полезна в поиске багов в т.ч. "логических"
Не обязательно ведь просить ее править код. Но попросить подсветить несколько мест, куда стоит посмотреть - почему бы и да.
Это ни в коем случае не значит, что он лучше меня справляется. Сплошь и рядом я ему подсказываю "у меня две версии, почему так, проверь". И он уже говорит "вот эта вряд ли потому то и потому, а вот эта - да..." Правда это приходится делать редко, только когда вижу, что сам он никак найти не может.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели.
Такое впечатление, что вы ни разу не видели тестов, написанных LLM, просто пишете штампы, не попытавшись хотя бы просто посмотреть, как она напишет тесты какой-нибудь вашей функции.
Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Вы точно со мной сейчас разговариваете?
Не надо мне приписывать свои страхи (галлюцинации, фантазии) про "заменить архитектора"
Я тут всю дорогу распинаюсь, что специалист (архитектор) необходим. LLM - помощник ему при планировании и написании детальных формальных спецификаций. И на следущем этапе - "строитель", который делает "грязную работу", следуя качественной детальной спецификации.
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый.
Ну так это же прекрасно! У человека "ничего не понял", "не совсем понял" и т.п. Субъективно. У ЛЛМ все гораздо четче, ее на мякине не проведешь. "42%, надо уточнять". Никаких "вдруг если спрошу, подумают, что я плохой специалист, лучше промолчу"...
Почему, кстати, вас беспокоит, кем написан тест?
Меня лично больше волнует полнота условий для проверки, чтобы один и тот же тест гонялся с десятками разных комбинаций параметров перебирая и "нормальные" случаи из "серединки", и нормальные "на границах" допустимого, и "за границами. Причем в рзаных комбинациях (несколько граничных и т.п.)
Ну т.е. тест написать не сложно, вот они ассерты, глазами смотри, точно так же, как после коллеги. А вот набрать немеряную кучу условий... И опять же - само собой, потом надо их посмотреть, искусственно "испортить", чтобы убедиться, что это приводит к фейлам....
Причем код, который пишет LLM - отдельно. А входящие исходящие параметры для тестов (где она должна зафейлиться, а где должна в соответствии с задачей выдать нечто конкретное) LLM (возможно другая) пишет именно исходя из задачи. Т.е. код теста отнюдь не "подтягивается" под функцию.
А про контекст... Вы точно понимаете разницу, к примеру, между вызовом агента и скиллза?
Вкратце: И то и это вызывается при необходимости. Но в случае скиллза он остается в основном контексте. Вызван единожды, больше не потребуется в той сессии, но в конексте место занимает. А агенту "основной контекст" дает задачу и всю необходимую информацию. Агент "шуршит", возможно получает кучу "мусора", выбирает именно то, что требуется, и возвращает только это. Он выполняется в отдельном контексте, возвращшет только нужное, безо всяких промежуточных этапов. В основном конексте появляется только минимально необходимый результат.
Не надо тупо скармливать в контекст всю вашу кодовую базу. Человек, кстати, тоже вряд ли помнит каждую строчку.
Мне, конечно, интересно узнать, чем "непонятно" отличается от "энтропия выше", ну да ладно.
Вы же в курсе, что так-то он еще и тестами код покрывает, как минимум, unit test? Причем генерирует больше edge cases, чем я сам бы напилил. И это все по согласованию со мной. Если я считаю, что может еще подводный камень быть - я ему подскажу, что еще протестировать, это и есть моя задача :)
Разумеется, даже с интеграционными тестами все еще возможны рантайм ошибки. И я слабо верю, что вы настолько хорошо просчитываете на 10 шагов вперед, что сразу написаный код оправляете в прод, и он там без багов работает.
Если же даже ваш код проверяется, зачем вы постоянно пытаетесь ограничить LLM? То дать ей меньше данных, чем программисту (пусть сама решает, какие скидки суммировать, а какие нет), то отправить код на выполнение без проверок...
ИИ же, в принципе, не разбирается в предметной области. Ни в какой.
"Хоть горшком назови, только в печку не ставь"
ИИ не будет ничего "уточнять". Он просто реализует.
Если вы про веб-интерфейс - возможно. Хотя пока я опыта в составлении промптов не набрался, он даже там умудрялся уточнящие вопросы задавать, когда я "кофе черный с молоком" просил.
А в нормальной системе он именно что сначала задает кучу уточняющих вопросов, чтобы лучше "понять" задачу. Потом предлагает варианты, объясняя их поюсы и минусы. Потом пишет спеки/планы. И приступает к реализации только когда они меня полностью устроили.
Причем изредка бывает, что я даже при таком подходе чего-то пропустил, и тогда даже на этапе реализации система может остановиться и сказать "вот тут написано надо сделать так-то, но так не получится....".
Вы писали, мол агент не может проверить, соответствует ли код бизнес-логике. Соответственно у меня вопрос: кто у вас это проверяет? Кто проверяет код, если не программист? Аналитик, знающий бизнес-требования, когда какие скидкы суммируются, а какие нет?
И так-то ИИ разбирается в предментной области, скорее всего, лучше рядового программиста. И с гораздо большей вероятностью уточнит. что обычно так не делается.
Кого вы имели ввиду, упоминая "для человека разбирающегося в предметной области, это повод задать вопрос бизнесу"?
Да! Использование LLM, как и торцовки/болгарки/etc., требует обучения, формирования навыков, соблюдения техники безопасности 😊 А вовсе не просто "замена всем человекам".
Да я не спорю. Помню и на Москвич газовые амортизаторы.
Но, как по мне, жто для специфических целей типа гонок. Не для обычной езды. Я такое отношу к "тюнинг", от которого ожидаются более высокие характеристики за существенно большие деньгши. В то время как "неоригинал" подсознательно воспринимаю как "может чуток и похуже, но существенно дешевле".
Моя внутренняя терминология :)
То, что речь шла о "Брембо на ВАЗ" - не понял, извините. Это действительно
извращениередкость.На роботе нельзя было. На нынешней не особо экспериментировал. Сразу орет, ругается.
В принципе я ее понимаю - на нейтрали с принудительно выключенным двигаетелем - зачем? Явно ведь чтобы перемещать, вероятно на тросе. С заблокированным рулем - плохая идея, даже если не полностью заблокирован, а просто без ГУР. Стоит того, чтобы посопротивляться и потребовать доказательств, что я в своем уме, и правда очень надо.
Вспоминается классика: "Вы, Шариков, чепуху говорите, и возмутительнее всего то, что говорите ее безапелляционно и уверенно".
И зачем же тогда покупают (и производят) ломучий дорогущий неоригинал? Не могу понять вашу картину мира.
Да, цены выросли, сейчас "неоригинал" стоит дороже, чем когда-то оригинал. А китайский автомобиль сейчас стоит дороже, чем когда-то немецкий.
И что? Какую вашу мысль должно подтвердить такое сравнение?
P.S. Моему авто почти 10 лет. Деньги на новый есть, но менять не собираюсь. Обслуживаюсь у тех же официалов, что и этот новый обслуживал, и предыдущий новый (и уже после окончания гарантии). Разумеется, и скидку дают, и сами предлагают варианты в т.ч. с неоригиналами. И подсказывают - вот этот узел критичный, нагруженый, здесь лучше вот это, а тут нет смысла переплачивать...
Это многое объясняет.
У меня машинка хоть и старая, почти 10 лет, но даже она имеет защиту от дурака. Например, не дает переключаться на ходу в режим "Ракета". И заглушить двигаетель на ходу - тоже. Орет благим матом даже если просто оставил на скорости, педаль на тормозе, и пытаешься заглушить не в положении Паркинг. И на Нейтрали тоже орет, потому как знает, что машина может покатиться, опасно это.
На предыдущей была роботизированая коробка. Аналогичные приколы. Можно, конечно, буксировать на нейтрали. Но для этого надо волшебную кнопку на консоли хорошо так нажать, чтобы коробку разблокировать.
Делать такое ради "протолкнуть машину три метра" - спасибо, нафиг.
Почти как в анекдоте - "Не дай Бог до такого дожить"
IMHO уже в начале 2000 начали массово ставить сеточки в бензобаки/горловины.
Фиг сейчас сольешь из собственного бака, чтобы газонокосилку заправить...
Вот трудно было сразу адрес этой чудо-АЗС привести?
Вы точно помните, о чем спор?
Даже если так, вы уж определитесь. Я - ленивая жопа (поленился поменять таксиста несмотря на возросшее неудобство от комбайна). Или я попросил сделать это комбайн (проявил активность, не поленился).
"Поленился наказать изготовителей комбайна, а мендежеры воспользовались моей пассивностью ради своих KPI" - OK.
Но переформулировать это в "менеджеры исполнили мою просьбу" - слишком сильно, надо бы обосновать.
---
Возможно вы выбираете сервис такси ориентируясь исключительно на приложение. Я - нет. Я плачу за сервис такси, в котором приложение - очень незначительный фактор.
Возможно вы выбираете банк ориентируясь исключительно на приложение. Я - нет. Я выбираю банковские услуги.
"Сделали иконку не того цвета/размера, пойду в другой банк" - для меня это из серии "назло маме отморожу уши".
В сервисе такси для меня главное - сервис такси. Приложение вторично.
Мне кажется странным "сервис, конечно, говно, зато приложение в точности, как я хочу, и пофиг, что могут кинуть, заказ отменить и повезти, главное, что размещаю заказ удобно". Ну нет же! Я буду чертыхаться, нажимая лишние кнопки, продираюсь через неудобное меня, но буду пользоваться, покуда уверен, что в большинстве случаев получу то, что мне надо. Однако можно ли называть это "я проголосовал за приложение-комбайн"?
Вы же утверждаете, что коли я не прекратил пользоваться сервисом такси, когда они сделали комбайн из приложения, значит я проголосовал за этот комбайн.
Не просто смирился, а именно проголосовал за него!
Ну вот прямо так вы и писали, и сейчас подтвержаете свою мысль:
Не "терпят 3 блока рекламы, потому что банковские сервисы устраивают", а "выбирают банк не за сервисы, а зе эти 3 блока рекламы".
Чудеса...
Можете привести пример, каким образом вы или кто-то из ваших родных знакомых потребовали превращения Яндекс Такси в адовый комбайн?
Переходили в другие такси, где было вприложении купить солнцезащитные очки, поло и баллон со сжатым газом (это я сейчас его открыл)?
Это просто пруфы, что я не выдумал историю. Разумеется, вникать туда незачем.
Я лишь хотел продемонстрировать, что ИИ вполне может помогать в том числе в поиске ошибок в логике, когда код сам по себе выглядит вполне правильно и человек, не знающий, что этот код должен делать, ошибку не найдет.
У меня есть два подозрения, почему вы считаете поиск такого бага сложным:
Константа в другом файле (партнера).
баг - не crash, не "совсем неправильные данные", а ошибка, которая маскируется под нормальное поведение. На code review такие чсложно найти, поскольку код выглядит "правильно" на первый взгляд.
В первом случае LLM имеет даже преимущества, она по умолчанию проверяет связанное, когда готовит сама себе контекст для анализа
Во втором - ну вот мой пример. Как мне кажется, этот "котенок с дверцей" показывает, что LLM учитывает логику, реализуемую кодом.
Много букв
Причем что в дополнительный плюс записываю - он проверил другие вызовы, связанные с изменением. Возможно вы тоже проанализировали "где используется другие константы партнеров" (вряд ли она была единственной), но LLM в любом случае быстрее подсветила бы вам, куда еще глянуть.
Если честно, я бы в качестве примера скорее race conditions приводил. Брейкпойнты не особо помогут, даже логи дополнительные могут поведение изменить.
Был прикольный случай, когда я просил его задокументировать, что мой модуль делает. И он в процессе написания документа (когда анализировал, что в какой последловательности модуль делает) нашел:
Да, запустить параллельно ту же задачу через cli - в жизни такое вряд ли произошло бы, поскольку это механизм скорее для отладки и исключительных ситуаций (доступен только через podman exec). Однако ж если можно поправить - надо поправить Спасибо, Клод.
Ну или вот: я пришел с запросом: "No spinner, I see “running” forever, even when completed".
Клод:
Как по мне, frontend/backend timing race (бэкенд запускает job асинхронно, фронтенд не знает когда он завершится, и без polling’а статус «running» застывает навсегда) - сложно тем, что две команды должны согласовано чинить. А Клод понимает код как фронтенда, так и бэкенда.
Понятно, что "своя рубашка ближе к телу", и ваш баг суперсложный, а мои - "сам дурак, что такое допустил". Однако ж, мне кажется, они демонстрируют, что ИИ может быть полезна в поиске багов в т.ч. "логических"
Не обязательно ведь просить ее править код. Но попросить подсветить несколько мест, куда стоит посмотреть - почему бы и да.
Это ни в коем случае не значит, что он лучше меня справляется. Сплошь и рядом я ему подсказываю "у меня две версии, почему так, проверь". И он уже говорит "вот эта вряд ли потому то и потому, а вот эта - да..." Правда это приходится делать редко, только когда вижу, что сам он никак найти не может.
Такое впечатление, что вы ни разу не видели тестов, написанных LLM, просто пишете штампы, не попытавшись хотя бы просто посмотреть, как она напишет тесты какой-нибудь вашей функции.
Вы точно со мной сейчас разговариваете?
Не надо мне приписывать свои страхи (галлюцинации, фантазии) про "заменить архитектора"
Я тут всю дорогу распинаюсь, что специалист (архитектор) необходим. LLM - помощник ему при планировании и написании детальных формальных спецификаций. И на следущем этапе - "строитель", который делает "грязную работу", следуя качественной детальной спецификации.
Ну так это же прекрасно! У человека "ничего не понял", "не совсем понял" и т.п. Субъективно. У ЛЛМ все гораздо четче, ее на мякине не проведешь. "42%, надо уточнять". Никаких "вдруг если спрошу, подумают, что я плохой специалист, лучше промолчу"...
Почему, кстати, вас беспокоит, кем написан тест?
Меня лично больше волнует полнота условий для проверки, чтобы один и тот же тест гонялся с десятками разных комбинаций параметров перебирая и "нормальные" случаи из "серединки", и нормальные "на границах" допустимого, и "за границами. Причем в рзаных комбинациях (несколько граничных и т.п.)
Ну т.е. тест написать не сложно, вот они ассерты, глазами смотри, точно так же, как после коллеги. А вот набрать немеряную кучу условий... И опять же - само собой, потом надо их посмотреть, искусственно "испортить", чтобы убедиться, что это приводит к фейлам....
Причем код, который пишет LLM - отдельно. А входящие исходящие параметры для тестов (где она должна зафейлиться, а где должна в соответствии с задачей выдать нечто конкретное) LLM (возможно другая) пишет именно исходя из задачи. Т.е. код теста отнюдь не "подтягивается" под функцию.
А про контекст... Вы точно понимаете разницу, к примеру, между вызовом агента и скиллза?
Вкратце: И то и это вызывается при необходимости. Но в случае скиллза он остается в основном контексте. Вызван единожды, больше не потребуется в той сессии, но в конексте место занимает. А агенту "основной контекст" дает задачу и всю необходимую информацию. Агент "шуршит", возможно получает кучу "мусора", выбирает именно то, что требуется, и возвращает только это. Он выполняется в отдельном контексте, возвращшет только нужное, безо всяких промежуточных этапов. В основном конексте появляется только минимально необходимый результат.
Не надо тупо скармливать в контекст всю вашу кодовую базу. Человек, кстати, тоже вряд ли помнит каждую строчку.
Мне, конечно, интересно узнать, чем "непонятно" отличается от "энтропия выше", ну да ладно.
Вы же в курсе, что так-то он еще и тестами код покрывает, как минимум, unit test? Причем генерирует больше edge cases, чем я сам бы напилил. И это все по согласованию со мной. Если я считаю, что может еще подводный камень быть - я ему подскажу, что еще протестировать, это и есть моя задача :)
Разумеется, даже с интеграционными тестами все еще возможны рантайм ошибки. И я слабо верю, что вы настолько хорошо просчитываете на 10 шагов вперед, что сразу написаный код оправляете в прод, и он там без багов работает.
Если же даже ваш код проверяется, зачем вы постоянно пытаетесь ограничить LLM? То дать ей меньше данных, чем программисту (пусть сама решает, какие скидки суммировать, а какие нет), то отправить код на выполнение без проверок...
"Хоть горшком назови, только в печку не ставь"
Если вы про веб-интерфейс - возможно. Хотя пока я опыта в составлении промптов не набрался, он даже там умудрялся уточнящие вопросы задавать, когда я "кофе черный с молоком" просил.
А в нормальной системе он именно что сначала задает кучу уточняющих вопросов, чтобы лучше "понять" задачу. Потом предлагает варианты, объясняя их поюсы и минусы. Потом пишет спеки/планы. И приступает к реализации только когда они меня полностью устроили.
Причем изредка бывает, что я даже при таком подходе чего-то пропустил, и тогда даже на этапе реализации система может остановиться и сказать "вот тут написано надо сделать так-то, но так не получится....".
Правильно ли я вас понял, что программисты пишут код детерминировано?
Попросил одного - он написал. Попросил другого - он написал в точности так же (ну может разве что переменные по другому назвал).
А это на любителя. Некоторые умудряются со стековерфлоу куски кода тупо копировать не понимая, что они делают. Тест проходит - отлично.
Вы писали, мол агент не может проверить, соответствует ли код бизнес-логике. Соответственно у меня вопрос: кто у вас это проверяет? Кто проверяет код, если не программист? Аналитик, знающий бизнес-требования, когда какие скидкы суммируются, а какие нет?
И так-то ИИ разбирается в предментной области, скорее всего, лучше рядового программиста. И с гораздо большей вероятностью уточнит. что обычно так не делается.
Кого вы имели ввиду, упоминая "для человека разбирающегося в предметной области, это повод задать вопрос бизнесу"?
Да! Использование LLM, как и торцовки/болгарки/etc., требует обучения, формирования навыков, соблюдения техники безопасности 😊 А вовсе не просто "замена всем человекам".