Закон Фолкленда

Если решение принимать необязательно - не принимайте его.*

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

Почему это я так решил?

1.
Они не стремятся принимать решения и всячески их оттягивают.
2.
А те решения, что они принимают делают это очень несвоевременно- все помнят, как вы долго-долго выбираете стек, архитектуру, пишите максимально подробное ТЗ, пока «рынок убегает вперед»

Ииии вот как надо, если следовать этому простому закону:
- Если есть вопрос, который блокирует вас - займетесь им и решите.
- Если этот вопрос вас не блокирует, то оставьте себе пространство для маневра.

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

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

*Почти 400 лет назад, в 1641 году, виконт Фолкленд сказал: «Когда перемены не необходимы, необходимо ничего не менять».

Столько лет прошло, а мы все никак не научимся следовать этому простому правилу.

Самый дешевый AI-агент может оказаться самым дорогим

Короче, мы нашли еще один прекрасный способ неправильно измерять эффективность AI: смотреть на стоимость токенов😉

Токены дешевеют?
Отлично, значит и AI становится дешевле!

Ну да. Ну да. Пошли мы нафиг со своей простой математикой.

McKinsey выпустили материал об экономике AI-агентов, и там, как обычно это бывает, супер очевидная мысль, когда ее кто-то озвучил, но нифига не очевидная до этого:

Токены - это не ценность. Токены - это счет, который вам выставляют.

Он (счет) показывает, сколько вы потратили, но вообще не отвечает на вопрос:

А зачем вы это потратили? И самое важно, сделали ли вы это эффективно

Проблема в том, что агент - это уже не один запрос к LLM, потому что агент:

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

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

Причем около 60% стоимости может уходить не на создание первого ответа, а на его проверку, исправление и повторную проверку.

Ииии вот тут начинается самое интересное.

Один и тот же агент на одной и той же задаче может пройти совершенно разный путь.
Сегодня сделал пять вызовов инструментов.
Завтра — двадцать.

Поэтому стоимость агента - это не фиксированная цена, а распределение веротяностей. Потому что все в LLM - это распределение вероятностей.

А оценивать его нужно не по стоимости миллиона токенов, а по:
стоимости успешно выполненной задачи.

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

время проверки результата / время самостоятельного выполнения задачи.

Например:
Человеку нужно два часа, чтобы сделать задачу.

Проверить результат агента можно за шесть минут.

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

Но только если ошибка ничего не ломает.

Если агент отправил неправильный документ, то вы его удалили.

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

McKinsey называет это agency tax:

стоимость проверки + стоимость переделки + последствия ошибки.
Как итог, недостаточно считать:

— токены;
— запросы;
— стоимость модели;
— количество запущенных агентов.

Нужно считать:

— какой бизнес-результат получил агент;
— сколько стоило успешное выполнение задачи;
— сколько времени человек потратил на проверку;
— сколько стоило исправление ошибок;
— насколько агент улучшил реальную бизнес-метрику.

Иначе через год у вас будет 1000 AI-агентов, огромный счет от провайдера и очень сложный ответ на простой вопрос финансового директора:

«А кто из них вообще приносит пользу?»

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

Вот вам красивый дек)

#пятничное

Будущее?
😱 - оно самое
❤️ - мы еще держимся

Ты отправляешь отклик за откликом, обновляешь резюме, поднимаешь его в поиске — а в ответ тишина или автоотказ. Кажется, что hh просто перестал работать.

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

Альтернативные каналы поиска есть, и мы их знаем.

11 августа в 19:00 МСК приглашаем на бесплатный мастер-класс: «hh "умер". Где теперь искать работу?»
Спикер — Кристина Можаева, карьерный консультант AgileFluent с 12+ годами в HR и 1200+ часами практики с кандидатами из IT и digital.

На мастер-классе разберём:
— что изменилось на рынке РФ и почему даже сильные специалисты застревают в поиске;
— как выстроить стратегию, которая держит тебя востребованным даже на нестабильном рынке;
— как собрать резюме, CV, портфолио и сопроводительные так, чтобы они вели на собесы.

Записывайся по ссылке, участие бесплатное 👉 [ссылка]

Реклама. ООО «Эджайл», ИНН 7810964334, erid: 2VtzqwqT4MZ

AC DC снова в моде

Highway to Hell петь начинать не надо!

1.
AC DC клевый термин от ребят из Sonar.
Agentic Centric Developer Cycle.
2.
И казалось бы ну какие статические анализаторы кода в век победившего AI, однако всякая инфраструктура базовая становится все важнее и критичнее.
3.
Ребята из Sonar предлагают любопытную мысль - нафиг проверять код агента только после того, как он закончил весь PR и отдал его на ревью. Они предлагают ревьюить код в процессе его написания, тем самым повышая его качество еще до того, как агент закончит свою работу.

Почему именно так?
4.
Тут все просто: количество кода, генерируе ого после взрывного роста AI растет х2, но люди не могут ревьюить с той же скоростью и становятся узки горлышком.
В ответ на это, мы предлагаем ревьюить код, используя других агентов.
Прикольно?
5.
Да, но в таком случае получается слишком длинный «хоп» и с учетом роста стоимости использования агентов мы начинаем тратить больше времени и ресурсов на исправление.

Как решение, нам и предлагается инкрементально улучшать код прямо в процессе его написания.

А вот ссылочка на оригинал доклада

Присылаешь что-то умное своей аудитории!

Все такие «фууууууу, что за фигня! Перешлюка я это!»

А где лайки?!

Модель тройного долга от соавтора фреймворка SPACE

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


И идея там довольно простая:
AI позволяет нам быстрее производить код, но это совсем не значит, что мы автоматически быстрее производим хорошие и понятные системы.
Просто долг начинает накапливаться немного в других местах😉
Всего Стори выделяет три вида долга:
1. Технический долг
Плохие архитектурные решения, костыли, сложный код, отсутствие тестов и все то, что потом делает систему дорогой в изменении и поддержке.
Причем тут есть забавный парадокс.
Именно этот долг AI потенциально умеет неплохо сокращать:
-отрефакторить код;
-написать тесты и т.п.
То есть код может становиться даже лучше.

2. Когнитивный долг
Это долг, который накапливается уже в голове разработчика: агент написал 1000 строк хорошего кода. И даже тесты все зеленые. Так что вперед и PR в проде.
Только инженер, который этот PR принял, понимает систему чуть хуже, чем если бы писал это изменение самостоятельно. А потом еще один PR. И еще один.
Иииии в какой-то момент получается довольно странная система:
код работает, но никто толком не понимает почему.
Скорость производства кода растет быстрее скорости нашего понимания системы.
Вот это Стори и называет cognitive debt.

И да, тот факт, что скорость производства выросла - это супер! В этом вся суть моей работы, в принципе.
3. Долг намерений — Intent Debt
А вот это типовая проблема, которая всплыла наверх. Раньше она тоже была, но мы особо ей внимание не уделяли.
Можно прекрасно понимать, как работает код, но совершенно не понимать:
почему он работает именно так?
Какие продуктовые ограничения существовали? Что вообще хотел пользователь? Какие компромиссы были приняты?
Все это обычно живет где-то между:
- ADR;
- документацией;
- и, конечно же в голове того самого Тим-лида😁
А теперь представьте AI-first разработку.
Один агент написал изменение.
Через полгода другой агент должен его изменить.
И второй агент пытается понять намерения первого агента… по коду первого агента.
Ну удачи.

В мире AI-разработки документация, ADR, спецификации, acceptance criteria и domain model — это уже не какая-то бюрократия рядом с разработкой.
Это внешняя память вашей системы (на следующей неделе расскажу, как решают и эту задачку)
Причем память нужна уже не только людям, но и агентам.
Последние пару лет мы в основном спрашивали:
как заставить AI писать больше хорошего кода?
Но следующий вопрос будет:
как сделать так, чтобы люди и AI продолжали понимать систему, пока AI пишет все больше кода?
Потому что код становится все дешевле.
А вот понимание:
-зачем система существует;
- почему она устроена именно так;
- какие ограничения нельзя нарушать;
становится только дороже.
И возможно, через несколько лет главным инженерным активом компании будет уже не сам код.
А накопленный контекст вокруг него.

А вот тут мы с Сашей Поломодовым разбирали разные фреймворки и историю их развития

Не грустите там, у нас всегда есть План Б!