GPT-5-Codex vs Sonnet 4.5 - обзор

Всем привет. Давненько я ничего не выпускал, и мне очень хотелось записать ролик про GPT5 кодекс, потому что у этой модели есть одно очень интересное отличие по сравнению с классической GPT 5. Она сильно выросла в рефакторинге, и мне хотелось потестировать её на каких-то реальных тасках с этим связанных. Я собрал пул из двенадцати задачек, связанных с рефакторингом, и, собственно, погонял кодекс на этих задачках и посмотрел, что она там способна делать, а что у неё всё ещё не получается. В целом ролик я планировал посвятить именно этому.

Но пока я готовился к записи этого видео, вышла ещё одна новая флагманская модель Sonet 4.5 от Antropic. И я подумал, а если ж у меня уже развёрнуты репозитории с кодовыми базами как раз под задачки по рефакторингу, а чего бы мне не погонять SNET на тех же самых задачах. И мы, во-первых, сможем поговорить сразу про две модели в этом видосе, а во-вторых, мы ещё и между собой сможем сравнить то, как они себя проявляют на объёмных задачах, связанных с редактированием большого количества файлов, рефакторингом, изменением архитектуры и так далее, и так далее.

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

И для начала мне бы хотелось сказать, а чем вообще этот релиз GPT5 кодекса мне показался примечательным? Потому что в целом, если посмотреть на bench, типа того же SVE Bench, довольно проходной релиз. Ну то есть да, мы увидели рост на почти пару процентных пунктов, но overall моделька стала лучше, пишет код лучше. Но не то, чтобы это прямо какая-то революция, не то, чтобы мы прямо что-то принципиально новое увидели. Но в press-релизе мне показался очень интересно вот этот график. Мы, к сожалению, понятия не имеем, что он означает, потому что это какой-то внутренний бенчмарк Open AI, и они особо-то не делятся, как они его читали, ближе поверхностно говорят, что у них де был набор каких-то задач по рефакторингу, и на этих задачах модель себя стала проявлять радикально лучше, если верить этим цифрам, чтобы они не значили, на почти 20% пунктов. Но мне это показалось даже неважным. Сам факт того, что ребята позиционируют свою модель как сильно выросшую в рефакторинге, в кодрев и в задачах, связанных с архитектурой и проектированием и всем таким, мне показалось само это заявление уже достаточным, чтобы это потестировать.

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

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

Первая группа - это когда рефакторинг и был задачей. Что я имею в виду? Я сам своими глазками увидел, что в коде есть вот такой вот кусочек, который я хочу переделать. Я хочу создать новый слой абстракции или я хочу, чтобы классы были расширяемы, какая-то была модульность в проекте, whatever. То есть сама задача, которая ставилась и - это и был рефакторинг. Я буквально просил его прямо его сделать. И это задача из первой группы. Туда попало четыре таски.

Это слой абстракции над сокетами. Что это такое? В одном игровом проекте у меня игра могла работать как в сингleплер режиме, прямо во вкладке браузера и в webвоer трейде поднимался виртуальный сервер и сокетсоединение оно как бы было не настоящее. Это был просто post message on message между workerдом и метредом. Но это всё было в обёртке, как будто бы это сокет. Таким образом, мне получалось использовать практически идентичный код, как для работы через веб-сокеты с реальным серваком, находящимся на удалённой машине, так и с локальной вкладкой самого браузера. И вот эту абстракцию я и хотел, чтобы искусственный интеллект мне сделал. В тот раз он не справился. Посмотрим, что будет сейчас.

Далее. Виртуальная файловая система. Это паттерн, который я обожаю в очень многих проектах, особенно в иагентах, когда я ими занимаюсь. Они очень любят работать с файлами, их читать, редактировать и так далее. Они очень хорошо умеют это делать и на этом обучены. Но далеко не всегда мне нужны реально файлы как таковые. Иногда я хочу, чтобы в какой-то виртуальной среде и агент мне собрал, не знаю, какой-нибудь компонент или код или ещё что-то. Но при этом я не хочу давать ему даже какую-то песочницу. Я реально хочу, чтобы это была просто inmemory виртуальная файловая система. Поэтому я хочу посмотреть, насколько хорошо с этой задачкой справится GPT5 кодекс.

Далее, одна из моих любимых задач. Я ненавижу реакт хуки и считаю, что это худшее, что происходило когда-либо с Реактом. Поэтому я обожаю, когда какой-то реакт-компонент, написанный на хуках, переписывается на MobК. И я очень люблю просить это сделать искусственный интеллект. Но иногда в кейсах каких-то особенно монструозных компонентов какое-то жёсткое legy, где один только stateйт-менеджмент занимает примерно так строк 600 кода, просто вот взять и переделать это на store, особенно когда мы говорим про какую-то асинхронщину, про какой-то там зависимость стейта друг от дружки и перетекание состояний одно в другое. Это может быть очень нетривиально. У меня был один конкретный кейс с личным кабинетом, где как раз-таки был отвратительный state, зашитый в use state в самом компоненте личного кабинета. И я тестил на том, как EИ сможет это выковорить в Mobк Store, насколько это хорошо у него получится сделать.

И последнее, у меня есть свой небольшой nots сервер, который имеет целый ворох разных тулов, связанных, скажем так, с моей жизнью. Там есть тул, который, к примеру, может открыть домофон у меня в доме или тул, который может мне включить или выключить телевизор. Какие-то штучки, связанные с умным домом. Или там есть лol callл, который может записать мой вес в специальный Google сadsheit. Э, весь этот ворог каких-то функциональностей, которые я держу на этом серваке, я потом использую в самых разных местах. Иногда это может быть кнопка на экране моего Айфона, чтобы я мог голосом записать, какой у меня сейчас вес и трекать это. А иногда это может быть какой-то вебху, который вызывается из какого-нибудь там Nathan Workflow на определённом этапе или с Telegramбота или ещё откуда-то. Короче, э главная проблема с этим NotJS сервером, что у него очень много ветвлений в зависимости от того, откуда он сейчас вызван, из Нейтона или из MCP, или это прямой HTTP вызов, или это какой-то ли call, э, CLI call, я имею в виду из консоли моего компа. И мне давно хотелось его отрефакторить, чтобы эта модель вызова была более универсальной. И это тоже отличная задачка для искусственного интеллекта.

Вторая группа связана с рефакторингом технического долга, который делают люди. И здесь есть важный нюанс. Если в первой группе я прямым текстом проговариваю и что есть, где сказать, такая задача по рефакторингу, тебе надо её сделать, то во второй группе я не говорю ему, что такая задача есть. Я ожидаю, что он сам идентифицирует проблемы в коде и поймёт, как их исправить. Почему для меня это очень важно? Я упоминал, что я хочу, чтобы новая модель стала частью моего как бы автономного пайплайна того, как и реализуют таски. Мне очень не хватает в этом пайплайне некого завершающего звена, которое по итогу выполнения работ проводит такую повторную проверку качества полученного кода, появившегося технического долга и, собственно, его исправляет. Я сейчас рассматриваю GPT5 кодекс как кандидата на такую роль. Поэтому мне важно, чтобы он сам по очень общей задаче на уровне взгляни на этот код и подумай, можно ли в нём что-то улучшить, если это необходимо, там что-то вот такое, насколько он будет хорошо идентифицировать косяки и исправлять их. Поэтому появился такой второй блок.

А, и здесь следующие таски. Первое, ээ, есть абстрактный database драйвер, в котором, э, абстракции протекли. То есть в наследниках абстрактного класса есть конкретная реализации под Посгриз, под MySQL и под Мон. Но при этом в самом абстрактном классе, в некоторых функциях, э, есть вид влияние типа, tyвен poгress и часть логики по сути вылезла наружу. Так исторически получилось, бывает, извините. Тем не менее, я хочу, чтобы и, во-первых, понял, что это неправильно, что это нарушение паттерна, и, во-вторых, поправил это.

Далее, в одном проекте у меня есть очень монструозная система, которая скедулит обработку колбэков по длинным задачам, которые юзеры подают на вход через там опишку. Они кидают long runing task, который может выполняться до получаса, и дальше там целый скернг того, как эти колбки resolватся. Это всё очень легко можно переделать на промезы, и тогда система станет гораздо более элегантна. То, что промез будет выполняться полчаса, ничего страшного, так бывает. И я хочу, чтобы и до этого догадался и сам предложил рефакторинг, как это можно сделать. По сути, когда-то я этот рефакторинг уже сделал сам. Я просто откатился на старый комит и смотрю, как и с этим справиться.

Далее, у меня есть одно приложение на Тауре. Это такой фреймворк, который позволяет десктопные приложения запускать свой бьюхой внутри. И у меня это приложение умеет работать в трёх разных средах. Оно умеет работать в браузере, оно умеет работать как Progressive Web App на Айфоне и оно умеет работать, собственно, в самом Тауре, запущено как десктопное приложение. И в зависимости от этого некоторые ээ интерфейсы, скажем так, с которыми оно взаимодействует, к примеру, локальное хранилище или, к примеру, то, а как вообще мы можем подключиться к тем или иным сокетам. В Тауре это можно делать напрямую, в браузере и ПВА это приходится делать через вебсокеetт и так далее, и так далее. немножко меняется логика работы приложения. Много ветвлений в коде. Я хочу, чтобы и сам догадался, что большую часть этих ветвлений можно вытаскивать на уровень абстракции, к примеру, pattern behavior или что-то подобное.

И последняя задача в этом блоке, она хоть и на рефакторинг, но догадаться до неё прям полностью самостоятельно, я думаю, невозможно. Я немножко наталкиваю и в промте. Собственно, что за задача? Э, у меня в одном моём давнем проекте, связанном с аналитикой в базах данных, э, есть парсер SQL запросов, который определяет, э, это у нас один в этом тексте SQL запрос или несколько. Если вы шарите за постгриз, то вы знаете, что через ключевое слово делиметр там можно менять, собственно, разделитель между запросами. Поэтому просто вот так взять и по точке запятой, к примеру, сплитануть текст не прокатит. Если вы в рамках этого текста делиметр переопределялся, то у вас там будет проблемка с этим связанная. Поэтому пришлось сделать, собственно, парсер. И я хочу, чтобы и переписал мне этот парсер из просто обычного императивного стиля на конечный автомат, потому что это будет гораздо быстрее и гораздо эффективнее. Это не очень сложный конечный автомат, у него на вскидку где-то семь-восемь состояний. Я думаю, с этим не сложно справиться, но посмотрим.

И последний блок, самый для меня интересный, - это рефакторинг технического долга от самого искусственного интеллекта. У меня накопилось в моих проектах дофига мест, которых мне именно и техдолг и создал. Самая любимая штука - это, естественно, дублирование функций. Мы посмотрим, насколько они справляются с этим. Следующее - это вынесение общего кода в тестах в хелперы. Это тоже очень классическая штука, когда у вас И написал 20 однотипных тестов. У них очень часто дублируются блоки инициализации, финализации, всего такого. Я хочу посмотреть, насколько новая модель будет справляться с тем, чтобы замечать это дублирование в коде, вытаскивать это в какие-нибудь хелперы, в отдельные файлы, дай бог, и заменять это в тестах самостоятельно. Далее, это, в принципе, вынесение функции однотипного характера в некие утилитарные файлы или даже неймспейсы. Я хочу посмотреть, насколько и в принципе функциях, не связанных с тестами, а работах с компонентами или просто по кодовой базе сможет идентифицировать, что здесь слишком много кода, скажем, в одном файле, в одном блоке, в одном модуле, и его хорошо бы посплитить на разные участочки. То есть я хочу понять, насколько искусственный интеллект способен разделять блоки на модули. И последняя задачка немножко связана с функциональным программированием. У меня в четырёх разных роутингах на ExpressJZ используется очень похожий midleware. Я хочу понять, насколько и справиться с тем, чтобы заметить это, и создать порождающую функцию высшего порядка, которая будет возвращать конкретный midleware для того или иного случая. То есть объединить все четыре очень похожих midлleвея в одну такую порождающую функцию для этого блока.

Как я уже сказал, я не буду показывать то, как именно и выполнял все эти задачки. Это довольно скучно смотреть, потому что это просто окно курсора, бегущий чат, бла-бла-бла, я отсматриваю код и грущу или радуюсь. Поэтому давайте поговорим про результаты. Что меня порадовало, что я подметил, что мне показалось классным. Они прямо сейчас на вашем экране. Как вы можете увидеть, GPT5 кодекс справился со всеми задачами рефакторинга, когда я прямо его об этом просил. Это действительно очень крутой результат, потому что предыдущие модели типа того же Sonet четвёртого довольно плохо справлялись, к примеру, с той же задачей абстракции над сокетами. Они, в принципе, вполне вывозили сделать какие-то обёртки, но эти абстракции почти всегда текли или обладали какими-то серьёзными проблемами. В случае GPT5 кодекса мне понравилось решение буквально каждой из задач. Когда я в дальнейшем буду говорить про санеты, вы увидите, что там на графике у меня есть жёлтые плиточки, когда я не определился до конца, понравилось ли мне это решение или нет. Формально оно работает, но там были какие-то изъяны. Здесь же GPT5 кодекс был довольно бескомпромиссным в том смысле, что либо задача была выполнена действительно очень клёво и мне нравилось, как это выглядит, либо мне вообще не понравилось решение или он не справился с ним совершенно.

Теперь про второй блок, где ему нужно было понять, что косяк в качестве кода есть. и, собственно, поправить этот косяк. И здесь всё, ну, уже чуть-чуть похуже. Если с первой задачкой про database драйвер он справился вполне хорошо, он заметил, что в абстрактном классе не должно присутствовать указаний на конкретную реализацию и прекрасно вычислил все эти места и исправил функции, то вот следующие две задачи для него стали проблемными. Он заметил, что система скейдлинга довольно монструозная и с ней тяжело работать. Он попытался предложить какой-то рефакторинг, связанный с тем, что он переделывал саму систему. Он не особо пытался использовать промизы. В какой-то момент он даже хотел пойти в notкрон и использовать его. Но в итоге после примерно пяти или шести попыток мне надоело. Я устал его подпинывать и конечного решения я не получил.

Следующая задачка - это то самое приложение STри. И это меня, честно говоря, удивило, потому что на мой вкус задача была не очень сложная. Он выделил то, что в проекте есть дублирование кода. К примеру, реализация Local Storage, которая у меня по-разному работала в браузере и в самом Тауре. Но тем не менее, несмотря на то, что сто он выделить смог, он не заметил ещё пять других мест с практически идентичным паттерном проблем. И когда я его немножко подпинывал, он вроде как что-то вывозил, но каждый раз это было так довольно вяло, каждый раз приходилось подпинывать. Реализацию подключения к тем же сокетам он сделал довольно плохо. Он не понял, что здесь можно выделить слой абстракции и использовать разные имплементации для браузера и для Тауре. Короче, мне показалось, что задача не была полностью решена.

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

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

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

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

Какие выводы можно сделать из этих результатов? Ну, можно банальный числовой 8 из двенадцати, что довольно неплохой результат. Следующий вывод, который бросается в глаза - это то, что когда я прямо просил GPT5 кодекс сделать рефакторинг, он делал его и делал его классно. Он полностью справлялся задачей. И по секрету, используя эту модель как повседневную модель уже почти полторы недели, он в целом клёво умеет делать рефакторинг. Он действительно как будто бы был получше натренирован на разных паттернах. И может быть кодрев, а связанный зачастую тоже с поиском каких-то дублирований и неидеальности в коде, тоже натренировал кодекс на то, как выглядит чистый, красивый, хороший код с хорошим проектированием. Поэтому в целом это очень клёвая модель для этих задач. Мне он этим прямо сильно нравится.

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

И что касается рефакторинга технического долга от искусственного интеллекта, ну, тут я уже высказался, что идентификация дублей во всей кодовой базе - это, в принципе, какая-то супер нетривиальная задача. У меня в голове нету готового алгоритма, как и мог бы это решать. Поэтому он с этим не справился, что довольно грустно. Это одна из самых популярных проблем того, какой технический долг создаёт. И, ну, что поделать, мы пока что ещё живём в реальности, где он не способен решить все проблемы, и с этим нам придётся мириться. Тот факт, что он не справился у меня с кейсом с Мидлвея, я думаю, это какая-то случайность. На самом деле, это была довольно простая задача. И в других похожих кейсах он справлялся с похожими ситуациями. Поэтому не знаю, что конкретно в этот момент пошло не так. Но для объективности результатов я решил, что раз уж мы считаем первый проход по каждой задачке, то и здесь мы засчитаем его первый проход с неудачей.

Главный финальный вывод, который мне бы здесь хотелось сделать, заключается в том, что эта модель по сути меняет мой пайплайн. Я практически сейчас для всех своих задач использую Pipeline Plan and Implement. Я про него, мне кажется, рассказал уже миллиард раз и показывал и даже скидывал Jсончики с ним. Но тем не менее я бегло покажу ещё раз на экране, что это такое. Это кейс, когда, э, при помощи workflow, это автоматический workflow, то есть он сам выполняется, когда я даю задачу. У меня задачка в начале проходит этап проектирования какой-то дорогой, умной, медленной моделью, после чего происходит этап реализации, когда дешёвая модель, собственно, просто пишет код, выполняет тесты, фиксит баги и так далее. И чего мне в этом пайплайне всегда не хватало, моя мечта была, чтобы он назывался Plan, Implement and Refactor, когда модель запланировала изменения, чуть более глупая и быстрая модель их внесла, и далее какая-то очередная умная модель, которая хорошо умеет рефакторить и следить за частотой кодовой базы, посмотрит на эти изменения и скажет: "Ага, здесь у нас технический долг, сейчас-ка мы его поправим". Мне кажется, что если такой пайплайн у меня заработает и он реально начнёт хорошо пифомить, то я решу где-то так 98% проблем, которые, в принципе, у меня возникают с разработкой с искусственным интеллектом. И это решит, мне кажется, подавляющее большинство технического долга, который и сам создаёт в кодовой базе. Поэтому я давно искал модель, которая будет клёво справляться с задачками по рефакторингу. И GPT5 кодекс выглядит как идеальный кандидат на эту роль.

Последние 2 дня я реально встроил её в своё workflow и начал использовать именно таким образом. Я могу даже показать примерно, как это выглядит. Это выглядит примерно так. Реализуй галерею изображений, которая будет показывать картинки пользователю. Собственно, что из себя представляет plan? Мы нажимаем на эту кнопочку, и мы видим, что что прот автоматически модифицировался. Research the code base and make a detailed implementation, бла-бла-бла. Собственно, он попёр делать research. Я сейчас его остановлю, чтобы мы просто увидели следующий степ. Автоматически сразу же запускается следующий запрос. Implement the plan above. А после чего пишется сам код и вносится всё изменения в кодовую базу. После чего я снова нажимаю стоп. Выполняется автоматически третий шаг, в котором происходит: "Проверь этот код на то, какие в нём, возможно, есть элементы технического долга, что здесь можно поправить и так далее, и так далее". И на этом шаге финально GPT5 кодекс тестирует изменения, которые произошли на предмет архитектурной частоты и фиксит какие-то проблемы, которые возникли. У меня пока что нет однозначно позитивного или негативного фидбека. Я вижу очень сильное улучшение на некоторых конкретных кейсах, когда GPT5 кодекс реально подмечал технически долг и исправлял его. С другой стороны, я видел несколько ситуаций, когда он немножечко борщил и выдумывал проблемы в коде, которые, на мой личный вкус, проблемами как таковыми и не являлись. Поэтому пока что я пытаюсь найти баланс. Ещё немножко играю с тем промтом, с которым вот как раз летит третий шаг этого workflow refactor, когда я приду к чему-нибудь конкретному, я думаю, я у себя в телеграмчике даже это пошарю, но пока что вот так. Кажется, что мы действительно видим модель, которая умеет делать очень хороший рефакторинг и умеет очень хорошо идентифицировать технический долг. И нам осталось только хорошо встроить её в наш процессы и радоваться жизни.

Что ж, на этом блок про GPT5 кодекс заканчивается, и давайте теперь поговорим про новую модель Sonet 4.5. Что ж, давайте теперь быстренько поговорим про Sonet 4.5. Времени с релизом модели прошло мало. Куча независимых BНЧ ещё пока что не выпущено, поэтому фактуры у нас не очень много, но я расскажу то, что было в официальном пресс-релизе, после чего мы глянем с вами на то, что, собственно, показали мои тесты. Мне кажется, тесты были релевантны, потому что в том числе в релизе упоминается, что модель стала сильно лучше в архитектурном дизайне, в дизайне систем и вообще в целом должна лучше уметь в проектирование и более чистый код.

Что ж, ну, во-первых, официальные цифры. Sve bench verified показывает, что модель в целом достигает 77.2%, что на пару процентных пункта выше, чем предыдущий результат. И это довольно клёво, учитывая, что Sonet - это повседневная модель. Это не какая-то продвинутая модель типа OPUS, она обычно используется для реализации каких-то несложных задач. Та самая часть, которая Impмен, модель, которая просто хорошо пишет код. И то, что она по качеству решения своей БНЧА уже превысила опус, это на самом деле весьма впечатляет. А то, что она по стоимости стоит столько же, сколько и предыдущий Sonнеet, и по сути является заменой предыдущему сонету, но при этом по качеству работы превосходит Опус 4.1, это впечатляет ещё больше. Поэтому кажется, что у нас случилась хоть и маленькая, но всё-таки революция в качестве работы моделек. Она также, если верить о своей бенчу, лучше, чем GPT5 GPT5 кодекс, что, я думаю, нам ещё предстоит проверить всякими независимыми тестами. Но тем не менее уже сейчас, как я уже сказал, раз у меня была развёрнута среда, я прогнал Sonet 4.5 на всех тех же самых тестах, которые прогонял, пока тестировал GPT 5 кодек. Давайте, собственно, посмотрим, что получилось у Sonet.

Она тоже справилась практически со всеми задачами из блока "Я прямо прошу модель отрефакторить код". Единственная проблема у неё возникла с последней задачкой, той самой, которая про execution-режим для моего персонального агента. А она что-то затупила, неправильно выделила паттерн. Она не поняла, что у агента есть режим работы, как oneшот запуск, когда он просто должен выполнить задачу, так и, скажем так, слушающий режим сервера, когда он включен и ожидает поступления команд, которые ему надо выполнять. Запуталась и сделала не до конца. Тем не менее, она хорошо выделила все блоки выполнения команд в абстрактные классы. Она хорошо разделила кодовую базу, но финальный результат я не готов зачистить как полностью готовый. И поэтому я поставил здесь полбалла.

Во втором блоке с человеческим техническим долгом она, в отличие от GPT5 кодекс, не справилась до конца задачкой выделения датас-драйвера и исправления текущей абстракции. Она исправила с погресом SQL, но почему-то не справилась с монгой. Попыталась несколько раз, сказала, что это невозможно, и оставила конкретный кусочек с монгой, как есть. То есть абстракция стала течь меньше, но всё ещё текла. Поэтому я тоже поставил полбалла. Непонятно, почему конкретно у неё не получилось. Вроде бы всё было примерно по похожему паттерну, но что круто, она полностью справилась с задачей исправления монструозного скедулинга, с которой вообще не справился GPT5 кодекс. Она догадалась, что здесь стоит использовать классические промезы. Она догадалась, как именно можно обернуть эти многоступенчатые задачки в промисчейны. И всё получилось в целом практически именно так, как я и хотел бы это видеть в своей собственной реализации. Поэтому здесь полный балл.

Далее, не очень хорошая реализация Таури. Она в целом выделила абстракции примерно так, как я это и хотел. Она в целом начала даже использовать что-то похожее на Pattern Behavior, но она это сделала примерно в трёх из пяти мест, где мне бы хотелось увидеть выделение однотипных участков кода в те самые абстракции с модулями, о которых я говорил. Тем не менее, этот результат сильно лучше, чем то, что было у GPT5 кодекс. Как мы помним, там я вообще не зачёл решение. Здесь я решил, что полбалла будет честно. Но грустная новость в том, что она совершенно не справилась с задачкой детерминированного конечного автомата, что в целом для меня ожидаемо. Я скорее больше поражён, что кодекс с этим справился, потому что задача так-то не самая простая. Я сам в своё время её решал, мне кажется, пару дней. Но она накосячила. Она совершила попыток, наверное, 20 запустить этот автомат, потестить, понять, в чём ошибка и так далее, и так далее. Она попыталась написать тесты, чтобы как-то более гранулярно проверить его кусочки. В конечном итоге, мне кажется, там на пятнадцатой минуте работы она уже сдалась и плюнула. И поэтому ноль баллов.

В последнем блоке точно такая же проблема с дублированием функций. Она не смогла идентифицировать, что у этой функции есть дубль в папке утилиты и её не нужно реализовывать заново. Как я уже говорил, это для меня понятное поведение. Я не до конца понимаю, как это будет исправлено. Просто буду молиться, что однажды модели научатся это исправлять самостоятельно. Но что меня порадовало, в отличие от GPT5 кодекса, она прекрасно справилась с той самой задачкой про Middleware. Она увидела, что Middleware совершенно однотипные в четырёх местах. И правда, единственное, я думал, что она сделает порождающую функцию. У нас там будет что-то типа функционального стиля. Она создала отдельный небольшой класс, который имел в себе забиндженный метод, который как раз реализовывал логику этого midleвея. Не совсем то, как я бы это сделал, но тем не менее решение правильное, работающее и в целом попадающее в общий стиль проекта. Поэтому я его тоже зачёл на один балл.

И если сравнивать количественно, то у Sonet получается 8, по баллов. Если мы считаем эти половинки, семь чистых баллов и три половинки, что на полбалла выше, чем мы получили у GPT5 кодекс, который как раз схвалился своей способностью рефакторить и писать чистый код. Что в целом меня радует, потому что Set вышел буквально сегодня. Это новая модель, и от новой модели ты всегда ждёшь, что она будет лучше всего, что уже есть на рынке. Кажется, в целом именно это мы и получили. Поэтому в дополнение ко всему предыдущему, что я сказал про то, что я хочу попытаться встроить кодекс в свой пайплайн как модель для рефакторинга и решения технического долга, возможно, я попробую точно также использовать и нововышедший Sonet. Вполне реально, что, учитывая текущие способности этой модели, она сможет справиться буквально со всеми тремя этапами: и с планированием изменений, и с их реализацией, и с последующей валидацией технического долга и исправлением каких-то косяков, которые были совершены до этого.

Сентябрь быдался какой-то невероятно удачный на очень сильные модели в разработке. Я радуюсь буквально каждую неделю и, честно говоря, я немного устал обновлять свой пайплайн, но тем не менее он реально становится лучше и лучше и всё больше и больше задачек у меня делает. И вообще без какого-либо бейбиситинга и без того, что мне даже надо за ним наблюдать. Всё больше и больше задач переходит в ту категорию, что когда я их даю и я точно знаю, что он справится и мне даже не надо будет перепроверять его работу, что лично меня очень сильно радует. Надеюсь и вас тоже. Спасибо большое за внимание. Подписывайтесь на всё, на что можно у меня подписаться. на Telegramканал, YouTube канал, какой-нибудь ещё канал, можете о Twitter. Можете подписаться на мой Twitter. Очень редко там пишу, но, блин, будет круто, если вы подпишитесь. Может, буду писать побольше. Спасибо вам большое и хорошего вечерочка. Угу.