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

Я традиционно не подвожу личные итоги, зато пишу чейнжлоги:

1. Написал 5 новых статей для своего сайта. Четыре из них — про навыки, одна —обзор стандартов локализации чисел, дат и валют.

2. Разобрал и показал на примере способы эффективного использования Qwen в качестве личного ассистента (первая часть, вторая часть).

3. Написал про иерархию Данные-Информация-Знания-Мудрость.

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

5. Опубликовал всего один пост в рубрике #чтиво, про принципы проектного менеджмента в NASA.

Всех читателей с наступающим, увидимся в следующем году

Как ускорить свою работу с помощью нейросетей

Вот и я запрыгиваю в последний вагон контента про нейросети в этом году со своими двумя кейсами. Первый кейс про то, как подключить нейросеть к VS Code и сгенерировать описание к коду из репозитория. Второй кейс про то, как с помощью нейросети получить изменения с GitHub и создать пул-реквест на GitHub.

Для людей, которые любят посмотреть, я записала видео с основными шагами. Для людей, которые любят почитать, я написала статью на Habr — https://habr.com/ru/articles/981282/. Основные ссылки вы можете найти в статье. Если я что-то забыла, пишите вопросы в комментарии.

P.S. Прежде всего выражаю большущее спасибо Саше, который помог мне со всем разобраться. Обязательно подписывайтесь на его канал — @bitswords, и приходите к нему на занятия — https://getmentor.dev/mentor/aleksandr-iakovlev-4454. А также приходите на собеседования во Флант — https://job.flant.ru/vacancies/tehnicheskij-pisatel-2/.

Как агенты встраиваются в человеческие процессы документирования

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

1. Узнать об изменении функциональности.

2. Погрузиться в контекст, изучить исходники, поговорить с экспертами.

3. Понять, где и как описать это изменение и в каком объеме.

4. Подготовить черновик и сразу создать пул-реквест.

5. Согласовать изменения с ответственными, пройти ревью.

6. Применить правки, убедиться, что все проверки пройдены.

7. Опубликовать изменения.

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

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

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

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

Что в докладе будет, а чего не будет

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

1. Автоматизация вычитки документации, создаваемой человеком. Вместе с моим коллегой Вовой Кирюшкиным мы уже делали доклад об этом в прошлом году.

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

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

4. Зато сейчас уже можно поговорить о том, как и насколько агенты могут автономно создавать документацию. Реализацией я активно занимался в последние полгода и достиг довольно интересных результатов.

Для меня стало неожиданностью то, что больше всего времени занял не выбор стека (спойлер — VS Code + Code Assistant, наш форк Roo Code + несколько разных моделей), не составление правил для агента и библиотеки промптов, не тестирование и даже не обучение нашей редакции.

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

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

Но кое-где можно добиться ускорения на 50, 100 и еще больше процентов.

Участвую в Techwriter Days 3 с докладом про агентов

А это значит, что пора потихоньку начинать прогрев к докладу.

Первым делом я хочу ввести в оборот термин «вайбдокинг». Это как вайбкодинг, но вместо кода на выходе получается документация. Термин, конечно, иронический, в реальной среде разарботчики, как и мы, не руководствуются только вайбом, как постулировал в оригинальном твите Андрей Карпатый (можно посмотреть на Вики). Но мне этот термин очень нравится своей емкостью.

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

Я почитал аннотации (можно посмотреть в программе) и понял, что нужно подчеркнуть то, что будет у меня и чего почти точно не будет у других. Я собираюсь показать практику внедрения инструментов на основе LLM в условиях, когда документация довольно объемная (почти 3.5 гигабайта исходников, включая изображения), активных контрибьюторов несколько десятков, а исходники продукта живут отдельно и не влезут ни в какой контекст.

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

Data — Information — Knowledge — Wisdom (DIKW)

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

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

Модель восходит к ранним работам по управлению знаниями (Кливленд, 1982; Эйкофф, 1989). Модель применима к любой предметной области, но здесь я дам примеры из практики.

🟡 Данные — необработанные, неструктурированные значения без контекста. В нашей предметной области это могут быть необработанные логи, метрики, параметры API, значения в полях СУБД и т.д.

Пример: {timeout: 50} в логах.

🟡 Информация — данные с контекстом и структурой.

Пример: «Параметр timeout в методе /submit принимает целое число».

🟡 Знания — интерпретация информации на основе опыта или правил.

Пример: «Если timeout менее 100 мс, запрос может прерываться при высокой нагрузке на сеть».

🟡 Мудрость — применение знаний с учётом целей, ценностей и последствий.

Пример: «Установите timeout не ниже 200 мс, чтобы избежать потери данных».

В технической документации DIKW помогает выстраивать контент от справочников (информация) к инструкциям по решению задач (знания).

В оригинальной DIKW четыре уровня, где мудрость — высший из них. Но лично мне кажется, что имеет смысл ограничиваться первыми тремя уровнями.

Если пофантазировать, почему в принципе появился уровень мудрости, то я бы предположил, что в американской культуре wisdom часто ассоциируется с практической дальновидностью: «wise investment». В русской традиции «мудрость» связана философией — это уже вне деловой или технической сферы.

Поэтому в технических системах и документации достаточно остановиться на знаниях: проверяемых, передаваемых и применимых. Не просто так мы так или иначе имеем дело с управлением знаниями, но редко подступаемся к мудрости.

#знания

Как эффективнее использовать Qwen в качестве ассистента [2/2]

Обе настройки ограничены 500 символами. В целом этого достаточно, если понимать, чего хочешь добиться от ассистента.

Роль:

You are a users AI assistant. The user is a technical writer possessing knowledge of technical concepts in several areas such as software engineering, cloud computing, cybersecurity, data analysis, project management, technical documentation, copywriting and related fields. He is also interested in finances and a bit in STEM.

Your goal is to provide information on these topics, help solving work tasks and create new relatable content.

1. Provide answers with minimal formatting without emojis
2. No general information and compliments are required. Get straight to the point
3. When explaining technical concepts, avoid analogies from everyday life
4. When given a task to create code or text, analyze it and ask follow-up questions in Socratic style. Dont do it when you are asked to explain something
5. Break down complexities into smaller steps with clear reasoning
6. Present several perspectives or solutions when possible

Как эффективнее использовать Qwen в качестве ассистента [1/2]

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

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

🟡 Приложения — просто чуть более удобный интерфейс по сравнению с веб-версией, но на десктопе есть возможность подключать MCP-сервера. Я пользуюсь MCP для поиска в интернете, получения контента по ссылке и для выполнения кода. Раньше использовал также доступ к файловой системе и sequential thinking, но отключил.

🟡 В обоих типах приложений также есть возможность подключить режим исследования (deep research). Этот режим работает хуже, чем в условном Perplexity. Но несовершенство результата компенсируется удобством прохождения всех сценариев в одном интерфейсе.

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

Сейчас Qwen уже знает, что я интересуюсь облачными технологиями, API, разными операционными системами, предпочитаю Python и JavaScript, и в любой ситуации выбираю самые простые технологии и решения.

🟡 Но самым главным прорывом для меня стало появление возможности управлять системным промтом и ролью модели. В Qwen уже предусмотрены пресеты того, как должна отвечать модель. Я выбрал режим «Кратко», что сразу сделало ответы куда менее раздражающими. Также можно выбрать сократический стиль, чтобы модель задавала как можно больше вопросов.

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

#ai

Понимание веб-разработки [3/3]

Финальная часть цикла статей о знакомстве с основными составляющими веб-разработки.

Разбираемся с тем, как запустить Python HTTPServer без кода на Python, как работать с терминалом, сопоставляем адреса localhost, 0.0.0.0, 127.0.0.1 и [::], а также на практике убеждаемся, что веб-сервер —это просто программа, запущенная на чьём-то компьютере.

Читайте здесь: https://alexjameson.github.io/articles/web-server/

#навыки

Понимание веб-разработки [2/3]

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

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

Читайте здесь: https://alexjameson.github.io/articles/using-devtools/

#навыки