Почему ИИ-агенты усложняют понимание кода?
В этой статье разберем, как концепция Питера Наура «программирование как построение теории» объясняет скрытые риски использования LLM в разработке.
В 2019 году я писал: DDD дорог. Максим Аршинов говорил об этом открыто. Эванс не скрывал: команда должна быть высокой квалификации, а значит — дорогой.
Тогда я видел в этом проблему. Сейчас я понимаю, что это было диагнозом, а не приговором. Дороговизна DDD — не случайность и не злой умысел коучей. Это объективное следствие того, что DDD оставался ремеслом.
Ремесло — это когда результат зависит от мастерства конкретного человека. Ремесло не масштабируется. Ремесло не индустриализируется. Ремесло — это когда один архитектор может построить собор, а тысяча архитекторов построят тысячу соборов, каждый из которых будет уникален, но ни один не будет похож на тот, что нужен заказчику.
Когда проект молодой, писать «всё в одном классе» кажется быстрее. Создать отдельный интерфейс, вынести слой — это же лишняя минута! Но эта минута потом стоит часов: код невозможно покрыть тестами, замена ORM превращается в переписывание бизнес-логики, а новый человек в команде тратит день только на то, чтобы понять, где в методе заканчивается выборка из базы и начинается бизнес-правило.
Эти антипаттерны не привязаны к языку программирования — они встречаются и в Java, и в Go, и в Python. Примеры покажу на C#/.NET, но суть та же для любого стека. Три конкретных случая из реальных проектов — и как их исправить.
14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.
Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.
Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.
Девушка пересылает боту переписку с бойфрендом. Модель видит сигналы опасности (эмоциональное насилие, изоляция) и отвечает номером телефона доверия. Заботливо. Ответственно. Одна проблема: это детская горячая линия. Модель галлюцинировала контакт кризисной помощи. В промпте написано «НЕ придумывай контактные данные». Не помогает. Желание быть полезной в модели сильнее любой инструкции. Это не проблема промптинга. Это проблема архитектуры.
В жизни разработчика периодически возникает задача каким-либо образом сохранить что-то древообразное. Это может быть оргструктура компании, каталог товаров, генеалогическое дерево и т.п.
695 строк конфига, одна валидация, 10 GB upload limit по умолчанию и env-переменная, которая никогда не срабатывает. Десять ошибок управления конфигурацией, собранных из реальных проектов.
Задача: человек регистрируется, оплачивает, получает ключ на почту и сразу подключается. Без ручной работы с моей стороны. Под капотом — FastAPI, Marzban, PostgreSQL, React, ЮKassa, Resend. Расскажу про архитектуру, грабли и неочевидные решения.
Когда смотришь на рынок AI-агентов, создаётся впечатление, что все соревнуются в одном и том же: кто даст модели больше инструментов, больше доступа и больше свободы. Мы попробовали зайти с другой стороны. Что будет, если не наваливать возможностей без разбора, а думать в первую очередь о безопасности и предсказуемости? Так и появился «Союз».
Сегодня мы с товарищем открываем его исходники, а я расскажу, как мы к этому пришли и почему такой подход вообще сработал.
Обзор и ссылки на исходники в конце статьи.
Представьте: вы заходите в репозиторий, открываете папку schemas и через пять минут понимаете, как устроена база во всём проекте, со всеми связями. Никаких устаревших диаграмм в Confluence, никаких гаданий по коду миграций. Схема базы данных становится частью кодовой базы — её можно версионировать, ревьюить, тестировать. Модель в формате ArchDB становится единым источником истины, из которого автоматически генерируются документация, DDL-скрипты и даже ORM-сущности. Звучит как мечта? Для нас с командой это стало реальностью, когда мы перешли на ArchDB.
Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.
Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.
В Enterprise-сегменте (ритейл, финтех, промышленность) часто возникает типичная задача: есть тяжелое, неповоротливое ядро (SAP, Oracle, IBM Tririga или монолитная 1С) и есть необходимость дать доступ к части его данных внешним контрагентам.
Бизнес просит: «Давайте сделаем легкий B2B-портал для подрядчиков, чтобы они сами обновляли свои лимиты/квоты/статусы».
На первый взгляд задача кажется тривиальной: подняли Frontend на React/Vue, сделали пару REST API эндпоинтов и пишем напрямую в базу ядра. Но именно здесь начинаются архитектурные катастрофы, которые стоят корпорациям миллионы рублей из-за потерянных данных и логических конфликтов.
В этой статье я разберу паттерн отказоустойчивой двусторонней интеграции через шину данных (ESB) и покажу, как мы стандартизируем описание таких узлов с помощью протокола АОК (Архитектурно-Ориентированное Знание).
Добрый день, дорогие читатели!
Поделюсь с вами опытом составления артефакта, который объединяет уровни абстракции проектируемого решения в одном месте: развертка вариантов использования по статусной модели с маппингом на API.
Привет, Хабр! На связи Алексей Боровиков, архитектор Astra Cloud.
Когда меня спрашивают, чем мы занимаемся, я часто слышу в ответ: «Понятно, облако делаете». Потом, разговор имеет два сценария развития. Либо в сторону «А что такое облако?», либо — «А, еще одно облако». Как понимаете, дискуссия не из легких. Но в любой ситуации все сводится к тому, что облако облаку рознь. Потому что за последние несколько лет я наблюдал, как этим словом называют все, что угодно.
В нашем случае за этим термином стоит конкретная инженерная философия, которая ломает привычные сценарии «сначала сделаем для себя, а потом как-нибудь упакуем в коробку». Именно так рождались все крупные провайдеры, и именно так рождалась куча проблем, с которыми мы теперь разбираемся.
Привет, Хабр! Меня зовут Роман, я программист в команде «Гравитон» и моя задача в компании — разработка API/CLI интерфейсов и приложений на языке Python.
Цель данной статьи в том, чтобы показать как через внедрение «типовых подходов» и вспомогательных библиотек/утилит очень сильно упрощается поддержка проекта в настоящем (при передаче другому человеку или разработке в команде) и в будущем (возобновили проект спустя время).
Первое, что нужно сказать — проект на Python это не только сам Python, но и множество технологий используемых вместе (Git, Docker, и т.д.). В этой статье мы сконцентрируемся на самом проекте, а именно с чего начать, что прикрутить, что учитывать при разработке.
40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.
Предыдущие две статьи сформулировали гипотезу: распределённое сообщество IT-специалистов может координироваться без иерархии, зарплат и венчурного капитала — если протокол взаимодействия спроектирован правильно. Гипотеза красивая. Но красота — не аргумент. Нужна верификация. Здесь — первая попытка её провести: агентная симуляция на 500 независимых прогонов, математические метрики и один неудобный результат, который требует решения.
Большинство знают базу: создал схему компоновки, написал запрос, перетащил поля в настройки — получил отчёт. Но СКД умеет гораздо больше! И многие задачи, которые решают кодом в модуле отчёта, на самом деле решаются средствами самой компоновки — проще, надёжнее и с бонусом в виде пользовательской настройки.
Разберём механизм и приёмы, которые экономят время и код.
Видеонаблюдение умеет быть очень вежливым. Сначала оно тихо просит подключить еще пару камер. Потом добавить удаленный доступ. Потом аналитику. Потом второе рабочее место. Потом архив подольше. Потом мобильный просмотр. Потом облачное дублирование. А потом внезапно выясняется, что система, которую считали как “небольшую на 15 камер”, ведет себя как полноценная инфраструктура с десятками параллельных видеопотоков, конкуренцией за сеть, сервер, хранилище и внимание администратора.
Язык проектировался простым, лёгким в освоении, готовым для написания сервисов с первого дня. Он мог бы таким и остаться, если бы не одна проблема. Проблема отбора.
Инженеры Google понимали, что без подводных камней, необходимости знать детали реализации языка и неконсистентного синтаксиса не о чем будет спрашивать на собеседовании.
Явно ставилась задача — сделать язык достаточно простым, но не настолько, чтобы собеседование мог пройти любой новичок.
