ElKornacio

тут Курсор на днях Composer 2 выпустил, и все заинтересовались - в бенчах выше Opus 4.6, и быстрый ппц, и цены адекватные, в общем, по рынку стал разбегаться слушок о ренессансе Курсора.

сейчас вот увидел интересную инфу, что за Composer 2 возможно скрывается Kimi 2.5, дотюненная.

отдельно кекнул с того, что в комментах даже появился Маск, и прокомментировал модель в Курсоре))

https://x.com/fynnso/status/2034706304875602030

господи, предыдущие трейлеры нового Человека-паука, которые я посмотрел, оказывается, были не настоящими в каком жутком мире ИИ-слопа мы оказались 😕

я ещё думал - вау, всего один фильм, и 20 сюжетов одновременно, неужели он будет идти часов 5. теперь всё ясно((

P.S. если что - вот настоящий

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

в Кодекс завезли субагентов: https://developers.openai.com/codex/subagents/

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

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

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

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

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

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

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

https://ianbull.com/posts/software-architecture

P.S. btw, готов подписаться под каждым словом в разделе "Sinks, Not Pipes".

вот вам ещё размышление, по следам YC-видео про "compound startup", но чутка с другого ракурса. представьте, что вы можете заменить любой кусок вашего бизнеса, с потерей 50% качества, но он станет бесконечно масштабируем.

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

или есть у вас cold outreach. вы щелкаете пальцами, и конверсия в след. этап воронки упала на 50%, сообщения стали хуже. но теперь, если вы того хотите, вы можете делать не 20 сообщений в день, а 200. или 2000. для вас теперь бОльшая проблема - лимиты на рассылку, а не формирование персонализированных сообщений.

ну и всё та же пресловутая разработка. код стал на 50% хуже, но можно делать по 50, 500 PR/day. ревью на 50% хуже, пропускает больше техдолга, но можно ревьюить хоть 1000 PR/day. кол-во edge cases не покрытых тестами - в 2 раза больше, но можно покрывать 200 изменений в день тестами.

а что если где-то падение качества не 50%, а 10%? а где-то - 90%? а что если падение качества с каждым днём будет всё меньше? а что если на конкретном этапе, даже с падением качества, экономика всё равно сходится, пусть и сильно хуже, и за следующие 3-4 месяца можно дотюнить этот этап так, что она будет сходиться ещё сочнее, приносить прибыль?

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

P.S. не получится конечно, лол, вы чего. бизнес аля "говно на каждом этапе, но прибылен" возможен только в около-госухе или too big to fail, в реальности сейчас потери качества слишком заметные. но AI-first бизнес-модели, у которых прямо сегодня экономика не сходится, но с небольшим ростом качества ИИ - сойдётся - есть, и огромное кол-во венчура сейчас делает как раз такие ставки (в общем-то, YC поэтому про это видео и записали).

кароч, ща вкину противоречивый тейк, с которым я и сам не на 100% согласен, но все же, довольно сильно в него верю

тейки уровня "ИИ-агенты пишут код не так, как я хочу", это дроч в духе "мой код на JavaScript компилируется не в тот ассемблер, который мне привычен". разница только в том, что вы тот машинный код, в который компилится JS даже не видите, а если бы и видели - многие ли сегодня умеют читать-писать на fasm/masm? а когда вы просите ИИ писать на _вашем_ языке, а он вдруг взял, и написал не так, как вы любите - начинаются истерики.

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

останьте от кода. он больше не ваш. вы вообще не должны его видеть. ИИ написал большущий файл на 3000 строк? дурашка, это он для тебя мельчит, ему и 100000 было бы норм, для него вся кодовая база - одно большое полотно текста. ИИ использует не твой любимый архитектурный паттерн? вместо ООП пишет функционально? вместо instance refs передаёт колбеки? господи, тебе не насрать?

"наша бизнес-логика такая сложная, ИИ её не поймёт" = в течение 3 лет вас выебут компании, кто смог адаптироваться под ИИ и развивал продукт в 10-20-50 раз быстрее. "ИИ делает баги" = ну и что? разрабы тоже их делают, хоть и значительно меньше (да, даже в очень хорошем ИИ-пайплайне с ИИ-тестами, ИИ все равно делает багов заметно больше чем человек). перестройте QA, научитесь в graceful rollouts, чтобы быстро детектить баги, выстройте авто-ревью, раздробите продукт и так далее: это ваша задача придумать, как использовать ИИ эффективно. вайбы уровня "зачем нужны самолёты, поезд приезжает на вокзал прям в центре города, а из аэропорта ещё надо потом в город ехать, ну и что, что 5 дней в пути, зато надежнее" в 2025 вызывали реакцию "кек, дед с Хабра", а в 2026 по большей части раздражают.

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

https://boristane.com/blog/the-software-development-lifecycle-is-dead/

главная (для меня) дилемма ИИ-кодинга сейчас

делаешь монорепу: • агенту оч удобно получать широкий контекст связей между проектами - и фронт, и бек, и прочее, всё как на ладони, никакогой рассинхронизации контрактов, full-stack end-to-end таски • worktrees превращаются в полное очко - одна только установка и билд модулей для всей монорепы занимает минуты, а надо же ещё полную изолированную для конкретного этого worktree связку всех сервисов поднять. в общем, параллельные запуски агентов сильно проседают

делаешь раздельные репы: • worktrees работают идеально, гоняешь агентов в 5 окон, потом они сами всё мержат, не жизнь, а сказка • дрифт контрактов ебейший, тратишь часы на то, чтобы эти дурики обменивались сведениями о том, как устроен функционал в соседних репах, затраты времени на "стыковку" раза в 4 выше, чем в монорепе. и это ещё ладно, если агент может тупо сам зайти да глянуть через "cat ../../../" другую репу, а если у тебя worktrees и "другая репа" тоже существует в 5 копиях? в общем, беда

так и живём... 😕

в общем, OpenAI добрались рассказать (февраль 2026...) как они научились писать весь код только через агентов. если вы ещё не в подобном режиме, то вам могут пригодиться их наблюдения, выделил самое сочное. кратко:

- в ai-only dev, вы больше не "пишите код", вы строите среду, где агент может писать код сам. ваша работа — ставить задачи, настраивать механики ревью, добавлять тулы/данные/правила, чтобы агент стабильно доезжал до именно того качества кода, какой вы хотите видеть. - репа — это единственный источник правды. всё, что живёт в головах/чатах/гуглодоках, для агента как будто не существует. поэтому знания нужно перетаскивать в репо: доки, решения, схемы, "как у нас принято", "как дебажим", "как релизим". - по мере ускорения разработки, узким местом стал QA. мы запарились над тем, чтобы дать агенту прямой доступ к UI, логам и всем метрикам приложения, чтобы он мог тестить всё сам (а если бы OpenAI читали мой канал, то давно бы заюзали скилл из этого поста) - наш агент видел логи/метрики/трейсы через локальный observability-стек, который поднимается под конкретный worktree. он работает в полностью изолированной копии приложения — со своими логами и метриками — и после завершения таски это всё просто сносится. агенты ходят в логи через LogQL, в метрики — через PromQL. и когда у агента есть этот контекст, задачи типа "startup сервиса должен быть < 800ms" или "в 4 ключевых user journey ни один span не должен быть > 2s" стали решаемы. - вместо одной большой "библии для агента" лучше делать короткую сводку "куда смотреть" и нормальную структуру docs/ с небольшими кусками, которые легко поддерживать. агентам обычно проще идти слоями, чем проглатывать мегатекст. - замечания типа "вкус/стиль/как принято" лучше переводить в исполняемые правила. сначала — зафиксировать в доке. если правило важное и повторяется — лучше поднимать его до кода: линтер, статанализ, codemod, check в CI. цель — чтобы агент сталкивался с правилом автоматически, а не только через комментарии людей. - "agent-generated" обычно лучше считать не только продуктовый код. туда же логично относить тесты, CI, релизный туллинг, внутренние скрипты, доки, дизайн-историю, eval/harness, даже ответы на ревью. людям остаётся judgement: приоритеты, acceptance criteria, риски. - по мере роста скорости разработки ожидание начинает стоить дороже фикса, поэтому шерховатости и мелкие косяки иногда выгоднее закрывать доп. запросом, чем ждать идеального результата — при условии, что есть страховка в виде тестов, метрик и алертов. - качество со временем почти неизбежно "плывёт": агент копирует паттерны, включая плохие, появляется энтропия/ai-slop. ручная чистка не масштабируется, поэтому лучше закладывать garbage collection руками агентов: поиск тех.долга, фиксы мелочей, апдейты доков, рефакторинги. - ключевая дисциплина в ai-only dev — скорее не "prompting engineering", а scaffolding + системы контроля: как устроен репо, какие есть тулы, какие проверки считаются истиной, как агент сам себя валидирует/останавливает/откатывает/эскалирует, и как системно снижать долю человеческого участия.

стоп, подождите, а вы не пропустили прошлый пост про AI Hard Fork?

если вдруг, то вот: ребята из Стратоплана (где я выступал) сколлабились с ребятами из Entropy Talk (где я тоже выступал), и отказаться было нереально - я 25 февраля (среда) залечу на панельку в AI Hard Fork.

в целом, скриншот со спикерами - лучше любых объяснений. практическая онлайн-конфа о том, как AI меняет процессы разработки, и как управлять этими изменениями. для senior engineers, тех- и тим-лидов, СТО и VP of engineering, фаундеров

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

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

Head of AI и СТО крупных банков, ex-CTO Booking и EM из Mapbox, Степан Гершуни и Глеб Кудрявцев, Артем – ex-Meta и автор «эйай ньюз», со-основатели Школы Стратоплан и идейный вдохновитель Entropy Talk.

24-26 февраля, онлайн или в записи, можно бесплатно, можно платно (для тех кто хочет сертификат)

⚡️ регистрация здесь ⚡️

буду вас ждать!

заметил, что даже в около-ИИ тусах не все шарят за разницу между UI/harness/model. мне кажется, ситуация ещё усугубляется дегенеративным неймингом (Composer в Composer, Codex в Codex в Codex, вот этот вот весь адок).

оч коротко, и с упрощением (опустим мультимодальности, и прочие ньюансы): модель - это буквально LLM, "провайдер интеллекта", вы ей на вход даёте текст, она вам в ответ тоже даёт какой-то текст (вызов инструмента - это тоже текст, просто оформленный по особым правилам) harness - это "среда" вокруг модели: набор инструментов, который модели предоставляется (чтение/редактирование файлов/веб-поиск/etc), управление окном контекста (компактизация, сжатие) и вся низкоуровневая работа с моделью - прокидывание вспомогательной информации и правил в контекст модели, парсинг её текстовых ответов, etc. UI - это UI. ну то есть то, что вы видите на экране: интерфейс чата, кнопочки, diff views, и прочее.

скажем, у Cursor - своё harness и UI, но чужие модели (есть пара своих - Composer 1 / 1.5, но 90% трафика на модели Anthropic/OpenAI) а вот у Anthropic всё - модели (Sonnet/Opus), нативный harness (Claude Agent SDK), несколько UI (extensions для VSCode-like редакторов, Claude Code, Claude Desktop, etc) и у OpenAI тоже есть всё своё: Codex, Codex, Codex и Codex. ну ладно, если серьёзно: модели (gpt-5.2/gpt-5.2-codex/gpt-5.3-codex/etc), harness (codex app server), UI (extensions и Codex App под мак). OpenCode - нет своих моделей, но зато свой harness и UI (OpenCode CLI / OpenCode Desktop app).

при этом, есть примеры UI-only: скажем, Conductor (чистый UI, использует нативный harness codex app server/claude agent sdk), или JetBrains умеют в UI-only (тоже юзают нативные harness codex app server/claude agent sdk, но при этом умеют ещё и с собственным harness Junie работать).

почему это всё должно быть вам важно? rule of thumb: нативный harness (то есть когда вы используете модель компании X в harness компании X) в 99% случаев лучше любого не-нативного (то есть модель компании X, а harness компании Y). говорят, что OpenAI буквально до-тренировывает свои модели под их server-side compact-алгоритм, который использует codex-harness (app server). Anthropic затачивает тулы в Claude Code под то, на что они тренировали свои модели (то как происходит редактирование файлов), ну и так далее.

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

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

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/

ну что, поверим что в этот раз у Google получилось что-то, что не стыдно будет юзать для реальных задач?

оч зашла концепция compound startup из этого видео вообще, compound effects это то, на что YC/около-YC тусовка надрачивает регулярно, тот же sama про это целое эссе писал

но конкретно в концепте compound startup идея простая - если вы делаете x1.5-2 раза эффективнее участки автономных процессов, вы получаете экспоненту в конце воронки. ну то есть, буквально: в два раза больше трафика на сайте, в два раза выше конверсия в юзера, в два раза выше конверсия из юзера в продажу = в 8 раз больше профита. почему про это говорят в контексте агентов и автономных процессов? потому что без них compound effect не сработает - если вы увеличили трафик в 2 раза, а на следующем участке воронки у вас отдел продаж с людьми, то вы быстро создаёте в этой точке боттлнек, и вся система разваливается. в общем, as usual - пропускная способность системы равна худшей пропускной способности среди её частей. компании в видео говорят как раз об этом: automate as much as possible, keep headcount as small as possible - единственный способ для команды в 2-3 человека конкурировать с корпорациями с 2000-3000 человек.

философствуя на эту тему с товарищем, подумалось: а насколько можно пожертвовать качеством на отдельном шаге в угоду автоматизации? условно: человек SDR - 100% качества продажи, AI-SDR: к примеру, 20%. но зато исключение human bottleneck из пайплайна, расшивает все остальные участки, и окупается за счёт масштаба. или не окупается? интуитивно кажется, что если на старте автоматизация идёт с максимальной потерей качества, то на выходе можно получить compound типа "1.01 в 10 степени - это 1.1", ато и вообще уйти в <1. с другой стороны - даже с такой неприятной точкой старта, минимальные усиления каждого шага будут давать кратный прирост - 1.02^10=1.2, 1.07^10=2, 1.2^10=6, и так далее

как мне кажется, это очень интересный ракурс на ai-first процессы в компаниях: очень часто говорят под эффектиность и экономию, дескать, ИИ-агент стоит дешевле человека. но динамическая масштабируемость чуть ли не более важное свойство: возможность ad-hoc расширять/сжимать участки процессов, адаптируясь под нагрузку - это та штука, которую почти невозможно делать с сотрудниками из мяса.

я с начала года планировал не участвовать в конфах, но узнав, что ребята из Стратоплана (где я выступал) сколлабились с ребятами из Entropy Talk (где я тоже выступал), отказаться было нереально - я 25 февраля (среда через неделю) залечу на панельку в AI Hard Fork.

в целом, скриншот со спикерами выше - лучше любых объяснений. но для формальности:

«AI Hard Fork» — практическая онлайн-конфа о том, как AI меняет процессы разработки, и как управлять этими изменениями. для senior engineers, тех- и тим-лидов, СТО и VP of engineering, фаундеров

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

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

Head of AI и СТО крупных банков, ex-CTO Booking и EM из Mapbox, Степан Гершуни и Глеб Кудрявцев, Артем – ex-Meta и автор «эйай ньюз», со-основатели Школы Стратоплан и идейный вдохновитель Entropy Talk.

24-26 февраля, онлайн или в записи, можно бесплатно, можно платно (для тех кто хочет сертификат)

⚡️ регистрация здесь ⚡️

буду вас ждать!

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

1. не юзайте TUI в VSCode/Cursor для Claude Code / Codex / etc. мерцания интерфейса и проблемы со вставкой текста (в том числе из голосового ввода) - это не баги самих приложений, а баги tty-среды в VSCode. юзайте нативный терминал.

2. если вы хотите, чтобы агент выполнял одну и ту же цепочку действий - вместо описания цепочки в глобальных правилах лучше просто упакуйте её в bash-скрипт. чем писать "ты всегда должен сделать тайп-чек, билд, прогнать тесты, и потом деплойнуть скрипт", просто попросите агента создать ./check-build-test-deploy.sh, и пропишите этот скрипт в правилах. да, современные агенты неплохо следуют инструкциям, но рандома оч много. иногда агент воспринимает "прогони тесты" как pnpm run test, а иногда он по хардкору начинает писать конструкции типа npx ./node_modules/.bin/jest ... --runInBand ..., и спотыкается. скрипты - гарантия повторяемости (это супер-очевидная штука для вещей, которые приходится делать руками самому, но при этом я часто вижу, что люди не заботятся о том, чтобы обеспечить удобство работы агентам).

3. если вы хотите, чтобы агент после какой-то операции анализировал её результат - прокиньте логи/данные сразу в stdout этой операции. это рифмуется и дополняет предыдущий пункт, если вы юзаете конструкции типа "выполни этот скрипт, после чего прочитай логи в ./abc.log", то поставьте tail -n 50 ... прям в конец скрипта. когда я дебажил ESP-плату, у меня билд-деплой кода были на одном скрипте, а чтение serial monitor - на другом. объединение этого в один скрипт аля "залей новый код, сними логи в течение 15 секунд и верни в stdout" улучшило мою жизнь кратно.

4. правило "агент должен иметь возможность самостоятельно проверить результаты своей работы" известно, наверное, уже всем, но как же часто я вижу нарушения этого принципа с отмазками "ну, у нас такая среда, что не автоматизируешь". классические примеры: - tauri/electron-приложение: "мы не можем запустить фронт в playwright/встроенном-браузере, надо руками" - react-native / flutter: "ну, оно в эмуляторе / на телефоне гоняется, надо руками" - любительский embedded, etc

давайте честно: вам просто влом. за 20 минут работы агента (https://t.me/elkornacio/505) собирается элементарный runtime-eval-debug сервер, который для веб-приложений позволяет агенту кидать команды напрямую в любую среду (и можно ещё и ключевые части приложения прям в window прокинуть, для удобства). логи из фронта в tauri / electron / react-native / flutter тоже прокидываются минут за 5 (можно связкой "фронт шлёт логи на бек, бек пишет в файл"), без особых проблем. embedded прекрасно умеет слать данные датчиков и дебаг-инфу в serial, а оттуда агент умеет читать. в общем, не убеждайте себя, чтобы ваша среда уникальная: если действие происходит на вашем компе, и не связано с физическим миром, то автоматизировать можно всё.

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

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

—

кидайте ваши лайфаки в комментах, буду рад что-то для себя почерпнуть 🙂

ой, ребята, я чёт с этим Spark чуть не забыл про реальную важную новость!

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

на конфе они расскажут инсайты по следующим темам: - когда "сеньор + AI" действительно дешевле и эффективнее команды, а когда вы тратите меньше на ФОТ, но больше на техдолг и инциденты • что ломается в процессах при внедрении AI и почему одни и те же инструменты ускоряют одних и тормозят других - найм: как быть с теми, кто против AI, что делать джунам и каких людей искать в 2026

с практическими примерами и ориентирами, которые можно применить.

всего 11 докладов за два дня (19–20 февраля): от фаундеров, тех-лидов, CPO и Head of AI. цифры, P&L, архитектура и реальные боли внедрения - без воды.

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

👉 в общем, полная программа конфы на сайте: ai-pnl.com 💌 зарегаться можно через бота, вот по этой ссылке

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

но очень поверхностные решения, какие-то костыльные workaround'ы, и всё такое. при этом, контекст жрёт как не в себя, субъективно - раза в 3-4 больше файлов читает чем 5.3-codex. казалось бы, вся инфа об архитектуре есть, данных для нормальных решений, а не workaround'ов, более чем достаточно.

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

если что - Spark уже доступен в Pro, наслаждаюсь всё утро. скорость и правда имбовая + multiple tool calls тоже завезли (на видео хорошо видно, как он по 3 файла за раз вычитывает)

⚡️ https://openai.com/index/introducing-gpt-5-3-codex-spark/

ну и ещё одна сочная новость как результат коллабы OpenAI и Cerebras: новая модель на базе 5.3-Codex, > 1000 токенов в секунду (примерно в 5 раз быстрее классической).

контекст - 128k, пока только текст.

на SWE-Bench Pro и Terminal-Bench 2.0 показывает сильные результаты (заметно слабее флагманских моделей, заметно сильнее мини-моделей), но при этом ппц быстрее: улучшена вся latency-цепочка: −80% roundtrip overhead, −30% per-token overhead, −50% time-to-first-token (для WebSocket).

пока превью только для ChatGPT Pro (та, которая 200 баксов).

P.S. у меня пока доступа в Pro нет(

между тем, Gemini выпустили новый Deep Think

интереснее всего было бы глянуть на hallucination rate - предыдущий Gemini Pro ооооочень сильно тащил по знанию фактов, но ужасно справлялся с реальными агентными задачами.

помимо этого, рассказали про "Aletheia" - свою агентную систему для решения математических задач исследовательского уровня, которая итеративно генерирует идеи решений, сама их проверяет и переделывает (последние два скрина как раз про неё).

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

P.S. за наводку спасибо подписчику в чате! P.P.S. интересно, завезут в Antigravity? 🙂