На эту мысль меня натолкнуло обсуждение под прошлым постом про то, чему вообще стоит учиться разработчику, если ИИ пишет всё больше кода.

В комментариях довольно быстро разговор ушёл от самого кода к другому вопросу: а что происходит с системой после того, как код уже написан?

Допустим, агент за несколько минут сделал endpoint. Написал тесты. Тесты зелёные. Локально всё работает. Задача готова?

Мне всё чаще кажется, что самое интересное начинается именно здесь.

Потому что дальше появляются вопросы: – что произойдёт, если внешний сервис не ответит; – что делать, если запрос придёт повторно; – как система поведёт себя при частичном сбое; – что будет с конкурентными запросами; – можно ли безопасно повторить операцию; – не потеряем ли мы данные; – что произойдёт под нагрузкой; – и как вообще понять после релиза, что всё работает так, как мы задумали.

Написать happy path сейчас действительно становится всё проще. Но happy path - это ещё не система.

И здесь, как мне кажется, проходит довольно важная граница между просто написанием кода и инженерной работой.

Код может выглядеть аккуратно. Тесты могут быть зелёными. ИИ может уверенно сказать, что решение корректное.

Но кто-то всё равно должен спросить: а что здесь может пойти не так?

Последние месяцы именно поэтому мне всё интереснее разбираться в транзакциях, идемпотентности, конкурентности, отказоустойчивости, брокерах, наблюдаемости и System Design. Не потому, что хочется усложнить простую задачу архитектурой. А потому, что реальная система рано или поздно сталкивается не только с идеальным сценарием.

Наверное, поэтому я всё больше смотрю на разработку так: Работающий код – это только начало. Готовая система – это когда ты понимаешь, как она поведёт себя, если что-то пойдёт не по плану.

А где для вас проходит граница между "код работает" и "это уже можно считать готовой системой"?