grep - это тоже индекс. Просто не очень эффективный. То ли дело rg… :)
А если серьёзно, то "индексация кодовой базы" раньше подразумевала использование RAG. Этот подход был жизненно необходим когда у моделей был очень небольшой размер контекста, но это уже в прошлом. А сегодня RAG создаёт больше проблем, чем решает (конкретно в случае работы с кодом): индексация может отставать от изменения файлов и возвращать устаревшие данные, RAG обычно базируется на семантическом поиске но при поиске в коде grep предположительно работает намного точнее.
Поэтому сегодня фраза "проиндексировать всю кодовую базу" часто означает только то, что модель имеет возможность анализировать всю кодовую базу, не важно каким способом.
При создании HTML-файла с размышлениями модели промпт-иньекции взяться неоткуда.
Если при создании модели доступен поиск в инете или Вы сами передали ей данные полученные из недоверенного источника - то есть откуда.
Если она у вас уже прошла, то там совершенно не до формата документов: у вас уже все что надо уведут,
Если у модели есть доступ к соответствующим инструментам - да.
Но если у модели нет доступа к запуску команд, и либо нет доступа к изменению локальных файлов либо этот доступ ограничен каталогом текущего проекта (т.е. сделать инъекцию в ~/.bashrc модель не может), то ей остаётся отдавать Вам файлы с кодом (либо создавать их в каталоге проекта и надеяться что Вы сами их выполните, либо отдавать содержимое файла прямо в чате - вроде обсуждаемого html - и надеяться что Вы его откроете в приложении которое выполнит код). И вот в этих ситуациях md определённо безопаснее html.
Настройте свой редактор на автоформатирование табличек, чтобы столбцы были выровнены под одинаковую ширину, и читабельность таблиц в md улучшится кардинально (по крайней мере пока они помещаются на экран).
В контексте промпт-инъекций абсолютно не важно, что создаёт агент - важно какими источниками он при этом пользуется. Если разрешить ИИ использовать поиск в инете или что-то скачивать из инета - появляется возможность и для промпт-инъекций/sca. И даже без прямого доступа в инет, если пользователь сам где-то скачал недоверенные данные (получил по почте PDF, например, или склонировал локально сторонний репо) и потом передал их ИИ - тоже возникает возможность промпт-инъекции.
Если у агента есть доступ к выполнению команд - никаких.
Но доступ к консоли для генерации html не обязателен. И тут разница уже появляется, потому что в маркдаун проблематично засунуть выполняемый код, особенно незаметно - в отличие от html.
А вообще я отвечал на конкретный комментарий, никак не связанный с дилеммой mardkown/html.
Потому что ИИ ошибся и сделал это нечаянно. А ещё потому, что существуют атаки типа промпт-инъекция и supply chain attack, ведущие к тому, что "ваш" ИИ начинает выполнять инструкции атакующего.
Технически там можно наворотить смарт-контракт с оракулом, который позволит гарантировать возврат средств как только оракул подтвердит закрытие кредита, и не позволит использовать эти средства до какой-то даты/события тем, кто выдал кредит.
Зато их не соблюдает сам РКН. Будет забавный юридический казус, если подать в суд на Apple за то, что они выполняют незаконные требования РКН. Подать в западный суд, разумеется. И посмотреть, как в том суде РКН будет обосновывать требования удалять VPN клиенты и что конкретно они нарушили по текущему законодательству РФ.
Для админов, которым ансибл всё-равно нужно освоить - безусловно. Но мне оно не профильное, я его дольше изучать-вспоминать-актуализировать перед каждым использованием буду чем собственно использовать.
Повторюсь - я сам так делаю, но считаю что это неправильно и учить такому не стоит.
Эта позиция (в отношении других вещей) мне хорошо понятна. Более того, я примерно из этих соображений несколько раз пытался освоить Ansible, да и на все альтернативы смотрел - те, которые Вы упомянули плюс ещё Terraform. И хотя я в основном всё-таки архитект и программист, но у меня хватает и админского опыта: начинал со слаквари в 94-м, в 2001 даже сделал собственный дистрибутив линуха на базе LFS и поддерживал его года 2.5 примерно, после этого перешёл на Gentoo, которым пользуюсь до сих пор. И я прекрасно понимаю всю пользу IaC. Но если при таком бэкграунде, многолетнем желании внедрить IaC, и нескольким подходам к существующим инструментам, я этого так и не сделал - возможно дело не во мне (моей лени или безграмотности), а в том, что существующие инструменты действительно не подходят для такой задачи и целевой аудитории "не профессиональный админ"?
Кроме того, даже если так делать неправильно, может всё-таки лучше так, чем никак (настраивать ручками без IaC)? У этого подхода довольно узкая область применимости - но я вроде бы честно и чётко её в статье обозначил. И если ни я ни Вы не взяли Ansible, а делаем так - почему "плохо" про это честно написать? От того, что про этот подход все будут стыдливо молчать - что изменится к лучшему? У меня вот управление серверами с ним однозначно стало лучше - IaC вполне рабочий получился, с IaC и документацией стало на порядок лучше, чем без них. Почему про это плохо рассказывать и подталкивать внедрять IaC хотя бы такими, колхозными методами?
Эта проблема касается только bootstrap.sh, а он минимален. Да, надо поставить докер и настроить ssh - но это плюс/минус всё, и поддерживать этот набор не сложно. Да и новые сервера в концепции "пара личных" появляются не часто. Всё это по-прежнему сильно проще, чем разбираться с Ansible (который, к слову, тоже постоянно развивается, меняется, и его конфиги скорее всего тоже через пару лет нужно адаптировать к текущей версии ансибла - так что размен такой себе).
Я храню в keepass. И на серверах пишу в конфиги руками если нужно.
Ну, свои (личные, а не которые для серверов) я тоже в Keepass держу. Но писать в конфиги сервера ручками - это ломает перевыкат сервера "одной кнопкой", разве нет? Как Вы этот подход с тем же Ansible совмещаете?
Если ключ шифрования скомпрометирован, то даже если вы его смените и перешифруете секреты - предыдущие коммиты доступны со старым ключом.
Если ключ скомпрометирован, то нужно сменить все защищённым им секреты. В любом случае, вне зависимости от того, где они хранились, и доступны ли старые коммиты - разве нет?
Разделения доступа нет - это только для одного человека с одним ключом.
Ну, технически fnox всё это умеет, и пригоден даже в enterprise. Но практически, для заявленной задачи "до 5 личных серверов" разделение доступа явно лишняя фича.
Я и не сомневался, что так делают многие, идея вполне очевидная и напрашивающаяся. Проблема, на мой взгляд, как раз в том, что все делают это молча, хотя возникающие в процессе сложности и подходы к их решению могут быть очевидны далеко не всем. Так что статья не "о достижении", а просто чтобы задокументировать этот подход и связанные с ним проблемы/решения.
Chef/Puppet/Salt/Ansible/etc. В зависимости от масштабов. А писать свои скрипты - это несерьёзно.
Ну я вот пытался внедрить Ansible на протяжении многих лет. Не идёт. Слишком сложно для таких масштабов, как у меня. Поэтому заставить себя не просто почитать его доку и немного поиграться, а начать использовать полноценно у меня просто не получалось. А Ansible - это лучшее из всего упомянутого.
Поэтому не вижу ничего плохого в одном тривиальном скрипте, который вполне соответствует масштабу задачи, и позволил мне таки перейти на IaC. Да, пытаться колхозить скрипт для решения этой задачи на тех масштабах, где уже нужно использовать Ansible - дурная идея. Но туда тащить этот подход я и не предлагал.
Хранить секреты в git - я этого вообще не понимаю, ну да бог вам судья, у каждого свой подход.
fnox позволяет держать секреты где угодно. Но, мне просто интересно, а где Вы предлагаете хранить секреты для пары личных серверов? И чем, на Ваш взгляд, мой вариант принципиально отличается от Ansible Vault?
Можно, но не очень эффективно - в отношении времени и денег. Чем раньше модель поймать за руку и остановить, тем быстрее и дешевле получим нужный результат. А когда модель сворачивает "не туда" и начинает закапываться из-за какой-то глупости, то это очень часто проявляется в виде попыток запуска странных шелл-команд или чтения файлов за пределами каталога проекта - т.е. как раз в тех ситуациях, когда срабатывает (хорошо настроенный) запрос разрешения.
В целом да, но есть нюанс: хотя запрос разрешения действительно имеет очень слабое отношение к безопасности (тут - только песочница), он полезен для того, чтобы оперативно отслеживать когда ИИ пошёл не в ту сторону, чтобы его тормознуть и уточнить задачу.
Но на самом деле юзер просто нажал кнопку "скачать" в гуглплей для очередной игрушки. А в игрушке подключён рекламный SDK, который собирает геолокацию для лучшего таргетинга рекламы… ну и дальше собранную геолокацию продают/крадут/теряют/находят/… а потом её легально покупают все желающие конторы из трёх букв в самых разных странах.
полностью становясь менеджером агентов или как сейчас модно говорить - вайб-кодером. Изначальный комментарий, на который я отвечала, показывал эту динамику в положительном ключе
Значит, или я плохо мысль изложил, или Вы что-то своё в ней увидели. Я никогда не говорил и не подразумевал ничего положительного в вайб-кодинге. Не для программистов, по крайней мере - я допускаю, что для бизнесмена ставить задачу что программисту (и получать в результате код, который бизнесмен не понимает) что ИИ (и получать ровно то же самое) - одна фигня и в таком качестве вайб-кодинг может иметь своё применение. Но программист обязан понимать код, который он коммитит в репо, и отвечать за него.
с каким-то что ли сарказмом говорите, вы же "ведущая"
Сарказм там был исключительно в отношении комбо "ведущей" с "работаю сама", а не в отношении грейда как такового. Прошу прощения, если прозвучало иначе.
Вызван этот сарказм исключительно тем, что у меня это тоже больное место - самому работать намного проще, но это не всегда возможно, поэтому приходится уметь работать не только самому… и при работе с ИИ эти навыки неожиданно сильно пригодились.
я подхожу к этому индивидуально, я знаю у кого особо можно не смотреть, а у кого стоит поподробнее
Возможно Вы удивитесь, но с разными моделями ИИ - ровно та же фигня!
коллегу не нужно вводить в контекст, он работает там же где ты
При качественном AGENTS.md и хорошими моделями (уровня не ниже Claude Sonnet, а лучше Opus) это работает практически точно так же.
Общение с нейронкой имеет вайб общения с человеком, который только вышел на испытательный срок и никогда с него не выйдет.
Так было. Но было это, по меркам скорости развитии ИИ-агентов, - очень давно! Сейчас это решил AGENTS.md для проекта в целом плюс дополнительные аналогичные файлы правил для отдельных-специфичных областей проекта, если проект достаточно сложный или просто большой. AGENTS.md добавляется автоматически всегда, дополнительные правила изредка нужно одно-два (про нужную часть проекта и про нужный тип задач) добавить в чат ручками, в зависимости от текущей задачи.
Человек умеет делать разный выбор исходя из ситуации и принимает во внимание срочность задачи, объем последующего рефакторинга (если добавляешь костыль), соизмеримость усилий (когда файл не придерживается последних стандартов, а тебе нужно добавить одну строчку).
А вот это как раз то место, где становится критичен Ваш личный опыт и донесение его до ИИ в промпте. Если этого не делать, то ИИ примет решения уровня среднего миддла, и количество несогласованного кода в проекте только вырастет. Но при работе с командой из тех же миддлов результат будет ровно такой же, и придётся всё-равно либо доносить свой опыт в процессе ревью PR либо мержить как есть.
Да, сильный сениор в такого рода руководстве не нуждается. И да, ИИ сейчас этому уровне не соответствует, и пока нет оснований считать что он дорастёт до этого уровня в обозримом будущем без очередного прорыва в технологиях. Но сениор и стоит сильно подороже, чем ИИ, нанять его сложнее, плюс не все задачи требуют такого уровня опыта, так что польза от ИИ всё-равно есть.
Но она не принесёт ничего нового, у нее нет опыта, как у твоих коллег, она не знает проект как свои 5 пальцев и какие там приколы были при его создании.
А вот из этого правда только последняя часть про "какие там приколы были при его создании". Остальное неверно. ИИ знает намного больше любого из нас, поэтому узнать от ИИ новое проще простого. Опыт у него сравним со средним миддлом. Он знает проект зачастую даже лучше тебя - просто потому, что ты уже успел забыть какие-то детали, которые ИИ только что выяснил тупо перечитав кучу файлов проекта.
Это правда. Но когда Вы работаете в команде (Вы же лид, ведущий - кого Вы "ведёте" если работаете в одиночку?) то всё, что Вы описали как "проблему работы с ИИ", ровно так же проявляется при работе с коллегами! И да, это совсем другой флоу. Но в одиночку много не наработаешь, к сожалению.
Мне лично писать код нравится, нравится состояние потока
Ну, у меня та же фигня. Но нейронка не может этому мешать. Есть поток и хочется писать код - пишите. Но когда поток сбивается из-за того, что происходит "неведомая фигня" или пора писать нудные тесты или нужно провести исследование - в этот момент вполне норм подключить ИИ.
Кроме того, состояние потока вполне норм использовать не для написания относительно низкоуровневого кода на конкретном языке программирования, а для проектирования решения текущей задачи на более высокоуровневом языке - русском. А потом спроектированную в потоке задачу выдать ИИ для механического набора кода, тестов, и отладки мелких проблем, которые Вы не предусмотрели. В целом это тоже очень близко к работе с коллегами, только если коллеге выдать настолько детально спроектированную задачу, то коллега может и обидеться, потому что Вы "съели всё самое вкусненькое, всю творческую часть задачи", а для ИИ это не проблема.
В целом, по моим наблюдениям, ИИ скорее способствует сохранению состояния потока более длительное время - потому что даёт возможность скидывать на него то, что раньше бы из потока выбивало. Да, с ИИ в потоке пишется меньше именно кода, но зато делается больше проектирования - что, на мой взгляд, намного лучше. Код я писать люблю, но разбираться с сутью вещей на более высоком уровне мне ещё интереснее.
я пока не готова отказаться от своего опыта 🤷♀️
И не нужно отказываться. Качество того, что ИИ выдаёт самостоятельно - очень и очень средненькое. И вряд ли станет лучше без какого-то принципиального изменения в подходах к обучению ИИ - потому что обученный на всём доступном коде ИИ не различает где код хороший а где плохой, считая средний по выборке нормой - а этот средний уровень очень далёк от нормы. Поэтому Ваш опыт - это именно то, что позволяет получать от ИИ результаты Вашего уровня, а не среднего. Описывая свои требования, приоритеты, отношения и подходы в AGENTS.md и промптах конкретной задачи, плюс показывая ИИ текущий код написанный в соответствии с Вашим опытом, Вы и формируете тот контекст, который необходим ИИ чтобы писать код "как Вы", а не как в среднем пишут на этой планете.
Вы как-то не так используете AI. Может модель слабая (попробуйте Claude Sonnet/Opus). Может Вы режим агента не включили на полную (чтобы AI за один запрос написал и код, и тесты, запустил линтеры+тесты и исправил все ошибки, и только потом выдал результат на ревью). Может Вы плохо ставите задачу модели, например не описав достаточно хорошо суть проекта и используемые подходы в CLAUDE.md/AGENTS.md (там должно быть примерно всё то, что выдаётся новичку при онбординге в проект). У Вас в профиле написано "ведущий", значит Вы умеете ставить задачи коллегам - вот ровно так же ставьте задачу и модели.
У меня вот эффект наблюдается прямо противоположный: задачи с ИИ стали крупнее, сложнее и интереснее. С ИИ я берусь за то, что раньше месяцами откладывал, потому что было сложно (или наоборот, нудно) подступиться к этим задачам.
И да, ровно как при переходе на высокоуровневые языки, количество строк уменьшилось на порядок - тех строк, что я набираю модели, чтобы получить тот же результат, как если бы я сам набрал код.
grep- это тоже индекс. Просто не очень эффективный. То ли делоrg… :)А если серьёзно, то "индексация кодовой базы" раньше подразумевала использование RAG. Этот подход был жизненно необходим когда у моделей был очень небольшой размер контекста, но это уже в прошлом. А сегодня RAG создаёт больше проблем, чем решает (конкретно в случае работы с кодом): индексация может отставать от изменения файлов и возвращать устаревшие данные, RAG обычно базируется на семантическом поиске но при поиске в коде grep предположительно работает намного точнее.
Поэтому сегодня фраза "проиндексировать всю кодовую базу" часто означает только то, что модель имеет возможность анализировать всю кодовую базу, не важно каким способом.
Если при создании модели доступен поиск в инете или Вы сами передали ей данные полученные из недоверенного источника - то есть откуда.
Если у модели есть доступ к соответствующим инструментам - да.
Но если у модели нет доступа к запуску команд, и либо нет доступа к изменению локальных файлов либо этот доступ ограничен каталогом текущего проекта (т.е. сделать инъекцию в
~/.bashrcмодель не может), то ей остаётся отдавать Вам файлы с кодом (либо создавать их в каталоге проекта и надеяться что Вы сами их выполните, либо отдавать содержимое файла прямо в чате - вроде обсуждаемого html - и надеяться что Вы его откроете в приложении которое выполнит код). И вот в этих ситуациях md определённо безопаснее html.Настройте свой редактор на автоформатирование табличек, чтобы столбцы были выровнены под одинаковую ширину, и читабельность таблиц в md улучшится кардинально (по крайней мере пока они помещаются на экран).
В контексте промпт-инъекций абсолютно не важно, что создаёт агент - важно какими источниками он при этом пользуется. Если разрешить ИИ использовать поиск в инете или что-то скачивать из инета - появляется возможность и для промпт-инъекций/sca. И даже без прямого доступа в инет, если пользователь сам где-то скачал недоверенные данные (получил по почте PDF, например, или склонировал локально сторонний репо) и потом передал их ИИ - тоже возникает возможность промпт-инъекции.
Если у агента есть доступ к выполнению команд - никаких.
Но доступ к консоли для генерации html не обязателен. И тут разница уже появляется, потому что в маркдаун проблематично засунуть выполняемый код, особенно незаметно - в отличие от html.
А вообще я отвечал на конкретный комментарий, никак не связанный с дилеммой mardkown/html.
Потому что ИИ ошибся и сделал это нечаянно. А ещё потому, что существуют атаки типа промпт-инъекция и supply chain attack, ведущие к тому, что "ваш" ИИ начинает выполнять инструкции атакующего.
Не ошибается только тот, кто ничего не делает. Ревьювьте код, тестируйте, не путайте ИИ с детерминированным алгоритмом - и всё будет хорошо.
Технически там можно наворотить смарт-контракт с оракулом, который позволит гарантировать возврат средств как только оракул подтвердит закрытие кредита, и не позволит использовать эти средства до какой-то даты/события тем, кто выдал кредит.
Зато их не соблюдает сам РКН. Будет забавный юридический казус, если подать в суд на Apple за то, что они выполняют незаконные требования РКН. Подать в западный суд, разумеется. И посмотреть, как в том суде РКН будет обосновывать требования удалять VPN клиенты и что конкретно они нарушили по текущему законодательству РФ.
Для админов, которым ансибл всё-равно нужно освоить - безусловно. Но мне оно не профильное, я его дольше изучать-вспоминать-актуализировать перед каждым использованием буду чем собственно использовать.
Эта позиция (в отношении других вещей) мне хорошо понятна. Более того, я примерно из этих соображений несколько раз пытался освоить Ansible, да и на все альтернативы смотрел - те, которые Вы упомянули плюс ещё Terraform. И хотя я в основном всё-таки архитект и программист, но у меня хватает и админского опыта: начинал со слаквари в 94-м, в 2001 даже сделал собственный дистрибутив линуха на базе LFS и поддерживал его года 2.5 примерно, после этого перешёл на Gentoo, которым пользуюсь до сих пор. И я прекрасно понимаю всю пользу IaC. Но если при таком бэкграунде, многолетнем желании внедрить IaC, и нескольким подходам к существующим инструментам, я этого так и не сделал - возможно дело не во мне (моей лени или безграмотности), а в том, что существующие инструменты действительно не подходят для такой задачи и целевой аудитории "не профессиональный админ"?
Кроме того, даже если так делать неправильно, может всё-таки лучше так, чем никак (настраивать ручками без IaC)? У этого подхода довольно узкая область применимости - но я вроде бы честно и чётко её в статье обозначил. И если ни я ни Вы не взяли Ansible, а делаем так - почему "плохо" про это честно написать? От того, что про этот подход все будут стыдливо молчать - что изменится к лучшему? У меня вот управление серверами с ним однозначно стало лучше - IaC вполне рабочий получился, с IaC и документацией стало на порядок лучше, чем без них. Почему про это плохо рассказывать и подталкивать внедрять IaC хотя бы такими, колхозными методами?
Эта проблема касается только
bootstrap.sh, а он минимален. Да, надо поставить докер и настроить ssh - но это плюс/минус всё, и поддерживать этот набор не сложно. Да и новые сервера в концепции "пара личных" появляются не часто. Всё это по-прежнему сильно проще, чем разбираться с Ansible (который, к слову, тоже постоянно развивается, меняется, и его конфиги скорее всего тоже через пару лет нужно адаптировать к текущей версии ансибла - так что размен такой себе).Ну, свои (личные, а не которые для серверов) я тоже в Keepass держу. Но писать в конфиги сервера ручками - это ломает перевыкат сервера "одной кнопкой", разве нет? Как Вы этот подход с тем же Ansible совмещаете?
Если ключ скомпрометирован, то нужно сменить все защищённым им секреты. В любом случае, вне зависимости от того, где они хранились, и доступны ли старые коммиты - разве нет?
Ну, технически fnox всё это умеет, и пригоден даже в enterprise. Но практически, для заявленной задачи "до 5 личных серверов" разделение доступа явно лишняя фича.
Я и не сомневался, что так делают многие, идея вполне очевидная и напрашивающаяся. Проблема, на мой взгляд, как раз в том, что все делают это молча, хотя возникающие в процессе сложности и подходы к их решению могут быть очевидны далеко не всем. Так что статья не "о достижении", а просто чтобы задокументировать этот подход и связанные с ним проблемы/решения.
Ну я вот пытался внедрить Ansible на протяжении многих лет. Не идёт. Слишком сложно для таких масштабов, как у меня. Поэтому заставить себя не просто почитать его доку и немного поиграться, а начать использовать полноценно у меня просто не получалось. А Ansible - это лучшее из всего упомянутого.
Поэтому не вижу ничего плохого в одном тривиальном скрипте, который вполне соответствует масштабу задачи, и позволил мне таки перейти на IaC. Да, пытаться колхозить скрипт для решения этой задачи на тех масштабах, где уже нужно использовать Ansible - дурная идея. Но туда тащить этот подход я и не предлагал.
fnox позволяет держать секреты где угодно. Но, мне просто интересно, а где Вы предлагаете хранить секреты для пары личных серверов? И чем, на Ваш взгляд, мой вариант принципиально отличается от Ansible Vault?
Можно, но не очень эффективно - в отношении времени и денег. Чем раньше модель поймать за руку и остановить, тем быстрее и дешевле получим нужный результат. А когда модель сворачивает "не туда" и начинает закапываться из-за какой-то глупости, то это очень часто проявляется в виде попыток запуска странных шелл-команд или чтения файлов за пределами каталога проекта - т.е. как раз в тех ситуациях, когда срабатывает (хорошо настроенный) запрос разрешения.
В целом да, но есть нюанс: хотя запрос разрешения действительно имеет очень слабое отношение к безопасности (тут - только песочница), он полезен для того, чтобы оперативно отслеживать когда ИИ пошёл не в ту сторону, чтобы его тормознуть и уточнить задачу.
Давно сняли: https://youtu.be/ioAyDiFTznc?t=2621
Но на самом деле юзер просто нажал кнопку "скачать" в гуглплей для очередной игрушки. А в игрушке подключён рекламный SDK, который собирает геолокацию для лучшего таргетинга рекламы… ну и дальше собранную геолокацию продают/крадут/теряют/находят/… а потом её легально покупают все желающие конторы из трёх букв в самых разных странах.
Значит, или я плохо мысль изложил, или Вы что-то своё в ней увидели. Я никогда не говорил и не подразумевал ничего положительного в вайб-кодинге. Не для программистов, по крайней мере - я допускаю, что для бизнесмена ставить задачу что программисту (и получать в результате код, который бизнесмен не понимает) что ИИ (и получать ровно то же самое) - одна фигня и в таком качестве вайб-кодинг может иметь своё применение. Но программист обязан понимать код, который он коммитит в репо, и отвечать за него.
Сарказм там был исключительно в отношении комбо "ведущей" с "работаю сама", а не в отношении грейда как такового. Прошу прощения, если прозвучало иначе.
Вызван этот сарказм исключительно тем, что у меня это тоже больное место - самому работать намного проще, но это не всегда возможно, поэтому приходится уметь работать не только самому… и при работе с ИИ эти навыки неожиданно сильно пригодились.
Возможно Вы удивитесь, но с разными моделями ИИ - ровно та же фигня!
При качественном
AGENTS.mdи хорошими моделями (уровня не ниже Claude Sonnet, а лучше Opus) это работает практически точно так же.Так было. Но было это, по меркам скорости развитии ИИ-агентов, - очень давно! Сейчас это решил
AGENTS.mdдля проекта в целом плюс дополнительные аналогичные файлы правил для отдельных-специфичных областей проекта, если проект достаточно сложный или просто большой.AGENTS.mdдобавляется автоматически всегда, дополнительные правила изредка нужно одно-два (про нужную часть проекта и про нужный тип задач) добавить в чат ручками, в зависимости от текущей задачи.А вот это как раз то место, где становится критичен Ваш личный опыт и донесение его до ИИ в промпте. Если этого не делать, то ИИ примет решения уровня среднего миддла, и количество несогласованного кода в проекте только вырастет. Но при работе с командой из тех же миддлов результат будет ровно такой же, и придётся всё-равно либо доносить свой опыт в процессе ревью PR либо мержить как есть.
Да, сильный сениор в такого рода руководстве не нуждается. И да, ИИ сейчас этому уровне не соответствует, и пока нет оснований считать что он дорастёт до этого уровня в обозримом будущем без очередного прорыва в технологиях. Но сениор и стоит сильно подороже, чем ИИ, нанять его сложнее, плюс не все задачи требуют такого уровня опыта, так что польза от ИИ всё-равно есть.
А вот из этого правда только последняя часть про "какие там приколы были при его создании". Остальное неверно. ИИ знает намного больше любого из нас, поэтому узнать от ИИ новое проще простого. Опыт у него сравним со средним миддлом. Он знает проект зачастую даже лучше тебя - просто потому, что ты уже успел забыть какие-то детали, которые ИИ только что выяснил тупо перечитав кучу файлов проекта.
Это правда. Но когда Вы работаете в команде (Вы же лид, ведущий - кого Вы "ведёте" если работаете в одиночку?) то всё, что Вы описали как "проблему работы с ИИ", ровно так же проявляется при работе с коллегами! И да, это совсем другой флоу. Но в одиночку много не наработаешь, к сожалению.
Ну, у меня та же фигня. Но нейронка не может этому мешать. Есть поток и хочется писать код - пишите. Но когда поток сбивается из-за того, что происходит "неведомая фигня" или пора писать нудные тесты или нужно провести исследование - в этот момент вполне норм подключить ИИ.
Кроме того, состояние потока вполне норм использовать не для написания относительно низкоуровневого кода на конкретном языке программирования, а для проектирования решения текущей задачи на более высокоуровневом языке - русском. А потом спроектированную в потоке задачу выдать ИИ для механического набора кода, тестов, и отладки мелких проблем, которые Вы не предусмотрели. В целом это тоже очень близко к работе с коллегами, только если коллеге выдать настолько детально спроектированную задачу, то коллега может и обидеться, потому что Вы "съели всё самое вкусненькое, всю творческую часть задачи", а для ИИ это не проблема.
В целом, по моим наблюдениям, ИИ скорее способствует сохранению состояния потока более длительное время - потому что даёт возможность скидывать на него то, что раньше бы из потока выбивало. Да, с ИИ в потоке пишется меньше именно кода, но зато делается больше проектирования - что, на мой взгляд, намного лучше. Код я писать люблю, но разбираться с сутью вещей на более высоком уровне мне ещё интереснее.
И не нужно отказываться. Качество того, что ИИ выдаёт самостоятельно - очень и очень средненькое. И вряд ли станет лучше без какого-то принципиального изменения в подходах к обучению ИИ - потому что обученный на всём доступном коде ИИ не различает где код хороший а где плохой, считая средний по выборке нормой - а этот средний уровень очень далёк от нормы. Поэтому Ваш опыт - это именно то, что позволяет получать от ИИ результаты Вашего уровня, а не среднего. Описывая свои требования, приоритеты, отношения и подходы в AGENTS.md и промптах конкретной задачи, плюс показывая ИИ текущий код написанный в соответствии с Вашим опытом, Вы и формируете тот контекст, который необходим ИИ чтобы писать код "как Вы", а не как в среднем пишут на этой планете.
Вы как-то не так используете AI.
Может модель слабая (попробуйте Claude Sonnet/Opus).
Может Вы режим агента не включили на полную (чтобы AI за один запрос написал и код, и тесты, запустил линтеры+тесты и исправил все ошибки, и только потом выдал результат на ревью).
Может Вы плохо ставите задачу модели, например не описав достаточно хорошо суть проекта и используемые подходы в
CLAUDE.md/AGENTS.md(там должно быть примерно всё то, что выдаётся новичку при онбординге в проект). У Вас в профиле написано "ведущий", значит Вы умеете ставить задачи коллегам - вот ровно так же ставьте задачу и модели.У меня вот эффект наблюдается прямо противоположный: задачи с ИИ стали крупнее, сложнее и интереснее. С ИИ я берусь за то, что раньше месяцами откладывал, потому что было сложно (или наоборот, нудно) подступиться к этим задачам.
И да, ровно как при переходе на высокоуровневые языки, количество строк уменьшилось на порядок - тех строк, что я набираю модели, чтобы получить тот же результат, как если бы я сам набрал код.