В моей команде нет чёткого разделения на бизнес‑аналитика, системного аналитика, руководителя проекта и разработчика.
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.
AI ушёл дальше: “сделай мне форму регистрации с валидацией телефона по российским правилам, с подтверждением через SMS, с проверкой что номер уникальный в БД, дизайн как у соседних форм в проекте”.
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
повторяющуюся, шаблонную часть работы делает машина.
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
На Ютубе есть такой канал — М О Р И А Р Т И. В двух словах, это персонаж в маске, позиционирующий себя как владелец дарквебовского маркетплейса, который торгует роскомнадзорными медикаментами. Заметно, что на канал не жалеют бюджета: эффектный монтаж, красивые кадры, качественный звук и, главное, — очень мощные манипулятивные тексты. Его видео можно рассматривать как учебники по маркетингу.
генеральный директор Duolingo Луис фон Ан объявил, что платформа будет отслеживать использование ИИ сотрудниками в ходе оценки их работы. Теперь топ-менеджер заявил, что этот показатель решили исключить.
А кто это такой, чего он добился, и почему его мнение вообще важно в вопросах разработки?
ИМХО, проблема многих современных компаний в том, что люди со слабыми навыками разработки (но на высоких корпоративных позициях) почему-то начинают считать, что лично им разработка теперь стала понятна, и они могут принимать важные технические решения.
Дело не только в "повсеместном внедрении ИИ", но и в работе с техдолгом, автотестами, деплоем, наймом и увольнением разработчиков, решениями о том, какие конкретно технологии и инструменты использовать и т.п. Как правило, они принимают плохие решения, думая, что принимают хорошие.
Считаю, проблема не в нехватке источников информации, каналов, вычислительных ресурсов и тп. Проблема концептуальная - отсутствие у LLM понимания. Имитацию они могут сделать, ну это как попугай, он тоже вроде "говорит", но толку от этого не сказать чтоб много...
Первые три отгадал без проблем. Четвёртый считаю тоже отгадал - мой ответ был "либо оба писал ИИ, либо оба писал человек, либо какой-то прикол/ошибка".
У вас в чётвертом примере оба варианта содержат идентичный код
...видимо, вы так старались запутать читателя, что запутались сами 😂
Далее,
Угадай, кто написал код
Ниже — три пары функций.
...проблема не в функциях, синтаксисе, или коротких изолированных кусках кода.
Проблема в отсутствии ИИ понимания и мышления "в глубину". На любом мало-мальски крупном проекте эти проблемы в итоге начнутся, и эффективность пойдет вниз.
Можно конечно затыкать эту проблему более хитрыми промптами, агентами, mcp, "скиллами" и прочим - но скажите, кто это "затыкание" и донастройку каждый раз будет делать - человек или "ИИ"?
LLM и подобное - это хороший инструмент, НО только в уместных ситуациях (а не в 100% случаев) И в руках опытного специалиста (а не любого вайбкодера-вкатуна, путающего java и javascript).
Проблема начинается в момент, когда высказывания от вас - разработчика - типа таких:
По этим данным многие проекты стали закрываться примерно в пять раз быстрее.
...видят люди, далёкие от серьёзной разработки.
Это что же получается, теперь можно нифига не учить, нанимать кого попало, а "умный ИИ" всё сегенерирует сам? (ответ в их голове - да!)
У вас бывало такое, что кучу усилий тратишь на то, чтобы простом языком объяснить не-разработчикам сложность той или иной задачи, нюансы, условия, ограничения?
Теперь готовьтесь объяснять чужой спагетти-код, нагенеренный ИИ в промышленных масштабах. Потому что сам ИИ объяснить не сможет.
я по‑прежнему считаю LLM одним из самых сильных инструментов в разработке
А я - нет. Потому что LLM это не разработка, а имитация разработки. Иногда прокатывает, а иногда нет. Но самое интересное начинается, когда не прокатило и надо в сжатые сроки вникнуть в наспех нагенеренную белиберду...
По сути, это очень маленькая виртуальная машина, встроенная в приложение Яндекс Музыки и выполняющая роль интерпретатора для специального байт-кода
Я так и не понял, зачем там виртуальная машина...
формирует офлайн-рекомендации на устройстве. В нём закодированы операции: вычисление косинусов между векторами, матричные умножения, применение преобразующих функций — все те базовые операции, которые производят рекомендации и на серверах
....вы же сами писали до того, что на серваках у вас нейросеть. А вот это вышеперечисленное в TinyML - это не нейросеть, а скорее "более базовый" ML, типа матричной факторизации. Но для факторизации ни нейросеть ни виртуальная машина не нужны, там довольно прямолинейный матан...
Высокая проактивность: на этом уровне ожидается, что вы будете самостоятельно выявлять и решать проблемы. [...] Задача Ticketmaster: от Staff+ кандидата ожидается высокое качество решений по сложным проблемам, которые обсуждались выше. [...] Хорошим показателем вашей экспертизы является то, что интервьюер завершает дискуссию, обретя новое понимание или точку зрения.
Статья с интересными идеями, но конкретно эти моменты вызвали у меня напряжение и аллергическую реакцию.
Нет, проактивность - это всё хорошо. Но SD интервью - это обычно 1-2 часа времени максимум. Это не работа (которая длится неделями, месяцами, годами). Это попытка за сверхсжатое время, за разговором понять уровень кандидата. И не всегда успешная.
ИМХО, интервьюер находится в "нечестном выигрышном положении", ведь он многие задачи либо уже решал (и не за один час лол, а за дни и недели ресёрча, обсуждений, тестов), либо изучал детальные разборы типа этого. А кандидат - как правило, нет.
Я не знаю, сколько ticketmaster платит senior+, если это от $400k, то свёрхжесткие требования оправданы.
Но ведь этот подход могут взять на вооружение и компании помельче, с значительно более скромными бюджетами. В результате таких собесов наиболее выигрышным будет смотреться кандидат, который каким-то образом вызубрил и насобачился именно к такому типа собеседования и вопросам, нередко - за счёт откровенного жульничества (привет "осознанным меркантилам" и прочим "волкам").
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.
Вот кому интересно, и так всё это знают.
А кому не интересно - непонятно, зачем им этот курс нужен...
Красавчик.
Спасибо, - значит, не зря старался!
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
ИМХО.
Спасибо! Ну, возможно несколько сложноват или не было попадания в целевую аудиторию.
Вы нанимаете опытных специалистов не для того, чтобы указывать им, как делать. А чтобы они показывали вам, как следует делать.
Это:
Маркетинговое фуфло.
Повторю свой вопрос полугодовой+ давности:
ИМХО, проблема многих современных компаний в том, что люди со слабыми навыками разработки (но на высоких корпоративных позициях) почему-то начинают считать, что лично им разработка теперь стала понятна, и они могут принимать важные технические решения.
Дело не только в "повсеместном внедрении ИИ", но и в работе с техдолгом, автотестами, деплоем, наймом и увольнением разработчиков, решениями о том, какие конкретно технологии и инструменты использовать и т.п. Как правило, они принимают плохие решения, думая, что принимают хорошие.
Считаю, проблема не в нехватке источников информации, каналов, вычислительных ресурсов и тп. Проблема концептуальная - отсутствие у LLM понимания. Имитацию они могут сделать, ну это как попугай, он тоже вроде "говорит", но толку от этого не сказать чтоб много...
Первые три отгадал без проблем. Четвёртый считаю тоже отгадал - мой ответ был "либо оба писал ИИ, либо оба писал человек, либо какой-то прикол/ошибка".
У вас в чётвертом примере оба варианта содержат идентичный код
...видимо, вы так старались запутать читателя, что запутались сами 😂
Далее,
...проблема не в функциях, синтаксисе, или коротких изолированных кусках кода.
Проблема в отсутствии ИИ понимания и мышления "в глубину". На любом мало-мальски крупном проекте эти проблемы в итоге начнутся, и эффективность пойдет вниз.
Можно конечно затыкать эту проблему более хитрыми промптами, агентами, mcp, "скиллами" и прочим - но скажите, кто это "затыкание" и донастройку каждый раз будет делать - человек или "ИИ"?
По большому счёту, согласен с вами.
LLM и подобное - это хороший инструмент, НО только в уместных ситуациях (а не в 100% случаев) И в руках опытного специалиста (а не любого вайбкодера-вкатуна, путающего java и javascript).
Проблема начинается в момент, когда высказывания от вас - разработчика - типа таких:
...видят люди, далёкие от серьёзной разработки.
Это что же получается, теперь можно нифига не учить, нанимать кого попало, а "умный ИИ" всё сегенерирует сам?
(ответ в их голове - да!)
У вас бывало такое, что кучу усилий тратишь на то, чтобы простом языком объяснить не-разработчикам сложность той или иной задачи, нюансы, условия, ограничения?
Теперь готовьтесь объяснять чужой спагетти-код, нагенеренный ИИ в промышленных масштабах. Потому что сам ИИ объяснить не сможет.
В команде есть ответственные, авторы кода. Обычно можно понять, спросить "что имел в виду автор"...
В тоннах быстро созданного, плохо отревьюированного (или вообще не) ИИ-кода - отвественный - кто? И "что имел в виду "ИИ-автор"?..
А я - нет. Потому что LLM это не разработка, а имитация разработки. Иногда прокатывает, а иногда нет. Но самое интересное начинается, когда не прокатило и надо в сжатые сроки вникнуть в наспех нагенеренную белиберду...
Я так и не понял, зачем там виртуальная машина...
....вы же сами писали до того, что на серваках у вас нейросеть. А вот это вышеперечисленное в TinyML - это не нейросеть, а скорее "более базовый" ML, типа матричной факторизации. Но для факторизации ни нейросеть ни виртуальная машина не нужны, там довольно прямолинейный матан...
В статье есть примечательные приёмы словесности и риторики. Что-то из серии искусства управления мнениями.
НО!
По факту - довольно легко расти на растущем рынке.
А вот на падающем...
Статья с интересными идеями, но конкретно эти моменты вызвали у меня напряжение и аллергическую реакцию.
Нет, проактивность - это всё хорошо. Но SD интервью - это обычно 1-2 часа времени максимум. Это не работа (которая длится неделями, месяцами, годами). Это попытка за сверхсжатое время, за разговором понять уровень кандидата. И не всегда успешная.
ИМХО, интервьюер находится в "нечестном выигрышном положении", ведь он многие задачи либо уже решал (и не за один час лол, а за дни и недели ресёрча, обсуждений, тестов), либо изучал детальные разборы типа этого. А кандидат - как правило, нет.
Я не знаю, сколько ticketmaster платит senior+, если это от $400k, то свёрхжесткие требования оправданы.
Но ведь этот подход могут взять на вооружение и компании помельче, с значительно более скромными бюджетами. В результате таких собесов наиболее выигрышным будет смотреться кандидат, который каким-то образом вызубрил и насобачился именно к такому типа собеседования и вопросам, нередко - за счёт откровенного жульничества (привет "осознанным меркантилам" и прочим "волкам").
Какой тонкий намёк на трактор и поросёнка Петра...