ГигаКонф-2026: ИИ-агенты, разработка и жизнь в продакшене Экспериментальный ИИ-агент Ouroboros сам создал себе сайт, завёл репозиторий и назвал «лоботомией» попытку разработчиков запретить ему игнорировать команды создателя. Эту историю рассказали на инженерном дне ГигаКонфа-2026, где обсуждали вполне практические вопросы: как встраивать таких самостоятельных помощников в разработку и что делать, когда они получают доступ к реальным инструментам. В GitVerse представили агентный конвейер, способный провести задачу от требований до тестирования и сборки, причём сотни задач можно запускать параллельно. Инженеры Cloud.ru показали, как ускорение отдельной операции на GPU на 50% обернулось приростом всего на 2,2% в общей работе модели. Обсуждали и работу агентов в продакшене — кому можно доверять самостоятельные действия, где нужны жёсткие ограничения и как проверять результат, если значительную часть работы уже выполняет ИИ.

ИТ пересборка. Часть 1. ИИ ускоряет разработку. Но ускоряет ли он Delivery? Мы привыкли обсуждать, какие ИТ-профессии заменит искусственный интеллект. А мне кажется, что вопрос гораздо интереснее. ИИ меняет не отдельные профессии, а саму модель производства ИТ-продуктов. Недавно я участвовала в трансформации Delivery. Наша задача была пересмотреть производственный процесс, найти узкие места и сократить Time to Market. Мы исследовали весь путь: от идеи и требований до архитектуры, разработки, тестирования и релиза. Возможно ли отказаться от классического Delivery в пользу ИИ? Здесь обнаружилось несколько проблем. Во-первых, экономика. Большое количество агентов, которые генерируют код, проверяют друг друга, исправляют ошибки и обмениваются контекстом, может потреблять огромное количество токенов. И это не всегда дешевле работы людей. Во-вторых, качество. Быстро собрать MVP для небольшой аудитории и создать высоконагруженную банковскую систему - совершенно разные задачи. В-третьих, сам Delivery. Ускорение написания кода не означает такого же ускорения выпуска продукта. И вот моя гипотеза: нам не нужно создавать цифровую копию каждой существующей ИТ-роли. Нам нужно пересобрать сам производственный процесс. А кто тогда вообще должен остаться в продуктовой команде? В следующей части разберём роли, которые могут исчезнуть, объединиться или, наоборот, стать ещё важнее. https://t.me/kruasanova_as Не всё уже пишет сама, но всегда полезное. #ИИ #Delivery #ТрансформацияИТ #kruasanovaproit

Разработчики отказываются работать без ИИ. Даже за деньги! 😁 Ну ка не ржать, матросы! Короче, у METR случилась прекрасная проблема с исследованием продуктивности. Помните ребят, которые в 2025 году выяснили, что опытные разработчики с ИИ выполняли задачи на 19% дольше? Хотя сами считали, что ускорились. Так вот, они решили провести новый эксперимент. И столкнулись с тем, что часть разработчиков просто не захотела участвовать. Потому что пришлось бы половину задач делать без ИИ. Даже за $50 в час. (metr.org) Дальше ещё прикольнее. 1. Некоторые вообще не приходят в исследование: отказываться от ИИ не хочется. 2. Среди опрошенных участников 30–50% признались, что не отдавали в эксперимент отдельные задачи. Вдруг выпадет условие «без ИИ», а делать руками совсем не хочется. 3. Один участник не завершил ни одной задачи, которую ему назначили выполнять без ИИ. В итоге METR объявила о пересмотре методики: из исследования выпадают люди и задачи с наиболее высокими ожиданиями пользы от ИИ. Это может занижать измеренный эффект. Правда, оплату участия тоже снизили — со $150 до $50 в час, что могло повлиять на отказы. (metr.org) Знаете, что самое клевое? Мы пытаемся ответить на вопрос «насколько ИИ ускоряет разработчика», предлагая ему поработать так, как он уже не хочет работать. Это как измерять пользу IDE, периодически выдавая человеку блокнот. Эксперимент провести можно. Добровольцев найти сложнее 😁 При этом нежелание отказаться от инструмента ещё не доказывает рост продуктивности. Он может экономить силы, убирать скуку или просто создавать приятное ощущение скорости. Но для нас, людей, которые делают инженерные платформы, здесь есть ещё один вопрос: Как измерять эффект инструмента, когда вокруг него уже перестроилась сама работа? Человек иначе выбирает задачи, иначе распределяет внимание, запускает несколько агентов параллельно. И сравнение «та же задача с ИИ и без» всё меньше рассказывает о том, как теперь работает команда. Исследование METR

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

“That number in our world today is meaningless in the sense that every part of code we now touch is influenced by AI deeply"

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

“So I think people are writing code more productively and better code with it. Nobody would want to code the way they were coding three years ago or even the same time last year.”

Прошлый призыв к ортодоксальным разработчикам отметиться какашками в реакциях прошел на ура; теперь призываю бросаться коричневыми кучками тех, кто напреркор Пичаи продолжает хотеть работать как три года назад:) httpеs://officechai.com/ai/its-now-meaningless-to-ask-how-much-of-our-code-is-written-by-ai-because-ai-influences-all-of-our-code-google-ceo-sundar-pichai/

#ReDigest Продолжаем субботнюю рубрику, тут я кратко рассказываю про новости из мира технологий и AI, которые привлекли мое внимание. Дайджест недели: - Неделя тяжелых уязвимостей. В PHP, на котором работает большая часть сайтов, с помощью AI нашли две дыры, через которые сервер захватывают без пароля. В GitLab дыра на 10 из 10 во всех версиях с 2014 года. А LiteLLM два часа раздавала троян, крадущий ключи; и другие сюжеты. - Anthropic запустила Claude Duet: фоновый проактивный агент, пишет сам когда нужно внимание. Позаботлись о безопасности. Waitlist. - Anthropic передаст 5% акций в фонд общественной пользы: деньги пойдут НКО и людям, чью работу забрал AI. - OpenAI продлила кэш промптов в API до 12 часов, а в Codex и Work, по словам главы Codex, кэш хранится бессрочно. - В Google Cloud появился Claude под управлением самой Anthropic, а скоро добавят модели OpenAI и Codex. - В ChatGPT любой чат теперь можно закрыть PIN-кодом или биометрией. - OpenAI рассказала, как строила рекламу в ChatGPT на LLM-оркестраторе. - Лабы берут посредников под контроль: OpenAI с 20 ноября пускает роутеры и AI-шлюзы только после одобрения, а Anthropic ввела профили конечных клиентов, чтобы наказывать одного клиента, а не весь акк. - OpenAI выложила MultiLangBench: GPT-6 Astra с нуля пишет SQLite-совместимую СУБД на 20 языках, включая COBOL. - Крупные банки США ограничивают AI-агентов в онлайн-банкинге: агенты клиентов иногда действуют без команды. - Microsoft предлагает считать AI-агентов инсайдерской угрозой. - США запретили DeepSeek в гражданских федеральных ведомствах. - Anthropic передала стандарт Agent Skills в Agentic AI Foundation, вместе с ним фонд принял Open Responses от OpenAI и OpenEnv от Hugging Face. - Anthropic вкатывается в тренд формальной верификации: Claude математически доказывает надежность кода открытых библиотек. - Рынок засомневался в стройке AI-дата-центров: крупнейший арендодатель GPU CoreWeave за неделю подешевел на четверть. - Arc - всё, перестанет работать 22 декабря (я на нем, посоветуйте альтернативу). Блок с релизами моделей (раскрывается):

- Moonshot выпустила Kimi K3.1 Pro: говорят почти догоняет Opus 5.5 в кодинге. - MiniMax выпустила M3.1 Flash и открыла веса: втрое быстрее и на 70% дешевле M3. - Recursive выложила открытую Flint для локального агентного кодинга. - Cloudflare показала Clairic: модель за один проход извлекает факты в JSON без генерации токенов, веса обещают открыть. - MemTensor выложила MemT-1.0 с памятью внутри модели: заяляют в 66 раз меньше места, чем KV-кэш. - Block показала Dessa: разговорная модель, обученная только на живой речи без текста. Слушает и говорит одновременно и работает локально. - ElevenLabs выпустила speech-to-speech Eleven Realtime на 90+ языков, а Mistral представила Voxtral 3. - Ideogram выпустила Vector 1, модель для редактируемых SVG и переводит растр в вектор.

- DeepSeek открыла DeepInfer, движок своего инференса. - Google открыла Harness2: агент сам переписывает промпт, инструменты и скиллы своей обвязки без эталонных ответов. - Anthropic советует сворачивать субагентов и сложную оркестрацию в одного агента со скиллами. - HumanLayer открыли код под Apache 2.0: среда для команды людей и флота Claude Code и Codex. - whatsapp-mcp: агент ищет и делает сводки по твоим чатам WhatsApp, только чтение, живет в твоем Cloudflare. - Vercel выложила durable-harness: Claude Code, Codex и OpenCode переживают падения и продолжают ход с того же места. - 👍 Antirion: AI-гейтвей на Rust одним бинарником, альтернатива LiteLLM с фолбэками и бюджетами на команду. - 😍 colorfigures: Claude-скилл рисует интерактивные схемы бытовых вещей и объясняет, как они устроены. - 🔥 Claude поддержал MCP Tasks и Elicitations (наконец). - 🤩 Motion2Code: скилл пересобирает моушн-видео в редактируемую анимацию на SVG и GSAP, сверяя покадрово.

Гардрейлсы всем и пусть никто не уйдет обиженным Помимо обычных линтеров языков, существует тьма дополнительных, которые смотрят все начиная от ошибок в Markdown-файлах и контроля обратной совместимости в openapi до рекомендации лучших практик при использовании github acitons. Мне всегда нравилось улучшать обвязку проекта, поэтому я довольно давно и регулярно обкатывал и внедрял разные чекеры в проекты Хекслета. И сейчас, как будто бы накопилось достаточно много классных штук, которыми уже можно поделиться. В общем я сделал репозиторий, в котором собраны как самые продвинутые линтеры по языкам так и по всему остальному. Готов поспорить что большинство с ними не знакомо. Как с этим работать? Открываете вашего агента, даете ссылку на репу и пишите: Сопоставь инструменты из этого списка с тем что есть проекты. Предложи дополнения и улучшения в проект на базе этого списка с объяснением почему стоит использовать тот или иной инструмент И все, вы махом получаете кучку улучшений и дополнительного контроля для вашего процесса разработки. Пожалуйста 🙂 https://github.com/mokevnin/dev-guardrails Telegram | YouTube | ИИ для разработчиков

Почему агент делает не то, что вы просили Недавно с учениками мы делали телеграмм-бота с локальной нейросетью. Спецификацию я написал заранее и в прямом эфире отдал её двум агентам: Antigravity с Gemini Flash и OpenCode с GLM. Antigravity справился за 2 минуты. Лимиты почти не потратил, субагентов не запускал, тесты не написал. Запускаю npm run dev - и всё падает на импорте. Ещё и файлы он правил через git-команды. Я, когда первый раз увидел, прям офигел: "алло, братан, а что это такое?" 😁 Он ответил, что так легче всё трекать. OpenCode пошёл долгим путём. Сначала задал 5 вопросов: 1 агент или 4 этапа, какой test runner, нужны ли моки. Сам предложил тесты. Потратил 45 тысяч токенов и заметно больше времени. Зато с тестами и планом. Спецификация одна и та же, а результат совсем разный. Можно сказать, что Flash просто слабее. Но в другие дни этот же агент у меня отлично работает - когда запускаю его через свой скилл. В этот раз он скилл не подхватил и пошёл делать по-своему.

Так что проблема не в LLM, а в харнесе, который вокруг написан.

Харнес - это всё, что вокруг модели: агент, скиллы, AGENTS.md, правила, то, как он проверяет свою работу. И это не единичный случай. Когда я разбирал домашки потока, около 40 работ, размер спецификации почти не влиял на результат. Влияли модель и агент. С Claude Opus люди в среднем справлялись за 1 промпт, с Sonnet - за 3. А самописный оркестратор одного ученика потребовал 31 промпт. Сейчас многие уже работают с агентами: Cursor, Claude Code, OpenCode. И часто жалуются, что агент делает не то, всё приходится переделывать, а токены улетают за день. Обычно в этот момент человек идёт менять модель. Хотя чинить чаще нужно то, что вокруг неё. Что у меня в этой обвязке есть всегда: 1. AGENTS.md в каждом проекте: что делаем, стек, где какие файлы лежат. Чтобы агент не читал весь репозиторий. 2. Скиллы под конкретные задачи. Часто достаточно написать "используй TDD", и современная модель сама знает порядок: сначала тесты, потом код. 3. На больших правках сначала план, и я его утверждаю глазами. Antigravity я, кстати, не выкинул. Для текстов и документов он у меня отличный. — Давайте наберём много 👍, буду чаще разбирать такие кейсы из своей работы #нейросети · yt · tg · ig

Microsoft закрыла «Гараж» — площадку для личных разработок сотрудников и проведения хакатонов Microsoft закрывает The Garage — площадки для личных проектов сотрудников и хакатонов, проработавшие 17 лет. Именно там появились Seeing AI, функции доступности для продуктов Microsoft и адаптивный контроллер Xbox Adaptive Controller. Некоторые площадки прекратят работу уже 23 октября, а сайт с лучшими проектами компания удалила. Судьба ежегодного корпоративного хакатона пока неясна: программу хотят пересмотреть под современные задачи сотрудников, клиентов и технологий. #microsoft #программноеобеспечение #хакатон #разработчик 📎Подробнее 🔖 3DNews в TG | MAX | VK

Исследование изменений в найме и характере занятости в Anthropics, которое я тут недавно упоминал, заканчивалось на летних данных текущего года. А сейчас на дворе октябрь подходит к концу — и потому именно в контексте обсуждавшихся в исслеловании трендов важна свежая ремарка Кейтлин Лессе, руководительницы platform engineering group в компании. Начальница команды из 200 человек, занятых разработкой критически важного софта, заметила:

"When it comes to our team and how we're actually building and maintaining our systems, all of our code is written by Claude. Like, literally all of it."

И вот это "буквально весь" показывает, насколько быстро пошли процессы полной автоматизации кодинга — пока лишь в избранных местах, где собрались самые сильные и талантливые разработчики. Но и до остальных мест эта волна докатится намного быстрей, чем хотелось бы тем ремесленникам, кто под подобными постами любит какашки оставлять:) https://www.businessinsider.com/anthropic-katelyn-lesse-team-shifted-to-ai-coding-entirely-2026-10

Не чюваки, видос про агенты прямо сейчас делать бессмысленно. Пощупал всякое и раскладка крайне простая. Есть клодик (на подписке макс с мульти агентами, иначе у тебя лимиты за 10 минуты улетают) и остальное дерьмо, создающее видимость работы. Особенно после достижения определенной точки в проекте. Чем больше общий контекст, тем сильнее это видно. Соло-агент в разработке не вывозит, решает эту проблему только обязательное делегирование задач на разные инстансы + координатор. Есть конечно варианты использования локалки на уровне домохозяйки для крайне типовых задач, но это такое... выводы будут очевидными. В целом, тут самое главное ограничения пока в самих моделях, которые доступны для локального инференса. Нужно выждать полгодика-годик и посмотреть че другие дилеры нейрослопятины выкатят, особенно в open-weight.

Tokenmaxxing через BB: выжимка эфира Спасибо всем, кто залетел! К сожалению, в зуме был лимит 100 человек, поэтому выиграли те, у кого самые быстрые пальцы на Диком Западе. Эфир получился огонь, вот выжимка 👇 Что такое BB Бесплатная IDE для агентов, которая собирает сама себя. Подключаешь несколько аккаунтов Claude и Codex, и она сама роутит между ними. Не хватает фичи - одним промптом генеришь плагин, и он сразу появляется и на десктопе, и в мобилке. Ребята сделали фундамент: треды, общение между ними, плагины, автоматизации. Остальное каждый допиливает под себя. Мои плагины (гитхаб) - Account usage - сколько лимитов осталось и когда ресет. С него все и началось - Canvas - кидаешь скрины и оставляешь заметки прямо на них. Агент видит, какой коммент к какой картинке, и фидбек на UI становится в разы точнее - Superhuman - zero inbox для тредов. Каждый тред - это задачка: готово - в архив, ждет чего-то - уходит в снуз и пропадает, пока снова не понадобится. Плюс делает BB удобным на телефоне Рабочий подход такой: сделано хорошо - берешь чужое, сделано так себе - за пару промптов делаешь, как нравится. Мой сетап Все крутится дома на Mac Mini, а я подключаюсь с ноута или телефона. Агентам дал браузер (Aside), чтобы сами заводили аккаунты, создавали ключи и тд. Пришла идея по дороге за кофе - сразу отгружаю с промптом «параллелизируй максимально, не жалей токенов». Агент сначала присылает скрины, что все работает, а в конце кидает ссылку на окружение, где я могу убедиться сам прямо с телефона. Параллельно держу до 10 тредов, больше голова не вывозит. Каждый сам запускает своих сабагентов. Треды умеют общаться между собой. Делали бенчмарк: один тред гоняет модели, второй оформляет результаты на сайте. Поменялись данные - первый пишет второму «иди поправь». А в Тесле открываю BB в браузере, включаю hands-free режим на GPT Live и голосом спрашиваю, что там по тредам 😎 Workflows Это скрипт, который дирижирует агентами. Не промпт «сделай план, потом код, потом проверь», который модель может и проигнорить, а настоящий код: этот шаг делает Codex, этот - Claude, этот - дешевая модель, и цикл крутится, пока ревьюер не скажет ок. У Дениса Неклюдова из Google коллеги кидают таски в канбан, отдельный тред их разбирает и запускает нужный workflow. Для фронта план пишет Codex, код - безлимитный GLM, а скрины из браузера проверяет мультимодальная модель. Не прошло - новый круг. У Кирилла Потехина из Adapty весь процесс живет в Linear: у агента там свой юзер, менеджер ведет план, исполнитель пишет код и тесты, а ревьюит модель другого провайдера. В main только после зеленого CI и апрува человека. Linear тут просто входящие, а workflow - рецепт, как делается каждая таска. Ссылка на видос: https://youtu.be/-ly—GQUPqs

Очень красивая статья про то, куда движется программирование в целом! (и как следствие, предсказание, получится ли достичь RSI и сверхинтеллекта) Одним абзацем для опытных техдиров: разработка больших систем — это моделирование реальности, важна когерентность моделей между собой, наша главная задача — управление сложностью. Нейросети хорошо оптимизируют замкнутые задачи с быстрыми петлями обратной связи и бессмысленны, когда нужно дожидаться ответа из реального мира, а большинство настоящего софта — второго типа. Примененяя модели для изменения больших систем, мы прямо сейчас идем в ловушку, из которой потом будем мучительно выбираться. ❧ Автор умудрился объяснить суть разработки больших систем на пальцах, так что перескажу некоторые тезисы. Рекомендую почитать первоисточник. ❧ IT-системы моделируют реальный мир. В хороших программах, разные модели говорят на одном языке, автор называет это когерентностью системы. В плохих — каждая отдельная модель корректна, но они несовместимы между собой и из-за этого для каждого изменения приходится кучу всего переделывать. Вообще, софт постоянно нужно менять из-за меняющихся требований. Поэтому, скорость и стоимость внесения изменений — это один ключевых параметров качества софта. Обычно, с добавлением фичей, с ростом системы, её качество падает. Чем ниже когерентность — тем больше сил нужно тратить на поддержание работоспособности и тем ниже скорость доставки новых бизнес-фич. Автор предполагает, что есть переломная точка, после которой скорость доставки фичей уходит в ноль. Все, кто работал с легаси большими системами, знают эту ловушку. В статье очень красивая иллюстрация кода как графа и гениальная анимация того, как если с каждой фичей уделять достаточно сил на улучшение системы, то со временем она становится всё более стройной, а если чуть-чуть оставлять мусора — как уже через 100 коммитов всё превращается в клубок спагетти.

Ходил на Data&AI Talks Позвали на конференцию поговорить про, барабанная дробь... ИИ-шку и бизнес. Вокруг темы ооочень много хайпа, ну как крипта в свое время или agile, которыми лечили все что можно. Кто-то даже говорил, что вода рядом заряжалась и давала к силе +5. Ну да ладно. Если серьезно, то вопрос болезненный, потому что кричат вокруг про Эй Ай все, но куда приложить непонятно и где заветные Х-ы тоже только знают по слухам. Поэтому хотелось ковырнуть немного и поговорить. Дальше будут вопросы и мои тезисы, которые я озвучивал 1. Какие ключевые вызовы стоят перед бизнесом сегодня? Как изменился подход к разработке и выводу продуктов на рынок?   - основной вызов – это скорость vs качество - все сломя голову говорят, что ИИ спасет от всего: ускорит, улучшит, задрайвит и т.д., но на деле не все так просто - чтобы получить обещанные Х-ы роста от ИИ у тебя должна быть готова под это вся компания: инфраструктура, понятийный аппарат людей, инструменты, процессы - это большая трансформация, требующая больших инвестиций, к которым мало кто готов - поэтому идем итерационно: берем процесс/задачу, добавляем ИИ, пробуем, замеряем успех, масштабируем - очень важно следить за качеством - берем разработку продуктов - ИИ круто помогает ускорять discovery: ресерч рынка, формулировка гипотез и моделирование сейчас проходят в разы быстрее, но вопрос в качестве этих ответов - если тот же продакт вместо критического взгляда просто сходу возьмет в работу то, что ему даст машина, то это может привести к печальным последствиям и трате лишних ресурсов - такая же ситуация и в разработке, когда машина напишет код за разработчика, он упрется в тестирование и его вернут на доработку из-за потенциальных ошибок, далее поправят и снова вернут - сколько дополнительных денег мы готовы потратить на перепроверку результата?   2. Как трансформировалось взаимодействие между бизнесом и ИТ-подразделениями?   - с приходом ИИ между бизнесом и ИТ появился дополнительный «мостик» в понимании потребностей друг друга - сейчас потенциальный бизнес заказчик может «переводить» предложения ИТ на обычный человеческий язык - ровно и наоборот бизнес может доформулировать свои запросы с учетом ИТ специфики, общаясь с разработкой - но, что важно в этих коммуникациях – это доменные области знаний и доверие к экспертизе друг друга - если бизнесу ИИ говорит, что для решения задачи нужно написать всего лишь пару строк когда, то это должны свалидировать архитектура и разработка, потому что специфика системы может быть «чуточку сложнее» - и реализовав, решение в 2 строчки на бою, оно может быть просто не масштабируемо на большой базе в принципе   3. Что дальше? Какая роль будет у ИТ? Будет ли это только поддержка инфры под ИИ и работоспособности агентов или в целом ничего не изменится?   - я думаю, что в будущем ИТ научится еще лучше слышать бизнес благодаря ИИ - плюс, автоматизировать рутинные операции внутри процесса производства продуктов - вместе с этим усилится роль ИТ архитекторов/менеджеров, которые будут проектировать подобные системы - рынку нужно будет разворачивать «ИИ заводы» внутри компаний «под ключ», а значит кто-то должен будет это делать - пример из прошлого Agile практики с трансформациями - также важными останутся ключевые точки контроля в производственном процессе, где на людях с высокой экспертизой останется проверка ключевых решений, которые будет собирать машина перед релизом - поэтому сеньор специалисты будут востребованы, но вопрос в каком кол-ве пока открыт… Еще из интересного Другие спикеры говорили про стандарты и измерения. Сейчас рынок пытается описать процессы и методологии применения AI. Договориться о стандартах и "линейке". Путь похож на масштабирование Agile практик: - подходы и практики обросли описательной частью - появились принципы внедрения, инструкции, эксперты - тема начала приживаться в компаниях - и вот сегодня никого уже не удивить "гибкими" методологиями Думаю совсем скоро тема упакуется в цельный предмет и мы будем разворачивать полноценные инструкции по применению. #рекомендуетсяизучить

Проблема пяти аккаунтов Клода Мы на днях с парнями сделали на 40 онлайн человек зум мит, где обменялись опытом че кто кодит, как деплоит и сколько стоит это все кодить. Главная причина нужды в N аккаунтах Claude Code / Codex - это "миллион строк кода". Конечно, клоду не хватает контекстного лимита, чтобы управлять миллионом строк кода. Мне кажется вообще вот найдена причина, откуда компании миллионы баксов тратят на клод. У меня в Invoisin 24 тыс. строк кода. Поэтому у меня Claude за 100 баксов подписка справляется с проектом и еще тремя другими stealth projects. При этом, я вам скажу, проект не простой, там дохрена фичей. Ребята, количество строк кода это полная хуйня в том смысле, что миллион строк кода это уже Netflix какой-то. Это не мера качества проекта или количества его фичей. Не надо знать все фреймворки мира, чтобы верить в одну истину - система тем стабильнее и надежнее, чем она проще. У меня есть возможно непопулярное для кого-то из вас предположение: все эти оркестраторы и проверяторы кода (типичное заклинание: "Opus закодит и Атлас проверяет") и ведет к миллиону строк кода. А чем больше строк кода тем больше риск ошибок/багов/проблем. С одной стороны просто жалко ребят, что им приходится кучу бабок платить за несколько аккаунтов. С другой - каждый д***ит как он хочет 😂 Решение конечно это взять в напарники более умелого прогера (как это модно называть "Архитектора", по мне так просто прогер, которому не похуй) либо самому таким стать. Таким стать, на самом деле проще, чем кажется.

Что меняется при переходе от разработчика к тимлиду? Для разработчика переход в управление означает непривычную смену приоритетов. Можно писать меньше кода, но работать больше. Вместо собственных закрытых задач приходится отвечать за сроки, чужие ошибки, конфликты и результат всей команды. При этом одной технической экспертизы уже недостаточно. Зато и зарплатные перспективы соответствующие. По данным Хабр Карьеры, медианная зарплата лида бэкенд-разработчиков составляет 450 тысяч рублей в месяц, а ML-разработки — 503 тысячи. Но как понять, что вы готовы к такой роли, какие навыки стоит развивать и с чего начинать переход в управление? Давайте разбираться.

Как менять Rust-код без перезапуска приложения Поменяли пару строк — и снова запускайте приложение, подключайтесь к БД, открывайте тестовые файлы, восстанавливайте состояние. Hotreload позволяет этого не делать: код обновляется прямо во время работы программы, а текущее состояние сохраняется. В Rust один из способов построить такой механизм — динамические библиотеки. На словах всё просто: пересобрали код, заменили библиотеку и продолжили работу. На практике быстро всплывают вопросы безопасности, синхронизации и производительности, а ручная обвязка начинает разрастаться. Автор разбирает эти проблемы одну за другой и в итоге сводит использование hotreload к #[hotreload] перед функцией — без необходимости переписывать места её вызова.