Долгое время я вообще не был уверен, что этому сайту нужен блог.
Большую часть рабочего времени я и так решаю задачи. Некоторые — обычный фронтенд или бэкенд. Другие быстро становятся очень узкими: кодирование изображений, поведение браузеров, SEO-эксперименты, проблемы инфраструктуры, разработка с помощью ИИ, обработка медиа или какой-нибудь странный production-баг, который начинается с простого вопроса и превращается в несколько дней исследования.
После этого писать ещё несколько тысяч слов может казаться бессмысленным.
Кто это будет читать?
Что я вообще с этого получу?
Почему не решить задачу и просто идти дальше?
В итоге я нашёл ответ, которого мне достаточно: часть такой работы слишком дорого обходится, чтобы просто выбрасывать её.
В сложной задаче может скрываться целая статья ещё до того, как я это замечу
Мои статьи обычно не начинаются с мысли: «На этой неделе надо написать пост в блог».
Они начинаются с задачи.
Иногда она появляется на работе, иногда — в одном из моих проектов. Иногда мне просто становится интересно что-то, чего я не понимаю, и я продолжаю копать, пока не начинаю разбираться намного лучше.
Обработка изображений особенно часто затягивала меня в такие исследования.
Сначала задача может звучать почти смешно просто:
Возьми эти картинки и сделай их меньше.
Можно попросить ИИ-модель написать скрипт и получить его почти сразу.
Но это ещё не значит, что у вас появился хороший pipeline обработки изображений.
Первая версия может не учитывать разницу между JPEG, PNG, WebP и анимированным контентом. Может использовать одно значение quality для всего. Может без необходимости увеличивать картинки. Может плохо работать с прозрачностью. Может сохранять метаданные, которые вы хотели удалить, или уничтожать те, которые хотели оставить. Может уменьшать размер файла, вообще не измеряя визуальную деградацию. На десяти тестовых файлах всё может работать идеально, а на значительно большем масштабе та же логика превратится в очень дорогую ошибку.
Скрипт, который успешно отработал, — это не то же самое, что система, которой я доверяю.
Из этой разницы рождается много моих статей.
Мой workflow с ИИ намного медленнее, чем «спросить у ChatGPT ответ»
Когда я разбираюсь с такими задачами, я очень активно использую платный ChatGPT.
Один чат может жить днями или неделями. Я задаю вопросы, проверяю предложения, возвращаю результаты, оспариваю предположения, изучаю код, нахожу очередной edge case, меняю реализацию, запускаю снова, сравниваю результат и повторяю цикл.
В особенно глубоких исследованиях вокруг одной большой задачи у меня накапливалось больше 100 часов работы.
Это не значит, что я 100 часов сижу и жду, пока ИИ-модель магическим образом найдёт ответ.
Процесс итеративный.
Обычно он выглядит примерно так:
- Я описываю проблему.
- Модель предлагает первое решение.
- Я запускаю его на реальных данных.
- Что-то оказывается слабым, неэффективным или просто неправильным.
- Я возвращаю доказательства в чат.
- Мы меняем подход.
- Я снова тестирую.
- Появляется новый edge case.
- Повторяем.
Этот цикл может повторяться много раз.
Полезным результатом часто оказывается не первый скрипт, а накопившийся вокруг него набор ошибок, измерений, исправлений и решений.
ИИ удешевил получение первого варианта. Проверку он дешёвой не сделал
Это одна из причин, почему обычные споры о техническом контенте, написанном с помощью ИИ, кажутся мне слишком упрощёнными.
Да, ИИ-модель может очень быстро выдать правдоподобный tutorial.
Но она так же легко может выдать код, который выглядит совершенно разумно и ошибается именно там, где это действительно важно.
В узких технических задачах мне редко нужен первый правдоподобный ответ. Мне нужно узнать, что произойдёт, когда я реально его запущу.
Если я строю pipeline обработки изображений, я хочу смотреть на размеры выходных файлов и визуальное качество. Хочу знать, что произойдёт с разными исходными форматами. Хочу тестировать необычные размеры, alpha, анимации и повреждённые входные файлы. Хочу понимать, какие предположения делает реализация.
Если потом скрипт будет работать с огромной коллекцией, всё это становится ещё важнее.
Десять миллионов изображений — намеренно экстремальный пример, а не утверждение о размере какого-то конкретного моего датасета. Но он хорошо показывает проблему: маленькая систематическая ошибка, повторённая десять миллионов раз, уже не маленькая.
Стоимость генерации кода рухнула.
Стоимость проверки того, достоин ли этот код запуска в большом масштабе, — нет.
Чат — это исследовательский материал, а не готовая статья
После такого длинного исследования история чата может содержать невероятное количество информации.
Там могут быть:
- подходы, которые не сработали;
- код, который позже заменили;
- полезные результаты benchmark'ов;
- логи;
- неверные предположения;
- исправления;
- объяснения странного поведения;
- сравнения альтернатив;
- edge case'ы, о которых я изначально не думал;
- и финальные правила, которым я в итоге начал доверять.
Оставить всё это внутри одного приватного чата кажется мне расточительством.
Поэтому я вытаскиваю полезные части и превращаю их в статью.
Статья — не транскрипт разговора. Большая часть чата вообще не должна становиться статьёй.
Полезной технической статье нужен ещё один проход: удалить тупиковые ветки, которые ничему не учат, оставить те, которые объясняют что-то важное, проверить утверждения, восстановить хронологию, отделить наблюдение от объяснения и превратить итог в материал, которым другой разработчик реально сможет воспользоваться.
Этот редакционный этап важен.
ИИ может в нём участвовать, но доказательства всё равно приходят из реальной работы.
Обработка изображений показала мне, насколько глубокой может стать «простая» задача
Оптимизация изображений, пожалуй, самый наглядный пример из моей работы.
Я провёл с ней достаточно времени, чтобы то, что сначала выглядело как набор настроек encoder'а, постепенно превратилось в гораздо более крупную системную задачу.
Вопросы начинают множиться очень быстро.
С каким исходным форматом я работаю?
Он анимированный?
Нужно ли менять размеры?
Как выбирать quality?
Какая метрика должна определять, допустима ли потеря качества?
Работает ли один quality threshold для совершенно разных картинок?
Как избежать upscaling?
Какие метаданные должны сохраниться?
Что будет с прозрачностью?
Как валидировать результат?
Оправдывает ли уменьшение файла дополнительную стоимость кодирования?
Что произойдёт, если изменится состав входных данных?
Именно поэтому я скептически отношусь к пятистрочным скриптам «идеальной оптимизации изображений».
Картинку они обработать могут.
Но это совсем не то же самое, что построить pipeline, компромиссы которого ты понимаешь.
Для моих нынешних проектов с большим количеством изображений AVIF обычно становится первым форматом, который я рассматриваю. Это правило, появившееся из моих типов задач, а не заявление, что каждый сайт в мире должен завтра удалить все старые форматы. Требования совместимости, исходный материал, latency, стоимость encoder'а и архитектура доставки могут изменить ответ.
Интересно не объявить какой-то формат победителем.
Интересно достаточно хорошо понять workload, чтобы принять решение осознанно.
Я хочу так же глубоко погрузиться и в обработку видео. Пока я ещё не на этом уровне. В этом и есть часть интереса: каждый раз, когда кажется, что я дошёл до дна одной задачи, появляется следующий слой.
А потом блог нашёл японский сайт
Я не ожидал какого-то конкретного результата от публикации этих статей.
Этот блог не приносит мне сколько-нибудь значимого финансового дохода. Я веду его потому, что мне нравится сам процесс и я предпочитаю сохранить полезную работу, а не позволить ей исчезнуть в старых чатах и истории терминала.
А потом произошло то, чего я действительно не ожидал.
17 сентября 2026 года японский сайт Levtech Freelance опубликовал подборку с названием, которое примерно можно перевести как «Рекомендуемые блоги для инженеров, которые хотят развивать свои навыки».
В статье Levtech Freelance JSVar оказался рядом с несколькими другими инженерными блогами.
Levtech входит в крупную японскую экосистему вокруг IT-карьеры, а Levtech Freelance занимается поддержкой и подбором проектов для freelance IT-инженеров. Для меня интересным был не просто ещё один backlink. Гораздо интереснее было увидеть, какие части моей работы внешняя редакция сочла достаточно ценными, чтобы рассказать о них своим читателям.
В разделе про JSVar они особенно выделили три статьи.
Одна была о том, почему в production-разработке мне понравилось сочетание Codex и TypeScript, в частности потому, что типы TypeScript и feedback компилятора помогают раньше находить проблемы в сгенерированном коде.
Другая — о переводе блога на 20 языков с помощью ChatGPT и о том, как пользователи из разных стран начали приходить из поиска прямо на локализованные страницы.
Третья — мой эксперимент с публикацией 10 000 AI-generated SEO-страниц, который в итоге стал историей скорее о провале, чем о лёгком росте.
Этот выбор меня даже немного развеселил: статьи совершенно разные, но у них один общий паттерн.
Все они основаны на том, что я действительно делал.
Я не знаю, как именно Levtech меня нашёл
Здесь очень легко построить красивую историю.
Я не говорю по-японски.
У моего сайта есть японская версия.
Японское инженерное издание нашло сайт.
Следовательно, перевод блога на японский и привёл Levtech.
Я не могу это доказать.
Возможно, японские страницы помогли.
Возможно, поиск привёл их к английской статье.
Возможно, кто-то поделился ссылкой.
Возможно, они вообще пришли другим путём.
У меня нет данных атрибуции, поэтому я не собираюсь делать из этого аккуратный SEO-кейс, которого мои данные на самом деле не подтверждают.
То, что я могу подтвердить, намного проще: я публиковал блог на нескольких языках, а затем японское издание сочло его достаточно интересным, чтобы включить в редакционную подборку.
Это уже хороший результат.
И он особенно приятен потому, что локализация тоже изначально выглядела как эксперимент с большим объёмом работы и неопределённой отдачей.
Эта публикация была важна как независимая оценка
Под «оценкой» я не имею в виду, что Levtech доказал правильность всего, что я пишу.
Они не проводили аудит моей codebase и не воспроизводили каждый эксперимент.
Значение было скромнее.
Кто-то на другом конце мира, пишущий для аудитории, к которой я сам не могу обратиться на её языке, увидел в моей работе достаточно ценности, чтобы пересказать её своим читателям.
Я им ничего не предлагал.
Исходные статьи я писал не для Levtech.
Я не ожидал попасть в японскую подборку.
Именно поэтому для меня это имеет значение.
Это показывает, что очень узкой технической статье не обязательно нужна огромная аудитория, чтобы её стоило публиковать.
Она должна быть полезна правильному читателю.
Стоит ли разработчику заводить блог в 2026 году?
Для меня ответ — да, но с одним важным условием.
Вам действительно должно хотеться что-то записывать.
Я бы не советовал заводить технический блог только потому, что кто-то сказал: каждому разработчику нужен «личный бренд».
Я бы не начинал его ради ожиданий пассивного дохода.
И не стал бы заполнять общими объяснениями технологий, для которых уже существует документация лучше.
Но если ваша работа постоянно рождает вещи, которые вы сами хотели бы найти, когда только начинали, это уже другое.
Пишите их.
Пишите о странном production-сбое.
Пишите об оптимизации, которая заняла на три дня больше, чем ожидалось.
Пишите о benchmark'е, который опроверг ваше предположение.
Пишите о подходе, который выглядел красиво и не сработал.
Пишите о финальной реализации, но объясняйте и то, почему очевидная реализация оказалась недостаточной.
Именно эти вещи трудно искусственно собрать из общих знаний.
ИИ даёт мне больше материала для статей, а не меньше
ИИ не убедил меня, что технические блоги устарели.
У меня произошло почти обратное.
Я могу исследовать больше идей, потому что получить начальную реализацию или объяснение теперь быстрее.
Но более быстрые итерации создают и больше доказательств: больше вариантов, логов, benchmark'ов, неудачных попыток и вещей, которые нужно проверять.
Этот сырой материал приобретает ценность только после того, как кто-то проделает работу и разберётся, что в нём правда и что действительно важно.
Чат с ИИ на 500 сообщений сам по себе ещё не знания.
А вот скрипт, который в итоге пережил реальные тесты, плюс объяснение 20 версий, которые их не пережили, уже может стать знанием.
Именно эту разницу я хочу сохранять в блоге.
Публикация не даёт полезной работе исчезнуть
Большая часть технической работы удивительно временна.
Сложный баг исправлен.
Терминал закрыт.
Deployment успешен.
Чат уезжает вниз по истории.
Через шесть месяцев даже я могу уже не помнить, почему финальная реализация выглядит именно так.
Текст это меняет.
Он заставляет меня восстановить ход мыслей, пока доказательства ещё существуют.
Создаёт что-то, что можно потом найти.
Даёт мне справочный материал для собственной будущей работы.
И иногда, как оказалось, доходит до людей, которых я вообще не ожидал — включая инженерное издание на языке, которого я не знаю.
У меня до сих пор нет какой-то сложной философии, зачем я веду этот блог.
Мне нравится учиться.
Мне нравится что-то строить.
Мне нравится слишком глубоко погружаться в задачи, которые сначала выглядели простыми.
И после десятков, а иногда и больше ста часов, потраченных на получение полезного ответа, я больше не хочу, чтобы этот ответ умирал внутри окна чата.
Для меня этого достаточно, чтобы его опубликовать.
Если ваша работа тоже создаёт такие знания, которые приходится добывать с трудом, возможно, этого будет достаточно и для вас.