А вам не всё равно, что лежит в массиве по индексу 3? Поставьте try-catch и увидете в логах, что и как. Вы же на прод с отладчиком не лезете по каждой ошибке. ПишИте нормальный код, если понимаете как. Если не понимаете как - да, тогда используйте отладчик.
Код дебажат только те, кто его не понимают и собираются понять.
Я об этом и написал.
Вы не понимаете свой (или чужой) код - вам нужен дебаггер, т.к. вы собираетесь понять "что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось".
Если бы вы понимали, что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось, вам бы отладчик был не нужен.
Или если бы вы не собирались понять - тогда тоже отладчик не нужен.
А то, что данные пришли неожиданные, ну, так бывает иногда в некоторых ЯП.
Код дебажат только те, кто его не понимают и собираются понять. Зачем дебажить код, если он и так понятен? Или если ты его в принципе не собираешься понимать?
Тестировщики, например, код вообще никогда не дебажат. Им это в принципе не надо.
Скоро похоже SDD станет не актуальным, и процесс упроститься.
Ну, я, например, приверженец SDD. У меня он очень хорошо себя показывает. Код пишется по спекам, тесты пишутся по спекам. Тесты проверяют код. Спеки - единый источник истины для проекта.
Думаю, что для каждого типа проекта (утилита, скрипт, пет-проект, open-source, коммерческий, чиновничий, инфраструктурный, военный, ...) подходят разные "велосипеды" (метод использования ИИ в разработке). Нет и не будет одного единственного подхода, применимого ко всем типам проектов. В том же вайбкодинге можно спокойно генерировать одноразовые программы без каких-либо тестов, т.к. критерием приёмки является выполнение требуемых действий. Эволюция ПО и вайбкодинг не совместимы. Но SDD - это явный перебор, если нужно собрать shell-скрипт для наведения порядка на сервере.
Первое - все о чем тут пишите появилось буквально за 2 года. Хоть и разработка и так была быстроразвивающийся отраслью, но в все же для качественных изменений нужны были десятилетия. А тут годы.
А с этим полностью согласен. Не очень то и просто в массе разобраться, какой инструмент когда использовать. Время нужно.
Не соглашусь. Очень хороший обзор. То, что вы назвали "баззвордами" - это просто терминология. Актуальная терминология в описании актуальных проблем некоторой области человеческой деятельности. Просто это не та область, к которой вы привыкли и которую понимаете. Попробуйте, для начала, порезать документацию по $mol'у на чанки и засунуть в RAG.
Проблема в том, что вы не контролируете агента полностью, сколько было уже случаев удаления информации с личных ноутбуков и серверов?
Да, именно об этом я и говорю. Не надо вообще запускать агента там, где он может сделать что-то вредное. Надо сразу подходить с точки зрения, что агент - это "обезьяна с гранатой". Не пускайте её в "жилые помещения" (свой ноутбук), пусть в "специальном бункере" (VPS) играется.
А если агент уже в "бункере", то в чём смысл ограничивать его права? Как раз лучше сосредотачиваться на мониторинге и контроле. И сохранности данных.
Я бы посмотрел на это с точки зрения "а может просто дать рута агенту?" Поднимаешь виртуальный сервер и отдаёшь его агенту - пусть там сам хозяйничает, раз такой умный. Если что и грохнет, то только этот самый сервак (ну и всё, до чего дотянется через этот сервак). Тогда вопрос безопасности упирается не в ограничения, а в контроль - как убедиться, что агент выполняет то, что надо и не выполняет, чего не надо. Ну и в том, что телеметрия не фейковая.
Как бы мы агента ни ограничивали, эти вопросы всё равно будут актуальными. Может сосредоточиться на них?
Мне кажется, что в решении сложных задач ключом является как раз таки разбиение сложной задачи на последовательность простых задач, каждая из которых решается с малым количеством ресурсов.
Ну, или возможно, я просто ещё не дошёл до по настоящему сложных задач.
Для простых задач в готовой системе их обычно достаточно
Я исхожу из того, что промпт (входные данные) влияет на результат инференса сильнее, чем дообучение (коррекция весов, по сути). Поэтому я придерживаюсь другой позиции - дообучение "экономит" токены, позволяя задавать более простые промпты и подмешивая меньше текста из скиллов. Согласен, что дообученная модель сможет работать с бОльшими фрагментами текста, чем "скилизованная". Но декомпозиция кодовой базы на небольшие фрагменты вполне позволяет комфортно работать с типовой моделью и набором скиллов к ней.
У меня в ML опыта нет вообще, я наблюдаю. Поэтому тут наши выводы вполне могут разниться.
Я думаю, тут сильно влияет ML-деформация автора. Лично мне проще скорректировать поведение типовой модели навыками, чем дообучением.
Ну и вот это:
Я работаю с данными предприятий, а там почти всегда есть либо коммерческая тайна, либо персональные данные, либо и то и другое.
Но, если есть готовый корпус данных для обучения, который не "протухает" со временем, то дообученная модель будет, IMHO, эффективнее типовой. Для крупных "контор" вполне себе решение.
если мы пишем какой то плагин, или только часть файлов в целом проекте, то запуск его физически не возможен
Можно запустить отдельный файл с исполняемым кодом, если соорудить для него окружение. Юнит-тестирование и моки - они как раз про это. Можно и БД замокать, если надо. И сеть. Как раз таки плагин тестить проще, чем целое.
Другое дело, что искусственно поднятое окружение может значимо отличаться от натурального. Но, если такое выявляется, то и эти отличия можно замокать.
А если даже и не поможет, то мы сами справимся. И не с 10% вероятностью, а со 100%!
Вопрос не в том, "когда это произойдёт", а в том "как долго ещё мы сможем избегать неизбежного". И вполне возможно, что ИИ как раз и поможет "оттянуть конец как можно дальше". Но тут, как говорится, всё от нас самих зависит.
Согласен. Наличие собственной картины мира не означает возможности её осознанного использования. Персональный ИИ-агент такого рода - идеальный манипулятор своим "боссом".
Но с другой стороны, люди всегда пытались манипулировать другими - разговоры "по душам", письма-записки, стихи-книги, газеты-журналы, радио-телевидение, театр-кино. У кого-то это получается лучше, у кого-то хуже. Кто-замечает такого рода манипуляции, кто-то - нет. Это просто другой уровень. Ещё один. Надеюсь, не последний :)
А вам не всё равно, что лежит в массиве по индексу 3? Поставьте try-catch и увидете в логах, что и как. Вы же на прод с отладчиком не лезете по каждой ошибке. ПишИте нормальный код, если понимаете как. Если не понимаете как - да, тогда используйте отладчик.
Я об этом и написал.
Вы не понимаете свой (или чужой) код - вам нужен дебаггер, т.к. вы собираетесь понять "что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось".
Если бы вы понимали, что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось, вам бы отладчик был не нужен.
Или если бы вы не собирались понять - тогда тоже отладчик не нужен.
А то, что данные пришли неожиданные, ну, так бывает иногда в некоторых ЯП.
https://ru.wikipedia.org/wiki/Тестирование_по_стратегии_чёрного_ящика
Код дебажат только те, кто его не понимают и собираются понять. Зачем дебажить код, если он и так понятен? Или если ты его в принципе не собираешься понимать?
Тестировщики, например, код вообще никогда не дебажат. Им это в принципе не надо.
А компании решили, нужны ли им такие пользователи :)))
Мы с ИИ ещё в январе 2025 года это обсуждали. Я даже на Хабре это опубликовал, но тогда была другая политика по "нейрослопу".
Всё как и у всех - окончательную проверку проводит конечный пользователь :)
Для "танкистов" - вы платите, чтобы не банили. Какой вопрос, такой и ответ.
Времена изменились, а кто не успел, тот опоздал ;)
Вот вам и пытаются показать смысл через баны. Чтобы вы не только сливали регулярно свои данные, но ещё и денег заносили.
Я и сливаю, и заношу - и меня это слабо парит.
И где там RAG'и?
Ну, я, например, приверженец SDD. У меня он очень хорошо себя показывает. Код пишется по спекам, тесты пишутся по спекам. Тесты проверяют код. Спеки - единый источник истины для проекта.
Думаю, что для каждого типа проекта (утилита, скрипт, пет-проект, open-source, коммерческий, чиновничий, инфраструктурный, военный, ...) подходят разные "велосипеды" (метод использования ИИ в разработке). Нет и не будет одного единственного подхода, применимого ко всем типам проектов. В том же вайбкодинге можно спокойно генерировать одноразовые программы без каких-либо тестов, т.к. критерием приёмки является выполнение требуемых действий. Эволюция ПО и вайбкодинг не совместимы. Но SDD - это явный перебор, если нужно собрать shell-скрипт для наведения порядка на сервере.
А с этим полностью согласен. Не очень то и просто в массе разобраться, какой инструмент когда использовать. Время нужно.
Не соглашусь. Очень хороший обзор. То, что вы назвали "баззвордами" - это просто терминология. Актуальная терминология в описании актуальных проблем некоторой области человеческой деятельности. Просто это не та область, к которой вы привыкли и которую понимаете. Попробуйте, для начала, порезать документацию по $mol'у на чанки и засунуть в RAG.
Да, именно об этом я и говорю. Не надо вообще запускать агента там, где он может сделать что-то вредное. Надо сразу подходить с точки зрения, что агент - это "обезьяна с гранатой". Не пускайте её в "жилые помещения" (свой ноутбук), пусть в "специальном бункере" (VPS) играется.
А если агент уже в "бункере", то в чём смысл ограничивать его права? Как раз лучше сосредотачиваться на мониторинге и контроле. И сохранности данных.
Я бы посмотрел на это с точки зрения "а может просто дать рута агенту?" Поднимаешь виртуальный сервер и отдаёшь его агенту - пусть там сам хозяйничает, раз такой умный. Если что и грохнет, то только этот самый сервак (ну и всё, до чего дотянется через этот сервак). Тогда вопрос безопасности упирается не в ограничения, а в контроль - как убедиться, что агент выполняет то, что надо и не выполняет, чего не надо. Ну и в том, что телеметрия не фейковая.
Как бы мы агента ни ограничивали, эти вопросы всё равно будут актуальными. Может сосредоточиться на них?
Мне кажется, что в решении сложных задач ключом является как раз таки разбиение сложной задачи на последовательность простых задач, каждая из которых решается с малым количеством ресурсов.
Ну, или возможно, я просто ещё не дошёл до по настоящему сложных задач.
Я исхожу из того, что промпт (входные данные) влияет на результат инференса сильнее, чем дообучение (коррекция весов, по сути). Поэтому я придерживаюсь другой позиции - дообучение "экономит" токены, позволяя задавать более простые промпты и подмешивая меньше текста из скиллов. Согласен, что дообученная модель сможет работать с бОльшими фрагментами текста, чем "скилизованная". Но декомпозиция кодовой базы на небольшие фрагменты вполне позволяет комфортно работать с типовой моделью и набором скиллов к ней.
У меня в ML опыта нет вообще, я наблюдаю. Поэтому тут наши выводы вполне могут разниться.
Я думаю, тут сильно влияет ML-деформация автора. Лично мне проще скорректировать поведение типовой модели навыками, чем дообучением.
Ну и вот это:
Но, если есть готовый корпус данных для обучения, который не "протухает" со временем, то дообученная модель будет, IMHO, эффективнее типовой. Для крупных "контор" вполне себе решение.
Я вот на это триггернулся.
Ну, а дальше уже только от вас зависит, какое вы (или ваши модели) окружение поднимут.
Можно запустить отдельный файл с исполняемым кодом, если соорудить для него окружение. Юнит-тестирование и моки - они как раз про это. Можно и БД замокать, если надо. И сеть. Как раз таки плагин тестить проще, чем целое.
Другое дело, что искусственно поднятое окружение может значимо отличаться от натурального. Но, если такое выявляется, то и эти отличия можно замокать.
А если даже и не поможет, то мы сами справимся. И не с 10% вероятностью, а со 100%!
Вопрос не в том, "когда это произойдёт", а в том "как долго ещё мы сможем избегать неизбежного". И вполне возможно, что ИИ как раз и поможет "оттянуть конец как можно дальше". Но тут, как говорится, всё от нас самих зависит.
Не жизнь такая, мы такие.
Согласен. Наличие собственной картины мира не означает возможности её осознанного использования. Персональный ИИ-агент такого рода - идеальный манипулятор своим "боссом".
Но с другой стороны, люди всегда пытались манипулировать другими - разговоры "по душам", письма-записки, стихи-книги, газеты-журналы, радио-телевидение, театр-кино. У кого-то это получается лучше, у кого-то хуже. Кто-замечает такого рода манипуляции, кто-то - нет. Это просто другой уровень. Ещё один. Надеюсь, не последний :)