Текст без опечаток любой ценой, но бесплатно

Я наконец закончил статью о внедрении спеллчекера CSpell, работать над которой начал почти год назад. Немного не дотянул до 50 000 символов, пришлось немного порезать статью в финальной редакции.

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

В программе — проработка требований, настройка CSpell для локального использования, адаптация под командные процессы, создание прекоммитных хуков и много других захватывающих вещей.

https://habr.com/ru/articles/902236/

#docsascode

Пятничное чтиво 1

Fabrizio Ferri Benedetti: What's wrong with AI-generated docs.

Запускаю новую рубрику, надеюсь что регулярную. Есть много интересных текстов, которые так или иначе относятся к наиболее сильно интересующим меня областям — технологиям, управлению знаниями и организации процессов, и этими текстами иногда хочется поделиться.

В первом посте этой рубрики статья Фабрицио Ферри Бенедетти, в которой человек с впечатляющим опытом смотрит на явление, которое многих пугает. При этом я точно знаю, что даже понимание всего, что описано в статье, не предотвратит массовое распространение слоп-контента еще и под видом документации. Но ознакомиться и осознать минусы такого контента стоит как минимум для того, чтобы побеждать незнакомцев в интернете в спорах.

Некоторые мысли, которые мне особенно нравятся:

* Главная проблема — в игнорировании пользовательского опыта, который возникнет в результате взаимодействия с такой документацией.

* Документация даже у новых LLM получается похожей на старые README. Применение жестких правил для управления результатами стороны модели возможно, но это не просто.

* Документация, созданная таким образом и не проанализированная человеком, может содержать всевозможные галлюцинации, из-за которых она не может быть источником истины.

* Документация — это не просто набор фактов, это engineered experience, кто-то должен подумать о пользователе и о том, как он воспримет написанное.

В общем, советую.

#чтиво

Пост об использовании спеллчекера CSpell в CI на GitHub

GitHub Action для запуска CSpell в CI

В недавно упоминавшейся статье для Хабра, посвященной использованию CSpell, я не описал одну довольно важную вещь — как именно запускать проверку орфографии в CI-пайплайне. У меня был только черновой код, который демонстрировал нужный подход.

Я собрался с силами и написал настоящий Action, который позволяет полноценно работать с CSpell на GitHub. В новой статье я рассказал немного про требования, ограничения и нюансы реализации.

P.S. А прямо сейчас на канале QFE идет курс, посвященный основам GitHub Actions, к которому я приложил руку. После этого курса, конечно, нельзя сразу стать докопсом, но можно получить представление о том, как подходить к такой автоматизации.

Редизайн сайта: отказался от 11ty в пользу Zola

https://alexjameson.github.io/

Когда мне нужно было опубликовать статью о сравнении генераторов статических сайтов, я просто сделал сайт с помощью генератора 11ty и разместил там статью. Все SSG, которые я до этого использовал, так или иначе обещали минимализм в настройках и потреблении ресурсов, и для меня это было самым важным. Хотелось иметь возможность просто набирать текст в Markdown, просто делать git push и видеть результат.

Сейчас я надеюсь, что переделал сайт в последний раз. Хочу зафиксировать несколько выводов, к которым я пришел в процессе перебора разных инструментов:

* SSG для документации и для блога могут отличаться друг от друга. У многих классических генераторов есть темы, которые делают из них блог, но при этом они остаются теми же самыми инструментами со своими особенностями и ограничениями.

* Чем проще SSG для блога — тем лучше. В свободное время абсолютно не хочется разбираться с конфигурацией вещей, которые не относятся к созданию страниц или написанию постов. Но простота может быть иметь свой недостаток — невозможность обеспечить своему сайту желаемый вид. Управление сочетанием простоты и кастомизируемости — серьезная задача для создателей инструментов.

* Некоторые SSG хорошо годятся для обоих классов задач, например Hugo. Я не использовал его в финальной итерации исключительно из желания еще немного поэкспериментировать. В процессе я нашел еще много хороших решений, которые могу бы использовать, но в силу разных причин не стал.

* 11ty обещал простоту и возможность лёгкого расширения функциональности за счет плагинов, но кое-чего я не учел. В начале все шло хорошо, хотя я терпеть не могу какую-то непонятную массу в node_modules. Тем, кто давно работает с экосистемой JavaScript известно, что все это быстро устаревает и выстреливает в самый неподходящий момент. Еще в процессе работы я понял одну вещь — возможность кастомизировать что угодно предполагает необходимость принять множество мелких решений. А я не хочу принимать такие решения в свободное время — я хочу писать посты, делать git push и видеть результат.

Финальной точкой для меня стало появление ошибки в логах сборки, которая говорила об ошибке в парсинге статьи плагином для RSS, а он у меня даже не был активирован! В итоге я просто убрал фрагмент, который вызывал эту ошибку, и ...

Переписал все на последнем генераторе, который хотел попробовать. Zola написан на Rust (the only thing your customers care about is whether your software is written in Rust), при этом знание самого языка не обязательно. Как и у Hugo, для работы нужен только один бинарный файл без зависимостей. Начало работы и базовая настройка занимают минуты, нет никаких жестких требований к структуре сайта, есть поддержка CommonMark с элементами GFM. Темы также ставятся и подключаются сразу, шаблоны почти не отличаются от Liquid, а конфигурация осуществляется без магии с помощью TOML.

Кажется, с момента первого открытия документации и до публикации текущей версии сайта прошло около двух часов (отдельный плюсик за простоту добавления редиректов). Меня устроил даже тот вариант, который я собрал сам в ретро-стиле, пользуясь только документацией и примерами на GitHub без обращения к нейронкам.

Кажется, теперь текстоцентричность и простота интерфейса соответствует простоте самого инструмента, а большего я особо и не хотел, так что можно начать писать на сайт, а не сам сайт.

Пятничное чтиво 2

Arjun Panickssery: Why Have Sentence Lengths Decreased?

Достаточно давно одним из требований хорошего и востребованного текста стала простота восприятия. Это понятный язык, ясная структура, соответствие формализованным правилам разных стилей. Одно из проявлений простоты — количество слов в тексте и, что важнее, в предложениях. Конечно, речь идет об английском языке, где и слова, и предложения в среднем короче, чем в русском.

В статье, которую я предлагаю почитать сегодня, приведен статистический анализ снижения среднего количества слов в динамике. Для художественной литературы это снижение выглядит так: от 49 слов в предложении (wps, words per sentence) у Джеффри Чосера в 1400 году до 12 wps у Джоан Роулинг, а в газетах — с 35 до 20 wps с 1700 по 2000 гг. Схожая картина наблюдается во всех областях, от ежегодного обращения президента США «О положении страны» до писем Уоррена Баффетта инвесторам.

После статистической справки рассматриваются причины, среди которых есть как более, так и менее очевидные. Например, одна из изначально понятных причин: газеты экономили на краске и бумаге, когда использовали более короткие предложения. Менее очевидная причина: длинные предложения лучше подходят для публичных речей. Такие речи составляют немалую часть проанализированных текстов, и чем меньше текстов подготовливалось для чтения вслух, тем сильнее снижалась средняя длина предложения.

В общем, рекомендую интересный экскурс в историю для всех пишущих людей.

P.S. Кстати, этот пост попался мне на глаза в сообществе рационалистов LessWrong, и комментарии там традиционно стоят того, чтобы с ними ознакомиться.

P.P.S. В текстах, опубликованных на этом канале в 2025 году, в среднем было 15 слов в предложении.

#язык #чтиво

Как я выбрал Qwen в качестве основной модели

Заметил, что фактически ушла в прошлое распространившаяся в прошлом году привычка отвечать на вопрос реального собеседника копипастом ответа языковой модели. Кажется, теперь это наконец-то считается тем же, что и отправка скриншота поисковой выдачи в качестве аргумента. Хочется верить, что это следствие накопленного опыта и последующего «расколдовывания» таких технологий.

Поиск с ИИ, будь то ответы Гугла, Яндекса или Perplexity, для меня стал одним из самых частых сценариев использования. У меня даже произошел откат в этом смысле — я перешел обратно к поиску в браузере от вопросов в чате.

Но зафиксировать я хочу не это, а то, как меняются привычки, касающиеся нейросетей. С момента вирального распространения ChatGPT 3.5 я, как и большинство моих знакомых, пользовался Телеграм-ботами для доступа к разным моделям в режиме чата. Уверен, что каждый читатель перепробовал много разных, а самые целеустремленные (или просто живущие за пределами России) пользовались и непосредственно самим чатом. Напомню, что все фактически началось в ноябре 2022 года.

С тех пор почти все подобрали модели себе под свои задачи. Для кода и технических задач я давно остановился на Claude Sonnet, начал с 3.5 и остановился на 3.7, несмотря на релиз версии 4.0. Непосредственно для работы я использую YandexGPT Pro, которой могу отправлять в том числе то, что попадает под NDA.

Однако у такого подхода есть одна по-настоящему серьезная проблема — отсутствие долговременного контекста и полноценной мультимодальности. Я научился решать практически любые задачи с помощью разных инструментов, например почти каждый из моих ботов был написан с помощью разных моделей, для меня это даже стало своеобразным бенчмарком. Но мне нужно было каждый раз с нуля погружать модель в контекст своих целей и показывать свои предпочтения. К тому же, мне хотелось показывать модели дополнительные ресурсы, от веб-страниц до диаграмм последовательностей, что часто было затруднительно.

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

Фактически, основной развилкой для меня был выбор между непосредственной работой с моделями, доступными в России и любым способом доступа к западным платным моделям. Выбор был сделан в пользу первого варианта, так что вариантов у меня стало не так много — YandexGPT, DeepSeek, Qwen и Mistral AI (Le Chat).

Я сравнил результаты выполнения заданий, связанных с написанием кода и редактурой текстов всеми этими моделями, и достаточно уверенно сделал выбор в пользу Qwen, и вот почему:

1. Qwen действительно быстрый, лишь немного медленнее чем Le Chat и в разы быстрее DeepSeek.
2. Приложение и веб-версия работают стабильно, а поставщик этой открытой и бесплатной модели — одна компания (Alibaba).
3. Модель открытая, так что при необходимости доступа по API я смогу воспользоваться одним из российских сервисов Foundation Models (понятно, какой выбираю я).
4. Qwen действительно хорош в работе с русским языком. Вероятно, это стало одной из причин использования весов Qwen-2.5-32B-base на этапе претрейна при обучении YandexGPT 5 (подробнее на Хабре).
5. Модель показывает стабильно хорошие результаты для всех классов задач. YandexGPT я продолжу использовать для простых задач по обработке текста, особенно с информацией под NDA, или созданию регулярных выражений, но помощь с кодом и в принципе технологическими контекстами я поручаю другим моделям. Для работы у меня также остается плагин SourceCraft Code Assistant, который я использую в VS Code с той же целью, с которой люди используют Copilot, но я не использую его в свободное время сразу по нескольким причинам.

Не исключено, что в дальнейшем что-то из этого списка изменится, и я начну пользоваться другим инструментом, но пока что я сделал однозначный выбор и могу рекомендовать Qwen всем в качестве модели общего назначения.

Лучшая база данных фотографий, привязанных к месту

https://pastvu.com/

Как-то давно мне попадалась на глаза информация, что каждый год в интернете теряется около 0.5% информации, замещаясь чем-то новым. Я сходу не смог найти подтверждение, но интуитивно кажется, что это недалеко от истины. Ссылки ведут в никуда, бесплатные хостинги закрываются, посты в соцсетях удаляются, от некогда популярных ресурсов отворачиваются пользователи, все такое. Поэтому мне всегда нравились проекты, которые создаются сообществами и ведутся собственными силами. В этом есть некоторая гарантия, что информация будет жить дольше за счет чьего-то искреннего интереса.

Один из таких проектов — PastVU, как авторы сами пишут, это «Проект по сбору свидетельств прошлого. Взгляд на историю среды обитания человечества.». Работает он довольно просто, но эффективно — берется карта регионов на на OpenStreetMap, а к отдельным точка привязываются фотографии, которые загружают пользователи. Получается карта человеческих воспоминаний о каких-то конкретных местах.

Фотографии охватывают самые разные временные периоды, самые интересные лично для меня — оцифрованные чёрно-белые изображения позднесоветского периода. Но так попадаются настоящие раритеты, которые каким-то образом попадают к энтузиастам проекта. Охвачен фактически весь мир, но плотнее всего распределение по России. Если я правильно понял статистику, то сейчас на сайте около 2 миллионов аннотированных фото, что позволяет в том числе фильтровать изображения по конкретному периоду.

Проект опенсорсный, код выложен на GitHub под лицензией AGPL-3.0. На главной странице репозитория есть также краткая история проекта, как минимум один из основателей вам точно известен. Технические писатели могут внести свой вклад не только фотографиями, но и за счет улучшения документации, у проекта есть специальная страница, посвящённая этому вопросу.

В общем, рекомендую ознакомиться и поностальгировать.

Как именно ИИ угрожает профессии технического писателя [1/4]

Во-первых, меня страшно раздражает аббревиатура ИИ. В 90-е годы в переводной научной фантастике был введен термин ИскИн, и это было сделано людьми со вкусом, несравненно лучше ведь, чем безликий «ИИ».

Но есть и во-вторых. Я не особо беспокоюсь по поводу более продвинутых инструментов, которые смогут быстрее и эффективнее создавать тексты и сопутствующие материалы. Пусть ускоряют, пусть даже пишут за меня, я только за. Процесс создания и публикации контента — не самая затратный момент в работе, которому я в последние пару лет уделяю совсем все меньше времени. Меньше времени на рутину — больше времени на продуктовые задачи. Я сам пользуюсь и чат-ботами, и другими инструментами на основе нейросетей, от линтеров до первых, неуверенных экспериментов с агентами, и официальный курс в нашей компании — внедрять их как можно больше. В масштабах индустрии это сделает тексты дешевле, но я делаю ставку на то, что в итоге задокументированы будут те вещи, до которых никто и никогда не добрался бы, а качество документации будет в среднем выше при радикально меньших затратах.

Я говорю только о пользовательской документации к программным продуктам для самых разных аудиторий, вне зависимости от того, внешние они или внутренние. Документация в любом случае сама может и должна быть продуктом, решающим определенные задачи. Да, бывает документация других типов — проектная, для регуляторов и т.д., ее можно составлять для программно-аппаратных комплексов и прочих систем, но я всем этим не занимаюсь, и я не хотел бы рассуждать о том, в чем у меня нет достаточной экспертизы.

Причина моего беспокойства в другом. Мы пишем документацию для тех людей, которые так или иначе приносят деньги нашим работодателям, и привычки этих людей сейчас радикально меняются. Раньше у разработчика было, по большому счету, два варианта: изучать исходники и/или сопроводительные материалы — документацию, примеры кода, демо-примеры, вебинары, статьи. Сейчас же наш потребитель учится действовать иначе, пользуясь новым поколением инструментов. Меняется сам ландшафт сферы программной инженерии, и в следующих постах я постараюсь дать небольшой обзор этих изменений с точки зрения технического писателя.

Небольшой спойлер — угроза действительно есть, но не та, которую обычно имеют в виду.

#ai

Как именно ИИ угрожает профессии технического писателя [2/4]

Предыдущая часть

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

1. Открыть чат с наиболее умной и дорогой моделью и попросить проработать верхнеуровневую архитектуру. Можно до этого этапа сформировать ТЗ с требованиями и описанием системы.

2. Перейти в v0 или Loveable и подготовить интерфейс. Поиграться с дизайном, изучить варианты, зафиксировать какой-то вариант UI.

3. Открыть любимую IDE, будь то Cursor, Windsurf, что-то от JetBrains с Junie, VS Code с Copilot, ну вы поняли. Будет создан бэкенд, база данных, все проинтегрировано и подготовлено к развертыванию. На этом шаге используется архитектурная спецификация, подготовленная на первом шаге.

4. Подготовиться к списаниям с карты и начать контролировать процесс создания кода, нажимая Tab или просто комментируя происходящее в чате.

У этого пути есть множество вариаций, некоторым инструментам нужен MCP-интерфейсы, у некоторых — свой способ работы с окружением. Что-то я описал в упрощенном виде, что-то обязательно изменится в ближайшем будущем, а сам сценарий ориентирован на создание с нуля простого проекта, а не на поддержку и доработку существующих сложных систем.

Но кое-что можно понять уже сейчас — человек взаимодействует с инструментами на куда более высоком абстракции, и глубокое погружение в документацию просто не предполагается до определенного момента.

Значит ли это, что документация становится совсем не нужна? Я думаю, что даже в озвученном выше сценарии видно несколько мест, где документация всё-таки пригодится:

* Откуда-то нужно узнать о возможностях и базовых принципах продуктов, с которыми взаимодействует разработчик (частично может быть выполнено за счет запроса к чат-боту).

* Должен быть источник истины, чтобы можно было провалидировать результаты работы моделей.

* Сами модели должны откуда-то получить информацию.

Если первые два пункта не требуют радикального изменения существующих подходов к созданию документации, то последний представляет определенный интерес.

#ai

Как именно ИИ угрожает профессии технического писателя [3/4]

Предыдущая часть

Чтобы модели могли создать код на основе документации, им нужно узнать о содержимом этой документации. Это может произойти на этапе обучения или за счет передачи документации в контекст работающей модели.

С той или иной долей уверенности можно утверждать, что основная задача при подготовке документации для моделей — правильно перевести ее в удобный для нейросетей формат, а не изменить ее коренным образом. Насколько я знаю по собственному опыту и по конференциям, сейчас технические писатели редко погружены в эти задачи, чаще они выполняются ML-инженерами. То есть для обучения моделей нужна та же документация, которая существовала всегда, просто подготовленная особым образом. Но насколько глубокой должна быть подготовка?

Напомню, что хорошая документация почти всегда соответствует нескольким ключевым принципам, таким как Every page is page one. Документация, которую в идеальном случае увидит пользователь, должна быть понятной, легко воспринимаемой, атомарной, а информацию в ней должно быть легко искать. Подробнее см. в статье Should you write documentation differently for LLMs?

Иначе обстоят дела с документацией для агентских систем. Пока что рано говорить однозначно о каких-то связанных с документацией практиках работы с агентами, с начала их распространения прошло слишком мало времени. Да, их основная черта — автономная работа с любыми интерфейсами, но агенты могут сталкиваться со слишком объемным контекстом, странными API и просто выполнять свою работу неожиданным образом, что приведёт к дополнительной нагрузке на пользователя. Подробнее см. эту статью, описывающую основы работы с Claude Code. Она интересна сама по себе, а также в ней есть базовый пример документации для агентов. Она выглядит непривычно, и больше похожа на управление с помощью промтов, чем на обычную пользовательскую документацию, но ее, тем не менее, нужно писать и обновлять. Пока что, кажется, это должно быть скорее в зоне ответственности команды разработки, но я почти уверен, что в будущем это может измениться.

Интересную попытку осмысления этого вопроса с точки зрения технического писателя я видел в другой статье, напоследок советую с ней ознакомиться: Docs for AI agents.

#ai

Как именно ИИ угрожает профессии технического писателя [4/4]

Предыдущая часть

В предыдущих постах я постарался дать обзор изменений, происходящих с привычными способами разработки ПО. Теперь время оценить то влияние, которые эти изменения могут оказать на специалистов по документации. Приведу факторы в порядке возрастания значимости:

1. Инструменты на основе ML-моделей позволяют создавать документацию быстро и дешево

Я считаю этот фактор наименее значимым, так как если понятно, какой текст нужно написать, то большая часть работы уже сделана. Информация собрана, функциональность протестирована, с интерфейсом тексты согласованы. Это вещи, которые намного сложнее поддаются автоматизации, особенно если делать их для людей. Если говорить о доработке существующей документации, особенно для сложных систем, сложностей может быть больше.

Возможные последствия — бизнес может начать урезать затраты на документацию, так как разработчики смогут больше фиксировать какую-то информацию самостоятельно. Но это не сможет закрыть все задачи по управлению и особенно передаче знаний.

2. Люди меньше читают документацию, потому что сразу обращаются к чат-ботам и суммаризаторам для поиска информации

Это более серьезный фактор, который сейчас сложно однозначно оценить. Прямо на наших глазах видно, как перестраиваются человеческие привычки, и поиск информации стремительно уходит от поисковиков и сайтов в целом. Уверен, что эта тенденция будет только нарастать, но у такого стиля поиска информации есть понятный предел — там, где цена ошибки высока и нужна точность и достоверность, должен быть источник истины. Должны быть зафиксированные и проверенные знания, с которыми можно сверить ответы нейросетей, у которых процент галлюцинаций хоть и снижается, но вряд ли когда-то станет полностью равен нулю.

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

3. Люди начинают меньше участвовать в разработке программного обеспечения, делегируя это агентам

Я считаю, что этот фактор может иметь самый сильный эффект, так как будет перестраиваться сама структура рынка труда. Меньше денег будет выделяться со стороны бизнеса на главных потребителей документации — меньше будет потребности и в нас самих. Я уверен, что вместе с ростом продуктивности будет меньше потребности в людях, создающих типовые системы, но пока невозможно предсказать, где на самом деле будет проходить граница между типовыми решениями и вещами, для которых нужна человеческая экспертиза.

Некоторые вещи, тем не менее, могут быть либо частично, либо полностью недоступны для агентов. Я в первую очередь думаю о том, что находится на стыке физического мира и информационных технологий — сервера, сети, низкоуровневая виртуализация и в целом программно-аппаратные комплексы,но этим список не исчерпывается, просто именно такие вещи приходят мне на ум.

К тому же есть неясно, что делать со стремительно плодящимся кодом. Появится огромное количество сущностей, которые будут нуждаться в описании, категоризации и контроле. Будут ли этим заниматься технические писатели, сами программисты, специализированные агенты, получающие информацию от других агентов — покажет только время.

#ai

Как именно ИИ угрожает профессии технического писателя [Дополнение]

Предыдущая часть

Хочу показать одну понятную иллюстрацию из исследования, посвящённого изучению потенциальных последствий агентов: Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce

О чем вообще эта иллюстрация:

We visualize the desire-capability landscape of AI agents at work, and find critical mismatches (Figure 5). The worker desire and technological capability divide the landscape into four zones: Automation “Green Light” Zone (high desire and capability), Automation “Red Light” Zone (high capability but low desire), R&D Opportunity Zone (high desire but currently low capability), and Low Priority Zone (low desire and low capability). Notably, 41.0% of Y Combinator company-task mappings are concentrated in the Low Priority Zone and Automation “Red Light” Zone. Current investments mainly center around software development and business analysis, leaving many promising tasks within the “Green Light” Zone and Opportunity Zone under-addressed.

Если попытаться ответить на вопрос «что делать-то», можно попробовать выделить критические риски, которые может принести бизнесу использование нейросетевых инструментов, и предложить какие-то варианты митигации этих рисков. Я бы ориентировался на следующие пункты:

* Автоматически созданная документация может содержать ошибочную информацию, которая может иметь последствия вплоть до правового характера.

* Большие кодовые базы могут не уместиться в контекст модели, что приведет к фрагментации документации.

* Нарушение связи с программистами и другими участниками процесса разработки, что приведет к фрагментации знаний в организации.

* Документацию, созданную с меньшим участием человека, сложно поддерживать и развивать. Появляется необходимость в фиксации знаний о знаниях.

* Внешние модели могут и будут периодически сообщать пользователям неверную информацию о продукте.

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

Также имеет смысл углубляться в смежные области, которые связаны с управлением знанием и пользовательским опытом. Примерное направление — редактура получившихся ИИ-текстов, владение корпусом документации, повышенное внимание информационной архитектуре и смежным направлениям вроде UX-писательства, а также освоение других каналов поставки и распространения знаний.

На этом все, спекулятивный прогноз заканчивается. Приглашаю поделиться своими прогнозами, а может быть даже практиками, которые позволяют вам подготовиться к будущему нашей сферы.

#ai

О нейминге бигтеха

А вы когда-нибудь задумывались над тем, почему в акрониме FAANG нет буквы M, соответствующей Microsoft? Включены следующие компании: Facebook, Amazon, Apple, Netflix и Google. Я вот задумывался, но ленился пойти и выяснить.

Оказалось, что когда в 2013 году Джим Крамер, ведущий шоу о финансах и инвестициях Mad Money на американском канале CNDC, придумал объединить наиболее перспективные технологические компании в одну группу, Microsoft все еще был под руководством Стива Балмера, преемника Билла Гейтса. Это был не самый простой период для компании, считалось, что они отстают от набиравших силу облачных трендов, а где-то вообще потерпели поражение, как на рынке мобильных устройств. Команда шоу решила, что у Microsoft просто нет достаточного потенциала роста, чтобы рекомендовать инвесторам обратить внимание на эту компанию.

Но более того, изначально акроним звучал как FANG, и до 2017 года не включал Apple, давшую вторую букву A. Если я правильно понимаю, то примерно в этот же период акроним перестал быть в первую очередь финансовым и получил широкое распространение в технологическом сообществе. Он отвязался от конкретных компаний и стал, по большому счету, синонимом Big Tech. Дополнительным подтверждением этому служит то, что в 2015 году с биржи исчезли акции компании Google, потому что материнский холдинг был официально переименован в Alphabet, что никак не повлияло на буквы в FANG.

Изучив эту историю, я не мог не задуматься, что есть у нас. Я легко нагуглил МЯСО (Mail.ru Group, Яндекс, Сбер, Ozon), но мне этот акроним не нравится.

Предлагаю более благозвучный вариант — СВЯТ, включающий Сбер, Вк (VK), Яндекс, Т1 (или Т-Банк, кому что ближе).

Этот вариант мне нравится своей краткостью, но он упускает много крупных и важных компаний, поэтому можно ввести и расширенную версию — СВЯТОСЛАВ: Сбер, Вк, Яндекс, Т-Банк, Ozon, Солар (или 1С?), Лаборатория Касперского, Авито, Вайлдберриз.

Что думаете, хорошие варианты?

Технические писатели теперь и в GetMatch

У нас, по большому счету, для поиска работы есть не так много площадок — hh.ru, Хабр.Карьера и чаты в Телеграме. А недавно я случайно выяснил, что на https://getmatch.ru/ появились вакансии технических и UX-писателей. Не знаю, насколько давно они там, вакансий пока немного, но знак сам по себе хороший — значительная часть моих знакомых программистов и менеджеров, которые получают по верху рынка, нашли работу именно там.

Тут могла бы быть реферальная ссылка или что-то вроде того, но за рекламу мне пока не платят.

Пятничное чтиво 3

Harper Reed: My LLM codegen workflow atm

В последние месяцы я с головой ушёл в изучение ИИ, в том числе для задач, связанных с документацией. Я читаю про чужой опыт, потихоньку сам экспериментирую с агентами и думаю о трансформации своего собственного рабочего процесса.

Сейчас недостаточно просто отправлять запросы в чат, чтобы быть на острие технологий. При этом все меняется так быстро, что практически невозможно зафиксировать, чего в данный момент было бы достаточно. Но если и составлять список, то разработка с помощью агентом точно должна быть в топе рекомендаций.

Сегодня в моей любимой и нерегулярной рубрике статья неизвестного мне разработчика, который обобщает достаточно актуальный опыт как разработки проектов с нуля (к чему в первую очередь относится понятие вайб-кодинг), так и доработки существующих систем. Последнее представляет особенный интерес, так как в таких системах есть и кодовая база, не вмещающаяся в контекст, и разные версии API, и рассредоточенные знания об устройстве системы.

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

Помимо этого добавляются интересные детали работы с промтами, отличающеися для разных типов и стадий проекта. Также интересно посмотреть на то, как автор работает с умещением проекта в контекст и вообще управляет сложностью своих исправлений и дополнений.

P.S. Несмотря на актуальность самого подхода, с февраля 2025 года, когда была написана эта статья, многое успело измениться. Посмотрите также другую статью этого же автора, которая написана в июле: Basic Claude Code.

#чтиво

Что нового в Битословии за первую половину 2025 года

По работе я почти никогда не успеваю вовремя опубликовать чейнджлоги, с чем стараюсь бороться. Кажется, это распространяется не только на работу.

1. Самый большой текст, над которым я больше всего работал, и который кажется мне сейчас почти неважным — статья на Хабре про настройку спеллчекера CSpell. Обобщил опыт свой опыт за всю эпоху, которая предшествовала появлению нейросетевых инструментов. В итоге я почти не пользуюсь результатами собственного труда, сместив фокус на нейросети.

Пост со ссылкой на статью, а также дополнение к нему уже на моем сайте.

2. Написал программную серию постов, в которой изложил свой взгляд на возможные изменения в области технической документации, связанные с появлением нейросетевых инструментов. Кажется, эту серию тоже стоило опубликовать в виде статьи, чем я, вероятно, займусь в будущем, когда то, чем я занимаюсь по работе, начнет приносить первые плоды.

Первый, второй, третий, четвертый и пятый посты в серии.

3. Завел рубрику «Чтиво», в которой разрешил себе просто делиться статьями, которые я считаю действительно важными, и которые я до этого просто сохранял в свой Obsidian.

Ищите посты по тегу #чтиво, мой любимый — этот.

4. Написал несколько постов про нейросети в целом — DeepSeek: смотрим трезвым взглядом, Как я выбрал Qwen в качестве основной модели и пару связанных мелочей.

Ну и какое-то количество постов, которые не попадают ни в одну из категорий. Впрочем, еще больше вещей я как минимум пока не написал или не дописал.

В последнее время я с точки зрения профессиональных интересов перестал уделять внимание почти всему, кроме применения нейросетевых инструментов для задач, связанных с документацией. Я бы сказал, что этому я уделяю 90% внимания, 9% достается отношениям документации и бизнеса, а последний процент приходится на все остальное. Можно считать это анонсом контента, который будет тут публиковаться.

Спасибо, что читаете!

Разбираемся с локализацией чисел, валют и дат

https://alexjameson.github.io/articles/localization/

Написал краткую статью о правильном форматировании отдельных элементов для русского и английского языка. Всего 1069 слов с объяснениями, примерами и ссылками на стандарты. После прочтения не должно остаться вопросов, когда писать 230 000,00 ₽, а когда $2,890.24, и чем это обусловлено.

#знания