Обновить
128K+
49
Антон Васильев@ToxaBes

ML Engineer / Архитектор корпоративного ИИ

158,6
Рейтинг
62
Подписчики
Хабр КарьераХабр Карьера
Отправить сообщение

С тех пор я и пытаюсь понять, как теперь должна выглядеть разработка

В разработеке вайб-кодинг это гусеница, harness это куколка, имаго-кодинг это бабочка.

Что такое имаго-кодинг расскажу позже, на этой неделе. Одним комментарием тут не обойтись.

Из песни слов не выкинешь. Заодно подкинул диванным экспертам новый термин, а то как попугаи используют "эффект Даннинга-Крюгера" к месту и не к месту, не понимая его сути.

Я то как раз определился.

Смысл моих сообщений пытался догнать вас, но вы в очередной раз оказались быстрее. Прекращайте атаку глупостью.

Это какие модели? 

Все на базе Qwen архитектуры:

  1. Qwen3.5-9B это база для кодинга в таком размере.

  2. Ornith1.0-9B для агентной работы. Это пост трейнинг Qwen3.5 под многошаговую работу в роли агента ценой ухудшения непосредствеено кодинга. Именно 1.0 версия, не 1.5.

  3. Qwopus3.5-9B-coder свежая модель, дистиллят Qwen на ответах Opus, заточена как под агенсткую работу, так и под работу с tools.

Приятнее всего, конечно, Qwen3.8-27b для агентского режима и Gemma4-31b для чата.

Вы правы, Qwen лидер среди моделей подобного класса, еще Ornith 35B неплох и работает быстро.

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

Это мое самоназвание, дальнейшее развитие работы с моделями над проектами после вайбкодинга/чата и харнесса/RAG. Поэтому расскажу сразу отдельной статьей.

Разумный минимум для работы с кодом это sonnet. А дефолтный opus.

В рамочку и в галерею самых сильных ИТ-заблуждений этого года. Из пушки по воробьям.

Я согласен, с тем что 8-9B модели гораздо хуже фронтирных, но базовые вещи они делают нормально. Это нормальное решение при малом количестве VRAM.

А вот ~30B модели при правильной подготовке показывают себя на уровне фронтир моделей прошлого поколения и иногда даже превосходят их в типовых задачах, но работают дольше.

Я вообще от фронтир моделей отказался и перешел с харнесс-кодинга, на имаго-кодинг, со временем статью напишу об этом. Фронтир модели периодически тестирую по мере выхода чтобы понимать что куда.

Раньше я часто начинала писать код «с коленки».

Первая цифра вашего года рождения 2.

А это значит, что у Вас появляется хорошая возможность меня просветить и объяснить, "по чём фунт изюма". 

Зачем? Я ни в коем случае не хочу самоутверждаться за ваш счет или чему-то учить, я не учитель.

Хотя, кажется, у меня есть для вас прекрасный собеседник, @Wesha

С ним вы сможете продуктивно обсудить все на свете, он специалист по всему.

Держите новый термин в копилку:

Ультракрепидаризм, означает привычку человека высказывать свое мнение, судить или давать советы по вопросам, в которых он абсолютно не разбирается и не имеет экспертных знаний.

У вас явно он.

Я не юрист, поэтому детально описывать не возьмусь, т. к. консультацию юриста статья на Хабре от не юриста не заменит.

В общем случае, если в договоре маскировать данные (убрать реквизиты и реальные названия), оставив только "заказчик" и "исполнитель", то никаких проблем использовать зарубежные облачные модели нет. В остальных случаях смотреть предметно.

За 20+ лет опыта в ИТ (у нас и за рубежом) видел раза четыре, когда человек не вкатывался за 1-2 недели и все эти разы оказывалось, что работник профнеприооден, его увольняли.

То что пишете вы буквально высасано из пальца и не имеет отношения к реальной разработке.

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

Про "корп RAG" я написал в контексте куда сейчас движется реальный онбординг, а не то что вы себе напридумывали.

Я думаю к Пн другие разработчики подтчянутся в комментарии и обьяснят вам реалии онбординга более детально. Про то что вы сами онбордились больше года я просто в голос посмеялся.

Может быть, попробуете огласить некий предполагаемый стек и решённую задачу?

Может быть, не будете пытаться аргументировать там где вообше не разбираетесь?

Без обид, но ваши комментарии просто говорят сами за себя.

Это не идеал, а реальность. В статье автор пишет о:

собственный опыт найма старшего разработчика в команду

Вы понимаете что это означает? Не джуна, не человека после курсов, а специалиста.

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

Точно подсчитать количество сэкономленных часов в итоге трудно, но я оцениваю разницу в месяцы: через четыре месяца новый разработчик мог самостоятельно работать с ключевыми частями системы примерно на том же уровне, что и я. Мне самому, когда я пришёл в этот проект без технического онбординга, на достижение сопоставимого уровня потребовалось больше года.

Серьезно? Технический специалист вникал 4 месяца в процесс работы? А вы вникали больше года? Таких снежинок с поздним зажиганием даже в толерантной европе увольняют за месяц, у нас и того быстрее.

Вся статья выглядит как попытка накидать мяса на скелет и надуть очередную сферу услуг. Какой-то идеальный, комфортный, теплый, мягкий онбординг на 4 месяца. Это какая-то дичь (с)

Онбординг делится на локальный/удаленный по нахождению работника и быстрый/долгий по его уровню.

Если это не условный кобол/драйвера/БАК и человек реально соответствует заявленной позиции, то первые коммиты пойдут от него к концу первой недели. Если компания очень большая и много бюрократии, то к концу второй. Стек известен, процесс разработки знаком, детали за неделю понять можно и первую задачку закрыть.

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

А вот эта вот адаптация снежинок в вашей статье сильно надумана и оторвана от реальности

gemma3:4b и gemma2:2b.

Для любой работы с кодом и в агентских сценариях разумная нижняя граница это 8-9B.

Не «не готов», а «не обучен».

Это в ЕС, в РФ именно что не готов, тк часто ставят либо самого "говорливого" либо самого технически грамотного из команды. Это называется "рост" в компании и именно это описано в статье.

Нормальный подход, который вы описываете, в последние лет 5 пришел только в топ компании.

А техлида как отдельной позиции зачастую и нет, как и архитекта.

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

До вас туго доходит в последнее время. Об этом и речь, каждый выбирает свой путь.

Вот об этой разнице статья.

Я в этой разнице живу.

Зато я вам могу.

На самом деле меня нельзя допускать до таких соревнований по причине профдеформации.

Я бы еще удалил у них от 5 до 10% нейронов рандомным куском (мушиный дропаут), чтобы посмотреть как их сеть перестраивается пытаясь восстановить функционал.

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

После этого попробуйте проверить, может ли рой мух классифицировать MNIST.

Собственно, всё. Тимлидство — это повышение смена профессии с обнулением стажа, отсутствием обратной связи, ответственностью без полномочий и скверной асимметрией риска. Сеньоры, которые отказываются, поступают рационально. Всем спасибо.

Я не буду разбирать, где именно вы не вычитали ИИ-слоп из своей статьи, давайте разберем ваш вывод.

Если вы считаете, что становитесь джуном переходя в тимлиды, то вы просто еще не готовы (как и произошло с тем кого вы описали).

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

При этом синьор может быть очень сильным в техническом плане.

По моим наблюдениям, чем сильнее синьор технически, тем меньше он хочет идти на лида, потому что ему в кайф писать код.

Это как разные ветки прокачки, если до упора прокачал техническую часть, то управленческая ветка недокачана и это фатально на новой позиции.

Мимо дважды прошел всю лестницу до CTO, понял, что хочу продолжать писать код и заниматься R&D в тех сферах, которые мне интересны, после чего ушел из найма.

Т. е. можно считать, что я также в итоге понял, что не готов.

1
23 ...

Информация

В рейтинге
31-й
Откуда
Россия
Зарегистрирован
Активность

Специализация

ML разработчик, ML Architect