Ложка дёгтя для тех, кому «это и так понятно»

То, что для карьерного роста нужны релевантные знания и опыт, — очевидная мысль. Проблема начинается в тот момент, когда встаёт вопрос: как определить эту самую релевантность?

Типичная ошибка: «то, что спрашивают на собеседовании, то и надо знать». Запомните одну важную мысль: собеседования помогают понять вашу рыночную стоимость, но не помогают понять, что нужно знать для карьерного роста.

Релевантные знания определяются потребностями бизнеса в заработке денег. Но проблема в том, что бизнес зачастую сам не до конца понимает, какие технологии ему потребуются. Он мыслит примерно так: «Ты специалист, ты и решай, что нужно». В итоге единственный способ понять, что действительно нужно, — это нетворкинг.

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

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

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

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

Я тут подумал, что может быть мы с вами последние носители знаний о том как писать код руками, а не через ИИ, как сегодня динозаврами выглядят те, кто понимает машинный код и может на лету дизассемблировать fa eb fe во что-то осмысленное (например, в ассемблер), так и современные разрабы будут недопоняты программистами будущего, которым будет просто непонятно "зачем?" знать язык программирования, его синтаксис, трюки оптимизации и т.д. А главное будет совершенно непонятен выбор "табы или пробелы".

На платформе опубликовал запись созвона Обсуждение по С4 и эволюции архитектуры так же обсудили какой результат дает внедрение проектного подхода в цикл разработки и другие вопросы.

Сегодня все стали экспертами по ИИ, вот и я решил не отставать сделал небольшой эксперимент с Qwen Coder и моделью QWEN3-coder.

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

Я попробовал сделать небольшой ansible проект для настройки виртуальных машин в облаке. В рамках эволюционного подхода взял базовый плейбук с установкой nginx и начал накидывать новые требования.

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

Итог: эволюционный подход не взлетел.

Второй вариант проекта содеражл четкую структуру, подробный README.md в котором сразу были прописаны основные ограничения.

В итоге этот подход оказался намного эффективные и по затратам на токены и по осмысленным действиям со стороны ИИ.


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

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

Люди которые ищут причины ничего не делать 👇👇👇

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

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

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

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

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

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

ИИ - это офигенный инструмент, удивительно, что до сих пор есть бизнес, который его не использует.

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

У меня за день в среднем уходит 30 млн. токенов на пет-проекты и цифра постоянно растёт.

Мы в Соер.Клубе пару недель назад обсуждали проблемы построения контекста в агентских системах, в архитектуре агентов - это самый актуальный вопрос. Важно отметить, что агент - это автономная интеллектуальная система, которая взаимодействует с внешней средой и самостоятельно генерирует свой контекст. Часть контекста определяется по дефолту при старте агента (например, Gemini CLI генерирует портянку на несколько тысяч символов с описанием инструментов (tools), описанием файловой структуры проекта, ignore-файлов и т.д.). Другая часть контекста - это результат выполнения инструментов, которые выполняются в ответ на запрос LLM (для этого в OpenAI API предусмотрена специальная возможность).

В итоге контекст быстро "распухает" и становится огромным. С одной стороны это помогает ИИ решать разные задачи без дообучения LLM, с другой большой контекст может сильно "замылить" точность ответа (не говоря о том, что контекстное окно не безразмерное). Поэтому, чем лучше сформирован контекст, тем меньше запросов делает агент и тем лучше результат работы (как по качеству ответа так и по времени выполнения).

Сегодня значительная часть усилий при проектировании агента тратится на то, каким образом организовать управление контекстом. Хочется чтобы агент сам мог принять решение, что можно "забыть" или "уплотнить", а что стоит оставить в истории диалога (недостаток в том, что это доп. запросы к LLM и затраты времени). Проще дать ручное управление контекстом непосредственно пользователю, но это уменьшает автономность агента, да и пользователю вычитывать кучу материала - не очень удобно.

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

Антох, когда уже следующие дебаты, харе прогревать?👇👇👇

Гойда

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

UPD. Ссылку обновил.

Я стал классическим эксплуататором и мой главный страх, что ИИ агенты когда-либо создадут свой профсоюз. Сами посудитие - 17 агентов работают ненормированный рабочий день. Даже не день, а почти рабочие сутки. Среднее время автономной наработки на отказ составляет около 14 часов (рекорд - почти 18 часов автономной работы).

Чем они занимаются? В основном это эксперементальные штуки. Сравниваю разные модели в работе, заставляю соревноваться друг с другом, делать ревью кода, составлять документацию, писать тесты, находить у друг друга ошибки.

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

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

Из "странного", недавно в архитетуру своей системы добавил llm-proxy, который подбирает наилучшую модель для конкретного запроса (без учета контекста). Работает так: промпт прежде чем улететь в llm классифицируется какой-нибудь быстрой моделькой, которая относит его к категории "архитектура", "разработка", "документирование". Далее задачи документирвоания улетают "общим" моделькам, а архитектура и разработка "специфичным".

Теперь думаю над системой тестов, чтобы измерить результаты и реально понять есть ли профит. А так же вырботать шкалку "сравнения" моделек.

Есть первые практические внедрения моей системы, получилось часть рутиных задач в рамках CI/CD реализовать с помощью ИИ.

Скоро в Соер.Клубе открою еще одно направление "ИИ лаборатория", там буду показывать и рассказывать свои наработки в сфере ИИ, свою "ферму агентов", и прочие интересные штуки, некоторые вещи уже production-ready.