Текстовые редакторы и IDE *

Есть в жизни вещи, которые приносят мне и радость, и печаль одновременно. Например, горький шоколад и markdown. Серьёзно, зачем он нужен? В половине случаев мы даже не используем этот язык целиком!

HTML — лучший язык программирования!

Вы наверняка слышали о людях, которые говорят, что из языков программирования знают только HTML. Да, все мы в этот момент закатывали глаза и пытались доказать, что HTML — это только язык разметки, а не программирования.

Да, наверно, мы правы, но у того, кто так говорит, есть то, чего нет у нас.

Нормальная жизнь.

[Примечание] Когда я говорю о markdown, то имею в виду конкретно CommonMark, если не указано иное. Дело в том, что это неоднозначная спецификация синтаксиса. Я люблю этот проект и ценю усилия разработчиков. Поломана не спецификация, а сам язык.

В данной статье рассматривается процесс настройки vscode для разработки встроенного ПО на базе ядер cortex-M и процессе превращения редактора в полноценную IDE. При этом большинство представленных расширений являются универсальными и применимы в широком спектре задач программирования.

В отличии от проприетарных решений, таких как Keil, подход использования редактора vscode + компилятор gcc позволяет гибко настроить каждый пункт от начала разработки до релиза продукта. За время своей работы мною было опробованы разные решения: от классического keil до связки sublime и CodeSourcery. В последние годы я перешел на vscode + msys2: практически все ПО Open Source, не требует лицензий, не ограничено 32 Кб кода и может работать без сети интернет.

Покупая подписку ChatGPT за 20$, вы получаете возможность использовать токены на сумму ~1000$. Покупая подписку к Claude за 100$, вы получаете токенов на сумму ~2000$. Но подключить эти подписки напрямую в Cursor нельзя. Формат запросов в API и подписке отличаются. Вам нужен обходной путь — проксирование запросов.

Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.

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

Контекст: я работал в Google в 2011 по 2024 год. Часть информации может быть приблизительной, и я буду дополнять её, если мне сообщат об ошибках. В этом посте речь пойдёт об основном монорепозитории Google (google3).

Фрагментированная экосистема

Как и во многих компаниях, в Google разработчики имели возможность самостоятельно выбирать IDE, и из-за этого возникла высокая степень фрагментированности. В 2011 году одним из самых опытных разработчиков-сениоров задали вопрос: «Можно ли как-то сделать так, чтобы все гуглеры пользовались одной хорошей IDE?». Если вкратце, они ответили «Нет». Джефф Дин ответил так:

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

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

Django, пожалуй, самый популярный фреймворк для разработки на Python. Да простят меня «питонисты» и «джависты», если я рискну сравнить важность этого фреймворка для Python c важностью Spring для Java.

Я активно пользовался ИИ-помощниками для разработки еще до Codex. В основном — через среды, которые сделаны именно для работы с кодом: подготовка наборов изменений, правка хранилищ кода и выпуск готовых правок.

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

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

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

Это конспект вебинара. Спикер — Даниил Степанов, разработчик‑исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

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

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

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

 Архитектура «оркестратор + сабагенты» на одном экране: ведущий агент держит план и раздаёт подзадачи изолированным сабагентам.

Один AI-агент в чате – это удобно, пока задача помещается в контекст. Как только она начинает разъезжаться по 30 файлам, четырём ролям и циклу «исследуй – реализуй – отревьюй – поправь», единый чат превращается в свалку: модель путает, какой шаг где, тащит решения из первой задачи в третью и стабильно проседает по качеству начиная с заполнения окна примерно наполовину. Схема «оркестратор + сабагенты» – это инженерный ответ на проблему: один ведущий агент держит план и раздаёт подзадачи изолированным сабагентам с пустым контекстом.

Мы у себя в Veai полгода живём с этой архитектурой в IDE-плагине под JetBrains. За это время накопилось достаточно граблей, чтобы написать честный текст: как это устроено, на каких задачах команда из агентов реально лучше одного, и где она проигрывает с разгромом.

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

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

Этот пост о моей новой программе для редактирования текста yvi — минималистичном текстовом редакторе, похожем на Vi, и созданном на Yabasic (Yet Another Basic).

Как и в предыдущие месяцы, по итогам апреля мы решили рассказать про то, как изменилась GigaIDE за прошедший месяц. Ниже краткий обзор обновлений PRO-функциональности GigaIDE, который можно найти на нашем маркетплейсе.

6 мая 2026 года в Сан-Франциско прошла вторая конференция Anthropic для разработчиков — Code with Claude. Площадку для мероприятия в этот раз расширили: в этот раз взяли бывший автосалон SVN West, так как спрос оказался выше.

Следующие 2 конференции пройдут в Лондоне и Токио (19 мая и 10 июня), а записи всех докладов должны опубликовать в ближайшее время на YouTube канале Claude Code.

Для тех, кто хочет посмотреть все доклады уже сейчас, опубликовал полную запись в ТГК (5+ часов видео).

Ниже пройдемся по всем докладам и отметим самое важное.

Год с Claude Code: как собрать рабочую конфигурацию с первого запуска

Жемал Хамидун, Head of AI Alpina Digital, CPO AlpinaGPT, автор тг-канала «Готовим ИИшницу».

Двенадцатый выпуск еженедельных IT-новостей от OpenIDE!

На этой неделе прошёл JPoint 2026, вышел Amplicode 2026.1 со Spring Agent Toolkit, а Anthropic впервые обогнала OpenAI по оценке на вторичном рынке. Плюс история о том, как AI-агент удалил продакшн-базу данных за 9 секунд.

Heap‑дампы JVM — бесценный источник информации при разборе аварий с OutOfMemory и оптимизации производительности. Но вместе с тем они же — потенциальные каналы утечки данных, ведь будучи снятыми с боевого сервиса, дампы уносят в себе всё, с чем работал сервис на момент снимка: логины, пароли (иногда в открытом виде), важные ID и тому подобное — словом, всяческие sensitive данные, которые не нужны для анализа, но могут навлечь на получателя дампа серьёзную ответственность и риски. Как этого избежать без ущерба делу — разбираемся под катом.

Цепочка короткая: сначала был просто автокомплит, потом появились чаты, в которые надо было руками копировать код туда-обратно (и человек выступал прокси между моделью и проектом — «много ручной работы, контекст рвётся»). Потом пришли агенты, которые живут прямо в проекте, читают и правят файлы, запускают команды. Сверху — агентские системы, которые координируют нескольких агентов и решают проблему перегрузки одного контекста.

Где живёт агент: три класса инструментов

В последнее время я почти каждый день работаю с Markdown-файлами.

Документация, спецификации, ADR, планы реализации, инструкции для AI-агентов — всё это удобно держать в .md. Формат простой, читаемый, хорошо ложится в git и нормально работает как для человека, так и для модели.

Но есть бытовая проблема.

Чтобы быстро посмотреть Markdown-файл, часто приходится открывать IDE. Разумеется да, любая нормальная IDE умеет показывать .md. Но запускать ради этого полноценную среду разработки — избыточно. Особенно если задача простая: кликнуть по файлу, быстро прочитать, скопировать кусок текста, закрыть.

Я начал искать лёгкий Markdown viewer и понял, что большинство найденных вариантов меня не устраивают.