Этихлид
6.56K subscribers
173 photos
25 videos
152 links
Канал техлида с мыслями об AI, IT и спорте.

https://t.me/etechlead/6 - содержание

https://t.me/etechlead/8 - о канале

https://t.me/+NgQZbosvypEyYWQ6 - чат канала, там отвечаю(т) быстрее :)

(без рекламы)
Download Telegram
Сработаемся?

Навеяно обсуждением бенчмарков на недавнем стриме и тестированием Fable.

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

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

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

● Ну т.е. бенчмарки - резюме модели, сигнал к тому, чтобы в принципе обратить на неё внимание.
Эвалы - тестовое задание, вы даёте модели какие-то типовые для вашей работы задачи.
Вайб-чеки - испытательный срок, с моделью нужно провести некоторое время, чтобы понять, сможете ли вы с ней эффективно работать.

И именно совместная работа на реальных задачах становится самым информативным этапом выбора.



Кстати, взял бы я на работу Fable?
Вайб-чек ещё в процессе, но в рамках подписки - да, это no brainer, как говорят в наших деревнях.

А какой модели/агента вам достаточно?
И достаточно ли :)

#короткопост
🔥14👍85👏3❤‍🔥1
AgenticOps, часть №4 - агенты и сценарии

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

Роль агента приходит как внешний по отношению к CLI параметр (через конфиг или переменную окружения) и, по сути, ограничивает список доступных агенту команд в определённом контексте.
Т.е. агент ещё на этапе discovery видит только те команды, которые ему можно вызывать, а потом ещё и платформа эти доступы проверяет.

Агент-разработчик приложения
Это вот Codex / Claude Code, с которым непосредственно я сам работаю в контексте конкретного приложения.
Ему, помимо прочего, скиллом вменяется политика того, как правильно работать с платформой: как, к примеру, логировать и добавлять трейсинг в код приложения.

Возможности, которые даёт платформа:
● получить актуальную топологию и версии задеплоенных компонентов приложения
● узнать как идёт билд/деплой, триггернуть по необходимости
● получить отфильтрованные логи/трейсы со всех deployment units системы
● получить быстрый срез здоровья всей системы через запрос диагностического бандла
● залезть read-only в базу/redis/rabbitmq/etc
● создать/прочитать таски в таск-трекере

Примеры того, как агент этим пользуется:
● трейсы помогают понять, где сломался многошаговый процесс, затрагивающий несколько разных сервисов, получить связанные логи, опросить БД, очереди и т.п.
● агент сам придумывает и дебажит смоук- и e2e-тесты, держа под контролем не только "видимый" результат, но и то, что происходит внутри системы
● знание топологии помогает агенту лучше понимать системную архитектуру, писать совместимый код и предлагать изменения инфры

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

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

Агент-разработчик платформы
● управляет кодом платформы и может любой из сервисов добавить/поменять
● что при этом важно - он знает, какие из приложений и какие их ресурсы попадут в blast radius, потому что ему доступно состояние их инфраструктуры
● за счёт того, что все конфиги платформы, все адреса - в коде, и есть доступ ко всем компонентам и их телеметрии - может сам дебажить проблемы по всей инфре
● может интегрировать и увязать с существующими какой-то новый инфраструктурный компонент

Агент-деплоер
● использую как субагент стандартного workflow разработки, последним шагом
● если что-то фатально отвалилось - собирает диагностику и передает управление основному агенту с вменяемым описанием проблемы

Агент-монитор
Шедулится на 24/7 машине и следит за логами, алертами по расходу ресурсов и т.п. - мелочи фиксит сам и делает PR в Gitea, для более сложных - собирает более полную диагностику и заводит баги в таск-трекере со ссылками на спаны/логи/etc

Break-glass путь
Если случается какой-то дизастер/непреодолимое препятствие, можно переключиться на прямой доступ к серверам.
Для этого есть отдельный набор инструкций - где что брать и как подключаться, который хранится отдельно и выдается агенту по необходимости.



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

В том числе за счёт того, что агенты сами эти дорожки протаптывают, но об этом в следующий раз :)

#ai #agentic_ops #devops
🔥26👍17❤‍🔥6🎉32
AI-вангование, итоги

8 месяцев назад довелось мне поучаствовать в круглом столе на FrontEnd Conf 2025, где мы обсуждали тему внедрения AI в SDLC.

А недавно Глеб сообщил о том, что записи наконец выложили в открытый доступ, так что теперь есть чем поделиться :)
Пересказывать видео не буду, советую всё-таки посмотреть - дискуссия во многом всё ещё актуальная:

Круглый стол про AI в SDLC

Лучше сделаю вот что.

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

Список был такой:

🟢 1. Переход на работу с ИИ для разраба - смена психотипа с исполнителя на манагера, и сильно другой процесс мышления и навыков, не все переживут.

Подтвердился в полной мере. "Оркестратор агентов" стал общепринятым взглядом на то, как меняется профессия разработчика.

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

🟢 2. Цикл "постановка / ожидание / проверка" невыносим для некоторых психотипов.

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

Да, с наскоку новый ритм оказался для многих выматывающим - сам через это проходил ещё на заре агентной эры, в ноябре 2024го.

🟡 3. Не все могут чётко выражать свои мысли - это независимо от профессии и места в иерархии.

Косвенно. Ну да, случились открытия, что качественно сформулировать намерение, чтобы бежать в правильную сторону - это, внезапно, важно.

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

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

🟢 4. В оргах (и многих людях) дофига tacit knowledge, которое крайне сложно из них вытаскивается, но им самим кажется очевидным.

Этот, кажется, ещё и обострился. Мы за пару лет прошли от prompt engineering к context engineering, к скиллам и теперь вот даже целым бандлам скиллов для разных профессий, но проблема извлечения скрытого знания остаётся одним из главных узких мест в больших/старых организациях.

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

🟢 5. Успех внедрения ИИ зависит от доменной области, и если твой конкретный ИИ с ней плохо метчится - целый новый набор костылей нужен, боль и страдание.

Можно было бы ожидать появления ультра-эрудированных моделей, но увы. Если для вашей предметной у нейронки для обучения не хватило датасетов - интеллект её не спасёт: на каждый чих придётся собирать кучу контекста, т.к. знаний или хотя бы интуиции самой нейронки не хватит (даже если это Fable).

🟡 6. Сеньоры+, которые открыты к использованию ИИ - новая нефть )

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

А жёлтый тут потому, что "надбавки" недостаточно - люди будут уходить к более гибким конкурентам, делать свои продукты и строить AI-native teams и compounding startups.

🟢 7. Внедрение сверху ваще не работает в варианте "давайте просто купим подписки и курсы".

Ну это вообще стало базой, я и сам на нескольких докладах про это рассказывал, и мне даже реклама хайлоада постоянно попадается со слоганом "Cursor выдали — AI не внедрили" :)

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

🟢 8. Усилилось неравенство в командах, т.к. ИИ выступает мультипликатором (у кого-то - 1.1, а у кого-то - 0.9).

Тут я вилку, кажется, даже занизил - в действительности разброс оказался гораздо сильнее.
И да, реально есть те, у кого внедрение ИИ идёт в минус, как на уровне команд, так и отдельных людей :)

🟢 9. Роль конкретной личности резко возросла.

Прямое следствие №8 - разница между людьми, которые ИИ только трогают и теми, кто активно внедряет его в рабочие процессы, стала разительной, и продолжает усиливаться (вы посмотрите на Валеру Ковальского, к примеру :))

Всё как и писал один из фаундеров Anthropic:
к лету [2026-го] я ожидаю, что многие люди, работающие с передовыми ИИ-системами, будут чувствовать, будто живут в параллельном мире по сравнению с теми, кто с ними не работает. И, думаю, это будет больше, чем просто ощущение.


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

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

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

Ответ "простой" - работа над качеством и микроитерации на отдельно ускорившемся этапе.

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

Ох, тут половина индустрии в состояниях от легкой грусти до ПТСР, потому что поменялся характер самой работы. И отнятый кайф - это один из главных вкладов в то самое выгорание из пункта №2.

Что делать - искать инженерную красоту в других вещах (про это, кстати, есть в докладе).

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

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

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



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

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

Появилась и куча новых наблюдений и интересных исследований, на несколько серий постов хватит :)

#ai #sdlc #конфа
6🔥3518👍15👏4🎉2
В программировании всегда были такие задачи, за которые часто брались новички.
Некоторые из них оказывались крайне ценными для становления специалиста, а где-то это был весёлый бег по граблям и изобретение велосипедов.

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

Давайте попробуем собрать статистику.

P.S.
Ну и напишите, может есть ещё что-то такое, что должен сделать начинающий вайбкодер / ии-инженер / ai-native developer / etc :)

P.P.S.
В комменты скину свои ответы

P.P.P.S.
Если интересно - распишу, что тут может быть ценным для начинашек, и почему ✍️
👍1163🔥2👌2
Please open Telegram to view this post
VIEW IN TELEGRAM
💯16🔥9👍7😁5😢1
Этихлид
Что вы уже делали?
Вопросы "в глубину" к стартовым задачкам (1/2)

На самом деле, если вы занимались вышеперечисленными задачами, вы знаете, что они практически все с подвохами :)
И это делает их хорошими для того, чтобы копать вглубь на, к примеру, собеседовании на AI-assisted SWE.

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

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

⭐️ Рядом с каждой задачей - оценка "полезности" (5 звезд - максимум).


Транскрибатор звонков (+ диктовка)
⭐️⭐️⭐️⭐️

Лень - двигатель прогресса, ну и плюс ко всему, как бы сумбурно вы ни изъяснялись, голосом вы все равно больше контекста передадите, и современная нейронка вас всё-таки поймет :)
А чем больше вы дадите детализированного контекста - тем лучше у вас будет итоговое решение.

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

● разные модели дают сильно разное качество и тут бы мы поговорили по крайней мере про WER/CER как метрики
● хватит ли метрик и при чём тут предметная область?
● как боретесь с плохо распознанными словами?
● что делать, если у вас какой-то особенный сленг используется?
● случалось ли вам распознавать интенсивные беседы финна и русского (которые отлично друг друга понимают)?
● как насчёт стримингового распознавания? а стримингового перевода?
● как вы боретесь с Димой Торжком?
● ASR-модель - это LLM? Вы уверены?
● чем в этой задаче может помочь LLM?
● диаризация / VAD / speaker recognition - на сдачу :)


Суммаризатор каналов телеги
⭐️⭐️⭐️

Задача не столько про нейронки, сколько про обычную инженерию.

● основная проблема, которую нужно решить - это как вы, собственно, вытаскиваете контент каналов
● MTProto-юзербот vs Bot API
● каким образом вы выделяете темы, заслуживающие внимания?
● дедупликация и кластеризация при сборе новостей
● как не оказаться в эхо-камере, настроив "важные" темы?
● почему все пилят свои суммаризаторы?

Ну и мне наверняка было бы интересно, как вы хостите это решение, насколько оно независимо от вас может работать, и как долго :)


Счетчик токенов/лимитов подписок
⭐️⭐️⭐️

Задача интересная и довольно просто реализуемая в том числе очень простой адаптацией готового (тысячи их на гитхабе).

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

● что если нужно переключаться между разными подписками одного вендора и считать подписки по отдельности?
● а если между разными вендорами?
● а если у вендора нет API для того, чтобы узнать лимиты?
● почему у разных считалок могут быть в 10 раз отличающиеся числа?
● приходилось ли делать слежку за урезаниями лимитов со стороны вендора?
● можно ли посчитать токены перед отправкой?
● (со звездочкой) переносили ли когда-то сессию между разными вендорами / агентами?


Лендинг для AI-проекта, которого еще нет
⭐️⭐️

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

Нооо достаточно сюда добавить "лист ожидания" или "мы вам перезвоним" - и я точно уже никогда не вернусь. Фу!

Я бы обязательно спросил: почему, мистер Андерсон? Почему вы это делаете?

Ладно-ладно:
● какая была гипотеза?
● откуда трафик?
● была ли заранее продумана метрика "ну не шмогла я, не шмогла", чтобы не попасть в ловушку невозвратных потерь? Как она выглядела?

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


Уникальное приложение для задач / фитнеса / финансов
⭐️⭐️⭐️

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

Поэтому мне скорее был бы интересен путь ваших мыслей относительно того как вы подходили к самой задаче кастомизации:
● насколько сильно отличался конечный результат от первого ваншота?
● что пришлось допиливать под себя?
● сколько времени ушло на допиливание?
● сколько раз стартовали заново? :)
● какие вещи оказались неожиданно сложнее, чем казались?

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


RAG для чата с кучкой markdown
⭐️⭐️⭐️⭐️⭐️

Ну предположим, что кто-то именно на векторах решил эту задачу сделать :)

В 2023м это было по дефолту: чанки, эмбеддинги, векторная база, вот это вот всё.
Сейчас первый вопрос скорее "а нужен ли вам вообще векторный RAG"?

Для кучки markdown длинный контекст или простой агент с grep'ом по файлам часто даёт результаты лучше наивного эмбеддинг-поиска.

● почему вы вообще решили, что вам нужны эмбеддинги?
● как нарезали чанки?
● как боролись с потерей мелких фактов?
● dense / BM25 / гибрид?
● верили ли ранжированию выдачи векторного поиска?
● как душили галлюцинации, особенно на мелких моделях?

Ну и контрольный: где всё ещё оправдан векторный RAG?

#aiswe #hr #junior
👍17🔥98👏2🎉2
Вопросы "в глубину" к стартовым задачкам (2/2)

Прокся для доступа к нейронкам (типа OpenRouter)
⭐️⭐️⭐️

Хорошая задача, и опять же почти целиком инженерная.
Сам я тут обходился готовым, так что вдвойне было бы интересно послушать тех, кто полез делать своё - что именно не закрыл OpenRouter/LiteLLM.

● как справлялись с зоопарком вендорских API?
● что делали, когда вендор отвечает 429?
● по какому признаку роутили между моделями, если роутили вообще?
● а стриминг проксировали?
● приходилось ли решать проблему дрейфа API вендоров?
● как устроена система статистики?
● что изменится, если нагрузка возрастёт в 10 раз? А в 100?


MCP/CLI для какого-то сервиса
⭐️⭐️⭐️⭐️

Ухх, холиварная задача :)
Тут в первую очередь захотелось бы разобрать плюсы и минусы MCP как протокола - а заодно понять, нащупал ли человек границы применимости инструмента.

● в какой задаче возьмёте MCP, а в какой CLI?
● как тот и другой способ влияет на контекст?
● что и в каком формате класть в ответ для модели?
● нужен ли скилл под CLI? Как его сделать? А без него можно?
● REST -> MCP - как подошли к решению?
● автоконверсия MCP <-> CLI - насколько хорошая практика?
● смогли бы написать инъекцию для своего MCP/CLI?


Агент с нуля, голого JSON и while
⭐️⭐️⭐️⭐️⭐️

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

А крутится там, если убрать обёртки харнесса / агента / фреймворков, довольно простой цикл:
● собрать JSON
● послать на API-endpoint
● разобрать ответ
● выполнить вызов тула
● положить результат обратно
● повторить

Даже такая наивная реализация даст вам много инфы о том, как устроены агенты.

Ну а дальше начинается куча всего интересного:
● что остановит агента, решившего поработать вечно?
● пришёл ответ с парой тулов разом - исполняете подряд или параллельно?
● вызов тула упал - что увидит модель?
● предложите несколько вариантов того, что можно делать для экономии контекста
● как "договариваетесь" с моделью о структуре её ответа?
● пробовали сами создать и дёрнуть субагента?
● что делать, чтобы повысить cache hit rate?
● как мониторите работу агента?
● как будете подходить к задаче сэндбоксинга?


Мультиагентный флоу для кодинга
⭐️⭐️⭐️⭐️

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

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

● зачем в флоу каждый конкретный блок?
● сколько будет 0.9⁵ и при чём тут это?
● как передаётся контекст между агентами?
● как замеряете "хорошесть" результата и его повторяемость?
● как находите, где процесс свернул не туда?
● на каких шагах требуется участие человека (HITL)?
● где берёте одного агента, а где всё-таки мультиагентный сетап?
● а что можно было бы обычным детерминированным скриптом сделать?


Бенчмарк/эвал под свои задачи
⭐️⭐️⭐️⭐️⭐️

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

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

● какова цель эвала или бенча?
● как собирали задачи для golden set?
● есть ли уверенность в том, что он отражает реальное распределение задач?
● какие метрики вывели для оценок?
● метрики автоматические или "ручные"?
● если есть LLM-as-a-judge - как убеждались в том, что он работает как надо?
● как сохраняете результаты между разными запусками и как сравниваете между собой?


"Opus дома" на ~27B-Q3_K_M.gguf модели
⭐️⭐️⭐️⭐️

Если у вас были какие-то мечты о том, чтобы получить Opus дома, мне было бы любопытно узнать, как вы к этому пришли и как от этого ушли - сама вот эта траектория взлётов и падений всегда интересна :)

● что по железу: сколько GPU, сколько нод, баланс VRAM/RAM
● где для вас находятся границы применимости локальных моделей и какой спектр задач вы ими решаете?
● поговорили бы про квантизацию, её виды, связь с железом
● какие inference-движки вы используете, с какими параметрами и почему?
● веса модели заняли 20/24гб VRAM - насколько хорошо она будет работать?
● сталкивались ли с задачей многопользовательского доступа к нейронкам и какие были сложности?
● TTFT, TPOT/TPS, latency, KV-cache utilization - на что обращали внимание?

И обязательно была бы секция про то, каким видится будущее локальных моделей :)


Послесловие

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

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

А вот способность дожать задачу до "идеального" состояния, побегав по граблям и получив знания по дороге, - ну, это не ваншотится.
Этим и ценно.

#aiswe #hr #junior
👍32🔥138💯3👏2
Перевёл документ от Google, который описывает текущую ситуацию по переходу от "бессистемных промптов к агентной инженерии":

➡️ Новый SDLC с вайб-кодингом

Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle.

Бонусом там ещё и глоссарий терминов/переводов получился.

Это база
В нём качественно суммируется то, что разработка ПО с ИИ прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы.

Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке.

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

Документ лайтовый, без лишнего хайпа и думеризма.
Ну и картинки интересные :)

Содержание
- Сдвиг от синтаксиса к замыслу
- ИИ-агенты: краткое напоминание
- Что такое вайб-кодинг?
- Спектр: от вайб-кодинга к агентной инженерии
- Контекст-инжиниринг: настоящий навык
- Новый жизненный цикл разработки ПО
- Традиционный SDLC под давлением
- Как ИИ преображает каждый этап
- Требования и планирование
- Проектирование и архитектура
- Реализация
- Тестирование и контроль качества
- Ревью кода и деплой
- Поддержка и развитие
- Фабричная модель: строим систему, которая строит ПО
- Харнесс-инжиниринг: что окружает модель
- Что входит в харнесс
- Харнесс в SDLC
- Требования, планирование и архитектура
- Реализация
- Тестирование и QA
- Ревью кода, деплой и поддержка
- Меняющаяся роль разработчика: дирижёры и оркестраторы
- Дирижёр: ручное управление в реальном времени
- Оркестратор: асинхронное мультиагентное делегирование
- Проблема 80%
- Кодинговые агенты на практике
- Где кодинговые агенты вписываются в день разработчика
- Как вайб-кодинг доводит агентов до продакшена
- Экономика разработки с ИИ
- Скрытый долг вайб-кодинга
- Инвестиция агентной инженерии
- Контекст-инжиниринг как финансовый рычаг
- Масштабирование эффективности через динамический контекст и скиллы
- Умный роутинг моделей
- С чего начать
- Для отдельных разработчиков
- Для инженерных руководителей
- Для организаций
- Заключение: замысел как новый интерфейс
- Примечания
- Глоссарий


Замечания
● eсли вы уже по уши в мультиагентных воркфлоу, бандлах скиллов и прочих гермесах, то нового вы в нём вряд ли почерпнёте - коммьюнити стабильно на шаг-другой впереди :)

● это всё-таки Google с его собственным зоопарком (Jules, ADK, Agents CLI, Gemini, A2A), хотя авторы проделали хорошую работу по абстракции от него

● местами чутка оптимистичнее, чем стоило бы: мультиагентность как "естественный следующий шаг" - тут можно спорить об эффективности, да и модели пока что не готовы



Ссылки на оригиналы всех пяти документов с конкретикой для тех, кто хочет углубиться:
The New SDLC With Vibe Coding (переведён)
Agent Tools & Interoperability
Agent Skills
Vibe Coding Agent Security and Evaluation
Spec-Driven Production Grade Development in the Age of Vibe Coding

#article #translation #sdlc #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍36🔥219❤‍🔥1🕊1