Почему c LLM надо общаться на английском
Недавно в комментах упомянули, что с LLM уже можно общаться на русском языке без потери качества. По-идее, в силу архитектуры, модели пофиг, на каком языке получаеть команды — и сейчас они достигли такого состояния, где это действительно правда (я попробовал). Тем не менее, предлагаю всем кто может, всё равно общаться с моделями на английском.
Недавно читал очень милую книгу Дениса Оканя о буднях российских пилотов. И там он рассказывал, что в технологичных авиакомпаниях (он приводил в пример S7), принято даже внутри страны вести радиообмен на английском языке. Во-первых — так обстановка в воздухе больше понятна пилотам международных бортов, которые по-русски не говорят. А во-вторых — так каждый пилот потихоньку тренируется в ведении радиообмена вне страны. Надеюсь, ковид и санкции это не изменили.
В нашем случае, привыкая ставить задачи на английском, мы мало того, что делаем это на языке, на котором сами же читаем документацию — мы ещё и привыкаем использовать ai-инструменты на родном для них языке. Чтобы быть офигенной моделью, которая быстро пишет код, не обязательно тренироваться на русских текстах. К нам вполне может прийти модель, которая пишет код радикально лучше, но на русском не говорит. Уже сейчас английский язык открывает нам кучу инструментов (и не-ai тоже), которые на русский никто не переводил — и, честно говоря, я очень рад, что ради них не приходится учить китайский.
Ну и в конце концов, вы же как-то документацию читаете? Не ждёте же переводов? Если да — писать на английском гораздо вам будет гораздо легче, чем кажется.
Недавно в комментах упомянули, что с LLM уже можно общаться на русском языке без потери качества. По-идее, в силу архитектуры, модели пофиг, на каком языке получаеть команды — и сейчас они достигли такого состояния, где это действительно правда (я попробовал). Тем не менее, предлагаю всем кто может, всё равно общаться с моделями на английском.
Недавно читал очень милую книгу Дениса Оканя о буднях российских пилотов. И там он рассказывал, что в технологичных авиакомпаниях (он приводил в пример S7), принято даже внутри страны вести радиообмен на английском языке. Во-первых — так обстановка в воздухе больше понятна пилотам международных бортов, которые по-русски не говорят. А во-вторых — так каждый пилот потихоньку тренируется в ведении радиообмена вне страны. Надеюсь, ковид и санкции это не изменили.
В нашем случае, привыкая ставить задачи на английском, мы мало того, что делаем это на языке, на котором сами же читаем документацию — мы ещё и привыкаем использовать ai-инструменты на родном для них языке. Чтобы быть офигенной моделью, которая быстро пишет код, не обязательно тренироваться на русских текстах. К нам вполне может прийти модель, которая пишет код радикально лучше, но на русском не говорит. Уже сейчас английский язык открывает нам кучу инструментов (и не-ai тоже), которые на русский никто не переводил — и, честно говоря, я очень рад, что ради них не приходится учить китайский.
Ну и в конце концов, вы же как-то документацию читаете? Не ждёте же переводов? Если да — писать на английском гораздо вам будет гораздо легче, чем кажется.
4
AI и Developer Experience
AI может ускорить программирование и улучшить DevEx — с этим никто не спорит. А может и ухудшить. Самый яркий пример из прошлого — ещё в 24 году все сидели с моргающими tab-подсказками от Copilot, которые мало того, что отвлекали внимание — так ещё и не попадали в то, что нужно.
Менее очевидный пример — разрыв потока: раньше ты сидел и писал код в потоке, а теперь управляешь агентами и следишь за тем, чтобы у каждого была своя работа. От этого выматываешься гораздо сильнее, особенно если не привык организовывать среду, где тебя постоянно дёргают. Напишу об этом отдельный пост.
Кароч, мы с Марьяной решили добавить в «Без Ерунды» ещё один лонгрид — про AI. Он не про то, как выбирать модель и обвязку, и не про то, как писать промты. Он про то, как следить за опытом разработчика во времена, когда процесс разработки сильно меняется. Как понять, что из нового брать, а что не стоит? Как помочь команде адаптироваться? Как не погрязнуть в поиске нового вместо работы, и как при этом не застрять в каменном веке? Как сделать, чтобы коллеги не перевешивали ответсвенность на ai?
Цена остаётся той же. На сайте программу пока не обновили.
Смотреть отзывы →
AI может ускорить программирование и улучшить DevEx — с этим никто не спорит. А может и ухудшить. Самый яркий пример из прошлого — ещё в 24 году все сидели с моргающими tab-подсказками от Copilot, которые мало того, что отвлекали внимание — так ещё и не попадали в то, что нужно.
Менее очевидный пример — разрыв потока: раньше ты сидел и писал код в потоке, а теперь управляешь агентами и следишь за тем, чтобы у каждого была своя работа. От этого выматываешься гораздо сильнее, особенно если не привык организовывать среду, где тебя постоянно дёргают. Напишу об этом отдельный пост.
Кароч, мы с Марьяной решили добавить в «Без Ерунды» ещё один лонгрид — про AI. Он не про то, как выбирать модель и обвязку, и не про то, как писать промты. Он про то, как следить за опытом разработчика во времена, когда процесс разработки сильно меняется. Как понять, что из нового брать, а что не стоит? Как помочь команде адаптироваться? Как не погрязнуть в поиске нового вместо работы, и как при этом не застрять в каменном веке? Как сделать, чтобы коллеги не перевешивали ответсвенность на ai?
Цена остаётся той же. На сайте программу пока не обновили.
Смотреть отзывы →
Ваш проект умрёт не из-за разработки
Я всю профессиональную жизнь связан с разработкой. Видел много нормально запроганных, но мёртвых проектов, в которых создатель просрал продуктовую работу. Видел много успешно работающих проектов, где разработка была полным дерьмом даже без юниттестов — но создатель делал продуктовую работу на отлично, и проект, пусть и со страдающими программистами, но ехал вперёд.
И ни разу я не видел проекта, который не запустился из-за медленной разработки.
Конечно, в долине смерти много бизнесов, где код говно, а программисты нарушают обещания. Но причина их смерти — не в программистах, а всё в той же просранной продуктовой работе: нулевой product-market-fit, несходящаяся экономика, неумение нанимать людей и тестировать гипотезы. Плохой код — скорее следствие общих проблем, а не причина.
Когда пойдёте на следующий курс по вайб-кодингу, чтобы заменить своих программистов, вспомните пожалуйста меня — ваш проект умрёт не из-за программистов, не из-за бухгалтеров и не из-за поставщиков воды в офис. Он умрёт из-за вас.
Я всю профессиональную жизнь связан с разработкой. Видел много нормально запроганных, но мёртвых проектов, в которых создатель просрал продуктовую работу. Видел много успешно работающих проектов, где разработка была полным дерьмом даже без юниттестов — но создатель делал продуктовую работу на отлично, и проект, пусть и со страдающими программистами, но ехал вперёд.
И ни разу я не видел проекта, который не запустился из-за медленной разработки.
Конечно, в долине смерти много бизнесов, где код говно, а программисты нарушают обещания. Но причина их смерти — не в программистах, а всё в той же просранной продуктовой работе: нулевой product-market-fit, несходящаяся экономика, неумение нанимать людей и тестировать гипотезы. Плохой код — скорее следствие общих проблем, а не причина.
Когда пойдёте на следующий курс по вайб-кодингу, чтобы заменить своих программистов, вспомните пожалуйста меня — ваш проект умрёт не из-за программистов, не из-за бухгалтеров и не из-за поставщиков воды в офис. Он умрёт из-за вас.
Не забывать про зерокод
Часто вижу, как «самостоятельные» продакты, которые работают без программистов, выбирают вайбкодинг в курсоре вместо старого доброго зерокода. А вообще-то зерокод до сих пор хорош во многих областях! Простые пайплайны данных, уведомления, бекенд «сохрани этот запрос в Google Sheets» — всё это натыкивать мышкой на современном тулинге гораздо проще, чем генерить код.
Самое главное преимущество зерокода — это меньшие затраты на эксплуатацию. Навайбанный бекенд надо как-то деплоить, следить чтобы он не разваливался, чтобы не протухали токены и не кончались деньги на хостинге. Дебажить ошибки в конце концов.
У того же n8n всех этих проблем нет. А есть ещё и прекрасные плюшки, вроде волшебного журнала. В обычном проекте, чтобы отследить, что партнёр по интеграции неделю назад один раз прислал неправильный JSON, нужно иметь целую инфраструктуру с логами — JSON надо куда-то сохранить а потом найти. В n8n всё это есть в интуитивно понятном журнале выполнения.
Никогда бы не подумал, что буду так говорить, но не забывайте старый добрый зерокод
Часто вижу, как «самостоятельные» продакты, которые работают без программистов, выбирают вайбкодинг в курсоре вместо старого доброго зерокода. А вообще-то зерокод до сих пор хорош во многих областях! Простые пайплайны данных, уведомления, бекенд «сохрани этот запрос в Google Sheets» — всё это натыкивать мышкой на современном тулинге гораздо проще, чем генерить код.
Самое главное преимущество зерокода — это меньшие затраты на эксплуатацию. Навайбанный бекенд надо как-то деплоить, следить чтобы он не разваливался, чтобы не протухали токены и не кончались деньги на хостинге. Дебажить ошибки в конце концов.
У того же n8n всех этих проблем нет. А есть ещё и прекрасные плюшки, вроде волшебного журнала. В обычном проекте, чтобы отследить, что партнёр по интеграции неделю назад один раз прислал неправильный JSON, нужно иметь целую инфраструктуру с логами — JSON надо куда-то сохранить а потом найти. В n8n всё это есть в интуитивно понятном журнале выполнения.
Никогда бы не подумал, что буду так говорить, но не забывайте старый добрый зерокод
7
Качать многозадачность
В последнее время, работая над Зоей, чувствую себя на последней картинке — приходится одновременно быть бекендером, девопсом, фронтендером и биайщиком. И кажется я с этим справляюсь, хотя продуктовую работу тоже надо делать — вместе с Саматом и Настей формулировать гипотезы, планировать юридическую и налоговую часть бекофиса. Да и аутсорс вместе со школой никуда не делись.
Когда появляется час на вдумчивую работу (больше за раз найти не получается) — нужно одновременно продвинуть все возможные направления: сделать ПР в 3-4 репы, докрутить SQL в метабейзе, а в идеале — поизучать документацию директа и налоговое законодательство. Конечно, приходится гонять одновременно 3–4 таски в opencode — других вариантов нет.
Вижу, как поменялось время. Раньше нужно было сдерживать себя: если взял задачу — не думать ни о чём другом, а то потеряешь контекст и придётся делать заново. Сейчас стерильная кабина нужна только, чтобы быстро перепрыгивать между терминалами, чтобы LLM не ждала кожаного мешка.
Не представляю, как я бы справлялся без самого обычного опыта управления проектами — когда с одной стороны сыпятся требования, с другой срываются сроки, и все это происходит одновременно в 3–4 контекстах.
Кажется, сейчас этот опыт нужен буквально всем: если раньше ты руководил только собой, то сейчас чем больше ai-джунов ты можешь потянуть — тем больше ты молодец.
В последнее время, работая над Зоей, чувствую себя на последней картинке — приходится одновременно быть бекендером, девопсом, фронтендером и биайщиком. И кажется я с этим справляюсь, хотя продуктовую работу тоже надо делать — вместе с Саматом и Настей формулировать гипотезы, планировать юридическую и налоговую часть бекофиса. Да и аутсорс вместе со школой никуда не делись.
Когда появляется час на вдумчивую работу (больше за раз найти не получается) — нужно одновременно продвинуть все возможные направления: сделать ПР в 3-4 репы, докрутить SQL в метабейзе, а в идеале — поизучать документацию директа и налоговое законодательство. Конечно, приходится гонять одновременно 3–4 таски в opencode — других вариантов нет.
Вижу, как поменялось время. Раньше нужно было сдерживать себя: если взял задачу — не думать ни о чём другом, а то потеряешь контекст и придётся делать заново. Сейчас стерильная кабина нужна только, чтобы быстро перепрыгивать между терминалами, чтобы LLM не ждала кожаного мешка.
Не представляю, как я бы справлялся без самого обычного опыта управления проектами — когда с одной стороны сыпятся требования, с другой срываются сроки, и все это происходит одновременно в 3–4 контекстах.
Кажется, сейчас этот опыт нужен буквально всем: если раньше ты руководил только собой, то сейчас чем больше ai-джунов ты можешь потянуть — тем больше ты молодец.
6
python-telegram-bot как пример продуктовой ошибки
Создатели опенсорс-инструментов совершают продуктовые ошибки ещё чаще, чем предприниматели.
Каноничный пример — python-telegram-bot. Хороший, вроде бы, фреймворк: приемлемый бойлерплейт, поддерживает все нужные эндроинты, в документации разобраться тоже возможно.
Но вот несколько лет назад его взяли и переписали на asyncio. Получилось очень по-программистски: авторы не надели шляпу пользователей, у которых уже есть кодовая база. Хочешь новые фичи и секьюрити-фиксы — будь добр, переписывай кодовую базу под никому не нужный async. Авторы даже не удосужились как-то продать юзерам ценность перехода, добавить хоть каких-то фич. Просто переписали и всё — в анонсе нет вообще ни капли смысла, одни только «embracing the future». Оно и понятно — откуда взяться смыслу, если у телеграм-ботов в принципе не может быть задач, для которых нужен event loop.
Самое смешное в этом переходе — фреймворк даже на asyncio продолжает быть однозадачным: не будет отвечать одному юзеру, пока обслуживает другого. Чтобы включить интуитивно ожидаемое поведение, надо в бойлерплейте писать какое-то странное заклинание, что-то вроде
Не люблю, когда продуктовые решения принимают по-программистски.
Создатели опенсорс-инструментов совершают продуктовые ошибки ещё чаще, чем предприниматели.
Каноничный пример — python-telegram-bot. Хороший, вроде бы, фреймворк: приемлемый бойлерплейт, поддерживает все нужные эндроинты, в документации разобраться тоже возможно.
Но вот несколько лет назад его взяли и переписали на asyncio. Получилось очень по-программистски: авторы не надели шляпу пользователей, у которых уже есть кодовая база. Хочешь новые фичи и секьюрити-фиксы — будь добр, переписывай кодовую базу под никому не нужный async. Авторы даже не удосужились как-то продать юзерам ценность перехода, добавить хоть каких-то фич. Просто переписали и всё — в анонсе нет вообще ни капли смысла, одни только «embracing the future». Оно и понятно — откуда взяться смыслу, если у телеграм-ботов в принципе не может быть задач, для которых нужен event loop.
Самое смешное в этом переходе — фреймворк даже на asyncio продолжает быть однозадачным: не будет отвечать одному юзеру, пока обслуживает другого. Чтобы включить интуитивно ожидаемое поведение, надо в бойлерплейте писать какое-то странное заклинание, что-то вроде
bot.init(simultaneos_updates=True).Не люблю, когда продуктовые решения принимают по-программистски.
FEDOR BORSHEV
Не писать тесты с 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, а не человек.
Ну и ревью, конечно, никто не отменял — каждый сгенерированный тест нужно прочитать вручную перед мёрджем, как и весь другой код.
Кароч, я поменял мнение по поводу генерации тестов в LLM. Теперь считаю, что делать это можно и нужно.
Мой старый посыл был в том, что когда кожаный мешок пишет тесты, он лучше думает о коде. Но ведь ничего не мешает подумать о коде на этапе планирования. Если сделать это хорошо — будете буквально попросить модель «Write tests: 1. for XXX; 2. for YYY; 3. All tests you suggest». То есть описывать важные для бизнеса тест-кейсы, предоставив модели тестирование скучных крудов.
Увы, LLM-тесты, по крайней мере в pytest, всё ещё не сравнятся с человеческими по лакончиности и читаемости. Но это не так уж и важно — если загнать в AGENTS.md достаточное количество правил и примеров, то тесты получаются вполне приемлемыми. А чуть-чуть поломанная читаемость — вполне адекватная плата за скорость: в конце-концов чинить эти тесты тоже будет LLM, а не человек.
Ну и ревью, конечно, никто не отменял — каждый сгенерированный тест нужно прочитать вручную перед мёрджем, как и весь другой код.
1
Не верю в автономных агентов
По-моему, хайповый OpenClaw очень похож на Apple Watch — такое же футуристичное, но бесполезное дерьмо.
Клёво конечно, когда агент без моего участия что-то пишет. Но мне же всё равно придётся проверить за ним код! Если не проверю — рискую, что он задеплоит в продакшн неработающее говно, да ещё и когда меня не будет рядом.
Или представить агента, который в фоне решает долгую задачу и периодически задаёт мне вопросы в телегу. Выглядит круто, но я же не хочу, чтобы мне задавали вопросы в телегу! Неважно, человек это или робот — если меня нет за компьютером, то наверное я отошёл не просто так. Да и в любом случае, раз уж я ставлю задачу, то лучше сконцентрироваться и поставить сразу нормально, чем потом постоянно отвлекаться, отвечая на вопросы.
Доверить агенту отвечать на почту/вопросы в трекере — ещё глупее, чем доверять это другому человеку: если у меня столько писем, что я не могу ответить на них самостоятельно — надо выплачивать управленческий долг и делегировать, а не обслуживать происходящее дерьмо.
Кароч, языковые модели клёво решают программистские задачи: как организовать код, как спроектировать API и что порефакторить, чтобы в систему влезла новая фича. Но они бесконечно далеки от решений, которые касаются бизнеса — какую часть фичи дропнуть, чтобы успеть поскорее, какую — переложить на соседнюю команду, а что лучше перенести на следующий спринт, чтобы в текущем катить атомарную пачку изменений.
В моём понимании, хорошая AI-assisted разработка в 2026 году выглядит так же скучно, как и в 2023: я ставлю задачу в трекер кожаному мешку, веду с ним коммуникацию (лучше бы нет) и получаю результат от того же кожаного мешка. Просто результата должно быть в 3 раза больше, а кожаный при этом должен меньше уставать.
По-моему, хайповый OpenClaw очень похож на Apple Watch — такое же футуристичное, но бесполезное дерьмо.
Клёво конечно, когда агент без моего участия что-то пишет. Но мне же всё равно придётся проверить за ним код! Если не проверю — рискую, что он задеплоит в продакшн неработающее говно, да ещё и когда меня не будет рядом.
Или представить агента, который в фоне решает долгую задачу и периодически задаёт мне вопросы в телегу. Выглядит круто, но я же не хочу, чтобы мне задавали вопросы в телегу! Неважно, человек это или робот — если меня нет за компьютером, то наверное я отошёл не просто так. Да и в любом случае, раз уж я ставлю задачу, то лучше сконцентрироваться и поставить сразу нормально, чем потом постоянно отвлекаться, отвечая на вопросы.
Доверить агенту отвечать на почту/вопросы в трекере — ещё глупее, чем доверять это другому человеку: если у меня столько писем, что я не могу ответить на них самостоятельно — надо выплачивать управленческий долг и делегировать, а не обслуживать происходящее дерьмо.
Кароч, языковые модели клёво решают программистские задачи: как организовать код, как спроектировать API и что порефакторить, чтобы в систему влезла новая фича. Но они бесконечно далеки от решений, которые касаются бизнеса — какую часть фичи дропнуть, чтобы успеть поскорее, какую — переложить на соседнюю команду, а что лучше перенести на следующий спринт, чтобы в текущем катить атомарную пачку изменений.
В моём понимании, хорошая AI-assisted разработка в 2026 году выглядит так же скучно, как и в 2023: я ставлю задачу в трекер кожаному мешку, веду с ним коммуникацию (лучше бы нет) и получаю результат от того же кожаного мешка. Просто результата должно быть в 3 раза больше, а кожаный при этом должен меньше уставать.
32
Небольшие онлайн-школы закрываются
С начала года от коллег по образованию приходят очень грустные новости — закрывается одна онлайн-школа за другой. Первая причина — банальная и экономическая: многим сейчас страшно за будущее в финансовом плане, многие компании сокращают людей.
Вторая — ИИ-страх. Типа нахрена мне учить новые технологии и подходы, если я могу потерять будущее, а пока не потерял — всё можно спросить у опуса.
Мы держимся. Причём не потому, что умеем считать деньги и планировать вперёд (хотя я этим и горжусь), а потому, что большинство наших продуктов стали только актуальнее в новом мире. Смотрите, единственное, чего не умеет опус — это быть полезным бизнесу: вынимать требования, выстраивать их в цельную систему, обходить говнолегаси и проектировать новое так, чтобы не переделывать. К слову, этого не умеют 80% процентов программистов до сих пор.
«Анализ Систем» — как раз об этом. Шестой поток начинается с 20 мая — как раз после дач и отпусков. Учебная нагрузка — примерно 10 часов в неделю. Это довольно интенсивный курс, поэтому если возьмете на работе отпуск хотя бы на один день в неделю — будет проще затаскивать. Если до сих пор сомневаетесь — посмотрите демку на сайте.
До вечера вторника действует промокод
С начала года от коллег по образованию приходят очень грустные новости — закрывается одна онлайн-школа за другой. Первая причина — банальная и экономическая: многим сейчас страшно за будущее в финансовом плане, многие компании сокращают людей.
Вторая — ИИ-страх. Типа нахрена мне учить новые технологии и подходы, если я могу потерять будущее, а пока не потерял — всё можно спросить у опуса.
Мы держимся. Причём не потому, что умеем считать деньги и планировать вперёд (хотя я этим и горжусь), а потому, что большинство наших продуктов стали только актуальнее в новом мире. Смотрите, единственное, чего не умеет опус — это быть полезным бизнесу: вынимать требования, выстраивать их в цельную систему, обходить говнолегаси и проектировать новое так, чтобы не переделывать. К слову, этого не умеют 80% процентов программистов до сих пор.
«Анализ Систем» — как раз об этом. Шестой поток начинается с 20 мая — как раз после дач и отпусков. Учебная нагрузка — примерно 10 часов в неделю. Это довольно интенсивный курс, поэтому если возьмете на работе отпуск хотя бы на один день в неделю — будет проще затаскивать. Если до сих пор сомневаетесь — посмотрите демку на сайте.
До вечера вторника действует промокод
S6FSTART на 10% скидки.Выходной — это когда нет планов
Я работаю по выходным. Слишком люблю то, что делаю, чтобы надолго от этого уходить.
Самое главное правило, которое я сформулировал за годы такой работы — на выходной нельзя ставить планы. Если проводить выходной день так же, как будний, с обзором-перепиской-помидорками, довольно быстро устанешь и возненавидишь не только работу, но ещё и самого себя.
Единственные дела, которую можно делать в выходные — это те, которую хочется делать прямо сейчас. Если говорить одним словом — по делам на выходных надо фланировать: в таком случае найдётся время и потупить в ютуб, и побыть с близкими, и поделать приятные дела, и просто побездельничать.
Ни в коем случае нельзя обещать кому-то «посмотреть на выходных» — одно такое обещание (даже данное самому себе) может испортить всё фланирование. Выходные — время свободы от планов, только так работает отдых. Сделал работу — хорошо. Не сделал — хорошо.
Я работаю по выходным. Слишком люблю то, что делаю, чтобы надолго от этого уходить.
Самое главное правило, которое я сформулировал за годы такой работы — на выходной нельзя ставить планы. Если проводить выходной день так же, как будний, с обзором-перепиской-помидорками, довольно быстро устанешь и возненавидишь не только работу, но ещё и самого себя.
Единственные дела, которую можно делать в выходные — это те, которую хочется делать прямо сейчас. Если говорить одним словом — по делам на выходных надо фланировать: в таком случае найдётся время и потупить в ютуб, и побыть с близкими, и поделать приятные дела, и просто побездельничать.
Ни в коем случае нельзя обещать кому-то «посмотреть на выходных» — одно такое обещание (даже данное самому себе) может испортить всё фланирование. Выходные — время свободы от планов, только так работает отдых. Сделал работу — хорошо. Не сделал — хорошо.
Wikipedia
Фланёр
Фланёр (фр. flâneur, «гуляющий») — тип горожанина, впервые отмеченный в Париже середины XIX века (также boulevardier). Фланирование означало гуляние по бульварам с целью развлечения и получения удовольствия от наблюдения городской жизни.
28
Полюбил Spec-driven development
Недавно осознал, что допрогал вайб-фронтенд Зои до состояния, при котором стандартного контекста opencode (128k) перестаёт хватать на большие задачи.
Увеличивать контекст не хочу — моей личной оперативной памяти и так не хватает, чтобы помнить, о чём я за эти 128к договорился с моделью. Мне и 64к кажется многовато.
Естественным образом пришёл к openspec. Теперь у меня есть отдельный этап проработки спеки, и в любой момент этого этапа можно открыть буквально весь текущий план разработки. Не надо помнить, что там было две реплики назад, и проверять не потеряла ли модель мелкий багфикс, который мы нашли по дороге.
Архив спек пока не оценил, но кажется что это почти как ADR, только на уровне кода. Хороший архив по-идее делает ненужным сервисы типа entire.io. А ещё openspec открывает дорогу к отказу от тормозного opencode, который вместе с моим agents.md занимает уже больше 20к, в сторону быстрого и управляемого pi.
В общем как бы странно это ни звучало, но я теперь снова пишу ТЗ.
---
20 мая стартует 6 поток «Анализа Систем». Ждём мидлов и синьёров, которые хотят надёжных знаний по архитектуре больших систем.
Недавно осознал, что допрогал вайб-фронтенд Зои до состояния, при котором стандартного контекста opencode (128k) перестаёт хватать на большие задачи.
Увеличивать контекст не хочу — моей личной оперативной памяти и так не хватает, чтобы помнить, о чём я за эти 128к договорился с моделью. Мне и 64к кажется многовато.
Естественным образом пришёл к openspec. Теперь у меня есть отдельный этап проработки спеки, и в любой момент этого этапа можно открыть буквально весь текущий план разработки. Не надо помнить, что там было две реплики назад, и проверять не потеряла ли модель мелкий багфикс, который мы нашли по дороге.
Архив спек пока не оценил, но кажется что это почти как ADR, только на уровне кода. Хороший архив по-идее делает ненужным сервисы типа entire.io. А ещё openspec открывает дорогу к отказу от тормозного opencode, который вместе с моим agents.md занимает уже больше 20к, в сторону быстрого и управляемого pi.
В общем как бы странно это ни звучало, но я теперь снова пишу ТЗ.
---
20 мая стартует 6 поток «Анализа Систем». Ждём мидлов и синьёров, которые хотят надёжных знаний по архитектуре больших систем.
Ищем синьёрных питонистов
Мы в ФАНС ищем бекендеров на проектную работу — 3-4 месяца. По итогам, если сработаемся, сможем заключить долгосрочный контракт.
Стек — современный python, django, местами fastapi. Работаем в github, оплачиваем подписки copilot или cursor на выбор.
Требования всего два:
1. Писать хороший код (как выглядит хороший код на наш взгляд можно посмотреть тут)
2. Выполнять обещания. Если сказал, что сделаешь в среду — надо делать в среду.
Работа удалённая, 4 дня в неделю со свободным графиком и полной занятостью.
Писать на python@fands.dev. Мы точно не сможем ответить, если ваше письмо будет похоже AI-мусор, в нём не будет примеров ваших проектов или оно будет состоять из одного только CV.pdf.
Мы в ФАНС ищем бекендеров на проектную работу — 3-4 месяца. По итогам, если сработаемся, сможем заключить долгосрочный контракт.
Стек — современный python, django, местами fastapi. Работаем в github, оплачиваем подписки copilot или cursor на выбор.
Требования всего два:
1. Писать хороший код (как выглядит хороший код на наш взгляд можно посмотреть тут)
2. Выполнять обещания. Если сказал, что сделаешь в среду — надо делать в среду.
Работа удалённая, 4 дня в неделю со свободным графиком и полной занятостью.
Писать на python@fands.dev. Мы точно не сможем ответить, если ваше письмо будет похоже AI-мусор, в нём не будет примеров ваших проектов или оно будет состоять из одного только CV.pdf.
Назови свою цену
Ненавижу, когда люди не могут назвать цену за свои услуги. Вот нанимаю я исполнителя на разовую работу, к примеру написать пачку кода. Разговор подходит к деньгам, я спрашиваю сколько эта работа стоит, а в ответ получаю странное «сколько заплатишь, столько и ок».
Вроде бы человек пытается уйти от денежных отношений — типа я ему настолько дорог, что он готов и бесплатно поработать. Или задача для него новая, и он не знает сколько такие вещи стоят в принципе. Или ещё какая-нибудь внутренняя причина, которую я даже придумать не могу.
Единственное, что при этом вижу я — что почему-то исполнитель не хочет принимать ответственность за то, чтобы назвать свою цену. И пытается переложить эту ответственность на меня.
Я от своей части не отказываюсь, но интересно, а когда мы всё-таки договоримся про деньги и начнём делать работу — ответственность за её результат исполнитель тоже мне вернёт? А когда в процессе вылезут проблемы, исполнитель так же постесняется мне о них сказать?
Удивительным образом, ненависть появляется именно при найме самостоятельных людей на конкретные услуги. При трудоустройстве всё совсем по-другому.
---
20 мая стартует 6 поток «Анализа Систем». Обсуждаем, как строить большие системы для бизнеса, а не на основе докладов с конференций.
Ненавижу, когда люди не могут назвать цену за свои услуги. Вот нанимаю я исполнителя на разовую работу, к примеру написать пачку кода. Разговор подходит к деньгам, я спрашиваю сколько эта работа стоит, а в ответ получаю странное «сколько заплатишь, столько и ок».
Вроде бы человек пытается уйти от денежных отношений — типа я ему настолько дорог, что он готов и бесплатно поработать. Или задача для него новая, и он не знает сколько такие вещи стоят в принципе. Или ещё какая-нибудь внутренняя причина, которую я даже придумать не могу.
Единственное, что при этом вижу я — что почему-то исполнитель не хочет принимать ответственность за то, чтобы назвать свою цену. И пытается переложить эту ответственность на меня.
Я от своей части не отказываюсь, но интересно, а когда мы всё-таки договоримся про деньги и начнём делать работу — ответственность за её результат исполнитель тоже мне вернёт? А когда в процессе вылезут проблемы, исполнитель так же постесняется мне о них сказать?
Удивительным образом, ненависть появляется именно при найме самостоятельных людей на конкретные услуги. При трудоустройстве всё совсем по-другому.
---
20 мая стартует 6 поток «Анализа Систем». Обсуждаем, как строить большие системы для бизнеса, а не на основе докладов с конференций.
3
Уйти на второй круг в бизнесе
Мне очень нравится приём, который используют в авиации, чтобы пилотам было легче уходить на второй круг при посадке.
Подсознательно пилот всегда будет воспринимать уход на второй круг как поражение — типа с первого раза не смог попасть в полосу. Но если это подсознание выпустить наружу — будут проблемы: огромное количество авиакатастроф связаны с тем, что пилоты садились во что бы это ни стало, когда надо было прервать заход и уйти на второй круг.
Чтобы такого не было, молодых пилотов учат думать инвертировано. Не «мы садимся, а если что-то пойдет не так, то уйдём на второй круг», а ровно наоборот — «мы уходим на второй круг, но если вдруг мы поймём, что самолёт стабилизирован, и мы своими глазами видим полосу — тогда сядем» (знатоки авиации наверное меня поправят).
Теперь посмотрим на предпринимателей. Закрыть бизнес — это же поражение: не смог придумать продукт, который интересен пользователям. И от нежелания признавать это поражение появляются потерянные годы и кредиты под залог недвижимости. А вообще-то закрыть бизнес — такой же профессиональный поступок для предпринимателя, как уйти на второй круг для пилота.
Пытаюсь вместить этот майндсет в свою голову с Зоей — не ждать, что мы сделаем гениальный продукт нужный рынку, а понимать, что мы проект идёт к закрытию, но если вдруг где-нибудь увидим железный Product-Market fit, то тогда остановим его закрытие.
Мне очень нравится приём, который используют в авиации, чтобы пилотам было легче уходить на второй круг при посадке.
Подсознательно пилот всегда будет воспринимать уход на второй круг как поражение — типа с первого раза не смог попасть в полосу. Но если это подсознание выпустить наружу — будут проблемы: огромное количество авиакатастроф связаны с тем, что пилоты садились во что бы это ни стало, когда надо было прервать заход и уйти на второй круг.
Чтобы такого не было, молодых пилотов учат думать инвертировано. Не «мы садимся, а если что-то пойдет не так, то уйдём на второй круг», а ровно наоборот — «мы уходим на второй круг, но если вдруг мы поймём, что самолёт стабилизирован, и мы своими глазами видим полосу — тогда сядем» (знатоки авиации наверное меня поправят).
Теперь посмотрим на предпринимателей. Закрыть бизнес — это же поражение: не смог придумать продукт, который интересен пользователям. И от нежелания признавать это поражение появляются потерянные годы и кредиты под залог недвижимости. А вообще-то закрыть бизнес — такой же профессиональный поступок для предпринимателя, как уйти на второй круг для пилота.
Пытаюсь вместить этот майндсет в свою голову с Зоей — не ждать, что мы сделаем гениальный продукт нужный рынку, а понимать, что мы проект идёт к закрытию, но если вдруг где-нибудь увидим железный Product-Market fit, то тогда остановим его закрытие.
106
DevEx → VibeEx
Кажется, я насмотрелся на достаточное количество новых проектов, чтобы утверждать, что AI-тулинга повылезали ровно те же проблемы, что и любых других программистских инструментов. И самая главная из них — воспроизводимость.
Какие-то проекты хранят все llm-наработки в курсоре одного из разработчиков. Кто-то жёстко рассчитывает на внешние скиллы, которые неизвестно где взять. Где-то каждую новую юзер-сторю реализуют с новым паттерном, потому что никто не озаботился выкинуть неактуальный код, и llm считает его живыми примерами.
Принцип «поработал — убери» стал ещё более актуальным. Раньше можно было расчитывать, что бардак выбесит кого-нибудь настолько, что тот потратит пару дней и выкинет мусор. Сейчас бардак бесит только агентов — а они ребята терпеливые.
Сделать проект удобным одновременно и для агентов, и для кожаных мешков — это всё ещё работа кожаных мешков. И это такой же техдлолг, как и любой другой.
Кажется, я насмотрелся на достаточное количество новых проектов, чтобы утверждать, что AI-тулинга повылезали ровно те же проблемы, что и любых других программистских инструментов. И самая главная из них — воспроизводимость.
Какие-то проекты хранят все llm-наработки в курсоре одного из разработчиков. Кто-то жёстко рассчитывает на внешние скиллы, которые неизвестно где взять. Где-то каждую новую юзер-сторю реализуют с новым паттерном, потому что никто не озаботился выкинуть неактуальный код, и llm считает его живыми примерами.
Принцип «поработал — убери» стал ещё более актуальным. Раньше можно было расчитывать, что бардак выбесит кого-нибудь настолько, что тот потратит пару дней и выкинет мусор. Сейчас бардак бесит только агентов — а они ребята терпеливые.
Сделать проект удобным одновременно и для агентов, и для кожаных мешков — это всё ещё работа кожаных мешков. И это такой же техдлолг, как и любой другой.
13
А вы заметили как обесценилась в последнее время команда ping? 10 лет назад, чтобы проверить интернет в сомнительных условиях, я делал
Сейчас такой пинг ничего не значит — ответ может прилететь от ВПН-клиента или вообще от ТСПУ. Даже если ответ прилетит от оригинального хоста — далеко не факт что я до него достучусь с реальным запросом — пинг может проходить, а коннект на 443 порту рваться посередине хендшейка.
Теперь, чтобы проверить интернет, хожу на 443 порт — пишу
ping google.com, 1.1.1.1 или yandex.ru, и смотрел результат.Сейчас такой пинг ничего не значит — ответ может прилететь от ВПН-клиента или вообще от ТСПУ. Даже если ответ прилетит от оригинального хоста — далеко не факт что я до него достучусь с реальным запросом — пинг может проходить, а коннект на 443 порту рваться посередине хендшейка.
Теперь, чтобы проверить интернет, хожу на 443 порт — пишу
curl ifconfig.co: сразу проверяет и доступность интернета, и маршрутизацию. А вы как?Вернулся на Claude code
Вот уже больше месяца прошло, как я отказался от OpenCode и pi в пользу Claude code. Попробовал просто в надежде сэкономить токенов после того, как Copilot перестал выдавать свои первые бесплатные дозы, да так и остался.
Да, Claude code намного медленнее свободных альтернатив, но планы, которые он приносит — гораздо полнее и продуманнее. Оказалось, что мне гораздо ценнее получать ответы через 5 минут, чем через 2 — потому что через 5 минут мне достаточно будет написать «ok», а сколько ещё итераций понадобится после двухминутного ответа — заранее неизвестно.
Клёво, что теперь не надо думать о выборе модели и о том, насколько заполнено контекстное окно — всё это происходит где-то в недрах харнеса.
Немного бесит кривая система настроек и театр безопасности (а вы точно доверяете этому фолдеру? А можно я запущу find? Ой, а find -exec?). Но со всем этим можно мириться ради большей автономности агента и проработанных планов.
Opencode остался только в местах, где нужно совсем тонкое взаимодействие с моделью — к примеру для системы перевода материалов школы на английский, или в экспериментах с локальными моделями.
Вспоминаю ощущения от перехода с линукса на мак — контроля стало меньше, а результата больше.
Вот уже больше месяца прошло, как я отказался от OpenCode и pi в пользу Claude code. Попробовал просто в надежде сэкономить токенов после того, как Copilot перестал выдавать свои первые бесплатные дозы, да так и остался.
Да, Claude code намного медленнее свободных альтернатив, но планы, которые он приносит — гораздо полнее и продуманнее. Оказалось, что мне гораздо ценнее получать ответы через 5 минут, чем через 2 — потому что через 5 минут мне достаточно будет написать «ok», а сколько ещё итераций понадобится после двухминутного ответа — заранее неизвестно.
Клёво, что теперь не надо думать о выборе модели и о том, насколько заполнено контекстное окно — всё это происходит где-то в недрах харнеса.
Немного бесит кривая система настроек и театр безопасности (а вы точно доверяете этому фолдеру? А можно я запущу find? Ой, а find -exec?). Но со всем этим можно мириться ради большей автономности агента и проработанных планов.
Opencode остался только в местах, где нужно совсем тонкое взаимодействие с моделью — к примеру для системы перевода материалов школы на английский, или в экспериментах с локальными моделями.
Вспоминаю ощущения от перехода с линукса на мак — контроля стало меньше, а результата больше.
6
Как дела у Зои
TLDR — прорывов нет, работаем.
Реклама продолжает болтаться вокруг прибыльности — чтобы нормально достроить финмодель, надо подождать ещё 2 месяца, чтобы когорты, пришедшие на текущую версию продукта, стали хоть чуть-чуть зврослее.
По фичам — запустили медицинские карты: теперь модель знает, какие лекарства и диагнозы есть у пользователя. Доработали память — теперь контекст старых бесед не теряется: это важно, т.к. количество сообщений у активного юзера измеряется сотнями. Научили модель просматривать историю анализов и искать врачей, добавили голосовухи (на удивление не так уж и востребованные, подозреваю технические проблемы). Скоро запустим мобильное приложение и тудушки — чтобы пользователь вместе с моделью планировал свои медицинские дела.
Очень необычно себя чувствовать одновременно CEO, который берётся за всё непонятное и думает про стратегию, и разработчиком, который просто пилит фичи. Во всех прошлых продуктовых забегах я ограничивался ролью CTO, изолировал себя от маркетинга. А сейчас осознал, что кроме меня это никто не сделает — и поменял букву T на E.
Жутко интересно и страшно — только живых денег потратили уже 1.3 млн, и дальше эту сумму надо только увеличивать.
TLDR — прорывов нет, работаем.
Реклама продолжает болтаться вокруг прибыльности — чтобы нормально достроить финмодель, надо подождать ещё 2 месяца, чтобы когорты, пришедшие на текущую версию продукта, стали хоть чуть-чуть зврослее.
По фичам — запустили медицинские карты: теперь модель знает, какие лекарства и диагнозы есть у пользователя. Доработали память — теперь контекст старых бесед не теряется: это важно, т.к. количество сообщений у активного юзера измеряется сотнями. Научили модель просматривать историю анализов и искать врачей, добавили голосовухи (на удивление не так уж и востребованные, подозреваю технические проблемы). Скоро запустим мобильное приложение и тудушки — чтобы пользователь вместе с моделью планировал свои медицинские дела.
Очень необычно себя чувствовать одновременно CEO, который берётся за всё непонятное и думает про стратегию, и разработчиком, который просто пилит фичи. Во всех прошлых продуктовых забегах я ограничивался ролью CTO, изолировал себя от маркетинга. А сейчас осознал, что кроме меня это никто не сделает — и поменял букву T на E.
Жутко интересно и страшно — только живых денег потратили уже 1.3 млн, и дальше эту сумму надо только увеличивать.
14
День рождения школы
Мы с Марьяной впервые встретились в перерыве между карантинами — в августе 2020 года. Почти сразу начали делать первую версию «Стать Тимлидом» — он родился из накопленного у обоих опыта, которым хотелось делиться.
Прошло уже целых 6 лет, офигеть. Школа пережила ковид, пережила сломанные платежи и потерянные данные. Надеюсь, переживёт и текущий кризис.
День рождения получается не очень весёлый, но всё таки это повод — так что вот вам скидка 25% на все самостоятельные курсы. Действует до вечера среды — приходите знакомиться, если давно присматриваетесь к «Анализу Систем» или лидерским курсам. Забирайте «Самому не проще» или «Есть минутку» если хотите прокачаться в делегировании или управляемой коммуникации. Промокод
Что там у них →
С днём рождения нас!
Мы с Марьяной впервые встретились в перерыве между карантинами — в августе 2020 года. Почти сразу начали делать первую версию «Стать Тимлидом» — он родился из накопленного у обоих опыта, которым хотелось делиться.
Прошло уже целых 6 лет, офигеть. Школа пережила ковид, пережила сломанные платежи и потерянные данные. Надеюсь, переживёт и текущий кризис.
День рождения получается не очень весёлый, но всё таки это повод — так что вот вам скидка 25% на все самостоятельные курсы. Действует до вечера среды — приходите знакомиться, если давно присматриваетесь к «Анализу Систем» или лидерским курсам. Забирайте «Самому не проще» или «Есть минутку» если хотите прокачаться в делегировании или управляемой коммуникации. Промокод
SIX.Что там у них →
С днём рождения нас!
1
Я спросил у опуса
Верный признак плохого менеджера — пересылать в команду письма от клиента без каких-либо приписок, ну разве что иногда добавляя что-нибудь вроде JFYI. С 25 года появился новый жанр — «я спросил у опуса и <тонна копипасты>». Напишу тем, кто так делает — вдруг у вас ещё не всё потеряно.
Друзья, у опуса я могу и сам спросить. Кожаный мешок существует не для того, чтобы перекладывать текст из одного места в другое — он нужен, чтобы приносить ценность и принимать ответственность. К копипасте из LLM можно приложить много ценности: начиная от фактчекинга и заканчивая тем, что вообще убрать копипасту и написать мне в один абзац, что в предлагаете сделать.
Префикс «я спросил у LLM» не спасает от ответственности: вас уволят, а опус останется. Всё, что делает этот префикс — говорит команде, что вы не уважаете их настолько, что не готовы потратить даже 5 минут на банальную проверку источников.
Верный признак плохого менеджера — пересылать в команду письма от клиента без каких-либо приписок, ну разве что иногда добавляя что-нибудь вроде JFYI. С 25 года появился новый жанр — «я спросил у опуса и <тонна копипасты>». Напишу тем, кто так делает — вдруг у вас ещё не всё потеряно.
Друзья, у опуса я могу и сам спросить. Кожаный мешок существует не для того, чтобы перекладывать текст из одного места в другое — он нужен, чтобы приносить ценность и принимать ответственность. К копипасте из LLM можно приложить много ценности: начиная от фактчекинга и заканчивая тем, что вообще убрать копипасту и написать мне в один абзац, что в предлагаете сделать.
Префикс «я спросил у LLM» не спасает от ответственности: вас уволят, а опус останется. Всё, что делает этот префикс — говорит команде, что вы не уважаете их настолько, что не готовы потратить даже 5 минут на банальную проверку источников.
7