Обновить

Почему AI не заменит разработчика

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели5.8K
Всего голосов 6: ↑4 и ↓2+4
Комментарии32

Комментарии 32

  1. К сожалению, однобоко устаревший подход - взгляд от проектирования, длительного цикла от идеи-разработки-результата. А жизнь (и суть ИИ-революции) в ускорении. В пределе - Получать результаты сразу, как захотелось.

    Отсюда, "К какому пойдете врачу?" - ответ из реальности "К никакому (не дождешься, затаскают, будут долго лечить от плоскостопия)".
    ИИ - "просто еще один" удобный советчик (наравне с Гуглом и тусовками).
    Хотя, так и хочется написать "антисоветчик".


    Надеюсь, что хайп - наша временная "Детская болезнь левизны".

  2. Нет (в реесте профстандартов) такой профессии "Разработчик" - это слово прилагается (к "программист", например в "Помощник программиста"). Т.е. это только одна из выполняемых функций. Да, ключевая, в фирмах-разработчиках.

    Из моего опыта работы в фирмах-проектировщиках, из перечисленного Автором - мне ближе "Проектировщик" (кодировщик - тоже разрабатывает, но в своей сфере).

    Не стал бы ставить "Осталась карта" на "Функция разработки".

    Как и пытаться выдавать какую-либо функцию (Разработка, Проектирование), за уникальные особенности своей профессии (где-то, да, но не у всех).

  3. Соглашусь в такой интерпретации, что:

    В конкретном деле (например, архитектуре зданий, их строительстве и сдаче под ключ) - всегда останется важна Специфика (риски, в случае зданий).

    Рано делать выводы (нам, руководству) "заменит/не заменит", сравнивая с "полуторагодовалым малышом" (может он в конце и обгонит нас в чём-то. Если будем "стоять и ждать (мы в домике)").

Результат в моменте отличается от долгосрочной стратегии.

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

Хоть в чемто вы согласны

Совет (но не настаивая, подумайте на досуге): воздерживаться от "приклеивания (сходу) ярлыков", с уникально-персональным (вкладываемым смыслом, из личного опыта и пристрастий) обозначением: "Начальник - плохо, руководитель - хорошо". Это разные функции (что следует из их имени - типа: техлид, тимлид), без следствий "начальник - самодур, с должностью".

"Местечковый ярлык" - затрудняет понимание другими вашей логики (например, в сравнении с профстандартом - хоть каким-то единым якорем).

Благодарю за совет

Мы уже в будущем

Мир действительно сильно быстро меняется, что очень сложно за ним успеть. Но это только начало трансформации

Меня уже заменил

Соболезную, а вы чем занимались?

если метрики у нейросеток выше, то можно заменять, вот и всё

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

Я в командах не смотрю на метрики до тех пор, пока все и каждый не начали работать по одним и тем же правилам. Иначе по метрикам всплывают бестолковые суперспециалисты. Которые по метрикам делают быстро, а по факту - плохо

Как мне кажется статья очень сильно не объяснила кто для автора является разработчик и чем он отличается от программиста, кодера, IT-шника и всех других и сколько процентов программистов это именно разработчики

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

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

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

Условно: программист относится к разработчику примерно так же, как оператор набора текста - к автору того-же текста. Оба работают с текстом, но уровни работы - разные.

  1. Вроде, теперь, до меня дошло:
    - Кодировщик - это (одна из) функция Программиста;
    - Разработчик - это (одна из) специализация профессии (Программиста, Архитектора зданий).

    Тогда, идею Автора, можно представить как:
    Некоторые специализации - (дольше) будут выполняться/цениться именно людьми

  2. Автору: Вы напоминаете меня, лет 30 (ладно, 10) назад - тоже считал "Разработчик - это круто. Кодировшик - тьфу, только слова расставить" (правда, до этого в юности - тоже самое про "ученый-инженер"). Но мне удалось встретиться с настоящими мастерами и ситуациями, когда конкретный исполнитель давал Решение, меняющее-выпрямляющее всё остальное (работу остальных).

    К чему: в общем (на уровне "температуры по больнице") - может, Вы и правы (функция кодирования - в массе, перейдет к AI), но не в частностях ("Разработчик", но без функции кодирования, зато "в одном флаконе" - с аналитиком, проектировщиком, ведущим (предлагающим/отвечающим за технические решения), и чего Вы еще себе "понавешали (орденов)").

  3. И может (только теперь), проявилась Ваша истиная мысль:

    Не сохранятся (за человеком) узкие специализации, функции

    Имеется в виду работа (в конкретных фирмах), на которой требуется выполнение только одной функции (например, кодирования), внутри конкретной специализации (например, там где занимаются Разработкой)

Спасибо за мнение

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

Это, скорее, вопрос подхода к разработке, чем привычки. У нас уже есть методология TDD, - хорошая, но плохо применимая. Тут что-то очень похожее. TDD плох на практике, - но красив в теории. С ИИ он находит новые смысле. Я в следующей статье хочу написать как раз о подходах в разработке через ai-first и разобрать плюсы и минусы каждого.

Будущее поколение программистов не факт, что вообще будет, а если и будет, то крайне малочисленным, ибо большая часть работы будет автоматизирована

Я 20 лет пытался приспособить существующий софт для своих задач. Делал шаблоны, изобретал костыли. Сейчас за несколько вечеров и 20 баксов я навайбкодил себе прекрасный рабочий инструмент, который работает так, как нужно именно мне. При этом я абсолютно ничего не понимаю в коде, но прекрасно разбираюсь в специфике своей работы. В этом и есть беда разработчиков и программистов - они ничего не знают про мою работу, и будут вникать в неё месяцами. В то время как ИИ получил мои файлы, за 15 минут проанализировал их досконально, задал мне вопросы, о которых я даже не догадывался, и сам составил себе ТЗ.

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

Так и есть. И это уже вопрос о том как использовать ИИ в работе.

Маленькие проекты можно легко генерировать. Но что-то объемное, сложное то что занимает только в генерации несколько месяцев - "по файлом" не сгенерировать. Уже нужны инженерные навыки и понимание области. Иначе получиться либо совсем плохо, либо вообще не получиться.

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

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

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

Поделитесь вашим подходом к созданию кода через ИИ.

Проект начинается с правил и требований и плана. Готовый код переодически проверяется разными моделями, которые находят друг у друга недочëты. А при выходе новых моделей код снова проверяется.

И естественно всë придумывается, постоянные правки и улучшения.

Поверхностно написал, в целом так.

Что-то похожее на SDD. Часто бывает что одно чиниться - другое ломается? Приходилось генерировать, таким образом, что-то больше чем CRUD, какую-то сложную бизнес логику?

Программы, приложения и онлайн сервисы. Было весьма сложное, уходило много месяцев.

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

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

Не только, есть и кросплатформ, с кучей разных сложных функций. Вот тут ии встали и было сложно. Тем не менее справились. Это было в середине лета. Сейчас модели ии сильно прокачались и такое уже сделают быстрее.

Уже заменяет так-то

Какое здание вы бы предпочли на ближайшие 5–10 лет? Почему-то мне кажется, что первое

Обошли стороной важный момент: цену. Если выбирать между первым домом за 6 млн. и вторым за 200 тыс., результаты моментально поменяются в пользу второго.

На самом деле в этом и есть дилемма. Именно в цене. Первый дом спроектирован по канонам и ГОСТам. Там точно все нормально, если с домом что-то случиться, застройщик сядет. Особенно если люди пострадают. В его интересах сделать все хорошо, пусть не качественно, но надежно. Второй дом спроектирован ИИ, без участия человека. Если что-то случиться с домом, - отвечать некому. Там могут быть разные проблемы: какие-то квартиры могут быть без дверей, другие - без окон. Какие-то без электричества. Как поддерживать такой дом - никто не знает. Купил там квартиру - дальше ты предоставлен сам себе. Если повезло - хорошо. А если нет? Цена переезда в нормальный дом будет больше чем если купить сразу. Ведь стоимость никто не возместит, продать плохую квартиру уже не получиться. Готовы рискнуть? Понятно что можно, когда выхода нет. Но грезы о нормальном доме будут мучать каждый день пребывания в ИИ квартире.

ИТ проект созданный ИИ без нормальной инженерии это такой же дом для бизнеса. Для МВП или одноразового фриланса - сойдет. Сдал и забыл. А для пользования на долгое время - уже вопросы: как развивать? как поддерживать? как решать проблемы? А правильно ведутся расчеты, ведь от этого зависят решения? А учитываються ли важные факторы? Много вопросв...

Вспомните проекты, где все делалось через Ж... Отдать и забыть. Где ПМ кричал - бизнесу нужно вчера! Все они либо ушли в архитектуру и инжиниринг либо умерли. Прямая аналогия. Вопрос цены и последствий.

Вы подняли очень хорошую тему.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации