Пишет @amastryukov

Brief intro – я лет 10 управляю разработкой весьма больших систем, в основном кожаными командами, но последнее время все с большим использованием AI. В общем, я значительно погрузился в кодинг с AI, причем не только с точки зрения разработки своего, но и мы сейчас немало правим/доделываем то, что навайбкодили другие (в рамках Ain’t Doctor)=) В основном, понятно, в медицине, где есть своя атмосфера. И мне таки есть что по этому поводу сказать.

Вайбкодинг позволяет очень быстро сделать красивое, работающее MVP. Но, в то же время, оно в 98% случаев является ДОЛБАННЫМ НЕПОДДЕРЖИВАЕМЫМ LEGACY from day one. То есть то, что сейчас красиво работает, через пару тройку месяцев, с ростом функционала, нагрузки, и т.п., превращается в ужасный ночной кошмар. Я где-то полгода писал пост в LI, что скоро мы увидим это массово, и вот оно.

Причина очень банальна – прежде чем писать что-то, надо сделать нормальную продуманную архитектуру, которая позволит продукту развиваться. Это может выглядеть как overkill на этапе тестирования гипотезы (ибо все говорят тестируй продажи как можно быстрее, нормальный продукт можно потом), но без этого все придется к чертям рефакторить по сути с нуля очень скоро.

Это достаточно просто и вшито на подкорку, если вы раньше разрабатывали что-то сравнительно большое сложное. Если нет, то этот этап довольно неочевиден, и тут надо либо воскурить матчасть, либо позвать кого-то, кто понимает.

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

- В системе у услуги есть просто «цена». Факт того, что у услуги могут быть разные цены для разны плательщиков (и режимы оплаты) не был учтен на этапе проектирования. Поэтому теперь надо переделывать систему записи, учета услуг, настроек услуг, оплат, и т.п. То есть это задевает примерно половину системы. Если бы в архитектуре это было предусмотрено, то оно прекрасно бы работало с 1 типом цены сначала, а потом уже могло элементарно расширяться.

- Большая система для работы с ритейлом сделана без разделения клиентов на отдельных tenants/instances, а массивы данных там дай Б-г. В итоге, первый клиент с настоящим объемом транзакций по сути кладет всю систему, и это нормально не решить просто увеличив мощность виртуалки. Там теперь переписывать всю структуру месяца два, так как куча функций уже есть, и при этом нельзя онбордить новых клиентов.

Да, продумывание архитектуры занимает время, и генерит блин большие страшные схемы, но зато оно позволяет продукту развиваться. Без этого получается не то что technical debt, а обычно technical bankruptcy.

Вторая вещь, которая может быть не настолько ужасна по последствиям (ну если вы не работаете в медицине как я) – это секьюрити. Calude/Codex имеет тенденцию творить отборную дичь, если ему прямо не сказать ее не творить – кидать сертификаты в открытый доступ (вот буквально вчера у товарища синьора), показывать наружу сервисы и эндпоинты которые не должны быть там, и прочее. Не надо так=) В целом, для большинства аппов вам не нужен сесурити эксперт из 8200, вам надо просто отдельно обсудить с клодом/чатом то, как вы будете выстраивать безопасность.

Side note – у разрабов часто бывает болезнь, что для одностраничника они хотят развернуть контейнеры, автоматические бэкапы, и запустить Redis (даже при отсутствии запросов вообще), просто потому, что они без этого чувствуют что что-то не так. Вот это некий оверкилл, что тогда, что сейчас.

Но я очень рекомендую потратить пару дней на архитектуру и безопасность прежде, чем вы начнете пилить что бы то ни было, иначе, если это вдруг полетит, оно может эпически прервать полет посредствам падения=)