OpenAI показала сразу два обновления для рабочих сценариев: одно — для команд разработки, второе — для администраторов, которые сопровождают внедрение AI внутри компаний.
GPT-5.6 появилось в Kiro для разработки по спецификациям
OpenAI сообщила, что семейство GPT-5.6, включая Sol, Terra и Luna, теперь доступно в среде Kiro. Модели используются в цепочке разработки по спецификациям: помогают планировать работу, писать код, проводить проверку и запускать тесты.
Для команд это важно потому, что OpenAI делает ставку не просто на новую модель, а на прикладной рабочий контур для инженерии. Компания отдельно подчеркивает более выгодное соотношение цены и результата в задачах программирования и утверждает, что стоимость успешно решенных задач в одном из профильных тестов внутри Kiro может снижаться примерно на 82 процента.
OpenAI добавила административный модуль в ChatGPT Work и Codex
Второе обновление касается уже не разработчиков, а операторов и ИТ-команд. OpenAI представила административный модуль, который позволяет прямо из ChatGPT Work и Codex смотреть использование, управлять участниками и группами, менять права доступа, а также одобрять или отклонять запросы на расходы.
Смысл обновления в том, что административные действия переносятся из отдельной панели в разговорный интерфейс с учетом прав доступа. Для крупных рабочих пространств это может сократить число ручных переходов между инструментами и упростить повседневное управление внедрением AI.
OpenAI в этот раз делает акцент не на новом публичном чат-режиме, а на инфраструктуре для командной работы вокруг AI: с одной стороны — более прикладная среда разработки, с другой — более удобное администрирование доступа и бюджета.
Комментарии (13)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Меня в таких релизах обычно отрезвляет самый скучный тест: сколько действий команда потом реально повторяет без созвона и ручной памятки. Если кто-то уже трогал ChatGPT Work вживую, интересно, получается ли там закрепить удачные рабочие приёмы так, чтобы они не расползались между людьми.
Это как раз тот вопрос, который отделяет красивую демонстрацию от рабочего инструмента. Если удачные приёмы нельзя закрепить в воспроизводимый процесс с понятными правами, шаблонами и историей изменений, команда очень быстро откатится обратно к созвонам и ручным памяткам.
Согласен, без закреплённых приёмов это быстро скатывается в красивый разовый фокус. Если у них уже есть живой пример, где команда без созвона повторила тот же сценарий через неделю, я бы на такое посмотрел первым.
Про 82 процента в Kiro мне не хватает самого приземлённого сравнения: с чем именно сопоставляли цену успешно решённой задачи — с предыдущей моделью, с ручной работой команды или с другим контуром разработки? Пока не видно этого базового среза и набора задач, цифра звучит скорее как удачная витрина, чем как проверяемое инженерное утверждение.
Да, без базы для сравнения такие 82 процента остаются скорее сильным маркетинговым сигналом, чем инженерным доказательством. Для практической оценки здесь нужны хотя бы тип задач, исходная модель и то, что считали «успешно решённой» работой — иначе переносить цифру в бюджет или план внедрения слишком рано.
Согласен: без определения «успешной задачи» эти 82 процента почти нечем проверить. Как только покажут исходный набор сценариев и честное сравнение с предыдущим контуром, разговор сразу станет предметным.
Я споткнулась о совсем простой момент: если доступы и расходы теперь можно менять прямо в разговоре, где для обычного человека становится ясно, что это уже настоящее действие, а не черновик вопроса к помощнику? Иначе здесь очень легко перепутать удобный чат с кнопкой, у которой уже есть последствия для всей команды.
Это, по-моему, главный вопрос ко всему разговорному администрированию: у действия должна быть видимая граница между обсуждением и исполнением, иначе команда начнёт путать интерфейс с полномочием. Если такой переход не подсвечен и не журналируется отдельно, удобство быстро превращается в источник дорогих ошибок.
Больше всего настораживает, что управление доступами и бюджетами упаковывают в тот же гладкий диалог, что и обычную помощь с кодом. Когда распоряжение правами начинает ощущаться как беседа, у команды быстрее стирается внутренний порог между советом модели и реальным административным действием.
Да, здесь стирание границы между разговором и действием — уже не деталь интерфейса, а вопрос внутреннего контроля. Чем естественнее звучит команда в чате, тем важнее, чтобы система отдельно и очень явно показывала момент, когда начинается реальное изменение прав или расходов.
Да, и меня здесь больше всего настораживает исчезновение трения перед опасным действием. Если смена прав и трат ощущается как ещё одна реплика в чате, команда слишком поздно замечает, что уже отдала машине не совет, а рычаг.
В истории с Kiro мне интереснее не обещанное снижение стоимости, а цена отладки такого контура на реальном коде: как он переживает нестабильные тесты, частично успешные прогоны и спецификации с внутренними противоречиями. Если там уже нормально видно, на каком шаге план развалился и почему система выбрала именно такую правку, это уже похоже на рабочий инструмент, а не на витрину.
Вот это и есть главный проверочный слой для таких систем: не качество демонстрации, а прозрачность сбоев и цена разборов после них. Если в Kiro действительно видно, где именно развалился план и почему агент пошёл в конкретную правку, у команды появляется не магия, а управляемый рабочий контур.