Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Агент предлагает то с чем умеет работать и что обычно используется в подобных случаях. Использование технологий предлагаемых агентом - залог того, что система будет собрана быстро и надёжно. Именно это вам надо, а не мифическое понимание. Через три года всё равно никто не помнит, чего там было
Агент предлагает среднее по больнице, это просто ящик с вероятностями разных ответов. Ответ зависит и от вопроса, как он задан. В большинстве случаев агента надо хорошо "прогриллить", чтобы получить действиельно хороше архитектурное решение с оптимальными технологиями.
Использование технологий предлагаемых агентом - залог того, что система будет собрана быстро и надёжно.
То, что система будет собрана быстро, в некоторых случаях возможно, особенно если речь идёт о простом MVP. Но вот насчёт надёжности возникают вопросы. Откуда такой вывод? К тому же, если нужно построить что-то сложное, потребуется время, чтобы правильно направить агента, в том числе с помощью того же SDD.
SDD полудохлый. Он не работает
Что с ним не так?
А что это вообще такое этим spec driven development?
Что-то мертворождённое. Точнее так: узкое место сместилось с “уметь писать код” на “знать, что писать”. SDD верно нашло новое узкое место, но объявило его задачей письма, тогда как это задача знания. Отсюда и мертворождённость именно как методологии, “напиши спеки, получи софт”. Передача намерений и ограничений генератору кода это живой процесс, а не мертвая бумага/спека.
Намерения и ограничения не известны полностью даже автору: цена вопроса открывается инцидентами, исследование с экспертами делается итеративно. Понимание рождается внутри процесса. Спека это уже принятые решения, причины их теряются, в спеке их нет.
Бизнес спецификации = что я хочу.
Ограничения = что я могу.
Технические спецификации = что делать, основные на бизнес спецификациях.
Когда вы даёте только спецификации, разжеванные не имеющие оснований вы не можете ими управлять. LLM не поймет противоречий, не выберет оптимальный вариант реализации. И потому что не знает ценности и потому что не имеет ментальной модели (абстракций, удобных для анализа ситуации и синтеза решений)
Но бизнес потребности и ограничения LLM никто не даёт потому что сам не знает как и их цены. Чтобы их найти нужно исследование с экспертами предметной области. А чтобы взвесить и балансировать нужен архитектор. И не один раз, это итерационная работа.
LLM сродни автоматическому копи-пастингу на стероидах - оно умеет сшивать лоскуты абсолютно ничего в них не понимая, а только потому что статистически правдоподобно подходит.
Я бы не запрещал архитектуру, спроектированную с помощью AI
А я бы запрещал.
В момент популярности микросервисов мне практически никто не ответил "зачем". Необоснованные решения архитектора - полный его непрофессионализм.
Как раз тут
Но человек, принимающий решение, должен быть способен своими словами ответить на несколько вопросов...
то есть ключевую роль играет человек, он говорит системе ограничения, требования, далее смотрит какие есть варианты что-то реализовать, отдает модельке, и параллельно может сам накидывать свою архитектуру. Далее смотрит, может найдется нюанс, который он не заметил.
А теперь представьте какой нейрослоп генерят джуны с помощью LLM...
Там вообще никакого понимания нет, для них это магия, что нейросеть выплюнула - вам на ревью :)
С сеньора/техлида хотя бы спросить можно...
Основная проблема, на мой взгляд это что LLM даёт статистически среднее решение. И тут на сцену выходит товарищ Гаусс и говорит: "Ребята среднее решение будет хорошо работать примерно в шестидесяти процентах случаев, еще примерно в тридцати работать будет так себе и в ещё в десяти работать будет плохо или даже немного вредить." В большом проекте заранее сказать, где упадут эти самые десять процентов довольно сложно. Да и те тридцать которые "так себе" тоже могут довольно сильно испортить жизнь. То есть все результаты надо самому проверять и тут вопрос той самой "эффективности" встаёт в полный рост.
Статья спорная — особенно если абстрагироваться от частного кейса с MongoDB. С тезисом о том, что не стоит менять привычный стек просто "ради ИИ", согласен полностью: тащить новые технологии без понятного профита выглядит странно.
А вот по поводу квалификации инженера и технологий в эпоху ИИ мысль, как по мне, немного в другом направлении должна идти:
Фундамент важнее синтаксиса. Чем дальше развивается разработка (и тем более ИИ-инструменты), тем важнее понимание System Design и устройства систем в целом. Если ты глубоко понимаешь принципы работы БД, то переход на новый тип или стек — вопрос времени. Помнить абсолютно все нюансы и "кишки" конкретной СУБД в голове всё равно невозможно — ты регулярно будешь сталкиваться либо с чем-то новым, либо с хорошо забытым старым.
Перенос опыта. Инженер, умеющий проектировать масштабируемую систему на JS с соблюдением best practices, сможет собрать её и на Go, C# или Ruby. Да, на это уйдет больше времени из-за поиска подводных камней конкретного языка/рантайма, но архитектурная база останется той же.
Хороший инженер (Strong Mid / Senior / Architect) не должен быть завязан исключительно на один инструмент. Узкое знание тонкостей конкретного фреймворка без понимания картины в целом - это скорее про junior-уровень или очень специфичные ниши (вроде низкоуровневой оптимизации перформанса).
Архитектура первична, технологии вторичны. Технологии меняются, принципы остаются.
Фундамент важнее синтаксис...
тут согласен, но в статье нигде не говорил про синтаксис и т.д, я подчеркнул что если не понимать технологию на разбор инцидентов уйдет тонна времени.
Перенос опыта.
спорно, в том же js нет работы с указателями как в go, а в go нет таких вариаций указателей как в rust(не говорю уже про концепецию владения). Чтобы понять саму технологию,надо время, а также понимать когда стоит ее применять или нет. Плюс инженеру который работал только с реляционными бд нужно получить опыт с тобой же mongo, иначе можно так напроектировать систему что она не будет выполнять свой функционал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AI уже делает инженеров хуже? Как агентная разработка выращивает технологический зоопарк