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

Сегодня обновил api-testing v0.11.0

Что изменилось:

- assertjson: добавлена поддержка JSON Lines (NDJSON) — методы LinesHas, Lines(t, data).Has(...) для проверки нескольких JSON‑объектов в каждой строке;
- assertjson: добавлены проверки для массива строк;
- assertjson: расширены проверки строк — добавлены проверки на префикс, суффикс, целочисленные значения и числа;
- assertjson: методы Has и FileHas теперь возвращают булевое значение.

На этой неделе начал проходить курс LLM Start от DeepSchool. Познакомился с n8n - очень крутое решение для быстрого прототипирования сценариев с AI агентами. Можно буквально за 10 минут накидать на дашборде пайплайн для телеграм бота, который будет говорить прогноз погоды, курсы валют и т.п. В n8n море встроенных интеграций. Отлично подходит для автоматизации каких-нибудь рутинных действий. Можно сделать бота для релизов, для вопросов по документации из Confluence, задач из Jira и т.п.

AI-ассистент может замедлять рост инженеров — даже если ускоряет delivery.
https://www.anthropic.com/research/AI-assistance-coding-skills

Anthropic выпустили исследование: 52 разработчика начального уровня решали задачи с AI и без него.

Плохие новости:
— Скорость — почти без статистически значимого выигрыша.
— Понимание того, что ты только что сделал — заметно хуже (~−17%).
— Сильнее всего проседает debugging: умение читать ошибки, строить гипотезы и чинить причины, а не симптомы.

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

И если вы научились или учитесь из AI извлекать повышение производительности, это может произойти за счет снижения квалификации.

Что стоит делать на регулярной основе лично каждому:
1. Для нового/сложного — режим Explain-first: "объясни, дай альтернативы", а не "сделай".
2. Для дебага — "план диагностики, дай гипотезы", а не "дай фикс".
3. В ревью — требовать 2–3 предложения: почему так, какие компромиссы.

Обновил muonsoft/validation https://github.com/muonsoft/validation/releases/tag/v0.19.0

Добавлено

- Slice validation: Slice, SliceProperty, Each и EachProperty — для валидации срезов с ограничениями для каждого элемента.
- HasUniqueValuesBy — ограничение, гарантирующее уникальность элементов среза по ключевой функции.
- Метод Validate в ограничениях — теперь ограничения можно напрямую использовать с Each и This.

Изменено

- Инициализация валидатора — глобальный валидатор заменён на атомарный указатель для потокобезопасного использования. В тестах следует применять новые методы настройки валидатора.
- CheckNoViolations — теперь принимает вариативные параметры errors для улучшённой обработки ошибок и условий завершения.
- Документация — структура README переработана:
- добавлены разделы об установке, пользовательских ограничениях и путях к свойствам;
- расширено руководство по пользовательским ограничениям (детали об интерфейсах и примеры).

Исправлено

- Корректная обработка единичных нарушений, возвращаемых валидируемыми объектами в validateIt.

Критические изменения

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

Сегодня специфичный пост для инженеров.

Много юзаю Claude Code в последнее время и не отпускает одна мысль. В своё инженерное прошлое я всегда угорал по «лучшим практикам» — SOLID, TDD, Clean Architecture, DDD, property-based testing и тд. Большинство команд их игнорировали: сложно, долго, вэлью непонятно. И аргумент про сложность был честным — поддерживать чистую архитектуру и писать тесты до кода реально дорого по времени и когнитивной нагрузке.

Так вот. Кажется, агенты снимают порог входа в эти практики — написать тесты, нарезать интерфейсы, разложить по слоям стоит копейки, когда это делает Claude Code. А сами практики в ответ снимают ключевое ограничение агентов — контекстное окно.

Агент не может держать в голове весь проект. 250к токенов звучит много, но реальная кодовая база вылезает за эти пределы быстро. А даже если влезает — качество падает. Даже с 1м контекстом. Модель теряет детали, путает зависимости, начинает галлюцинировать.

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

DDD усиливает эту же идею: bounded contexts — это готовые границы того, что агенту нужно загрузить, а ubiquitous language делает код читаемым без дополнительной документации.

SOLID вообще читается как готовый чеклист «как сделать кодовую базу, с которой агент справится»:

- Single Responsibility — меньше кода нужно видеть для одного изменения
- Open/Closed — агент добавляет новую реализацию, не трогая существующий код, который даже не нужно грузить в контекст
- Liskov Substitution — можно подменить реализацию и ничего не сломается, а тесты это верифицируют
- Interface Segregation — агент видит только нужный ему срез интерфейса, а не всё подряд
- Dependency Inversion — для меня самый показательный. Модуль зависит от абстракции, не от реализации. Агенту не надо тащить в контекст код базы данных, чтобы написать бизнес-логику — хватит интерфейса репозитория

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

Отдельно про property-based тестирование. Штука всегда была нишевой — мало кто хотел возиться с генераторами и инвариантами, когда можно накидать пять юнит-тестов. Но с агентами property-based тесты должны давать непропорционально много фидбека при минимуме тестового кода. Один тест с правильно описанным свойством — это тысячи кейсов, которые агент прогоняет за секунды. При этом llm’ки куда быстрее придумывают все инварианты для тестирования, что снимает с разработчика когнитивную нагрузку на имплементацию подхода.

И вот что мне кажется самым интересным: property-based тесты идеально ложатся в цепочку PRD → TDD → реализация. Свойства системы из PRD («баланс не может быть отрицательным», «сумма позиций равна итогу заказа») транслируются в property-тесты почти один к одному. Агент получает свойства как спецификацию и пишет код, который им удовлетворяет. По сути requirements (R из PRD) становятся исполняемой верификацией — без ручной работы по переводу в десятки отдельных тестов.

Годами шли споры, стоит ли Clean Architecture и другие практики своих накладных расходов — всех этих дополнительных абстракций и интерфейсов. Будет забавно, если окажется, что именно эти «лишние» абстракции делают кодовую базу пригодной для работы с AI.

Хорошая статья с обзором зрелости агентной инженерии. Must read для ознакомления.

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

Третья попытка начать вести блог

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

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

https://igorlazarev.ru/p/third-attempt-to-start-blogging/

Мы живем в эпоху "промышленной революции" в программировании

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

https://igorlazarev.ru/p/ai-industrial-revolution/

Как я навайбкодил CommRelay и перестал бояться desktop-приложений

Недавно я выпустил CommRelay - локальное приложение для стримеров, собирающее чат из Twitch, YouTube Live и VK Live в один overlay для OBS. В этой статье расскажу об инженерной части разработки, как я решил создать свое приложение и неожиданно получил рабочий desktop-продукт.

https://igorlazarev.ru/p/comm-relay-wails-experience/

Как Fable 5 воскресил мою заброшенную научную работу

Хочу поделиться опытом использования модели Fable 5 от Anthropic - сейчас это горячая тема, ведь модель доступна ограниченное время по подписке. До этого я воздерживался от подписки Claude Code, но маркетинговая кампания и buzz в чатах простимулировали попробовать. В итоге Fable 5 воскресил мою заброшенную научную работу: написал полноценное приложение для распознавания снимков звёздного неба и даже подготовил презентацию.

https://igorlazarev.ru/p/fable-5-experience/