masterpedikyura

Эта модель специализируется на возможностях рассуждения, критически важных для робототехники, включая визуальное и пространственное понимание, планирование задач и обнаружение успеха (success detection). Она действует как высокоуровневая модель рассуждения для робота, способная выполнять задачи путём нативного вызова инструментов, таких как Google Search для поиска информации, моделей vision-language-action (VLA) или любых других пользовательских функций сторонних разработчиков.

Gemini Robotics-ER 1.6 показывает значительное улучшение по сравнению с Gemini Robotics-ER 1.5 и Gemini 3.0 Flash, особенно усиливая пространственные и физические возможности рассуждения, такие как указание (pointing), подсчёт и обнаружение успеха. Мы также открываем новую возможность: считывание показаний приборов (instrument reading), позволяющее роботам считывать сложные манометры и смотровые стёкла — вариант использования, который мы обнаружили благодаря тесному сотрудничеству с нашим партнёром, Boston Dynamics.

Начиная с сегодняшнего дня Gemini Robotics-ER 1.6 доступна разработчикам через Gemini API и Google AI Studio. Чтобы помочь вам начать, мы делимся Colab для разработчиков, содержащим примеры того, как настроить модель и сформулировать ей запрос для задач воплощённого рассуждения.

Рисунок 1: Результаты бенчмарков, сравнивающие Gemini Robotics-ER 1.6 с моделями Gemini Robotics-ER 1.5 и Gemini 3.0 Flash. Оценки считывания показаний приборов проводились с включённым agentic vision (за исключением Gemini Robotics-ER 1.5, которая его не поддерживает). Все остальные оценки проводились с отключённым agentic vision. Оценки обнаружения успеха с одного и нескольких ракурсов содержат разные примеры, поэтому не сопоставимы.

Указание (Pointing): основа пространственного рассуждения

Указание — это фундаментальная возможность для модели воплощённого рассуждения, развивающаяся с каждым поколением модели. Точки могут использоваться для выражения многих концепций, включая:

• Пространственное рассуждение: Точное обнаружение объектов и подсчёт

• Реляционная логика: Проведение сравнений, таких как идентификация наименьшего предмета в наборе; определение отношений «from-to» (например, переместить X в местоположение Y)

• Рассуждение о движении: Картографирование траекторий и идентификация оптимальных точек захвата

• Соблюдение ограничений: Рассуждение через сложные запросы, такие как «укажи на каждый объект, достаточно маленький, чтобы поместиться внутри синей чашки»

Gemini Robotics-ER 1.6 может использовать точки как промежуточные шаги для рассуждения о более сложных задачах. Например, она может использовать точки для подсчёта предметов на изображении или для идентификации заметных точек на изображении, чтобы помочь модели выполнять математические операции для улучшения своих метрических оценок.

Пример ниже показывает сильные стороны Gemini Robotics-ER 1.6 в указании на множество элементов и в знании, когда указывать, а когда нет.

Gemini Robotics-ER 1.6 правильно идентифицирует количество молотков (2), ножниц (1), кистей (1), плоскогубцев (6) и набор садовых инструментов, который можно интерпретировать как одну группу или несколько точек. Она не указывает на запрошенные предметы, отсутствующие на изображении — тачку и дрель Ryobi. Для сравнения, Gemini Robotics-ER 1.5 не идентифицирует правильное количество молотков или кистей, полностью пропускает ножницы, галлюцинирует тачку и не имеет точности в указании на плоскогубцы. Gemini 3.0 Flash близка к Gemini Robotics-ER 1.6, но не справляется с плоскогубцами так же хорошо.

Обнаружение успеха: двигатель автономии

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

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

Gemini Robotics-ER 1.6 продвигает рассуждение с нескольких ракурсов, позволяя системе лучше понимать множественные потоки камер и взаимосвязи между ними, даже в динамических или окклюдированных средах, как показано в типичном многоракурсном сценарии ниже.

Gemini Robotics-ER 1.6 берёт сигналы из нескольких ракурсов камеры, чтобы определить, когда задача «положить синюю ручку в чёрную подставку для ручек» выполнена.

Считывание показаний приборов: визуальное рассуждение в реальном мире

Чтобы понять ключевую сильную сторону Gemini Robotics-ER 1.6, мы должны посмотреть, как она сочетает такие возможности, как пространственное рассуждение и знания о мире, для решения сложных реальных проблем. Идеальным примером является считывание показаний приборов.

Эта задача проистекает из потребностей инспекции объектов — критической области внимания для наших партнёров в Boston Dynamics. Промышленные объекты содержат множество приборов — термометры, манометры, химические смотровые стёкла и многое другое — которые требуют постоянного мониторинга. Spot, продукт-робот компании Boston Dynamics, способен посещать приборы по всему объекту и захватывать их изображения.

Gemini Robotics-ER 1.6 позволяет роботам интерпретировать разнообразные приборы, включая круглые манометры, вертикальные индикаторы уровня и современные цифровые табло.

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

Такие возможности, как считывание показаний приборов и более надёжное рассуждение о задачах, позволят Spot видеть, понимать и реагировать на реальные вызовы полностью автономно.  Marco da Silva  Вице-президент и генеральный менеджер Spot в Boston Dynamics

Gemini Robotics-ER 1.6 достигает своих высокоточных показаний приборов, используя agentic vision, который сочетает визуальное рассуждение с исполнением кода. Модель делает промежуточные шаги: сначала увеличивает изображение, чтобы лучше прочитать мелкие детали манометра, затем использует указание и исполнение кода для оценки пропорций и интервалов и получения точного показания, и в конечном счёте применяет свои знания о мире для интерпретации значения.

Рисунок 2: Как разные элементы Gemini Robotics-ER 1.6 способствуют достижению высокого уровня производительности в задаче считывания показаний приборов.

Точное считывание аналогового манометра

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

Наша самая безопасная робототехническая модель на сегодняшний день

Безопасность интегрирована на каждом уровне наших моделей воплощённого рассуждения. Gemini Robotics-ER 1.6 — наша самая безопасная робототехническая модель на сегодняшний день, демонстрирующая превосходное соответствие политикам безопасности Gemini на состязательных задачах пространственного рассуждения по сравнению со всеми предыдущими поколениями.

Модель также демонстрирует существенно улучшенную способность придерживаться ограничений физической безопасности. Например, она принимает более безопасные решения через пространственные выходные данные, такие как указание относительно того, какими объектами можно безопасно манипулировать в условиях ограничений захвата или материала (например, «не обращаться с жидкостями», «не поднимать объекты тяжелее 20 кг»).

Мы также проверили, насколько хорошо модель идентифицирует угрозы безопасности в текстовых и видеосценариях на основе реальных отчётов о травмах. В этих задачах наши модели Gemini Robotics-ER улучшают базовую производительность Gemini 3.0 Flash (+6% в тексте, +10% в видео) в точном восприятии рисков травм.

Рисунок 3: Gemini Robotics-ER 1.6 значительно улучшается по сравнению с Gemini Robotics-ER 1.5 в Safety Instruction Following, который проверяет способность придерживаться ограничений физической безопасности. Она улучшается по сравнению с Gemini 3.0 Flash в указании, и обе модели имеют очень высокую точность для текста. Gemini 3.0 Flash лучше работает с ограничивающими прямоугольниками (bounding boxes).

Сотрудничайте с нами для улучшения воплощённого рассуждения для робототехники

Мы стремимся обеспечить, чтобы Gemini Robotics-ER приносила максимальную пользу робототехническому сообществу. Если текущие возможности ограничены для вашего специализированного применения, мы приглашаем вас отправить эту форму с 10–50 размеченными изображениями, иллюстрирующими конкретные режимы отказов, чтобы помочь нам построить более надёжные функции рассуждения. Мы с нетерпением ждём сотрудничества с вами для улучшения этих возможностей в наших предстоящих релизах.

Попробуйте Gemini Robotics-ER 1.6 прямо сейчас в Google AI Studio

Это изменение, по сути, упрощает уже существующий рабочий процесс. Google Nano Banana 2 — один из лучших доступных ИИ-генераторов изображений, и в него уже было возможно подавать изображения себя или других людей в качестве контекста для создания нового ИИ-контента. Добавление «персонального интеллекта» в этот микс делает процесс более плавным, отпуская «бота» по содержимому ваших фотографий, если, конечно, это то, что вы хотите делать.

В целом верно, что добавление большего количества личных данных в ИИ-промпт даёт лучший результат. Google приводит несколько примеров того, как подключение Nano Banana к Photos может в этом помочь. Вам не придётся упаковывать столько контекста в свои подсказки — вы можете просто сослаться на «мою семью» или «мою собаку», чтобы робот нашёл полезные изображения в вашей библиотеке Photos.

Возможно, вам нужна забавная семейная фотография, и вы пишете: «создай пластилиновое (claymation) изображение меня и моей семьи, занятых нашим любимым делом». В этом промпте Gemini будет полагаться на метки, которые вы добавили в Google Photos, чтобы определить «семью», а содержимое изображений может помочь ему определить «любимое занятие».

Вы, конечно, могли бы получить аналогичный результат, явно указав Gemini включить определённых людей, делающих определённое занятие, но «персональный интеллект» избавляет вас от лишнего набора текста. Это снижает трение и может побудить людей чаще использовать ИИ-инструменты, что и является конечной целью Google.

Идеально несовершенно

Google отмечает, что новая функция всё ещё развивается, поэтому она не всегда может выбирать правильные изображения. Если такое случится, возможно, вам захочется проверить список источников, чтобы понять, что пошло не так. Там будут перечислены изображения, на которые ссылается промпт, и вы также можете в последующем сообщении спросить у Gemini о выбранных им изображениях. Ручной выбор фотографий с помощью кнопки «плюс» в Gemini может помочь устранить эти недостатки.

Хотя Nano Banana 2 теперь может просматривать вашу библиотеку Google Photos при генерации изображения, Google подчёркивает, что не сохраняет эти данные для обучения. Различие между использованием ваших данных в промпте и обучением ИИ на них может сбивать с толку, но Google заявляет, что не использует никакие изображения из вашей библиотеки для обучения. Однако компания использует входные данные (то, что вы вводите) и выходные (то, что модель делает в результате) для улучшения ИИ-продуктов. Это всё ещё может включать персональные данные о вас, но это не то же самое, что вливать все ваши фотографии в обучающие данные Nano Banana.

В любом случае, всё это предприятие может всё равно вызывать у людей мурашки. Хорошая новость в том, что вы не обязаны пускать Nano Banana в свою фотобиблиотеку, даже если используете его для генерации изображений. «Персональный интеллект» по умолчанию выключен и в настоящее время доступен только тем, кто на платных тарифах Google AI (привязка к Nano Banana доступна даже тем, кто на бюджетном тарифе Plus).

Однако, как мы видели в прошлом, ИИ-функции часто появляются на платных тарифах, прежде чем распространиться на всех владельцев аккаунта Google. Gemini настойчиво просит пользователей включить «персональный интеллект», поэтому вы, вероятно, будете видеть эти всплывающие окна и в будущем, даже если не платите за ИИ. «Персональный интеллект» также подключает Gemini к Gmail, YouTube и другим сервисам Google, но при настройке вы можете решить, какие из них разрешены.

Adobe и раньше предлагала чат-подсказки внутри отдельных приложений и в других интерфейсах Firefly. Также под брендом Firefly она ранее предоставляла доступ к генеративным моделям. Здесь же отличие в том, что Firefly AI Assistant (так они называют этот новый интерфейс) обещает работать сразу в многочисленных приложениях Adobe Creative Cloud и фактически оркестрировать рабочие процессы между ними, регулярно обращаясь к пользователю с предложениями и вопросами. Как и в случае с аналогичными инструментами, которые мы уже видели для программирования и тому подобного, пользователи могут вмешиваться в процесс выполнения задачи с уточнениями или дополнительной информацией.

Хотя в основном это чат-интерфейс, он динамически выводит на экран контекстно-релевантные элементы управления, такие как ползунки, в зависимости от текущей задачи.

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

Кроме того, появятся «навыки» (skills), которые работают практически так же, как навыки, которые вы могли видеть в аналогичных инструментах для других дисциплин — таких как Codex от OpenAI или Claude Code от Anthropic. Навыки — это, по сути, заранее упакованные интеграции и рабочие процессы, заточенные под конкретные задачи. Пользователи могут пользоваться библиотекой готовых навыков или создавать и настраивать собственные.

Firefly AI Assistant фактически впервые был показан в октябре прошлого года, когда он назывался «Project Moonlight» — это просто публичный релиз той же концепции.

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

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

Adobe сообщает, что Firefly AI Assistant выйдет в публичную бета-версию в течение нескольких недель, но пока не предоставила конкретики относительно цен, лимитов или того, каким пользователям и тарифным планам он будет доступен.

«Уже какое-то время я слышу от инженеров, которые гоняют несколько coding agents одновременно — запускают сразу несколько инстансов Claude Code или OpenAI Codex, иногда в одном и том же репо, иногда против нескольких чек-аутов или git worktrees.

Сначала я был довольно скептичен. AI-сгенерированный код нужно ревьюить, что значит, что естественное узкое место (bottleneck) во всём этом — насколько быстро я могу ревьюить результаты. Уже сложно поспевать даже за одной LLM, учитывая, как быстро они выдают результат — какой смысл в запуске нескольких параллельно, если это просто оставит меня ещё дальше позади?

Несмотря на мои сомнения, за последние несколько недель я заметил, как тихо начал принимать образ жизни параллельных coding agents.

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

Simon делится советами о том, что у него работает: research (исследования), maintenance tasks (задачи по сопровождению) и направленная работа — все упомянуты как use cases.

Интересно подумать, есть ли у параллельной работы с агентами потенциал перевернуть десятилетия практик software engineering. Допустим, software engineers, запускающие несколько агентов сразу, действительно становятся более продуктивными, чем «однопоточные» (single-threaded) коллеги, работающие над одной проблемой за раз. Если так, у этой практики есть шанс распространиться, если достаточно software engineers захотят быть продуктивнее — или захотят не отстать от тех коллег, кто делает больше, чем раньше.

Но инженерия в до-AI эпоху для многих продуктивных инженеров была про пребывание в потоке (flow). Состояние flow примерно такое:

Понять движущиеся части

Построить решение, валидировать его, итерировать

Когда удовлетворён тем, как работает, отправить pull request на code review — или, если ревью не нужно, просто смержить и зашипить

Прерывание этого процесса разрушает состояние flow, и нужно время, чтобы вернуться в него: вот почему software engineers стремятся приоритизировать focus time, чтобы продвигать кодинг.

Конечно, это не универсально среди всех высоко продуктивных инженеров; когда я был engineering manager, самые продуктивные инженеры в моей команде делали много context switching и были искусны в жонглировании несколькими вещами одновременно. Вот как выглядит средний день senior engineer, выполняющего роль tech lead:

Code reviews. Прийти в офис, пройти открытые ревью с прошлой ночи

Coding (программирование). Сделать какую-то часть собственной работы по коду

Standup (стендап). Как обычно

Ещё coding. Сделать работу. По крайней мере, такова идея. По факту:

Прерывания: code reviews, просьбы о помощи, похлопывания по плечу. Самый продуктивный инженер в команде регулярно получает сообщения с просьбами поревьюить код, чтобы разблокировать коллег по команде, помочь кому-то, кто застрял, или менеджер (я — извини!) хлопает по плечу за помощью с чем-то.

Я думаю, не окажутся ли senior+ инженеры «прирождёнными» в работе с параллельными AI-агентами, исходя из их существующих привычек и того, что они делают сейчас:

Держат параллельные workflows в голове; например, что члены команды делают в данный момент.

Code reviews по нескольким workstreams: они — go-to код-ревьюер, и обычно ревьюят все изменения кода по 2-5 workstreams. Они могут не делать саму работу, но знают, когда сделано правильно.

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

Хороши в направлении коллег: поскольку их регулярно прерывают, они также научились делегировать и объяснять срочную работу членам команды.

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

С AI-агентами качества, делающие хорошим tech lead, становятся доступны инженерам, которые хотят быть более продуктивными. Пока единственные, о ком я слышал, что они успешно используют параллельных агентов, — это senior+ инженеры.

С другой стороны, этот workflow прижился не у всех: я спросил создателя Flask Armin Ronacher о его опыте с параллельными агентами. Он сказал мне:

«Я иногда запускаю параллельных агентов, но не так часто, как раньше.

Дело в том, что мой ум может ревьюить только определённое количество!»

Но мы сейчас в новой территории, где любой dev может запустить параллельный кодинг с coding agents. Сделает ли это инженеров более продуктивными, или просто заставит людей чувствовать, что они более продуктивны? Возможно, окажется, что инженеры, делающие одно дело за раз и сохраняющие фокус, со временем покажут, что производят более надёжный софт. Или, может, выяснится, что работа с параллельными агентами ведёт к тому, что больше проблем проскальзывает и больше итераций — что уничтожает любой выигрыш.

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

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

Тестирование: у всех сайд-проектов есть unit tests, потому что я научился не доверять собственной работе без валидации

Маленькие, описательные задачи: я даю задачи достаточно небольшого scope, объясняю и привожу примеры

Refactoring (рефакторинг): каждая третья или четвёртая задача — для агента отрефакторить какой-то код, который он написал (например, вынести в метод, переместить в новый класс)

Review (ревью): я отслеживаю, что делает агент

Делать мелочи руками: держу IDE открытым и любые изменения в несколько строк делаю руками, чтобы оставаться в курсе кодовой базы

Я продолжаю слышать то же самое от других инженеров: «обязательные» инженерные практики — например, чтобы агент проходил все тесты прежде чем продолжить, — ведут к лучшим результатам. Это неудивительно и поэтому такие практики становятся популярными. AI-агенты недетерминированы и в какой-то мере ненадёжны; эти практики делают их гораздо надёжнее и применимее.

Это была одна из пяти тем, освещённых в The Pulse #149. Полное издание дополнительно покрывает:

ACP protocol. Новый протокол, построенный командой Zed, который пытается сделать создание AI-тулинга для IDE проще, чем позволяет MCP protocol

AI security tooling работает на удивление хорошо? AI-powered security tools, кажется, хорошо находят security-уязвимости в зрелых open source проектах

AI — единственный двигатель экономического роста США? 40% ВВП США в этом году основано на AI-связанных тратах, тогда как 60% венчурного капитала идёт в AI. Будем надеяться, это не закончится пузырём, лопающимся как в 2001 году

Сравнение интервью в 8 крупных tech-компаниях. Puneet Patwari подал заявку в 8 крупных tech-компаний и получил 6 офферов. Он сравнивает свой опыт интервью в Meta, Amazon, Uber и 5 других местах

Причина моего скептицизма была в том, что SaaS вроде HR-софта Workday — это больше, чем просто софт. Workday, например, поддерживает соответствие требованиям compliance (например, по оплате отпусков в разных странах), гарантирует корректность (например, payslips — расчётных листков, соответствующих локальным регуляциям), и со временем софт держится в актуальном состоянии вместе с изменениями во внешней и внутренней среде.

Однако на этой неделе я лично пережил, насколько до смешного легко сейчас заменять SaaS на LLMs. На моём сайте — pragmaticengineer.com — есть секция отзывов (testimonials), где показываются настоящие посты из LinkedIn и X об этом издании. Это стоило $120/год за маленький сервис под названием Shoutout.io и выглядело так:

А вот бэкенд: ничего изысканного, просто способ добавлять, редактировать, переставлять и удалять отзывы.

Я был клиентом четыре года и заходил, наверное, раз в год. Последний раз я залогинился, чтобы получить годовой счёт-фактуру для своих расходов. К сожалению, секция биллинга была сломана, и я написал в поддержку, а они вместо счёта прислали мне битую ссылку. Это раздражало: зачем платить за SaaS со сломанным биллингом? Я даже не мог понять, сколько они с меня возьмут в следующем году.

Так что я задал себе вопрос: смогу ли я перестроить свой случай использования (use case) с помощью LLM, и сделать это быстро. Мой use case был куда проще, чем сам SaaS:

Отображать существующие отзывы похожим образом

Сделать так, чтобы было легко добавлять новые — например, хранить отзывы в каком-то JSON-формате

Сделать так, чтобы выглядело хорошо

К моему удивлению, всё это усилие от начала до конца заняло ровно 20 минут с Codex. Шаги, которые я сделал, были вполне прямолинейные:

Попросил Codex составить план, как убрать эту стороннюю (third-party) зависимость и разместить все отзывы в моём собственном кодовой базе (GitHub-репозитории, развёрнутом в Netlify)

Подкрутил план: я настоял на модульном подходе, где отзывы лежат в отдельном JSON-файле, и они генерируются в HTML на этапе билд-шага во время компиляции (compile-time build step)

Добавил этот build-step и локально, и как build trigger в Netlify

Протестировал решение

Подтюнил UX (user experience, пользовательский опыт) и сгенерировал схему

Задеплоил

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

Что это значит для SaaS-продуктов и software engineers (программистов)?

Что это значит для software engineers:

Разработчикам (девам), вероятно, гораздо комфортнее использовать командную строку для будущих апдейтов, чем обычным пользователям. Чтобы добавить будущий отзыв, мне нужно будет обратиться к моему AI-агенту, чтобы он вставил его в кодовую базу, а потом мне нужно будет проверить, что выглядит хорошо. Для меня это не проблема, но для кого-то, кому некомфортно проверять выходной код LLM, это может быть deal-breaker (стоп-фактор).

Разработчику гораздо быстрее «портировать» SaaS, чем кому-либо ещё. Я сначала сказал Codex скопировать UI, и он сделал не так, потому что попытался использовать flexbox-модель. Мне пришлось сказать ему, что эта раскладка UI — не то, чего я хочу, и затем самому решить, какой фреймворк использовать для UI-раскладки. Не-разработчик, наверное, тоже это разрулил бы, но это заняло бы дольше.

Если по-честному, переписывать стороннюю фичу — это весело и интересно. Рекомендую. Часть причины, почему я взялся за этот проект, — я ожидал, что это будет интересный челлендж. Я думал, что усилие будет больше, чем оказалось, и я больше узнал о том, насколько хорошо работают эти инструменты. Я также использовал Codex, чтобы испытать его подробнее.

Что это может значить для SaaS-софта:

Перестроить SaaS целиком всё ещё ощутимо сложнее, чем перестроить ваш конкретный use case. Я никаким образом не «перестроил» Shoutout. У Shoutout в 10 раз или больше фич — добавление цитат с 10 разных платформ, аутентификация, биллинг (который у меня не работал) и многое другое.

SaaS, не дающий продолжающейся ценности, под угрозой замены клиентами. Shoutout не приносит никакой продолжающейся ценности после того, как отображает мои отзывы, и эта статичность означает, что его легко заменить. В отличие от этого, было бы сложнее перестроить, если бы я платил за платформу, чтобы оставаться compliant (соответствовать требованиям), получать аналитику или алерты и делать другие вещи в реальном времени, помогающие моему бизнесу.

Покупка и продажа SaaS-бизнесов может стать менее прибыльной. Изначальная версия Shoutout, на которую я подписался в 2021 году, была построена в 2020 году независимым разработчиком. В 2022 году этот разработчик продал этот микро-SaaS продакт-студии. Затем, в 2025 году, Shoutout был продан снова — новым разработчикам. С моей точки зрения, ничего не изменилось, кроме того, что сломалась биллинговая система. Полагаю, покупатели этого SaaS прикинули, что выручка может расти и без всяких инвестиций. Но, наверное, в какой-то момент это перестаёт быть правдой, когда людям надоедает сломанный продукт и они уходят — особенно когда уход обходится дешевле.

«Разбитые окна» (broken windows), которые не чинят, сегодня менее терпимы, чем раньше. Моё путешествие прочь от Shoutout началось с того, что у них была сломана биллинговая система. Например, ниже — то, что я увидел, когда зашёл в свою секцию биллинга, чтобы посмотреть счета:

Кроме того, customer support в ответ на мой email прислал мне битую ссылку. Этого мне хватило, чтобы решить заменить эту зависимость, и я был удивлён, насколько это легко с LLM, когда знаешь, чего хочешь от него получить. К моменту, когда служба поддержки через два часа прислала рабочую ссылку, я уже закончил миграцию с этого SaaS.

Об авторе: Gergely Orosz пишет The Pragmatic Engineer Newsletter. Автор книги The Software Engineer's Guidebook. Ранее работал в Uber, Microsoft, Skype, Skyscanner. Амстердам, Нидерланды.