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

А вы когда-нибудь задумывались над тем, почему в акрониме 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, и чем это обусловлено.

#знания

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

100 Rules for NASA Project Managers

Собственно, сборник правил, которые я скорее назвал бы принципами, для менеджеров проектов НАСА от 1996 года. Принципы в целом универсальные, и они мне очень нравятся.

Мои любимые:

Rule 7: One problem new managers face is that everyone wants to solve their problems. Old managers were told by senior management-"solve your own darn problems, that is what we hired you to do."

Rule 17: Talk is not cheap; but the best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly.

Rule 35: The number of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This means you should be able to construct a set of slides that only needs to be shuffled from presentation to presentation.

Rule 39: Reviews are for the reviewed, not the reviewer. The review is a failure if the reviewed learn nothing from it.

Rule 66: Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will astonish you.

Rule 81: NASA Management Instructions were written by another NASA employee like you; therefore, challenge them if they don't make sense. It is possible another NASA employee will rewrite them or waive them for you.

P.S. А еще есть русский перевод, но я, конечно, рекомендую смотреть оригинал.

#чтиво

Навыки технического писателя

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

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

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

Читайте здесь: https://alexjameson.github.io/articles/soft-and-hard-skills/

#карьера

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

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

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

В цикле, над которым я сейчас работаю, планируется три ориентированные на практику статьи. В первой рассмотрены основы работы с HTTP API — устройство, базовые запросы, работа с JSON.

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

Читайте здесь: https://alexjameson.github.io/articles/http-api-quickstart/

#навыки

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

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

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

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

#навыки

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

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

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

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

#навыки

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

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

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

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

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

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

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

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

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

#ai

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

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

Роль:

You are a user's 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. Don't 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

#ai

Data — Information — Knowledge — Wisdom (DIKW)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#знания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот и я запрыгиваю в последний вагон контента про нейросети в этом году со своими двумя кейсами. Первый кейс про то, как подключить нейросеть к 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/.

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

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

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

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

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

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

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

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

Протестировал Zensical от создателей Material for MkDocs

Статья: https://alexjameson.github.io/articles/zensical-review/

Созданная документация: https://alexjameson.sourcecraft.site/pink-sync-docs/

Не так давно команда разработчиков Material for MkDocs объявила, что они больше не будут заниматься развитием проекта, представив ему на замену Zensical. Я не мог удержаться от того, чтобы проверить новый SSG в деле.

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

Может показаться, что это пост не про нейронки, но им тоже нашлось применение. Документацию для примера я подготовил за два дня с помощью Claude Sonnet 4.5, бюджет — около 1 миллиона токенов плюс сколько-то токенов моего мозга на проектирование, ревью и доработку результатов. Сначала я создал спецификацию OpenAPI для абстрактного сервиса для синхронизации баз данных, затем проработал внешний вид и необходимую функциональность сайта в ТЗ, а потом на основе ТЗ и спецификации создал документацию в Markdown.

Также в качестве эксперимента я задеплоил получившийся статический сайт на SourceCraft Sites, наш аналог GitHub Pages.

Уровни автономности нейросетевых инструментов

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

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

1. Ассистент

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

Работает в отдельном интерфейсе вроде чат-бота, нужно переносить результаты работы вручную.

2. Валидатор

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

Может запускаться как часть CI/CD или с помощью плагинов в редакторе кода, IDE, Word или аналогах и поставлять результаты в том же интерфейсе, в котором проводится работа с текстом.

3. Полуавтономный агент

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

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

Изменения после работы агента в исходники после ревью и одобрения человеком. Типичные инструменты — от плагинов и форков VS Code до новых инструментов вроде Claude Code.

Здесь мы с командой сейчас. Мой любимый юзкейс — генерация релизнот.

4. Автономные агенты

К этому я подступаюсь в рамках экспериментов:

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

Контекст сохраняется между запусками агентов, например в memory banks с проработанными стратегиями обновления.

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

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

Инструменты мне пока что перечислить сложно, у меня есть кое-что из нашего внутреннего стека для экспериментов, но в экосистеме Anthropic это могло бы быть сочетание Claude Code + Claude Agent SDK + Claude Web + беcконечное число MCP, коннекторов и прочих интеграций.

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

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

«Цифровой аутизм в терминальной стадии»

«Я полгода буду мучить пустой канал, чтобы потом выдать лонгрид про уровни модели OSI через мнемонику про сосиску»

«Он совершенно точно уверен, что ботоголизм — это социально приемлемое хобби, а не способ избежать написания реальной документации».

Ни добавить, ни убавить.