На этой неделе начал проходить курс LLM Start от DeepSchool. Познакомился с n8n - очень крутое решение для быстрого прототипирования сценариев с AI агентами. Можно буквально за 10 минут накидать на дашборде пайплайн для телеграм бота, который будет говорить прогноз погоды, курсы валют и т.п. В n8n море встроенных интеграций. Отлично подходит для автоматизации каких-нибудь рутинных действий. Можно сделать бота для релизов, для вопросов по документации из Confluence, задач из Jira и т.п.
deepschool.ru
Курс по LLM для IT-специалистов
Научитесь использовать LLM для решения бизнес-задач: чат-боты, ответы по базе, ИИ-сотрудники
🔥2
Forwarded from Архитектура Стартапа - Anton Skogorev Engineering & AI (Anton Skogorev)
AI-ассистент может замедлять рост инженеров — даже если ускоряет delivery.
https://www.anthropic.com/research/AI-assistance-coding-skills
Anthropic выпустили исследование: 52 разработчика начального уровня решали задачи с AI и без него.
Плохие новости:
— Скорость — почти без статистически значимого выигрыша.
— Понимание того, что ты только что сделал — заметно хуже (~−17%).
— Сильнее всего проседает debugging: умение читать ошибки, строить гипотезы и чинить причины, а не симптомы.
Многие используют ассистента как замену мышлению — делегируют ему не только "делать", но и "понимать". На короткой дистанции вы получаете буст, а на длинной — теряете в навыках.
И если вы научились или учитесь из AI извлекать повышение производительности, это может произойти за счет снижения квалификации.
Что стоит делать на регулярной основе лично каждому:
1. Для нового/сложного — режим Explain-first: "объясни, дай альтернативы", а не "сделай".
2. Для дебага — "план диагностики, дай гипотезы", а не "дай фикс".
3. В ревью — требовать 2–3 предложения: почему так, какие компромиссы.
https://www.anthropic.com/research/AI-assistance-coding-skills
Anthropic выпустили исследование: 52 разработчика начального уровня решали задачи с AI и без него.
Плохие новости:
— Скорость — почти без статистически значимого выигрыша.
— Понимание того, что ты только что сделал — заметно хуже (~−17%).
— Сильнее всего проседает debugging: умение читать ошибки, строить гипотезы и чинить причины, а не симптомы.
Многие используют ассистента как замену мышлению — делегируют ему не только "делать", но и "понимать". На короткой дистанции вы получаете буст, а на длинной — теряете в навыках.
И если вы научились или учитесь из AI извлекать повышение производительности, это может произойти за счет снижения квалификации.
Что стоит делать на регулярной основе лично каждому:
1. Для нового/сложного — режим Explain-first: "объясни, дай альтернативы", а не "сделай".
2. Для дебага — "план диагностики, дай гипотезы", а не "дай фикс".
3. В ревью — требовать 2–3 предложения: почему так, какие компромиссы.
Anthropic
How AI assistance impacts the formation of coding skills
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
👍1
Обновил
Добавлено
- Slice validation:
- HasUniqueValuesBy — ограничение, гарантирующее уникальность элементов среза по ключевой функции.
- Метод Validate в ограничениях — теперь ограничения можно напрямую использовать с
Изменено
- Инициализация валидатора — глобальный валидатор заменён на атомарный указатель для потокобезопасного использования. В тестах следует применять новые методы настройки валидатора.
- CheckNoViolations — теперь принимает вариативные параметры
- Документация — структура README переработана:
- добавлены разделы об установке, пользовательских ограничениях и путях к свойствам;
- расширено руководство по пользовательским ограничениям (детали об интерфейсах и примеры).
Исправлено
- Корректная обработка единичных нарушений, возвращаемых валидируемыми объектами в
Критические изменения
- Тесты, использующие
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 или настройку валидатора, необходимо обновить с учётом новых сигнатур и вспомогательных инструментов.GitHub
Release v0.19.0 · muonsoft/validation
What's Changed
Added
Slice validation: Slice, SliceProperty, Each, and EachProperty for validating slices with per-element constraints.
HasUniqueValuesBy: Constraint to ensure slice elements a...
Added
Slice validation: Slice, SliceProperty, Each, and EachProperty for validating slices with per-element constraints.
HasUniqueValuesBy: Constraint to ensure slice elements a...
🔥2
Forwarded from from:adam
Сегодня специфичный пост для инженеров.
Много юзаю 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.
Много юзаю 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.
🔥2
Хорошая статья с обзором зрелости агентной инженерии. Must read для ознакомления.
https://habr.com/ru/articles/1010430/
https://habr.com/ru/articles/1010430/
Хабр
8 уровней агентной инженерии
Способности AI в написании кода растут быстрее, чем наше умение этими способностями пользоваться. Поэтому рост баллов на SWE-bench не коррелирует с метриками продуктивности, которые волнуют инженерных...
🔥1
Третья попытка начать вести блог
Хочу снова попробовать вести блог. Тем, о которых хочется рассказать, накопилось много, но тратить на каждую статью по нескольку часов на написание и вычитку мне уже совсем не хочется.
Поэтому я решил попробовать другой формат: использовать нейросети как рабочий инструмент. Не для того, чтобы они писали вместо меня, а чтобы помогали с черновиком, структурой и формулировками. Сейчас достаточно надиктовать идею в телефон, получить заготовку и уже от неё отталкиваться.
https://igorlazarev.ru/p/third-attempt-to-start-blogging/
Хочу снова попробовать вести блог. Тем, о которых хочется рассказать, накопилось много, но тратить на каждую статью по нескольку часов на написание и вычитку мне уже совсем не хочется.
Поэтому я решил попробовать другой формат: использовать нейросети как рабочий инструмент. Не для того, чтобы они писали вместо меня, а чтобы помогали с черновиком, структурой и формулировками. Сейчас достаточно надиктовать идею в телефон, получить заготовку и уже от неё отталкиваться.
https://igorlazarev.ru/p/third-attempt-to-start-blogging/
Игорь Лазарев
Третья попытка начать вести блог
Хочу снова попробовать вести блог. Тем, о которых хочется рассказать, накопилось много, но тратить на каждую статью по нескольку часов на написание и вычитку мне уже совсем не хочется.\n
❤3🔥2👀1
Мы живем в эпоху "промышленной революции" в программировании
Мы живем в эпоху своеобразной промышленной революции в программировании. Ранее программисты много времени тратили на ручное кодирование, но с появлением кодинговых агентов процесс стал быстрее и дешевле. Ручное кодирование постепенно превращается в нишевую работу, а значимость других инженерных практик, таких как проектирование и коммуникация, возросла.
https://igorlazarev.ru/p/ai-industrial-revolution/
Мы живем в эпоху своеобразной промышленной революции в программировании. Ранее программисты много времени тратили на ручное кодирование, но с появлением кодинговых агентов процесс стал быстрее и дешевле. Ручное кодирование постепенно превращается в нишевую работу, а значимость других инженерных практик, таких как проектирование и коммуникация, возросла.
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/
Недавно я выпустил CommRelay - локальное приложение для стримеров, собирающее чат из Twitch, YouTube Live и VK Live в один overlay для OBS. В этой статье расскажу об инженерной части разработки, как я решил создать свое приложение и неожиданно получил рабочий desktop-продукт.
https://igorlazarev.ru/p/comm-relay-wails-experience/
❤1🔥1
Как Fable 5 воскресил мою заброшенную научную работу
Хочу поделиться опытом использования модели Fable 5 от Anthropic - сейчас это горячая тема, ведь модель доступна ограниченное время по подписке. До этого я воздерживался от подписки Claude Code, но маркетинговая кампания и buzz в чатах простимулировали попробовать. В итоге Fable 5 воскресил мою заброшенную научную работу: написал полноценное приложение для распознавания снимков звёздного неба и даже подготовил презентацию.
https://igorlazarev.ru/p/fable-5-experience/
Хочу поделиться опытом использования модели Fable 5 от Anthropic - сейчас это горячая тема, ведь модель доступна ограниченное время по подписке. До этого я воздерживался от подписки Claude Code, но маркетинговая кампания и buzz в чатах простимулировали попробовать. В итоге Fable 5 воскресил мою заброшенную научную работу: написал полноценное приложение для распознавания снимков звёздного неба и даже подготовил презентацию.
https://igorlazarev.ru/p/fable-5-experience/
❤3🔥2