Pull to refresh

Comments 51

Концентрированная база. Спасибо за статью!

Проблемы начинаются, когда использование агента становится обязательным, людей в команде становится меньше, а план остаётся прежним или, чаще всего, растёт.

А если говорить прямо, то пользу от внедрения ИИ целиком присваивает бизнес, а все издержки скидываются на разработчиков и клиентов. И просто так учитывать интересы разработчиков никто не собирается.

Профсоюз мог бы решить проблему, но теперь ИТшники атомизированы как никогда. С чем нас всех и поздравляем.

Да в любой автоматизации за последние лет двадцать происходило ровно то же самое. Сначала руководство режет косты на людях, а потом нанимает тех же людей на роль дорогих консультантов для тушения пожаров

А ещё от использования ИИ наступает деградация, потому что начинаешь забывать как писать код руками...

Ну то есть старое то помнишь, но новые технологии не изучаешь, только поверхностно, а как оно там под капотом теперь знает только ИИ

С другой стороны, при желании можно поручить ИИ найти информацию про любую новую технологию и рассказать её.

Я за последние полгода разобрался как собирать пакеты Дебиана, как работать с тегами YAML в Питоне, как настраивать BGP, как работает конфигурация cloud-init при создании виртуалки и как делать мультитенантные дашборды в Графане.

Но всё это понимается чтением документации. Как собирать пакеты дебиан это вообще одна страница, которая читается за 10 минут и закрывает все потенциальные вопросы

Вот эта страница. Вы можете прочитать её за 10 минут? Или имелась ввиду другая страница? Какая?

Чтобы читать документацию - её надо сначала найти.

Особенно удачи вам с мультитенантными дашбордами в Графане.

Одно дело прочитать, а другое - с этим работать

Шишки набиваются (и опыт и насмотренность вместе с этим) только когда делаешь это сам

А если работает нейросеть, то остается только быть теоретиком, который может рассуждать, но исправить не сможет

Я могу при необходимости исправить сам всё из перечисленного выше, кроме дашбордов в Графане - для них нужно Go знать.

нужны ли новые технологии если старые (полностью) устраивают? для себя выбрал путь ронина - свой мега-фреймворк, все проекты на нем, если чего не хватило - расширил его функционал, и привет! а внутри можно и новыми заменить, и достижения науки добавлять, код систем, API не меняется.

Если постоянно отдавать агенту даже мелкую рутину, мозг отвыкает держать в памяти контекст проекта, в итоге любая нестандартная ошибка превращается в тупик, потому что сетка ее решить не может, а ты уже забыл кишки фреймворка

коллегой, который пишет с огромной скоростью, не помнит историю проекта

Он её не помнит, потому что он не участвовал в проекте полноценно, ему не дали память, не научили понимать и помнить проект, актуализировать знания. Он одноразовый гость. Аналогия - строитель без знания языка, которого взяли на заливку бетона на 28 этаже одного из домов нового микрорайона.

Если хочется получить полноценного коллегу, придётся попыхтеть, как со стажёрами, которые постепенно становятся (ценой усилий команды) джунами, мидлами и тд

Тут другая проблема. Хороший джун по мере работы над задачами в проекте рано или поздно дорастёт до мидла сам. Кому-то придётся по-отвечать на вопросы, но ответы он запомнит тоже сам.

А с ИИ так не работает, если не прилагать усилий к его обучению.- он так и останется вечным стажёром.

Сформулирую по-другому: если дать агенту иструкции, позволяющие иметь память (меморибанк), дисциплинирующие инструкции (написал - сделай выводы, пообщались с пользователем - запиши), а в идеале ещё и способность к саморефлексии (сделал работу - проанализируй действия, позже - последствия), он будет разбираться в проекте лучше человека. Это требует время, ресурсов, но по мне - окупается с лихвой. Этих электронных чудиков нужно воспитывать

А есть возможность поделиться ссылками на эту тему? Чтобы хотя бы примеры посмотреть?

Всё на личном опыте, мануалы не помогут, это как книжки по воспитанию детей - вроде умные вещи пишут, но пока не пройдешь этот путь сам, толку мало

Тогда ждём статью на Хабре. (без шуток)

@igorp1024 - я не стал давай прямые ссылки, поскольку альтернатив слишком много. Берите любую ссылку и изучайте. За примерами стоит сходить по github-ссылкам:

dreaming (самоанализ)
rag - поиск синонимичных вхождений в контекст
graph-rag - поиск связанных вхождений в контекст
memory-search
Agetic-loop, agentic-tasks .....

Полагаю, что комментарий выше имел ввиду что-то вроде вот этого: https://www.aihero.dev/skills

Я конечно не настоящий сварщик и к "взрослой" разработке отношения не имею, но сейчас с помощью этих скиллов и Опуса начал пилить один небольшой проектик для себя, результат, если честно, впечатляет. А процесс впечатляет ещё больше. Если интересно, вот: https://github.com/AlexeyDesyatnik/GymLog

vision.md написался в диалоге с Опусом без скиллов, затем по основному флоу тех скиллов: grill-with-docs - детальное интервью с записью архитектурных и дизайнерских решений, to-spec разработал спецификацию первой версии, to-tickets разбил её на таски и закинул в issues гитхаба, теперь по вечерам сижу тыкаю implement (code-review он автоматом после запускает), на мне только ручное тестирование и коррективы по направлению развития.

Так это уже есть в агентах, они сами себе скиллы создают. Только эти скиллы лучше не читать, так как там столько мусора копится, что вообще удивляет то, что ИИ с этим работал и даже как-то следовал своим инструкциям из скилла.

На текущий момент топовые модели генерируют код на уровне сеньоров. Очень быстро по логам находят причины багов. Но вот проблема контекста она есть, человек который пять лет работает на проекте много знает о нем и предметной области, и это нигде не задокументировано. Агент видит код в одном может двух репозиториях, а надо понимать как он работает в 10. Пока это не решили.

Слышал слух, что в топовых компаниях у каждой системы есть свой агент, и агенты начинают общаться между собой. Агент говорит другим агентам я хочу поменять то-то, для решения своей задачи. Пять агентов из смежных систем отвечают: у нас для этого есть 1,2,3, не забудь наши граничные кейсы. Дальше первый агент пошел думать что с этим делать.

У меня агент работает сразу с десятками репозиториев, если нужно, и тут нет придела. Проблема контекста решается документированием, достаточно открыть историю проекта (git log, jira issues, confluence pages...) и по истории вспомнить все моменты и надиктовать их агенту, после чего попросить агента аккуратно на основе ваших рассказов составить документацию с ссылками на артефакты.

Если хочется получить полноценного коллегу, придётся попыхтеть, как со стажёрами, которые постепенно становятся (ценой усилий команды) джунами, мидлами

Вот только этот джун потом от вас уйдёт, к вашим конкурентам за большей зарплатой, а вы в него вложили своё время и деньги

А нейросетка полностью ваша за 20 баксов, работает только на вас не отнимая ваше время на обучение

полностью ваша

...пока лимиты не закончились

Как закончились, так и сбросятся. Человек тоже ограниченное число часов в день работает

Ёмко написано. Боюсь только, что новое поколение программистов над этим просто посмеётся. А мнение зубров проигнорируют.

Расскажу две истории.

  1. Лет 15 назад я примерно такими же словами пытался объяснить начальству, что нельзя сэкономить деньги просто передав код ста дешёвым но тупым китайцам. Что придется менять философию подхода к коду, к тестированию, к архитектуре и к документации. Угадайте, что было дальше? Правильно, бабло победило зло, китайцев все равно наняли и нахлебались.

  2. Лет 30 назад в нашей маленькой аутсорсинговой фирме, писавшей тогда на всяких древних языках типа ASP и PHP, появился новый сотрудник, который только что закончил курсы чего-то новомодного, название я подзабыл. И вот мы у него стали интересоваться, а как вообще работает эта технология с т.з. реальных потоков данных от сервера к клиенту и обратно. Выяснилось, что он вообще не в курсе, его знания были уровня "я вот тут создаю кнопку, а дальше кнопка сама работает". Помню, как мы офигели. Я здесь у тому, что когда-то люди, знавшие ассемблер, офигевали от фортранщиков, потом фортранщики от ООП-ешников, и т.д., и т.д., каждый следующий слой все дальше удалялся от понимания, как это реально работает. Ну вот, мы уже на пороге новой эры, когда "программист" не будет видеть и понимать даже код, отдав все ИИ. И да, наверное ИИ будет каждый раз генерить новый код, но об этом никто не узнает :)

Что в именно в ООП мешает понять "как это реально работает"?

Раньше новые технологии - это станок для производства гвоздей, который позволят их делать много ровных, красивых и одинаковых. Сейчас новые технологии - это армия роботов, кующих гвозди вручную. Вместо поиска нормальных эффективных решений в программировании проблемы хотят завалить грубой силой числодробилок.

И цены на числодробилки уехали в космос.

В 70х эвм стоили дороже, а умели меньше

Так тогда ситуация с их производством несколько отличалась. Рынок не был настолько монополизирован, технологический барьер входа на него не было настолько высок и там не было такого количества свободных денег для инвестиций, чтобы спрос на компоненты для высокопроизводительных машин приводил к росту цен на электронные часы и микрокалькуляторы. А тут мы получили рост цен практически на всё в окрестностях расположения крупных дата-центров, особенно, если они находятся в областях, где проходила деиндустриализация и новых промышленных потребителей электроэнергии не появлялось многие годы. Это очень специфическая многофакторная бомба для всех прочих отраслей экономики. Это не "черный лебедь", это "черный тиранозавр".

Выяснилось, что он вообще не в курсе, его знания были уровня "я вот тут создаю кнопку, а дальше кнопка сама работает".

Осмелюсь предположить, речь шла о чём-то типа DDI/DDX в визуальных формах какого-нибудь Visual C++.

Классная статья. Всё разложено по полочкам. Картинки угар)

Особливо вторая, с фронтом, бэком и джейсоном.
Посмотрите, откуда у программеров руки растут!

Посмотрел. Как у всех остальных. А ты что нафантазировал?

Нет пошлых языков, есть пошлые уши (с) хорошая знакомая

С заменой тестов моделью вообще отдельная засада. Она переписывает падающий ассерт под свой баг с такой уверенностью, что на беглом ревью это легко пропустить. Приходится сидеть и вычитывать каждую строчку диффа внимательнее, чем за живым человеком..

Меня больше напрягает, что не будет стимула у разработчиков писать новые фреймворки под повторяющийся код, придумывать новые языки под определенные задачи, например, эрланг, исследовать новые концепции. Зачем? Если можно все написать на английском или русском и типа будет все сделано...

Прочитайте Промпты к Агентам, которыми пользуетесь. Там часто заточка под стек в вакууме. Порой даже “Ты элитный агент для Питона…”

mitmproxy для дебага Промптов от самих Агентов ;)

Последняя фотка в статье отлично иллюстрирует проблему. Потому что на ней пытаются подкинуть ИИ-шке задачу, для решения которой она не предназначена, и потом говорят "ваша иишка - говно". Если кто не в курсе - это "компьютерное зрение" обучено распознавать весовые товары. Флакон "фейри" к весовым товарам явно не относится

Не знаю, я не разраб, но в ит уже 26 лет и получил киллер инструмент с помощью которого могу реализовать все что хочу, раньше это было не возможно, не возможно заниматься и знать всё....так что для меня ии это полезный инструмент и да я учусь у него

Хабр не разочаровывает.

Концентрированный ИИ слоп со знаниями о мире ai кодинга из 2024-2025 чисто на уровне статей в интернете.

Хабровчане, конечно же, заплюсовали статью

Ты абсолютно прав, твой зорький глаз... Если серьзно, то да есть такое, многие аргументы устарели, так как статью хотел написать еще давно, но руки не доходили :(. Возможно будет 2 часть, попробую собрать более актуальные проблемы по типу meat proxy и так далее.

Почему тогда положившиеся на ИИ не проигрывают конкурентную гонку, не отсеиваются сами собой?

Потому что не 2025

Всё дело в годе? А в 2027-м агенты уж точно будут сами всё делать, без нашего участия?

Почему вы решили, что не проигрывают?

Сидят на лавочке возле хаты два старика и вспоминают молодость:

— Эх, кум,— вздохнул Иван,— а было же, что я в молодые годы и воз со снопами поднимал.

— Врешь, кум! Не было такого,— махнул рукой кум Игнат.

— А вот поспорим, кум, что не вру.

Ударили по рукам. Тогда Иван и говорит:

— Проиграли вы, кум, пол-литра, а я ведь поднимал тот воз. Поднимал, поднимал, да так и не поднял.

Мне вот интересно, как умудряются жить компании, в которых KPI - количество потраченных токенов. Я вот пока плачу за токены сам и вижу, что если не буду принимать меры, потрачу на токены существенную часть зарплаты.

Sign up to leave a comment.

Articles