Два года назад я писал диплом. Это был серьёзный, монументальный проект: классические микросервисы на Java, тяжёлый фронтенд, настройка CI/CD пайплайнов, возня с Docker, чтобы всё это красиво деплоилось. Я потратил на это полгода своей жизни, кучу нервов и литры кофе. Тогда казалось, что разработка любого нормального продукта — это долго, больно и требует армии программистов.
«Я собрал приложение за вечер на Claude. Разработчики больше не нужны».
Такие посты сейчас везде. Лента пестрит скриншотами красивых демок, историями «запустил стартап за выходные» и обещаниями, что теперь любой может стать продуктовым инженером.
А потом понеслась…
EnrichLead, собранный полностью на AI, взломали практически сразу после запуска. Ключи от сервисов лежали в открытом виде. Replit-агент, которому доверили продовую базу, просто её снёс и уверенно (далее…)
Вы отдали задачу инженеру, а через три дня она снова у вас: то с ворохом вопросов, то сделана наполовину, то с честным «я не был уверен и решил дождаться тебя». Делегировали ведь по‑настоящему, не сами сели делать, — почему вернулось?
Обычно потому, что отдали задачу, но не отдали всё остальное, без чего её нельзя довести самому: право решать, понимание, что считать готовым, и момент, в который свериться. Разберём, на чём делегирование ломается чаще всего, сколько свободы стоит отдавать и как отдавать так, чтобы не прилетало обратно.
Самая частая поломка — (далее…)
Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.
Любой практикующий архитектор знает: техдолг неизбежен. Он бывает двух видов — глупый (когда срезали угол просто потому, что лень) и осознанный (когда срезали угол ради продвижения выживания продукта на рынке). Вторая категория — это тот самый «долг со знаком плюс». Он работает на вас ровно до тех пор, пока процентная ставка не превышает экономическую выгоду.
«Она написала мне идеальную документацию. Триста страниц. Теперь я не понимаю не только код, но и документацию»
Код работает. Тесты проходят. А читать его невозможно. «Я бы написал это иначе» — думает каждый, кто открывал результат работы LLM-агента. Или другая сторона той же монеты: модель выдала исчерпывающий документ, в нём есть всё — а в голове после прочтения не остаётся ничего.
Мы привычно называем это «низким качеством». Плохо обучили. Недотюнили. Промпт кривой. Но давайте присмотримся: качество ли это?
С код-ревью есть такой парадокс: все согласны, что этот процесс важен, но времени на него обычно ни у кого нет. В результате ревью часто превращается в формальность. Очевидные баги при этом ловятся, а мелкие, вроде пропуска в условиях, перепутанных знаков, забытых edge cases и т.д., могут спокойно уехать в мердж и вернуться уже в виде задач в багтрекере.
В Content AI мы активно внедряем ИИ в разработку, и одна из задач, которую мы решали в этом году, — автоматизация код-ревью. В этой статье рассказываем, как одна из наших команд собрала ИИ-ревьюера, встроенного в Pull Request, и что мы поняли спустя месяц использования.
О неформальных архитектурах и о том, почему это всегда дороже, чем кажется
1. Управление иллюзией