Даёт удобство развёртывания в обмен на жертву некоторой степени производительности, безопасноcти и необходимости поддерживать доп. инструмент. В какую сторону и насколько склоняться - вопрос конкретного проекта. It depends.
Хз никогда не работал с подманом.
Где прописали, там и будут) или это вопрос на знание команды docker logs и подобных?
читать программу сложнее, чем писать.Потому что для чтения - требуется понимание. А для написания это необязательно - можно писать небрежно, можно копипастить из stackoverflow и всяких "ИИ" и т.п.
В разработке с "ИИ", ревью от опытного специалиста - это и есть бутылочное горлышко. Реальная революция начнётся тогда, когда "ИИ" начнёт решать задачи без или с минимальным ревью. Пока это не так, так что хайпа больше, чем реального прироста производительности.
LLM это не разработка, а имитация разработки. Иногда прокатывает, а иногда нет. Но самое интересное начинается, когда не прокатило и надо в сжатые сроки вникнуть в наспех нагенеренную белиберду...
так баг может вылазить на границах, когда нагрузочные равномерно давят по максимуму.
Это означает: забили на пользовательские сценарии и дата флоу. Или по-другому: нет времени думать, запиливай в продакшн быстро! У нас квартальный отчёт в понедельник! =) Не, понимаю, такое бывает. Проблемы начинаются, когда такое систематически и техдолг растёт аки снежный ком.
пока крупные компании пытаются заменить разработчиков искусственным интеллектом, сами разработчики избавляются от потребности в крупных компаниях с помощью ИИ))
В моей команде нет чёткого разделения на бизнес‑аналитика, системного аналитика, руководителя проекта и разработчика.
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.
AI ушёл дальше: “сделай мне форму регистрации с валидацией телефона по российским правилам, с подтверждением через SMS, с проверкой что номер уникальный в БД, дизайн как у соседних форм в проекте”.
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
повторяющуюся, шаблонную часть работы делает машина.
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
На Ютубе есть такой канал — М О Р И А Р Т И. В двух словах, это персонаж в маске, позиционирующий себя как владелец дарквебовского маркетплейса, который торгует роскомнадзорными медикаментами. Заметно, что на канал не жалеют бюджета: эффектный монтаж, красивые кадры, качественный звук и, главное, — очень мощные манипулятивные тексты. Его видео можно рассматривать как учебники по маркетингу.
генеральный директор Duolingo Луис фон Ан объявил, что платформа будет отслеживать использование ИИ сотрудниками в ходе оценки их работы. Теперь топ-менеджер заявил, что этот показатель решили исключить.
А кто это такой, чего он добился, и почему его мнение вообще важно в вопросах разработки?
ИМХО, проблема многих современных компаний в том, что люди со слабыми навыками разработки (но на высоких корпоративных позициях) почему-то начинают считать, что лично им разработка теперь стала понятна, и они могут принимать важные технические решения.
Дело не только в "повсеместном внедрении ИИ", но и в работе с техдолгом, автотестами, деплоем, наймом и увольнением разработчиков, решениями о том, какие конкретно технологии и инструменты использовать и т.п. Как правило, они принимают плохие решения, думая, что принимают хорошие.
Считаю, проблема не в нехватке источников информации, каналов, вычислительных ресурсов и тп. Проблема концептуальная - отсутствие у LLM понимания. Имитацию они могут сделать, ну это как попугай, он тоже вроде "говорит", но толку от этого не сказать чтоб много...
С этими вредителями надо что-то делать...
Даёт удобство развёртывания в обмен на жертву некоторой степени производительности, безопасноcти и необходимости поддерживать доп. инструмент. В какую сторону и насколько склоняться - вопрос конкретного проекта. It depends.
Хз никогда не работал с подманом.
Где прописали, там и будут) или это вопрос на знание команды docker logs и подобных?
https://habr.com/ru/articles/937844/comments/#comment_28718842
https://habr.com/ru/articles/1015730/comments/#comment_29731246
https://habr.com/ru/articles/1021494/comments/#comment_29806754
Это означает: забили на пользовательские сценарии и дата флоу. Или по-другому: нет времени думать, запиливай в продакшн быстро! У нас квартальный отчёт в понедельник! =) Не, понимаю, такое бывает. Проблемы начинаются, когда такое систематически и техдолг растёт аки снежный ком.
Согласен, на практике так и есть.
А как же нагрузочные тесты?
В точности мои мысли уже года два как.
Потому что "не можете", понятно? Владельцы заводов-пароходов хотят себе денег, а не проблем. (sarcasm)
Раз статистика в 1000 откликов не устраивает, надо "точечно" проверить, чтоб результаты и вызываемые ими эмоции были как задумано.
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.
Вот кому интересно, и так всё это знают.
А кому не интересно - непонятно, зачем им этот курс нужен...
Красавчик.
Спасибо, - значит, не зря старался!
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
ИМХО.
Спасибо! Ну, возможно несколько сложноват или не было попадания в целевую аудиторию.
Вы нанимаете опытных специалистов не для того, чтобы указывать им, как делать. А чтобы они показывали вам, как следует делать.
Это:
Маркетинговое фуфло.
Повторю свой вопрос полугодовой+ давности:
ИМХО, проблема многих современных компаний в том, что люди со слабыми навыками разработки (но на высоких корпоративных позициях) почему-то начинают считать, что лично им разработка теперь стала понятна, и они могут принимать важные технические решения.
Дело не только в "повсеместном внедрении ИИ", но и в работе с техдолгом, автотестами, деплоем, наймом и увольнением разработчиков, решениями о том, какие конкретно технологии и инструменты использовать и т.п. Как правило, они принимают плохие решения, думая, что принимают хорошие.
Считаю, проблема не в нехватке источников информации, каналов, вычислительных ресурсов и тп. Проблема концептуальная - отсутствие у LLM понимания. Имитацию они могут сделать, ну это как попугай, он тоже вроде "говорит", но толку от этого не сказать чтоб много...