#code_review — Public Fediverse posts

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

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

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

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

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

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

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает. Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров . Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами. Фича для эксперимента была такой: если выбранный фрилансер отказался от оффера, платформа должна автоматически найти следующего подходящего кандидата, отправить ему новый оффер и уведомить заказчика о переназначении. Claude написал спеку, реализацию и юнит-тесты, но полный сценарий отказа и переназначения не сошёлся. Два независимых ревью нашли одну и ту же группу ошибок: по отдельности сервисы выглядели нормально, а вместе работали не так, как нужно. На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается. Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними. В итоге спека получается подробной, но неполной: в ней есть локальные изменения по сервисам, зато нет системных инвариантов, которые живут между сервисами. Реализация может быть нормально разложена по слоям, тесты отдельных компонентов проходят, а ошибка обнаруживается уже на уровне сценария или ревью. Где LLM теряет контекст

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

#claude_code #specdriven_development #microservices #system_design #llm #архитектура #code_review #go #clean_architecture

AI Review не делает код лучше. И вот почему

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

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

#ai_review #code_review #llm #cicd #chatgpt #claude #gemini #openrouter #gitlab #github

AI Review не делает код лучше. И вот почему

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

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

#ai_review #code_review #llm #cicd #chatgpt #claude #gemini #openrouter #gitlab #github

[Перевод] Claude Code: почему HTML лучше Markdown

Markdown стал стандартным форматом для общения агентов с разработчиком. Простой, портативный, поддерживает базовое форматирование, легко редактируется. Claude даже научился делать ASCII-диаграммы внутри markdown-файлов. Но по мере того, как агенты становятся мощнее, markdown начинает ощущаться тесным. Файл длиннее ста строк уже трудно читать. Хочется нормальных визуализаций, цвета, диаграмм — и возможности легко поделиться результатом. К тому же я всё реже редактирую эти файлы руками. Чаще использую их как спецификации, референсы, брейнсторм-артефакты. Когда правки нужны, их вносит Claude — и тогда одно из главных преимуществ markdown исчезает. Я перешёл на HTML как основной выходной формат. Вот почему. (примеры можно посмотреть здесь: https://thariqs.github.io/html-effectiveness — возвращайтесь читать дальше)

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

#markdown #HTML #Claude_Code #AIагенты #формат_вывода #интерактивные_документы #SVG #спецификации #code_review #информационная_плотность

Гефестыч: наш опыт автоматизации Code Review через LLM. «Грабли», решения, код

Привет, Хабр! Меня зовут Данил Чечков, я Team Lead команды High End Meta Backend в «Леста Игры». Мы занимаемся всей web-составляющей «Мира кораблей». В нашем арсенале огромное количество микросервисов, работающих на Python и Go. Мы отвечаем за покупки в meta-валюте, авторизацию, стабильность инвентаря и профиля игрока, клановые сервисы, а также многое-многое другое. Наш основной продукт – высококачественные web-сервисы на стыке интеграции с игрой. И, да, интеграция – часть нашей работы. А ещё мы любим новые технологии и стараемся с ними знакомиться, чтобы оценить, как они могут принести выгоду бизнесу и нам. Одна из таких технологий – LLM

https://habr.com/ru/companies/lesta/articles/1029670/

#llm #pydanticai #openwebui #llamacpp #ollama #rag #code_review #selfhosted #atlassian

Гефестыч: наш опыт автоматизации Code Review через LLM. «Грабли», решения, код

Привет, Хабр! Меня зовут Данил Чечков, я Team Lead команды High End Meta Backend в «Леста Игры». Мы занимаемся всей web-составляющей «Мира кораблей». В нашем арсенале огромное количество микросервисов, работающих на Python и Go. Мы отвечаем за покупки в meta-валюте, авторизацию, стабильность инвентаря и профиля игрока, клановые сервисы, а также многое-многое другое. Наш основной продукт – высококачественные web-сервисы на стыке интеграции с игрой. И, да, интеграция – часть нашей работы. А ещё мы любим новые технологии и стараемся с ними знакомиться, чтобы оценить, как они могут принести выгоду бизнесу и нам. Одна из таких технологий – LLM

https://habr.com/ru/companies/lesta/articles/1029670/

#llm #pydanticai #openwebui #llamacpp #ollama #rag #code_review #selfhosted #atlassian

Гефестыч: наш опыт автоматизации Code Review через LLM. «Грабли», решения, код

Привет, Хабр! Меня зовут Данил Чечков, я Team Lead команды High End Meta Backend в «Леста Игры». Мы занимаемся всей web-составляющей «Мира кораблей». В нашем арсенале огромное количество микросервисов, работающих на Python и Go. Мы отвечаем за покупки в meta-валюте, авторизацию, стабильность инвентаря и профиля игрока, клановые сервисы, а также многое-многое другое. Наш основной продукт – высококачественные web-сервисы на стыке интеграции с игрой. И, да, интеграция – часть нашей работы. А ещё мы любим новые технологии и стараемся с ними знакомиться, чтобы оценить, как они могут принести выгоду бизнесу и нам. Одна из таких технологий – LLM

https://habr.com/ru/companies/lesta/articles/1029670/

#llm #pydanticai #openwebui #llamacpp #ollama #rag #code_review #selfhosted #atlassian

Гефестыч: наш опыт автоматизации Code Review через LLM. «Грабли», решения, код

Привет, Хабр! Меня зовут Данил Чечков, я Team Lead команды High End Meta Backend в «Леста Игры». Мы занимаемся всей web-составляющей «Мира кораблей». В нашем арсенале огромное количество микросервисов, работающих на Python и Go. Мы отвечаем за покупки в meta-валюте, авторизацию, стабильность инвентаря и профиля игрока, клановые сервисы, а также многое-многое другое. Наш основной продукт – высококачественные web-сервисы на стыке интеграции с игрой. И, да, интеграция – часть нашей работы. А ещё мы любим новые технологии и стараемся с ними знакомиться, чтобы оценить, как они могут принести выгоду бизнесу и нам. Одна из таких технологий – LLM

https://habr.com/ru/companies/lesta/articles/1029670/

#llm #pydanticai #openwebui #llamacpp #ollama #rag #code_review #selfhosted #atlassian

CodeClone 2.0: структурное ревью Python-кода для CI, IDE и AI-агентов

Когда я начинал CodeClone, это был довольно понятный инструмент: найти структурные клоны в Python-коде и не дать им незаметно расползаться по проекту. Сейчас вышел CodeClone 2.0.0, и это уже другой продукт. Не “ещё один линтер”, не попытка заменить Ruff, mypy, pytest, Bandit или Semgrep, а отдельный слой ревью: он смотрит на структуру Python-кода, отделяет старый технический долг от новых регрессий, связывает находки с покрытием тестами и дает одну и ту же картину в CLI, HTML-отчете, GitHub Actions, VS Code, Claude Desktop, Codex и через MCP. Эта статья не про список флагов CLI. Про флаги есть документация. Здесь я хочу рассказать, во что CodeClone вырос как продукт и зачем вообще нужен такой класс инструмента сейчас, когда разработка всё заметнее смещается в сторону AI-агентов.

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

#python #code_review #code_review_ai #quality_gates #ai_agents #static_analysis #test_coverage

$180 за три дня: история про архитектора, Cursor и пакет орешков

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

https://habr.com/ru/companies/simpleone/articles/1029070/

#Cursor #AI_в_разработке #вайбкодинг #code_review #ИИгенерация_кода #SDLC

$180 за три дня: история про архитектора, Cursor и пакет орешков

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

https://habr.com/ru/companies/simpleone/articles/1029070/

#Cursor #AI_в_разработке #вайбкодинг #code_review #ИИгенерация_кода #SDLC

$180 за три дня: история про архитектора, Cursor и пакет орешков

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

https://habr.com/ru/companies/simpleone/articles/1029070/

#Cursor #AI_в_разработке #вайбкодинг #code_review #ИИгенерация_кода #SDLC

$180 за три дня: история про архитектора, Cursor и пакет орешков

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

https://habr.com/ru/companies/simpleone/articles/1029070/

#Cursor #AI_в_разработке #вайбкодинг #code_review #ИИгенерация_кода #SDLC

Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

Один AI-агент может закрывать работу одного специалиста. Следующий шаг - собрать из таких агентов конвейер. Pipeline Triad Pattern - это модель enterprise-разработки, где каждый этап SDLC проходит через тройку ролей: Создатель, Критик, Арбитр. Не один “суперагент”, а цепочка специализированных троек с человеческим контролем в нескольких ключевых точках. Рассказываю, как устроен такой конвейер, чем он отличается от CI/CD, сколько стоит и где у него реальные пределы. Создатель + Критик + Арбитр

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

#aiагенты #multiagent_systems #llm #devops #devsecops #sdlc #code_review #orchestration #enterpriseразработка #pipeline_triad

Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

Один AI-агент может закрывать работу одного специалиста. Следующий шаг - собрать из таких агентов конвейер. Pipeline Triad Pattern - это модель enterprise-разработки, где каждый этап SDLC проходит через тройку ролей: Создатель, Критик, Арбитр. Не один “суперагент”, а цепочка специализированных троек с человеческим контролем в нескольких ключевых точках. Рассказываю, как устроен такой конвейер, чем он отличается от CI/CD, сколько стоит и где у него реальные пределы. Создатель + Критик + Арбитр

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

#aiагенты #multiagent_systems #llm #devops #devsecops #sdlc #code_review #orchestration #enterpriseразработка #pipeline_triad

Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

Один AI-агент может закрывать работу одного специалиста. Следующий шаг - собрать из таких агентов конвейер. Pipeline Triad Pattern - это модель enterprise-разработки, где каждый этап SDLC проходит через тройку ролей: Создатель, Критик, Арбитр. Не один “суперагент”, а цепочка специализированных троек с человеческим контролем в нескольких ключевых точках. Рассказываю, как устроен такой конвейер, чем он отличается от CI/CD, сколько стоит и где у него реальные пределы. Создатель + Критик + Арбитр

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

#aiагенты #multiagent_systems #llm #devops #devsecops #sdlc #code_review #orchestration #enterpriseразработка #pipeline_triad

Pipeline Triad Pattern: конвейер AI-агентов вместо команды разработки

Один AI-агент может закрывать работу одного специалиста. Следующий шаг - собрать из таких агентов конвейер. Pipeline Triad Pattern - это модель enterprise-разработки, где каждый этап SDLC проходит через тройку ролей: Создатель, Критик, Арбитр. Не один “суперагент”, а цепочка специализированных троек с человеческим контролем в нескольких ключевых точках. Рассказываю, как устроен такой конвейер, чем он отличается от CI/CD, сколько стоит и где у него реальные пределы. Создатель + Критик + Арбитр

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

#aiагенты #multiagent_systems #llm #devops #devsecops #sdlc #code_review #orchestration #enterpriseразработка #pipeline_triad

ИИ написал. Никто не понимает. Трогать страшно

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

https://habr.com/ru/companies/simpleone/articles/1021004/

#ИИдолг #технический_долг #AIgenerated_code #code_review #ИИ_в_разработке #SDLC

ИИ написал. Никто не понимает. Трогать страшно

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

https://habr.com/ru/companies/simpleone/articles/1021004/

#ИИдолг #технический_долг #AIgenerated_code #code_review #ИИ_в_разработке #SDLC

ИИ написал. Никто не понимает. Трогать страшно

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

https://habr.com/ru/companies/simpleone/articles/1021004/

#ИИдолг #технический_долг #AIgenerated_code #code_review #ИИ_в_разработке #SDLC

ИИ написал. Никто не понимает. Трогать страшно

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

https://habr.com/ru/companies/simpleone/articles/1021004/

#ИИдолг #технический_долг #AIgenerated_code #code_review #ИИ_в_разработке #SDLC

Как я сделал скилл для AI-ревью плана и кода — и зачем мне две модели

Когда одна и та же модель пишет код и проверяет его, она пропускает свои ошибки. Она «помнит», почему приняла именно это решение, и не ставит его под сомнение. Знакомо? Как вычитывать собственный текст: глаз замыливается, мозг подставляет правильный смысл туда, где его нет. В нормальной команде эта проблема решена давно: автор кода ≠ ревьюер. Два человека с разным контекстом и разными слепыми пятнами. С LLM можно сделать то же самое, взяв две модели от разных вендоров. Другая архитектура, другой pretrain - другие слепые пятна. Одна пишет, другая проверяет. В англоязычной среде этот подход называют adversarial review, «состязательное ревью». Суть: ревьюер не подтверждает, что все хорошо, а пытается сломать уверенность в решении. Я называю это проще: перекрестное ревью. У меня Claude (Opus) планирует и пишет код, а Codex (GPT-5.4) ревьюит. Автоматически, в цикле, пока не одобрит. Все это - один файл-скилл для Claude Code. О нем и расскажу.

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

#code_review #ревью_кода #AI_agents #Claude_Code #OpenAI_Codex #open_source #автоматизация_разработки #AI_code_review

Вася уволился — и унёс с собой 80% знаний о системе

Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.

https://habr.com/ru/companies/simpleone/articles/1017882/

#bus_factor #база_знаний #онбординг #adr #документация #управление_знаниями #code_review

Вася уволился — и унёс с собой 80% знаний о системе

Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.

https://habr.com/ru/companies/simpleone/articles/1017882/

#bus_factor #база_знаний #онбординг #adr #документация #управление_знаниями #code_review

Вася уволился — и унёс с собой 80% знаний о системе

Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.

https://habr.com/ru/companies/simpleone/articles/1017882/

#bus_factor #база_знаний #онбординг #adr #документация #управление_знаниями #code_review

Вася уволился — и унёс с собой 80% знаний о системе

Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.

https://habr.com/ru/companies/simpleone/articles/1017882/

#bus_factor #база_знаний #онбординг #adr #документация #управление_знаниями #code_review

Сеньор — уборщик чужого кода

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

https://habr.com/ru/companies/simpleone/articles/1014676/

#ии_в_разработке #технический_долг #code_review #управление_разработкой #SDLC

Ten Months with Copilot Coding Agent in dotnet/runtime
https://devblogs.microsoft.com/dotnet/ten-months-with-cca-in-dotnet-runtime/

#microsoft #NET #AI #Developer_Stories #CCA #Code_Review #Copilot_Coding_Agent #dotnet #dotnet_runtime #open_source

Ten Months with Copilot Coding Agent in dotnet/runtime
https://devblogs.microsoft.com/dotnet/ten-months-with-cca-in-dotnet-runtime/

#microsoft #NET #AI #Developer_Stories #CCA #Code_Review #Copilot_Coding_Agent #dotnet #dotnet_runtime #open_source

Топ-8 опенсорс‑инструментов, которые необходимы разработчику в кубере

Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме». Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.

https://habr.com/ru/companies/pt/articles/1009520/

#cybersecurity #backend #runtime #code_review #freelens #k9s #skopeo #bruno #zed

Три агента, один репозиторий, ноль менеджеров. Как я построил конвейер, где ИИ пишет, ревьюит и деплоит код

Месяц назад я закинул задачу на рефакторинг модуля авторизации и пошёл варить кофе. Кофе я допить не успел. Через двадцать минут пришло уведомление в ТГ: «staging обновлён, 94 теста пройдено, 0 упало». Открыл репозиторий. Ветка, diff на два экрана. Code review от второго агента. Три замечания, два по делу. Третий агент прогнал тесты и задеплоил. Код был чище, чем я обычно пишу по пятницам. Но до этого момента были три месяца граблей, упавший продакшен, и одна ночь, когда агенты сделали десятки бесполезных коммитов. Обо всём по порядку.

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

#LLM #AI_agents #python #code_review #автоматизация #docker #redis #claude #refactoring #AI

Claude Opus 4.5: как Anthropic сделала флагманскую модель в 3 раза дешевле и при этом умнее

24 ноября Anthropic выпустила Claude Opus 4.5 — и это не просто очередной апдейт. Модель стала в 3 раза дешевле ($5 vs $15 за 1M токенов), но при этом обогнала конкурентов по ключевым метрикам. Что изменилось: 80.9% на SWE-bench — лучший результат среди всех LLM для кода Работает автономно 30+ минут без вашего участия Экономия токенов до 76% через новый параметр effort В 4.6 раза устойчивее к prompt injection, чем GPT-5.1 Реальная экономика: Команда из 10 разработчиков экономит $4800-6000 в год только на стоимости API. GitHub Copilot после интеграции Opus 4.5 сократил расход токенов вдвое. В статье разбираем: → Детальные бенчмарки vs GPT-4 и Gemini → 5 практических кейсов с кодом (code review, генерация тестов, security audit) → Архитектуру AI-агентов на базе Opus 4.5 → Реальные цифры ROI и окупаемости → Ограничения, о которых молчит маркетинг Бонус: примеры интеграции в CI/CD, стратегия использования параметра effort и конфиги для мониторинга. Если вы используете LLM в production или только планируете внедрение — эта статья сэкономит вам недели экспериментов.

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

#Claude #Anthropic #LLM #AI #code_generation #API #GPT4 #нейросети #code_review #автоматизация

[Перевод] Ошибки, которые инженеры совершают при код-ревью

Код-ревью стало ключевым этапом в разработке: генерация кода с помощью LLM упростилась, а вот проверка его качества по-прежнему требует инженерной экспертизы. В новом переводе от команды Spring АйО эксперты сообщества подробно и на собственном опыте рассказали про нюансы код-ревью.

https://habr.com/ru/companies/spring_aio/articles/961332/

#java #kotlin #code_review #review #reverse_engineering #spring #spring_boot #spring_framework

We're Leaving Kubernetes
https://www.gitpod.io/blog/we-are-leaving-kubernetes
#ycombinator #gitpod #dev_environment #developer_environment #devops #cloud_ide #github_ide #gitlab_ide #javascript #online_ide #web_ide #code_review #remote_development #cloud_development #ready_to_code #cde #cloud_development_environment #platform_engineering #developer_experience #DevX #developer_velocity