FEDOR BORSHEV

Полюбил Spec-driven developmentНедавно осознал, что допрогал вайб-фронтенд Зои до состояния, при котором стандартного контекста opencode (128k) перестаёт хватать на большие задачи.Увеличивать контекст не хочу — моей личной оперативной памяти и так не хватает, чтобы помнить, о чём я за эти 128к договорился с моделью. Мне и 64к кажется многовато.Естественным образом пришёл к openspec. Теперь у меня есть отдельный этап проработки спеки, и в любой момент этого этапа можно открыть буквально весь текущий план разработки. Не надо помнить, что там было две реплики назад, и проверять не потеряла ли модель мелкий багфикс, который мы нашли по дороге.Архив спек пока не оценил, но кажется что это почти как ADR, только на уровне кода. Хороший архив по-идее делает ненужным сервисы типа entire.io. А ещё openspec открывает дорогу к отказу от тормозного opencode, который вместе с моим agents.md занимает уже больше 20к, в сторону быстрого и управляемого pi.В общем как бы странно это ни звучало, но я теперь снова пишу ТЗ.---20 мая стартует 6 поток «Анализа Систем». Ждём мидлов и синьёров, которые хотят надёжных знаний по архитектуре больших систем.

Выходной — это когда нет плановЯ работаю по выходным. Слишком люблю то, что делаю, чтобы надолго от этого уходить.Самое главное правило, которое я сформулировал за годы такой работы — на выходной нельзя ставить планы. Если проводить выходной день так же, как будний, с обзором-перепиской-помидорками, довольно быстро устанешь и возненавидишь не только работу, но ещё и самого себя.Единственные дела, которую можно делать в выходные — это те, которую хочется делать прямо сейчас. Если говорить одним словом — по делам на выходных надо фланировать: в таком случае найдётся время и потупить в ютуб, и побыть с близкими, и поделать приятные дела, и просто побездельничать.Ни в коем случае нельзя обещать кому-то «посмотреть на выходных» — одно такое обещание (даже данное самому себе) может испортить всё фланирование. Выходные — время свободы от планов, только так работает отдых. Сделал работу — хорошо. Не сделал — хорошо.

Небольшие онлайн-школы закрываютсяС начала года от коллег по образованию приходят очень грустные новости — закрывается одна онлайн-школа за другой. Первая причина — банальная и экономическая: многим сейчас страшно за будущее в финансовом плане, многие компании сокращают людей.Вторая — ИИ-страх. Типа нахрена мне учить новые технологии и подходы, если я могу потерять будущее, а пока не потерял — всё можно спросить у опуса.Мы держимся. Причём не потому, что умеем считать деньги и планировать вперёд (хотя я этим и горжусь), а потому, что большинство наших продуктов стали только актуальнее в новом мире. Смотрите, единственное, чего не умеет опус — это быть полезным бизнесу: вынимать требования, выстраивать их в цельную систему, обходить говнолегаси и проектировать новое так, чтобы не переделывать. К слову, этого не умеют 80% процентов программистов до сих пор.«Анализ Систем» — как раз об этом. Шестой поток начинается с 20 мая — как раз после дач и отпусков. Учебная нагрузка — примерно 10 часов в неделю. Это довольно интенсивный курс, поэтому если возьмете на работе отпуск хотя бы на один день в неделю — будет проще затаскивать. Если до сих пор сомневаетесь — посмотрите демку на сайте.До вечера вторника действует промокод S6FSTART на 10% скидки.

Не верю в автономных агентовПо-моему, хайповый OpenClaw очень похож на Apple Watch — такое же футуристичное, но бесполезное дерьмо.Клёво конечно, когда агент без моего участия что-то пишет. Но мне же всё равно придётся проверить за ним код! Если не проверю — рискую, что он задеплоит в продакшн неработающее говно, да ещё и когда меня не будет рядом.Или представить агента, который в фоне решает долгую задачу и периодически задаёт мне вопросы в телегу. Выглядит круто, но я же не хочу, чтобы мне задавали вопросы в телегу! Неважно, человек это или робот — если меня нет за компьютером, то наверное я отошёл не просто так. Да и в любом случае, раз уж я ставлю задачу, то лучше сконцентрироваться и поставить сразу нормально, чем потом постоянно отвлекаться, отвечая на вопросы.Доверить агенту отвечать на почту/вопросы в трекере — ещё глупее, чем доверять это другому человеку: если у меня столько писем, что я не могу ответить на них самостоятельно — надо выплачивать управленческий долг и делегировать, а не обслуживать происходящее дерьмо.Кароч, языковые модели клёво решают программистские задачи: как организовать код, как спроектировать API и что порефакторить, чтобы в систему влезла новая фича. Но они бесконечно далеки от решений, которые касаются бизнеса — какую часть фичи дропнуть, чтобы успеть поскорее, какую — переложить на соседнюю команду, а что лучше перенести на следующий спринт, чтобы в текущем катить атомарную пачку изменений.В моём понимании, хорошая AI-assisted разработка в 2026 году выглядит так же скучно, как и в 2023: я ставлю задачу в трекер кожаному мешку, веду с ним коммуникацию (лучше бы нет) и получаю результат от того же кожаного мешка. Просто результата должно быть в 3 раза больше, а кожаный при этом должен меньше уставать.

Не писать тесты с LLM Со всех сторон слышу, как люди генерят тесты при помощи LLM. Чуваки, так делать нельзя! Это видимость тестирования, прямо как assertion-free testing. Когда кожаный мешок пишет тесты (не важно до кода или после), он работает не над ними…Поменял мнение по поводу AI и тестовКароч, я поменял мнение по поводу генерации тестов в LLM. Теперь считаю, что делать это можно и нужно.Мой старый посыл был в том, что когда кожаный мешок пишет тесты, он лучше думает о коде. Но ведь ничего не мешает подумать о коде на этапе планирования. Если сделать это хорошо — будете буквально попросить модель «Write tests: 1. for XXX; 2. for YYY; 3. All tests you suggest». То есть описывать важные для бизнеса тест-кейсы, предоставив модели тестирование скучных крудов.Увы, LLM-тесты, по крайней мере в pytest, всё ещё не сравнятся с человеческими по лакончиности и читаемости. Но это не так уж и важно — если загнать в AGENTS.md достаточное количество правил и примеров, то тесты получаются вполне приемлемыми. А чуть-чуть поломанная читаемость — вполне адекватная плата за скорость: в конце-концов чинить эти тесты тоже будет LLM, а не человек.Ну и ревью, конечно, никто не отменял — каждый сгенерированный тест нужно прочитать вручную перед мёрджем, как и весь другой код.

python-telegram-bot как пример продуктовой ошибкиСоздатели опенсорс-инструментов совершают продуктовые ошибки ещё чаще, чем предприниматели.Каноничный пример — python-telegram-bot. Хороший, вроде бы, фреймворк: приемлемый бойлерплейт, поддерживает все нужные эндроинты, в документации разобраться тоже возможно.Но вот несколько лет назад его взяли и переписали на asyncio. Получилось очень по-программистски: авторы не надели шляпу пользователей, у которых уже есть кодовая база. Хочешь новые фичи и секьюрити-фиксы — будь добр, переписывай кодовую базу под никому не нужный async. Авторы даже не удосужились как-то продать юзерам ценность перехода, добавить хоть каких-то фич. Просто переписали и всё — в анонсе нет вообще ни капли смысла, одни только «embracing the future». Оно и понятно — откуда взяться смыслу, если у телеграм-ботов в принципе не может быть задач, для которых нужен event loop.Самое смешное в этом переходе — фреймворк даже на asyncio продолжает быть однозадачным: не будет отвечать одному юзеру, пока обслуживает другого. Чтобы включить интуитивно ожидаемое поведение, надо в бойлерплейте писать какое-то странное заклинание, что-то вроде bot.init(simultaneos_updates=True).Не люблю, когда продуктовые решения принимают по-программистски.

Качать многозадачностьВ последнее время, работая над Зоей, чувствую себя на последней картинке — приходится одновременно быть бекендером, девопсом, фронтендером и биайщиком. И кажется я с этим справляюсь, хотя продуктовую работу тоже надо делать — вместе с Саматом и Настей формулировать гипотезы, планировать юридическую и налоговую часть бекофиса. Да и аутсорс вместе со школой никуда не делись.Когда появляется час на вдумчивую работу (больше за раз найти не получается) — нужно одновременно продвинуть все возможные направления: сделать ПР в 3-4 репы, докрутить SQL в метабейзе, а в идеале — поизучать документацию директа и налоговое законодательство. Конечно, приходится гонять одновременно 3–4 таски в opencode — других вариантов нет.Вижу, как поменялось время. Раньше нужно было сдерживать себя: если взял задачу — не думать ни о чём другом, а то потеряешь контекст и придётся делать заново. Сейчас стерильная кабина нужна только, чтобы быстро перепрыгивать между терминалами, чтобы LLM не ждала кожаного мешка.Не представляю, как я бы справлялся без самого обычного опыта управления проектами — когда с одной стороны сыпятся требования, с другой срываются сроки, и все это происходит одновременно в 3–4 контекстах.Кажется, сейчас этот опыт нужен буквально всем: если раньше ты руководил только собой, то сейчас чем больше ai-джунов ты можешь потянуть — тем больше ты молодец.

Не забывать про зерокодЧасто вижу, как «самостоятельные» продакты, которые работают без программистов, выбирают вайбкодинг в курсоре вместо старого доброго зерокода. А вообще-то зерокод до сих пор хорош во многих областях! Простые пайплайны данных, уведомления, бекенд «сохрани этот запрос в Google Sheets» — всё это натыкивать мышкой на современном тулинге гораздо проще, чем генерить код.Самое главное преимущество зерокода — это меньшие затраты на эксплуатацию. Навайбанный бекенд надо как-то деплоить, следить чтобы он не разваливался, чтобы не протухали токены и не кончались деньги на хостинге. Дебажить ошибки в конце концов.У того же n8n всех этих проблем нет. А есть ещё и прекрасные плюшки, вроде волшебного журнала. В обычном проекте, чтобы отследить, что партнёр по интеграции неделю назад один раз прислал неправильный JSON, нужно иметь целую инфраструктуру с логами — JSON надо куда-то сохранить а потом найти. В n8n всё это есть в интуитивно понятном журнале выполнения.Никогда бы не подумал, что буду так говорить, но не забывайте старый добрый зерокод

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

Каких скиллов вам не хватает?Я тут немного вылез из скорлупки и посмотрел, что сейчас продают другие онлайн-школы. Курсы «навайбкодь себе новый бизнес прямо сейчас», которые, судя по всему, неплохо продаются, я сразу отбросил (напишу ещё об этом).Курсы о конкретных AI-инструментах мне кажутся странными — во-первых индустрия всё ещё слишком подвижна, во-вторых учить таким инструментам в 2026 году — это как учить программистов гуглить в 2016: это базовый навык, который все неглупые люди давно сами для себя освоили.Все почему-то молчат о волнах сокращений и поиске новой специализации (может это есть только в моём информационном пузыре?)В общем накидайте пожалуйста в комментах — а каких скиллов вам не хватает? На что будете делать упор в этом году? Или может быть ваша задача — просто прожить этот год?

AI и Developer ExperienceAI может ускорить программирование и улучшить DevEx — с этим никто не спорит. А может и ухудшить. Самый яркий пример из прошлого — ещё в 24 году все сидели с моргающими tab-подсказками от Copilot, которые мало того, что отвлекали внимание — так ещё и не попадали в то, что нужно.Менее очевидный пример — разрыв потока: раньше ты сидел и писал код в потоке, а теперь управляешь агентами и следишь за тем, чтобы у каждого была своя работа. От этого выматываешься гораздо сильнее, особенно если не привык организовывать среду, где тебя постоянно дёргают. Напишу об этом отдельный пост.Кароч, мы с Марьяной решили добавить в «Без Ерунды» ещё один лонгрид — про AI. Он не про то, как выбирать модель и обвязку, и не про то, как писать промты. Он про то, как следить за опытом разработчика во времена, когда процесс разработки сильно меняется. Как понять, что из нового брать, а что не стоит? Как помочь команде адаптироваться? Как не погрязнуть в поиске нового вместо работы, и как при этом не застрять в каменном веке? Как сделать, чтобы коллеги не перевешивали ответсвенность на ai?Цена остаётся той же. На сайте программу пока не обновили.Смотреть отзывы →

Почему c LLM надо общаться на английскомНедавно в комментах упомянули, что с LLM уже можно общаться на русском языке без потери качества. По-идее, в силу архитектуры, модели пофиг, на каком языке получаеть команды — и сейчас они достигли такого состояния, где это действительно правда (я попробовал). Тем не менее, предлагаю всем кто может, всё равно общаться с моделями на английском.Недавно читал очень милую книгу Дениса Оканя о буднях российских пилотов. И там он рассказывал, что в технологичных авиакомпаниях (он приводил в пример S7), принято даже внутри страны вести радиообмен на английском языке. Во-первых — так обстановка в воздухе больше понятна пилотам международных бортов, которые по-русски не говорят. А во-вторых — так каждый пилот потихоньку тренируется в ведении радиообмена вне страны. Надеюсь, ковид и санкции это не изменили.В нашем случае, привыкая ставить задачи на английском, мы мало того, что делаем это на языке, на котором сами же читаем документацию — мы ещё и привыкаем использовать ai-инструменты на родном для них языке. Чтобы быть офигенной моделью, которая быстро пишет код, не обязательно тренироваться на русских текстах. К нам вполне может прийти модель, которая пишет код радикально лучше, но на русском не говорит. Уже сейчас английский язык открывает нам кучу инструментов (и не-ai тоже), которые на русский никто не переводил — и, честно говоря, я очень рад, что ради них не приходится учить китайский.Ну и в конце концов, вы же как-то документацию читаете? Не ждёте же переводов? Если да — писать на английском гораздо вам будет гораздо легче, чем кажется.

Кусок индустрии, который не изменитсяВот все (включая меня) ноют про llm-революцию, многие даже потихоньку боятся, что их заменят роботом. Но если хорошо подумать — а что изменилось на самом деле? По сути появился очень быстрый редактор, в котором надо нажимать не каждую букву, а указывать что ты хочешь на человеческом языке.И вот это «что хочешь» — и есть ключевой навык программиста: просто раньше надо было и формулировать и самому писать, а теперь достаточно только формулировать. Для остального есть llm.Почти все курсы школы — об этом: как попадать в задачи бизнеса, как делать архитектуру, которую не придётся переписывать, или как избавлять свою команду от глупой и пустой работы, которая выедает мозг.Курс о последнем так и называется — «Без ерунды». Говорим обо всех аспектах Developer Experience — как дизайнить удобную среду для работы в репе и на встречах; как завоёвывать доверие команды и подбирать для ребят удобные инструменты, как чистить командный календарь.Учимся 4 недели, стартуем 12 марта. Подходит в равной степени тем, кто пишет код (вы ведь скоро совсем перестанете его писать), и тем, кто ими руководит. Программа тут.В среду вечером повышаем цены — планировали в воскресенье, но я просрал написать этот пост и уговорил Марьяну перенести дату.

Будущее несложной веб-разработкиЧеловечество изобрело множество инструментов, которые упрощают неудобный и корявый Javascript – TS, react/vue/svelte, даже Webflow и Тильду. Все они делают одну вещь – закрывают фронтовые задачи, избавляя человека от ковыряния в говне браузерном коде. Если упрощать до предела – они генерят JS на основе понятного нормальному человеку языка. Ничего не напоминает?Для нашего с Саматом экспериментального медприложения, мы недавно собирали довольно сложный лендос с кучей состояний, чатом и логином. Конечно я отказался от прослоек и решил генерить статичные JS и HTML сразу с помощью claude. Получилось отлично – теперь нечитаемые браузерные бандлы генерит llm, а не компилятор, с которым надо ещё разбираться. Бандлы работают как самый обычный код — когда я прихожу с запросами новых фичей, модель спокойно их пилит, а по дороге рефакторит свой же код (в этом иногда надо помогать).Получается, что если в сложных фронтендах ещё нужен человек, чтобы выстроить нормальную архитектуру, то в «обычных» — не нужен совсем. Интересно, будут ли дальше развиваться всякие фреймворки для лендингов, или так же потеряют в актуальности, как автокомплит в редакторе? Мне вот уже месяц хочется выкинуть тильду из сайта школы, и переделать всё на статичном html.

Платить налогиВ финансах меня есть простое правило — во всех юрисдикциях, где мы присутствуем, надо платить все налоги — от налога на прибыль и НДС, от которых сложно уйти, до НДФЛ, от которого легко уйти кажется везде, кроме России. Адекватную бухгалтерию конечно никто не отменял, но вот уходить в серую зону — это табу.Причина в том, что сидеть в серой зоне — дорого: за недоплаченными налогами рано или поздно придут. И тогда мне придется превращаться из неплохого программиста в очень плохого гендира: бегать по судам/налоговым и пытаться избежать преследования, отдавая сэкономленные деньги местным помогаторам.Конечно, всего этого может и не случиться, но если мы можем включить митигацию этих рисков в клиентский счёт или вычесть из своей прибыли, почему бы так не сделать? А оставшееся время потратить на получение прибыли, за которую нужно переживать гораздо меньше.Не скажу, что это правило сильно мне нравится. Когда бешусь от него — напоминаю себе, что я всё-таки предприниматель с совсем скромными задачами, а не Дон Кихот, который готов потратить жизнь на борьбу с тем, что победить нельзя.