«Нажал на кнопку — и готово! Уже открыл PR агент. Но пал соседний компонент — И править всё придется снова» За шуточными стихами вполне серьёзная проблема. Агенту легко написать код, но разбираться с последствиями его работы всё равно разработчику. А если система становится сложнее, каждая следующая фича обходится дороже — и людям, и самим агентам. Получается, писать код стало гораздо легче, а делать его простым по-прежнему трудно. Можно контролировать каждый шаг, а можно доверить агенту всё вплоть до выкладки в прод. Где-то между этими крайностями должен находиться разумный баланс. Обсудим, как его нащупать, если сложность систем трудно сравнивать, а возможности LLM постоянно меняются.

Три открытия последних дней: Paseo Среда для управления агентами на удалённой машине. Из ближайших аналогов – Orca, но у Paseo полноценное моб приложение. Перевёз работу по нескольким проектам на удалённый сервер, сделал агента-оркестратора, который может сам запускать сессии внутри Paseo, к которым я тоже могу подключаться при необходимости. При работе с сервера не грузишь локальный комп, а с агентами, которые ещё остались на нём, теперь могу оставлять его открытым и продолжать с телефона. В итоге получилось примерно то, что сделали для широкой публики сначала в Grok Bot, а потом в Dots – только с большей гибкостью и управляемостью, заточеное именно под мои задачи. Cloudcone Американский хостер. Собственно, там взял VPS-ку в дата-центре в Калифорнии по супер-ценам. При работе с него не нужны vpn, рисков блокировок меньше. Пинг прекрасный. Devin После блокировки аккаунта Claude (особенно обидно, что это произошло буквально через пару дней после списания очередной месячной подписки) решил больше с ним не париться и не регать новый. Остаётся верный Codex, Grok Heavy тоже взял в сентябре, но ещё искал запасные варианты. Сначала потыкался в китайцев – Minimax и GLM в целом неплохи для простых задач, но что-то серьёзное им не доверить, конечно. И тут наткнулся на Devin, разработчик которого в прошлом году купил давно забытый мной Windsurf, которым я пользовался на заре вайб-кодинга. У Devin тоже есть подписка с лимитами и внутри вообще все возможные модели, в том числе Anthropic, и собственная swe-2, которая по бенчам на равне с frontier моделями, но при этом полностью (!) бесплатная, по крайней мере пока. Собственный CLI агент тоже прекрасно встраивается в Paseo.

«Я всё ещё боюсь работать с ИИ» Агент написал фичу, тесты зелёные, на демо всё работает. Можно брать следующую задачу. Только код ещё надо понять, проверить и потом суметь объяснить тому, кто придёт после тебя. Особенно весело, если агент заодно помог залезть в область, в которой ты сам пока разбираешься примерно на уровне «ну вроде работает». Потом появляется второй агент, потому что первый что-то упустил. Коллега приносит PR и превращается в meat proxy между тобой и своей нейросеткой. Спеки генерируются быстрее, но их тоже нужно читать. А спустя несколько месяцев git blame показывает на коллегу, коллега — на Claude, и ты проходишь онбординг в проект, который сам же полгода разрабатывал. От агентов автор отказываться не собирается, но быстро написанный код — только одна часть работы. И чем сильнее становится ускорение, тем интереснее вопрос, на что на самом деле уходит выигранное время.

🤯 Нашёл, куда утекают лимиты Claude Code, и это касается всех, кто гоняет субагентов. По наводке из треда проверил свои логи и офигел. Основной чат Claude Code держит кэш контекста час, а субагенты-помощники — всего 5 минут!😱 Стоит помощнику постоять дольше пяти минут (ждёт мой ответ, долгие тесты или сборку), и следующий шаг заново записывает в кэш весь его контекст, сотни тысяч токенов, а такая запись примерно в 12 раз дороже обычного чтения из кэша!!!! У меня субагент на Opus, который пилит камеру в моей AI-DnD, за два дня записал в кэш 116,6 млн токенов и 159 раз перезаписал контекст целиком, по 200–900 тысяч токенов за раз. Похоже, именно это и съело недельный лимит Max 🫣 Решение официальное, есть в документации Claude Code: в settings.json добавить "subagentPromptCacheTtl": "1h", а если гоняете агентов через API-ключ, то CLAUDE_CODE_PROMPT_CACHE_TTL=1h. Запись в часовой кэш дороже, но полных перезаписей после каждой паузы больше нет. Проверил: кэш действительно пошёл с ephemeral_5m на ephemeral_1h. Чудес не ждите: у моего лейна это срежет примерно 20–25% расхода, потому что основное съедает раздутый до 900 тысяч токенов контекст, который читается на каждом шаге. Поэтому вторая мера: не вести одного агента сутками, а давать каждый шаг свежему агенту с коротким отчётом предыдущего 🔄 📄 Документация: https://code.claude.com/docs/en/prompt-caching P.S. Заодно для Opus 5.5 раскатили Fast mode: тумблер в меню модели или /fast в терминале. Та же модель и то же качество, только около 285 токенов/с, в 2–2,5 раза быстрее. Стоит вдвое дороже ($8 / $40 за миллион токенов), а на подписке в лимиты не входит и списывается только с usage credits ⚡️

Vim против всех: редактор, в который можно войти, но нельзя выйти Git открыл Vim. Ты пишешь exit — курсор куда-то прыгает. Пишешь quit — текст меняется. Пробуешь help — становится только хуже. И вот ты уже не закрываешь редактор, а случайно редактируешь сообщение коммита. Самое обидное, что Vim при этом не ошибается ни разу. Он честно делает ровно то, что ему сказали. Почему текстовый редактор вообще разговаривает с человеком настолько странным языком — отдельная история длиной почти в полвека. А потом случается совсем подозрительное. Люди, которые наконец освоились, тащат Vim в VS Code, JetBrains, браузеры и даже Emacs. И шутка «из Vim нельзя выйти» внезапно начинает звучать совсем иначе.

Часы Unix тикали от розетки: откуда взялся 1970 год и что сломается в 2038-м Первые Unix-часы считали время в шестидесятых долях секунды. Причина почти прекрасна: PDP-11 получал тики от переменного тока в американской розетке — 60 Гц. Правда, 32-битного счётчика при такой системе хватало примерно на 2,27 года. Потом единицы поменяли, точку отсчёта перенесли, а запас растянулся уже на десятилетия. До 19 января 2038 года: после последней нормальной секунды старый 32-битный счётчик перескочит из вторника прямиком в пятницу, 13 декабря 1901-го. Самое неприятное — это не проблема какого-то музейного Unix. Такой счётчик до сих пор может прятаться в коде, форматах данных, файловых системах и железе, которое вполне доживёт до 2038 года.

🖥 Задачка дня: «Я встану — вы ляжете» Дима решил складывать бесконечный ряд чисел до тех пор, пока не устанет. На вход программе подаются целые значения. Концом ввода служит слово Wasted — это значит, что Дима устал. Гарантируется, что кроме чисел и финального слова Wasted, никаких других слов во вводе не будет. Нужно обработать все числа до слова Wasted. Присылайте свои решения в комментарии — позже опубликуем разбор 👀 В прошлый раз мы решали задачу «Пары», предлагаем прочитать её разбор: Идея решения простая: сумма двух чисел нечётна только тогда, когда одно число чётное, а второе нечётное. Значит, весь набор можно разбить на такие пары только в одном случае: если количество чётных и нечётных чисел совпадает.

#include <bits/stdc++.h>

using namespace std;

int main() {
  int n;
  cin >> n;

  int even = 0, odd = 0;

  for (int i = 0; i < 2 * n; ++i) {
    int x;
    cin >> x;

    odd += x % 2;
    even += (x + 1) % 2;
  }

  if (even == odd) {
    cout << "Yes\n";
  } else {
    cout << "No\n";
  }
}

Собеседования на программиста в эпоху AI (пост для работодателей) Помните раньше была такая штука как собеседование по теории? Когда просто задают вопросы а-ля "как работает хеш таблица" или "а что там происходит при коллизиях"? Так вот, оказывается, такое и сейчас есть. Вообще, тема собеседований мне весьма не чужда, я даже когда-то готовил людей к прохождению этих самых собеседований, причем весьма успешно. Так вот, формат таких теоретических собеседований мне никогда не нравился. А теперь, в эпоху AI он и вовсе потерял какой бы то ни было смысл. Почему? Потому, что кандидату, в целом, ничего не стоит посадить рядом с собой какую-нибудь нейронку на церебрас + live модельку, которая будет слушать и выпуливать ответы даже на самые сложные вопросы быстрее, чем интервьюер закончит задавать вопрос. Более того, такие персональные агенты-помощники вот-вот вообще станут нормой (это если вдруг вы до сих пор относитесь к такому как к читерству). Собсна, при должно сноровке не сложно запромтить агента так, чтобы он вылавливал всевозможные уловки (а-ля чего это вы мне в третий раз одно и то же спрашиваете разными словами) и вообще вел себя как живой. Но как тогда? Есть радикальное мнение, что испытательный срок - это лучшее "собеседование", причем не 3-месячный, а куда более быстрый (сейчас с агентами, в принципе, за неделю-две уже можно делать выводы об адекватности кандидата). Ну ок, каждого же не будешь брать на платную испыталку - согласен. Что тогда? Мне очень нравятся два формата на собесах: 1. Обсуждение опыта: задач, которые кандидат решал ранее и особо запоминающихся проблем/граблей, которые возникали на этом пути (ок, такое и с нейронкой можно провернуть, но явно будет сильно сложнее сделать это органично). 2. И второй формат: вот удивитесь, но это лайв код ревью*. И это как раз тот формат, который не просто позволяет проверить знание той самой теории, но и понимание этой теории на практике. Ну, например, есть у вас тот самый блок вопросов про хеш-таблицы/dict (допустим, вы считаете понимание его строения важным), напишите в коде кейс с коллизией или кейс с overriden GetHashCode() => 0 и спрашивайте, что там в представленной портянке на 100 строк не так (спойлер: там все не так). Ну, или у вас есть странный вопрос про отличие Thread от Task - ну, бахните в коде `Thread.Start`с каким-нибудь async void и await'ом внутри и смотрите что на это кандидат скажет, ну и так далее - а если на ваш теоретический вопрос не получается придумать практический кейс тогда это хороший повод задуматься о целесообразности такого вопроса. Раньше подобные примеры портянок было не просто придумывать и я на РФ рынке встречал всего пару компаний, которые такие штуки делали. Сейчас же, как вы понимаете, такие задачки очень здорово можно нагенерить вместе с нейронкой - берете этот пост, описание вашей вакансии, описание компании и отправляете это все гпт 6 про с просьбой сгенерить такую портянку на часовое интервью. Ну ок, вы мне скажете, что мешает (сильной) нейронке поревьюить код и найти в нем все проблемы? То, что в любом ревью важен контекст, а контекст надо догадаться сначала уточнить и в зависимости от контекста важность той или иной проблемы будет отличаться (мы же помним как хорошо нейронки могут бесконечно находить проблемы). Проблемный код в этом случае выдается кандидату всей портянкой и в нем может быть как много проблем, так и наоборот практически не быть. Здесь еще важно отметить сам процесс - кандидат сразу побежал ошибки искать или сначала попытался понять а что вообще происходит и для чего. Ну и в целом, идеально когда вайб-кандидат не готов к такому формату и тогда его (обычно простой) live-агент просто будет хвататься за первую попавшуюся на экране проблему не вдаваясь особо в контекст и в ее важность. Короче, в таком сетапе обмануть систему становится сильно сложнее. * Речь, конечно, идет о кейсах, когда по классике нанимают конкретного специалиста на конкретный стэк, а не агентного инженера-агностика. А как у вас в компании поменялась механика собеседований? И спрашиваете ли еще в принципе про условное устройство хеш-таблиц или у вас уже AI-native полным ходом и все подкапотные детали - это что-то из разряда знаний ассемблера?) @ai_driven

От вайб-кодинга к AI-инжинирингу на примере простого агента #diy #ai Я в целом не особо силен во всяких кастомных обвязках и супер-навороченных практиках AI инжиниринга. Моя роль позволяет в целом быдлокодить делать прототипы, особо не считать токены и в целом обычно хватало просто спеки Spec.md и агента в виде чата. Так что я решил поиграться с чем-то более продуманным и заодно тут рассказать. Для примера взял скиллы Addy Osmani, чисто из-за предвзятости, это очень крутой чел, его суждениям я доверию (но в целом наверняка можно было взять и Superpowers либо скиллы Matt Pocock). Суть в том, что это не просто набор скиллов, а изменение всего подхода к agentic разработке. Что-то вроде Spec -> Plan -> Build -> Test -> Review -> Simplify -> Ship. Слишком томить не буду, дам наводку, а дальше LLM сама лучше расскажет-покажет. В последнее время я новые прикладные темы изучаю генерацией короткого мини-тьюториала в нашем либимом формате HTML. В данном случае я взял идею простенького агента-консультанта по путешествиям и попросил Gemini создать тьюториал о том, как разработать такого агента в стиле Addy Osmani: I've got a high-level idea of a travel assistant agent. Create an HTML course illustrating the development of such an agent with https://github.com/addyosmani/agent-skills and agents-cli, create sub-pages for each meaningful chapter (e.g. Spec -> Plan -> Build -> Test -> Review -> Simplify -> Ship), write code and make it copy-pastable so that I can follow the tutorial and go through the whole development process myself. Сначала gemini сам реализовал простенького агента, затем использовал это решение как референс для мини-курса. Далее мини-курс сам тебя ведет через все этапы разработки: 1) Определяем спеку, отвечаем на вопросы агента, что мы вообще хотим от продукта. Спека появляется не одна, а несколько – по одной на каждый компонент будущего решения /spec Build a travel concierge agent with Google ADK, scaffolded and evaluated with agent-cli. It must... <high-level idea pitch> После ответов на вопросы появится Spec.md и spec-*.md для компонентов. 2) Далее запускаем планирование /plan Use SPEC.md and the architecture we just agreed Появляются plan.md и конкретный todo.md со списком всех задач, acceptance criteria, плана проверки и файлов на выходе. Все в стиле TDD, то есть начиная с тестов. 3) Далее Build, либо вдумчиво по одной фиче из списка todo.md, либо сразу /build auto и почитывать, как он сам все по очереди реализует, тестирует и обновляет Todo. 4) И в конце финальные проверки и еще пара скиллов для упрощения кода. До Ship в данном случае не дошло 👨‍🦳 Что понравилось - так на выходе, конечно, решение куда более продуманное, с кучей тестов, покрытыми корнер-кейсами (например, а что если ты путешествуешь с мелким ребенком, наверное не надо советовать маршрут с прогулками дольше 10 минут). И документация получается сама собой, попутно с разработкой - далее улучшать решение тоже понятно как – спека уже лежит, фичи детально описаны, надо просто в том же формате добавлять новые фичи и следовать тому же процессу, что описан выше Ограничения - уходит больше времени и токенов, конечно. В моем случае 3 часа вместо 5 минут (хотя да, решение сильно более продуманное на выходе). - На эвалах может много токенов погореть. Да, агент сам помимает, где какие тесты нужны (юнит/интеграционные, а где LLM-as-a-Judge), но также из-за какой-то банальной мелочи типа несовпадающих сигнатур функций у tools может решить перезапустить весь LLM-as-a-Judge для какой-то фичи, а это и генерация синтетических данных, например, и эвал, то есть лекто минут 20 и 120 тыс токенов на один этап - Душновато получается, все же спеки, планы и todo – это много текста, который надо проверять. Для большого проекта на всю команду – да, можно даже продакта посадить, вместе отвечать на вопросы LLM. Но для мелких одноразовых вещей типа кастомного UI или демки навыброс я по-прежнему буду вайбкодить 😮‍💨

🥂Разбор Go 1.27 полностью дописан! Вы уже, наверно, забыли о том, что вышла новая версия языка, и что я пишу о ней статью.. 😩 В статье появились разделы про аллокации и рантайм, net/http, портируемый SIMD и go fix, а в самом конце чек-лист на случай, если после апгрейда у вас упал CI. А ещё я добавил в большинство запускаемых код-сниппетов, включая старые, переключатель версии, чтобы сравнить новое поведение с прежним (там, где это имеет смысл). Так ещё интересней щупать изменения. Если запутались в истории обновлений этого обзора, можете тыкнуть на дату обновления (в шапке статьи), там будет хронология важных правок. ---- 😩 Честно говоря, на эту статью я потратил неадекватно много времени. Релиз вышел 19 августа, а на дворе уже октябрь. Каждый раз, когда я брал в работу новый пункт из release notes, упирался в вопросу «а почему?». Например, авторы пишут, что мелкие аллокации подешевели «до 30%» на микробенчмарке и примерно на 1% в реальном коде. Откуда такой разрыв? Пришлось лезть в исходники рантайма и гонять разные бенчмарки на трёх машинах. Оказалось, что ускорение выключается, пока сборщик мусора помечает живые объекты. Чем больше программа аллоцирует, тем чаще работает сборщик и тем реже ей достаётся ускорение. А ещё мне хотелось, чтобы всё это читалось интересно и легко, даже сухие разборы бенчмарков. К примеру, я очень долго возился с графиками, пытаясь сделать их максимально понятными, наглядными и простыми. Но оно того стоило. В итоге, обзор релиза превратился в небольшой, но глубокий экскурс во внутрянку актуального Go — как аллокатор раскладывает объекты по спанам, когда запускается сборщик мусора, как были устроены таймеры до 1.23, зачем процессору векторные регистры и др. Так что, даже если сам релиз вам не особо интересен, статья — хороший повод углубить свои знания. Ну и на собеседовании про аллокатор будет что рассказать. Надеюсь, вам понравится! ———— Теперь напьюсь отдохну, и пойду дописывать обновлённую серию статей про Планировщик. Работы непочатый край.. ❤️ Если захотите поддержать мой труд, милости просим в наш закрытый клуб. Я сейчас занимаюсь контентом фуллтайм, и ничего не продаю, поэтому ваша поддержка очень важна.