Это логично, специалистов мало, профит очень большой был, вот и ценились.

Никто ж не требует специалистов, которые способны добраться самостоятельно до работы, донести ложку до рта в обед, уметь читать и т.д. Это подразумевается. Вот и с программированием так же.

Логично, тогда грейды ничего не значат. Оба специалиста работают с fastapi у одного работает, а у второго зависает иногда, ну с кем не случается. Пишут же они оба на python, значит программисты.

«Время I-shaped специалистов закончилось… А потом утверждаете, что нужны специалисты которые разбираются глубоко… тех кто понимает и продуктовые метрики их еще меньше.»

Дмитрий, вы возможно не поняли концепцию буквы «T». Отказ от I-shaped не означает отказа от глубины. ​I-shaped — это когда человек знает исключительно синтаксис своего фреймворка, вообще не приходя в сознание относительно того, зачем это нужно продукту. ​Глубокое понимание никуда не делось. Вертикальная палочка в «T-shaped» — это и есть ваша хардкорная фундаментальная база. А вот горизонтальная перекладина — это понимание контекста: как ваша архитектура влияет на продуктовые метрики, ломает ли она юнит-экономику и какую бизнес-задачу мы вообще решаем. ​И вы абсолютно правы в том, что людей, которые понимают и то, и другое, катастрофически мало! Именно поэтому рынок сейчас разорван надвое. Огромная толпа узких I-shaped специалистов сидит без офферов, потому что их рутину съели алгоритмы. А те редкие специалисты, которые могут и архитектуру выстроить, и продуктовую метрику посчитать, забирают чеки х2 от рынка и диктуют корпорациям свои условия.

“Вы утверждаете любой джун с нейросетью может завайбкодить MVP… Нужен джун который разбирается… но при этом не программирует”

Порог входа для MVP действительно упал до нуля. Джун теперь — просто оператор нейросети, который генерирует рутинный код. Но как только эта сгенерированная поделка столкнется с реальной нагрузкой, она развалится. Валидируют код, проектируют базы данных и встраивают ИИ в реальные бизнес-процессы — люди системным мышлением.

​«ИИ не обучали на эталонно верных данных… Любой Джун через год будет понимать больше чем ИИ… писать для нейросети псевдокод глупо.»

​Пока вы надеетесь, что джун за год поумнеет, современные языковые модели демонстрируют выдающиеся результаты в анализе чужой логики, делают автоматический рефакторинг и находят уязвимости нулевого дня. ИИ — это экзоскелет, который увеличивает скорость написания рутинной логики в 2–4 раза

Грейды — это какие-то галерные заморочки, никогда их не понимал. Специалист должен решать задачу. Если он выбрал решать ее на фастапи в котором не способен рвзобраться, то дело тут не в фастапи. Еще хуже, если он ничего кроме этого фастапи не знает. Там разобраться минут за 15 можно.

сеньор и джун оба могут решить задачу, просто сеньор предусмотрит в коде больше решений под возможные расширения и возможные ошибки с учётом используемых на проекте решений. И если нужно будет потом доработать то, что делал сеньор, не нужно будет много переписывать. fastapi за 15 минут (понимаю, что написано для красивого слога), но сам понимаешь это просто поднять и что-то отправить в 1 поток, когда оно начнёт терять запросы и медленно отвечать начнется поиск нетипичных решений.

Вот именно. А задачу чаще всего можно решить вообще организационными методами. Мелко мыслите.

какую задачу? Где я мелко мыслю? Ощущение, что часть текста просто пропала

Ну какие у бизнеса задачи бывают? Бабло рубить. Ну или там облагодетельствовать человечество на худой конец. А вы про фастапи какой-то. Это любой дурак сможет, даже искусственный.

Понятно что функция бизнеса стремится к максимизации чистой прибыли. Но если декомпозировать задачу, реализация каждого шага требует решения которое должно работать и не сбоить, фастапи это просто пример одной из возможных задач на этом пути. Если решения не будут сделаны достаточно гибко то их доработка начнет уменьшать прибыль, если решения не будут стабильными то сбои еще уменьшат прибыль, а если списать по 100р с каждого клиента без его разрешения то репутационные потери возможно убьют прибыль. Так что грамотно построенный фастапи внутри проекта экономит каждый день деньги компании. И если бы всё было так просто то ничего в интернете не падало.

Значит не верно понял =)) Просил вчера Клода написать мне класс для работы с API(Log) яндекс метрики, в итоге вышло, что пришлось переписывать за него процентов 70. При этом всё равно нужно изучать API и понимать, какие библиотеки он использует и какие проблемы мы рискуем получить при интеграции в свою систему. По сути да, код запускается и работает, но в ETL его использовать нельзя. По ощущениям джун, написал бы лучше. т.к. он больше понимает в том, что нужно.

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

Дмитрий, парадокс в том, что ваш пример с Яндекс Метрикой как раз идеально подтверждает мой тезис из поста ​То, что вам пришлось вникать в API, оценивать риски используемых библиотек и понимать, как это ляжет в вашу ETL-систему — это и есть та самая настоящая инженерная работа. ИИ выдал вам синтаксис и базовый бойлерплейт. А вот адаптация этого кода под реальную архитектуру — это то, за что бизнесу всё ещё нужны живые мозги с широким кругозором. ​Ощущение «проще было самому написать» возникает в 90% случаев, когда нейросети ставят задачу в вакууме. Если попросить «напиши класс для API», она выдаст дженерик-код, который ожидаемо не встроится в сложный пайплайн. Если вы дадите джуну такую же абстрактную задачу без контекста вашего ETL, он принесет вам точно такой же нерабочий кусок кода, просто вы будете ждать его не 10 секунд, а два дня. ​ИИ не дает магию, он дает скорость. Но чтобы эта скорость работала на вас, нужно уметь декомпозировать систему и скармливать алгоритму правильный архитектурный контекст. Иначе это действительно превращается в переписывание 70% кода.

Ну по идее по готовой документацит он должен нормально методы реализовывать. Если сказать: «напиши мне метод», то, конечно, фигня получится. Как и джуну. Если есть документация, где описано как этот метод писать, и какие подводные камни могут быть, то код оно выдаст. Для этого конечно надо разбираться в технологии и понимать как она работает. Но это никак не связано со знанием конкретного фреймворка или языка. Реализовать этот метод можно будет хоть на ассемблере, хоть на бейсике. А вот непонимание как должно работать, неумение поставить задачу джуну и скатывание в микроменеджмент (сам все напишу) — это залет для инженера.

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

Джун пойдет почитает доки посмотрит как у нас и реализует, дольше, но работать будет как надо. И сам он опыт получит.

ИИ быстро генерирует код, но ей потом нужно долго описывать, что мне нужно хранить id запроса внутри класса и чтобы все методы имели доступ к этому ID для работы и смещать офсет чем то типа next. Если для человека это очевидно то нейрона требует сопровождения за руку. А в итоге ей нужно сказать что если сервер не отвечает, то зависать не нужно, типа это не очевидно =))) В итоге сомнительный прирост.

Как альтернатива микроменеджмент для LLM. Попросил сейчас Клода читать таблицу postgresql построчно не загружая результат запроса в RAM на Rust. Он решил забить на требование и сделал как в примере =) Ну чёт как-то так себе.

Дмитрий, ваши примеры отлично показывают, в чем сейчас главная сложность адаптации к новым инструментам. Вы пытаетесь взаимодействовать с нейросетью так же, как ставили бы абстрактную задачу человеку, ожидая, что алгоритм сам «додумает» ваш локальный контекст ​Во-первых, перечислять методы API руками давно не нужно — сейчас LLM просто скармливают готовую спецификацию (Swagger/OpenAPI) или ссылку на документацию(Notebooklm), и она сама генерирует нужные обертки. А отдавать эту рутину джуну просто ради «получения опыта» — непозволительная роскошь. Коммерческая разработка — это конвейер проверки гипотез, где важен time-to-market. Бизнес не готов сжигать бюджет на то, чтобы новичок два дня набивал шишки там, где базовый код генерируется за минуту. ​Во-вторых, вы говорите, что ИИ нужно «вести за руку»: детально описывать работу с офсетами, обработку таймаутов или жесткие лимиты по загрузке в RAM для Rust. Но парадокс в том, что умение четко сформулировать эти системные ограничения — это и есть настоящая инженерная работа! То, что вам кажется «очевидным», — это конкретные архитектурные требования. LLM всегда будет выдавать усредненный код из туториалов, если вы изначально не зададите ей жесткие рамки пайплайна. ​Нейросеть — это не телепатический сеньор-архитектор, это высокоскоростной исполнитель. Умение декомпозировать систему и грамотно переложить архитектурные ограничения в промпт — это навык, который экономит часы рутинной печати.

Тут нужно задачу смотреть конкретно, т.к. согласен делать простые циклы и функции которые можно со стека скопировать нейросеть умеет круто. Как только задача отходит в сторону, ей нужно писать, что как делать по сути меняя шило на мыло, а после тестов переписывать. По факту экономия если и будет то 15% максимум ну пусть в перспективе 25%. Я руководствуюсь не только опытом внедрения LLM у себя, но и в других компаниях, где работа с LLM в итоге свелась к копипасте кода который потом переделывали и снова экономия оказалась сомнительная.

Единственное, что я сейчас понял это то, что джун с LLM не может MVP сделать он просто работать не будет.

Не понимаю вас, вы явно говорите, что сложность возникает только при конкретной работе с инструментами, здесь справится только человек, так как бойлерплейт накинет нейронка, а весь тезис поста был как раз диаметрально противоположное про то, что надо становится «мультитулом», но дальше обоснования ваши только и свидетельствуют о том, что инженер только тот, кто досконально знает как правильно вести нейронку за руку, т.е. знает свою область углубленно, можете объяснить какова ваша позиция?

Вы абсолютно правы в том, что для управления нейросетью нужна глубокая экспертиза. Это и есть та самая вертикаль буквы «Т». Без хардкорного понимания архитектуры, баз данных и системных ограничений вы не сможете валидировать работу LLM — вы будете просто потреблять её галлюцинации ​Но суть моего поста в другом: сегодня одной только вертикали уже недостаточно для выживания. ​Раньше бизнес мог позволить себе оплачивать работу глубоких, но узких I-shaped кодеров, которые получали ТЗ, хорошо писали синтаксис и не вникали, зачем это нужно компании. Сейчас эту базовую генерацию кода забрали на себя алгоритмы. ​Поэтому критически важной стала горизонталь буквы «Т» — продуктовый и бизнесовый кругозор. Это понимание того, зачем вы вообще проектируете эту архитектуру, как она повлияет на юнит-экономику продукта и окупятся ли затраты на инфраструктуру.

Вы противоречите себе в каждом сообщении, первый абзац про то, что ничего нейронка не сможет без углубленных знаний управлябщего, а следующий, что нейронка сама напишет алгоритмы при удобном случае.

Синтаксис делает нейронка, а систему проектирует человек — где здесь противоречие?

Ваш главный тейк, что нейросеть может писать код и этот навык затмил джунов, поэтому джунам нужно расширять знания в междисциплинарном пространстве, но на каждый тезис с комментариев о проблемах с нейросетью, что они не умеют писать код и спасает всю ситуацию только исключительно конкретные знания написания кода, вы утверждаете, что это именно тот момент, который требует инженерного внимания и так далее. И буквально в следующем абзаце, вы пишете, что «Сейчас эту базовую генерацию кода забрали на себя алгоритмы.», и это противоречие. Вы утверждаете, что «знания синтаксиса» стали менее значимы, так как нагенерить код может алгоритм, то как по итогу вы получите хоть какой-то конечный продукт, если сами согласны с тем, что продукт не может быть сделан из-за неспособности нейронки в тот же синтаксис. Если вы так уверены, что надо развивать «горизонталь буквы «Т» – продуктовый и бизнесовый кругозор», то просто представьте, что у вас команда из N джунов, где все в один момент пошли по вашему пути, стали изучать бизнесовое общение и прочее, вместо навыка закрывать неточности нейронки, теперь знают свой продукт как свои пять пальцев, умеют в метрики и т.д., только эта команда вся в сумме не сможет создать даже один проект, и весь их кпд это мольбы в чате с агентом

Ильдар, вы подменяете понятия. Команда джунов, знающая только бизнес-метрики и не умеющая кодить — это не T-shaped. Это просто менеджеры. Я нигде не призывал ампутировать хард-скиллы (вертикаль), я говорю, что одной лишь вертикали сегодня мало.

Я не подменяю понятия, я привел вашу прямую цитату «Сейчас эту базовую генерацию кода забрали на себя алгоритмы.». Но уже подменяете понятия вы, так как я не говорил, что джуны не умеют кодить, я говорил про конкретный выбор, на перипетии которого, встают большинство разработчиков в текущей реалии, где всегда, можно погружаться в бизнес и быть более самостоятельной единицой в плане производства полноценного продукта, но это работает только с тем уровнем знаний, в которых нейронка вкупе с хардскиллами, которые позволят с нейросетью делать качественный продукт, т.е. не джун априори. И вы правильно подметили тот факт, если сделать этот шаг слишком рано, то можно скатиться просто в недоменеджера, оставаясь недопрограммистом, а нужен ли такой человек бизнесу?