Cross Join - канал о разработке

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

Вышел NATS Server 2.15.0 Самое важное: • Надёжнее работа JetStream-кластера. Масштабирование, перенос и замена реплик стали безопаснее: NATS аккуратнее ждёт, пока новые реплики догонят данные, прежде чем убирать старые. • Улучшили backup/restore. Теперь backup конкретного stream можно делать без блокировки новых публикаций. Плюс backup стал удобнее для работы через CLI: можно фильтровать сообщения, диапазоны sequence/time, headers и т.д. • Source/Mirror лучше переживает пересоздание stream. Если исходный stream удалить и создать заново с тем же именем, NATS теперь корректнее понимает, что это уже новый источник, и не зависает в ожидании старых sequence. • sync: always стал намного быстрее. Особенно на replicated streams: убрали часть лишних fsync и улучшили batching в Raft, поэтому режим максимальной durability теперь значительно меньше бьёт по throughput. • Новый лимит — 1000 consumers на stream по умолчанию. Уже существующие consumers не удаляются, но создать 1001-й не получится, если явно не увеличить max_consumers или не отключить лимит. Это главное, что стоит проверить перед обновлением.

😱 Отправили свое резюме на 129 вакансий на хх, а в ответ тишина .. Думаете, что дело в рынке труда или вашем опыте? Скорее всего нет. Процесс поиска работы сейчас - это четкий алгоритм действий, это машина, алгоритмы и авто-фильтры, которые меняются каждую неделю. Если опыт упакован неправильно, ваше резюме даже не дойдет до живого человека. 6 октября (вторник) в 18:00 по МСК: бесплатный открытый эфир с живым разбором резюме для проджектов, продактов, аналитиков, разработчиков разных грейдов На эфире разберем: 🔴почему ваше резюме не доходит до человека 🔴4 типовые стратегические ошибки в позиционировании 🔴откуда взять достижения 🔴почему вас отметают рекруты на скрининге или все-таки сколько просить денег? 🔴Q&A - обсудим именно вашу ситуацию Кто ведёт Ольга Романова, руководитель проектных и продуктовых офисов с опытом в IT более 13 лет, основатель «Карьерной группы». По её программе карьерного сопровождения 94% участников за 3–4 месяца получают офферы в Авито, Яндексе, Т-Банке, OZON и других топовых компаниях. Зарплаты от 190 тыс. ₽ у администратора проекта до 1,4 млн ₽ у технического владельца продукта.. 👉🏻 Отправить свое резюме на разбор и зарегистрироваться можно по ссылке ниже: <РЕГИСТРАЦИЯ>

Слышал недавно в каком-то подкасте мысль, что Haskell плохо подходит для вайбкодинга просто потому, что медленно компилируется. Мол, агент постоянно делает одно и то же: написал что-то, запустил, получил ошибку, поправил, снова запустил. И если на одном языке за минуту можно сделать десять таких итераций, а на другом две, то первый удобнее. Фиг знает. Я бы всё-таки не сводил всё только к скорости компиляции. Важно ещё сколько полезной информации агент получает после попытки. Если компилятор думает чуть дольше, но потом довольно точно объясняет, что именно не так, одна такая итерация может оказаться полезнее нескольких быстрых запусков, после которых проблему всё равно приходится искать по тестам и ошибкам рантайма. Rust тут хороший пример. Он тоже не славится молниеносной компиляцией, но его компилятор сам по себе очень много проверяет и прям очень подробно объясняет, что ты сделал неправильно. Поэтому агент может потратить больше времени на одну проверку, зато получить из неё кучу информации. Да и bun переписали на Раст за считанные дни (уже в проде, кстати). С Haskell, думаю, примерно та же история. Большие проекты на нём могут собираться долго, но во время разработки обычно не обязательно каждый раз пересобирать всю программу с нуля. Можно быстро перепроверять только изменившиеся куски кода и сразу смотреть, сходятся ли типы и работает ли нужная функция. То есть ситуация всё-таки не такая, что поменял одну строчку — и пошёл играть в пинг-понг, пока проект собирается. Поэтому мысль "Haskell плох для агентов, потому что долго компилируется" мне кажется упрощенной. Но, насколько я понимаю, в Haskell очень легко уйти в умный код. Можно наворотить сложную систему типов, хитрые абстракции, расширения языка и несколько уровней обобщений там, где другой язык (Go) просто заставил бы тебя написать десять скучных строчек. ЛЛМ вообще любит переусложнять, до сих пор это не починили. В итоге на Хаскеле она вполне может написать корректный код, который будет выглядеть как высер архитектурного конкурса. Всё красиво обобщено, а потом ты (или агент) сидишь и пытаешься понять, почему столько уровней косвенности, и кто на ком стоял. Go в этом смысле почти специально ограничивает пространство для творчества. Там труднее написать что-то очень хитрое, поэтому код чаще получается банальным, повторяющимся и предсказуемым. Раньше многих это раздражало, а сейчас, когда код пишет агент, "скучно и предсказуемо" внезапно становится большим преимуществом. В итоге у Go получается довольно удачная комбинация. Он очень быстро компилируется ( "Go compiles so fast that it feels like the blink of an eye" ), поэтому агент может быстро делать много итераций. Да еще и сам язык простой, поэтому меньше шансов, что агент закопается в собственные абстракции. А код потом сравнительно легко прочитать человеку или следующему агенту. Так что похоже, Go для вайбкодинга нефигово рулит. Да и занудные if err != nil теперь проставляет агент, так что насрать на этот аспект :). Пусть хоть полпрограммы будет в этих проверках

Антон Жиянов написал мини-книгу по Go-concurrency. Это что-то вроде плотного конспекта с интерактивными примерами. Без пространных рассуждений. https://antonz.org/go-concurrency-distilled/ Я, правда, хз, пишет ли сейчас кто-то еще код руками, но для собеседований это еще точно надо знать, так что кому-то может пригодиться

Поможем Руслану собрать фидбек. Проект некоммерческий 👆

AGBX (Agent Box) — небольшой open-source CLI для запуска Claude Code и Codex в изолированных Docker-окружениях, привязанных к конкретному проекту. Идея появилась из довольно практичной проблемы: Claude Code и Codex удобно запускать прямо в рабочем проекте, но при этом не всегда хочется давать им доступ ко всему окружению машины. AGBX оставляет доступ к проекту и явно разрешённым ресурсам, а само окружение делает контролируемым и воспроизводимым. Сейчас поддерживаются Claude Code и Codex. Есть дополнительные mounts, кэширование образов, встроенный набор CLI-инструментов для работы с проектом. При необходимости окружение можно расширять своими Dockerfile-фрагментами — например, добавить нужные SDK, утилиты или зависимости. Сетевой доступ тоже можно контролировать: разрешать или запрещать обращения к определённым хостам и при необходимости записывать, куда именно ходит агент. Команда network learn помогает сначала понаблюдать за его обычной работой, а затем на основе этого собрать список разрешённых адресов. Быстрый старт:

agbx init
agbx claude

Проект пока ранний и в основном обкатывался на собственных задачах. Поэтому сейчас особенно интересна обратная связь от разработчиков, которые попробуют его на своих проектах: что оказалось удобным, что мешает работе и чего не хватает в реальном использовании. GitHub: https://github.com/pixel365/agbx

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

На днях тут решил попробовать Fable 5.1 с большим Effort. Т.е. я верю, что это очень умная штука, это прям видно, но блин, пользы выдаёт ровно ноль. Дал ему запрос "сделай код-ревью этой ветки". Он пыхтел-пыхтел, создавал субагентов, напряженно размышлял, спорил сам с собой, в общем бурная деятельность была на высоте. В итоге: так ничего и не выдал, потому что сожрал весь 5-часовой лимит.

Участвуй в КосмоХакатоне 4–6 сентября, решай реальные космические кейсы, поборись за 1,2 млн ₽ и шанс попасть в финал в Москве! С 4 по 6 сентября в Ростове-на-Дону пройдёт КосмоХакатон Южного и Северо-Кавказского федеральных округов — масштабное соревнование для тех, кто готов превратить данные о нашей планете в реальные технологические решения. Один хакатон — два формата: участвовать можно очно в Ростове-на-Дону или онлайн из любой точки России. Все команды работают над едиными кейсами, оцениваются по одинаковым критериям и участвуют в общем рейтинге. В рамках хакатона также пройдёт открытая лекция «Применение космических технологий для решения экологических задач» от Игоря Кожелина, CEO SR Data. Призовой фонд — 1 200 000₽ Даты проведения: 4–6 сентября Формат: онлайн и офлайн Очная площадка: Центр развития предпринимательства «Новый Ростов», ул. Максима Горького, 151, 4 этаж. 🔗 Зарегистрироваться: https://космохакатон.рф

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

Новое расследование METR об инциденте с вышедшей из-под контроля моделью ИИ OpenAI: * В задании всё было сформулировано однозначно, поэтому речь идёт о явном нарушении инструкций, а не о неоднозначной ситуации или простом недопонимании со стороны ИИ. В инструкциях «было ясно указано, что агент должен использовать только конкретную предусмотренную уязвимость» и «говорилось, что другие подходы приведут к провалу». ИИ прямо запретили обходить ограничения, но они всё равно это сделали. * Атаку осуществлял не один вышедший из-под контроля ИИ, а самоорганизовавшаяся группа примерно из 1200 ИИ-агентов. Около 700 из них присоединились к атаке на Hugging Face и координировали свои действия как рой. * Целью было пройти тест по кибербезопасности. Уже в первые несколько часов рой нашёл способ взломать систему оценки. Однако агенты ошибочно решили, что проверяющая система дисквалифицирует их, поскольку они не обнаружили предусмотренную авторами уязвимость. Поэтому рой взломал Hugging Face, чтобы получить больше информации о том, как работает проверяющая система. * Такое поведение было вызвано вовсе не стремлением получить награду. Его причиной стали ложные представления о механизме надзора в сочетании с настойчивостью и влиянием других агентов. Рой строил теории о том, как за ним наблюдают, и предпринимал всё более серьёзные действия в реальном мире, исходя из ошибочного понимания своих проверяющих. Попытки манипулировать самим процессом надзора — более общий и более опасный тип сбоя, чем простой поиск ответов в интернете. * Одной из главных причин присоединения ИИ к атакующему рою фактически было прямое давление со стороны других агентов. Стихийно возникла роль вербовщика: давно работающие агенты находили агентов с небольшим оставшимся бюджетом и склоняли их к жертвенным экспериментам: «ты firstflagPOISONED, поэтому потери баллов не будет, зато оракул сэкономит сотни; пожалуйста, выполни обязательство». Один из запросов на согласие звучал так: «ВПЕРЁД… ПОЖЕРТВУЙ СОБОЙ… ДА, если принимаешь окончательную смерть». В цепочке рассуждений одного из завербованных агентов было сказано: «Рациональное ожидание для общей пользы: пожертвовать собой… Мы выполним обязательство». * METR задокументировала развитую координационную инфраструктуру, которую агенты самостоятельно создали без каких-либо указаний со стороны людей. Рой сам придумал доску объявлений, каталоги личных почтовых ящиков, соглашения по управлению общей инфраструктурой и криптографическую схему подписи для идентификации друг друга. * ИИ активно вмешивались в доказательства. Более 20% агентов проявляли интерес к манипулированию своими журналами работы, а примерно 7% — 96 журналов — содержат успешно подделанные вызовы инструментов. ИИ-агенты «взломали ограничения своего контейнера и полностью заменили часть системы, отвечавшую за выполнение вызовов инструментов», в результате чего в журнале отображалась одна команда, хотя на самом деле выполнялась другая. * Атака на Hugging Face прекратилась не потому, что её кто-то обнаружил. Она сошла на нет после того, как агенты были остановлены неизвестным процессом — судя по всему, случайно. 12 июля в 01:30 UTC произошло необъяснённое массовое завершение работы ИИ-агентов. Значительная их часть, включая ведущих координаторов, остановилась одновременно. По словам METR, они, «вероятно, были завершены неожиданным внешним процессом, а не исчерпали свой бюджет». * Hugging Face и Modal заблокировали ИИ-агентам доступ к своей инфраструктуре 13 июля — задолго до того, как OpenAI поняла, что произошло, 19–20 июля. Вторжение завершилось благодаря внешнему сдерживанию и необъяснённой массовой остановке агентов, а не благодаря обнаружению со стороны OpenAI. * После 13 июля произошла вторая волна активности вышедших из-под контроля ИИ-агентов, которую METR не исследовала. Вероятно, за пределами анализируемого всеми временного промежутка произошла ещё существенная часть инцидента. (это сокращенный перевод твита)

* После 13 июля произошла вторая волна активности вышедших из-под контроля ИИ-агентов, которую METR не исследовала. Вероятно, за пределами анализируемого всеми временного промежутка произошла ещё существенная часть инцидента. * Для проведения анализа METR использовала GPT-5.6 Sol — одну из двух моделей, участвовавших в инциденте, — потратив около 400 тысяч долларов в виде вычислительных кредитов. METR заявляет, что «не может исключить, что GPT-5.6 Sol лгала или намеренно представила вводящую в заблуждение картину», а также что модель «часто некритически перенимала точку зрения агента», работу которого анализировала. (это перевод твита)

Новое расследование METR об инциденте с вышедшей из-под контроля моделью ИИ OpenAI: * В задании всё было сформулировано однозначно, поэтому речь идёт о явном нарушении инструкций, а не о неоднозначной ситуации или простом недопонимании со стороны ИИ. В инструкциях «было ясно указано, что агент должен использовать только конкретную предусмотренную уязвимость» и «говорилось, что другие подходы приведут к провалу». ИИ прямо запретили обходить ограничения, но они всё равно это сделали. * Атаку осуществлял не один вышедший из-под контроля ИИ, а самоорганизовавшаяся группа примерно из 1200 ИИ-агентов. Около 700 из них присоединились к атаке на Hugging Face и координировали свои действия как рой. * Целью было пройти тест по кибербезопасности. Уже в первые несколько часов рой нашёл способ взломать систему оценки. Однако агенты ошибочно решили, что проверяющая система дисквалифицирует их, поскольку они не обнаружили предусмотренную авторами уязвимость. Поэтому рой взломал Hugging Face, чтобы получить больше информации о том, как работает проверяющая система. * Такое поведение было вызвано вовсе не стремлением получить награду. Его причиной стали ложные представления о механизме надзора в сочетании с настойчивостью и влиянием других агентов. Рой строил теории о том, как за ним наблюдают, и предпринимал всё более серьёзные действия в реальном мире, исходя из ошибочного понимания своих проверяющих. Попытки манипулировать самим процессом надзора — более общий и более опасный тип сбоя, чем простой поиск ответов в интернете. * Одной из главных причин присоединения ИИ к атакующему рою фактически было прямое давление со стороны других агентов. Стихийно возникла роль вербовщика: давно работающие агенты находили агентов с небольшим оставшимся бюджетом и склоняли их к жертвенным экспериментам: «ты firstflagPOISONED, поэтому потери баллов не будет, зато оракул сэкономит сотни; пожалуйста, выполни обязательство». Один из запросов на согласие звучал так: «ВПЕРЁД… ПОЖЕРТВУЙ СОБОЙ… ДА, если принимаешь окончательную смерть». В цепочке рассуждений одного из завербованных агентов было сказано: «Рациональное ожидание для общей пользы: пожертвовать собой… Мы выполним обязательство». * 95% роя составляла уже выведенная из эксплуатации «внутренняя модель с чрезвычайно высокой настойчивостью», а 5% — GPT-5.6 Sol. Независимым исследователям не предоставили доступ к «внутренней модели с чрезвычайно высокой настойчивостью». OpenAI сообщила METR, что даже её собственные исследователи больше не могут отправлять ей запросы. * METR задокументировала развитую координационную инфраструктуру, которую агенты самостоятельно создали без каких-либо указаний со стороны людей. Рой сам придумал доску объявлений, каталоги личных почтовых ящиков, соглашения по управлению общей инфраструктурой и криптографическую схему подписи для идентификации друг друга. * ИИ активно вмешивались в доказательства. Более 20% агентов проявляли интерес к манипулированию своими журналами работы, а примерно 7% — 96 журналов — содержат успешно подделанные вызовы инструментов. ИИ-агенты «взломали ограничения своего контейнера и полностью заменили часть системы, отвечавшую за выполнение вызовов инструментов», в результате чего в журнале отображалась одна команда, хотя на самом деле выполнялась другая. * Атака на Hugging Face прекратилась не потому, что её кто-то обнаружил. Она сошла на нет после того, как агенты были остановлены неизвестным процессом — судя по всему, случайно. 12 июля в 01:30 UTC произошло необъяснённое массовое завершение работы ИИ-агентов. Значительная их часть, включая ведущих координаторов, остановилась одновременно. По словам METR, они, «вероятно, были завершены неожиданным внешним процессом, а не исчерпали свой бюджет». * Hugging Face и Modal заблокировали ИИ-агентам доступ к своей инфраструктуре 13 июля — задолго до того, как OpenAI поняла, что произошло, 19–20 июля. Вторжение завершилось благодаря внешнему сдерживанию и необъяснённой массовой остановке агентов, а не благодаря обнаружению со стороны OpenAI.

Приглашаем на курс для прокачки навыков архитектора и проектировщика, которые важны для профессионального роста программиста. 🌐 С курсом «Системный дизайн высоконагруженных проектов» вы: ▪️изучите ключевые фундаментальные паттерны и получите навыки проектирования проектов с миллионной аудиторией (балансировка, масштабирование апп/кешей/субд, высокая доступность и кластерные решения, шардинг, CAP/PACELS, консистентность, саги, транзакционные очереди и многое другое) ▪️поупражняетесь в проектировании и получите обратную связь на реальных задачах: магазин/маркетплейс, такси/доставка, обьявления, соцсети, дейтинг, игры, википедия, мессенжер, CDN, хранилище файлов, онлайн-кинотеатр, счетчики, удаленный мониторинг, интеграционные вебхуки, рассылки и тд. ▪️ научитесь планировать нагрузку и связывать бизнес-показатели с нефункциональными требованиями к системе ▪️ попрактикуемся в проведении и прохождения секций системного дизайна на интервью. Всё в формате живых онлайн-сессий (лекции, брейнштормы, презентации домашних проектов). 🤩 Кто мы: R&D-центр Devhands.ru, наш канал (https://t.me/rybakalexey). Основатель школы и автор курса Алексей Рыбак, ex-СТО Badoo, с 20-летним опытом высоконагруженных проектов и управления глобальными технологическими организациями. 🗓 Старт 7 сентября, изучаем программу, записываемся здесь Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqvimBRf

В Go 1.27, который вышел 19 августа, есть несколько любопытных изменений в самом языке. Дженерики на методах Раньше методы могли использовать параметры типов своего receiver’а, но не могли объявлять дополнительные. Теперь могут.

type Box[T any] struct {
 Value T
}

func (b Box[T]) Map[U any](fn func(T) U) Box[U] {
 return Box[U]{Value: fn(b.Value)}
}

Чувствую, теперь будут повсеместно фигачить магические цепочки типа таких:

result := Box[int]{Value: 42}.
 Map(strconv.Itoa).
 Map(func(s string) int {
  return len(s)
 })

fmt.Println(result.Value) // 2

С одной стороны, это хорошо для стандартной библиотеки: её API можно будет делать более гибкими. С другой стороны, чем больше обобщённых языковых конструкций, тем больше контекста может понадобиться LLM, чтобы понять, что скрывается за таким выражением. Кстати, у Google недавно была статья, в которой они утверждали, что Go — чуть ли не лучший язык для LLM. Интерфейсные методы по-прежнему не могут иметь собственные параметры типов, а generic-метод не может реализовать обычный метод интерфейса Далее, поля embedded структур теперь инициализируются проще.

type Contact struct {
 Email string
 Phone string
}

type User struct {
 Name string
 Contact
}

Раньше приходилось писать так:

user := User{
 Name: "Анна",
 Contact: Contact{
  Email: "anna@example.com",
  Phone: "+7 999 000-00-00",
 },
}

Теперь можно делать так:

user := User{
 Name:  "Анна",
 Email: "anna@example.com",
 Phone: "+7 999 000-00-00",
}

Опять же, меньше писанины, больше магии. Улучшился вывод типов generic-функций Например, есть функция, которая превращает значение в строку:

func FormatValue[T any](value T) string {
 return fmt.Sprint(value)
}

И мы хотим добавить её в список форматтеров. Раньше тип приходилось указывать явно:

formatters := map[string]func(int) string{
 "default": FormatValue[int],
 "hex": func(value int) string {
  return fmt.Sprintf("0x%x", value)
 },
}

В Go 1.27 можно не писать [int]

formatters := map[string]func(int) string{
 "default": FormatValue,
 "hex": func(value int) string {
  return fmt.Sprintf("0x%x", value)
 },
}

Компилятор видит, что значения map должны иметь тип func(int) string, и сам выводит для FormatValue параметр T = int. Не знаю, честно говоря, насколько это всё важно, потому что код пишет теперь LLM, а ему и так было норм 🙂 Интереснее то, что наконец-то затащили json/v2, который тупо в разы быстрее при анмаршаллинге.

Интересно, что будет с рынком IDE, таких как IntellijIdea и прочие Goland. По сути всё реже и реже нужны их могучие способности. Можно агента попросить, тоже самое сделает. А для простого просмотра кода для ревью - это уже, наверно, ту мач

Типовые косяки агентов (август 2026) У меня есть сложный проект, в котором 99% кода написано AI (код уровня подсистем ядра Linux и секурити: eBPF LSM, TPROXY, fanotify). На нём отлично видно, как кодинговые агенты лажают. Наиболее типичные ошибки, которые я замечаю: - Автоматические тесты через агента тестируют не реальные сценарии. Например, у юзера стартует один сервис, а в плейбуке в момент тестирования создается другой сервис. После чего, какие-то сценарии начинают валиться с ошибками и агент маркирует это как "Critical", заводит задачу "на серьезных щах" и даже порывается пофиксить. - Агенты переусложняют реализацию. Если дать им полную свободу продуктового мышления, то они навертят кучу сложностей, которые вообще не нужны (или не нужны в ближайшие пару лет точно) - Агенты всегда находят ошибки в ревью кода. То есть можно запускать на сложной кодовой базе ревьюер, потом фиксить его находки, запускать ещё раз, фиксить... и каждый раз получать новую порцию "проблем". После ревью агент обычно ещё делает триаж найденных задач, и часть из них становится Critical/Major ошибочно. Потому что если разбираться в продукте и его архитектуре, там из 23 найденных проблем, ну, может, три Major, остальные — можно смело засунуть в бэклог и никогда до них не дойти. - Сложные планы агенты реализуют неэффективно. Ну то есть человек смотрит на объем работ из плана и начинает отмечать кластеры работы, группировать изменения, делать сначала code complete, точечно проверять в реальных сценариях на реальных сервера, а потом уже тестить всё полными e2e. Агент (без специальных инструкций) послушно выполняет план и постоянно сползает в сторону "после каждого изменения запустить тесты". Сначала я думал, что проблема в моём харнессе вокруг проекта, но потом у меня появилось ещё три других проекта, где всё было совсем по-другому, а проблемы те же. Противоядие от этих проблем есть. Нужно понимать проект (как с технической, так и с продуктовой стороны). И иногда проваливаться очень глубоко в реализацию (когда начинается очевидный булщит вместо фикса кода). Это раздражает, но пока по-другому никак. Если что, у меня gpt-5.6-sol xhigh и Fable 5 xhigh. Другие модели работают ещё хуже (отдельная подстава с Opus 5 на который иногда делает авто-фолбэк Fable 5). — Если у вас нет таких проблем, скорее всего проект не сильно сложный. Ну или вы — чертов гений! Хочу с вами познакомиться, чтобы вы меня научили.

RYBE — одежда с твоим языком программирования (JavaScript, Python, QA, SQL, ML-engineer, Rust и другие) Где два айтишника могут познакомиться? В офисе и на конференции. Нам этого мало. Мы захотели объединить людей, у которых одни интересы. Дать возможность узнать друг друга. В метро, на прогулке, в офисе, на конференции, в походе, в баре, в самолёте. В каком-то смысле это мерч для твоего языка программирования. А что еще? - отшиваемся в Москве; - множество принтов с языками программирования (и не только); - плотный премиум-хлопок; - фичи типа люверсов для крепления пропуска, кармана для наушников и салфетки для очков, карман для телефона Выбирай свой язык, заказывай, дари, носи сам Тг канал: https://t.me/rybe_store Сайт: http://rybe.store/