Комментарии 32
К сожалению, однобоко устаревший подход - взгляд от проектирования, длительного цикла от идеи-разработки-результата. А жизнь (и суть ИИ-революции) в ускорении. В пределе - Получать результаты сразу, как захотелось.
Отсюда, "К какому пойдете врачу?" - ответ из реальности "К никакому (не дождешься, затаскают, будут долго лечить от плоскостопия)".
ИИ - "просто еще один" удобный советчик (наравне с Гуглом и тусовками).
Хотя, так и хочется написать "антисоветчик".
Надеюсь, что хайп - наша временная "Детская болезнь левизны".Нет (в реесте профстандартов) такой профессии "Разработчик" - это слово прилагается (к "программист", например в "Помощник программиста"). Т.е. это только одна из выполняемых функций. Да, ключевая, в фирмах-разработчиках.
Из моего опыта работы в фирмах-проектировщиках, из перечисленного Автором - мне ближе "Проектировщик" (кодировщик - тоже разрабатывает, но в своей сфере).
Не стал бы ставить "Осталась карта" на "Функция разработки".
Как и пытаться выдавать какую-либо функцию (Разработка, Проектирование), за уникальные особенности своей профессии (где-то, да, но не у всех).Соглашусь в такой интерпретации, что:
В конкретном деле (например, архитектуре зданий, их строительстве и сдаче под ключ) - всегда останется важна Специфика (риски, в случае зданий).
Рано делать выводы (нам, руководству) "заменит/не заменит", сравнивая с "полуторагодовалым малышом" (может он в конце и обгонит нас в чём-то. Если будем "стоять и ждать (мы в домике)").
Результат в моменте отличается от долгосрочной стратегии.
Опираться стоит на реальность, а не стандарты из реестра. Для меня это как начальник и руководитель. Первый самодур с должностью, второй уважаемый за проф.пригодность.
Хоть в чемто вы согласны
Совет (но не настаивая, подумайте на досуге): воздерживаться от "приклеивания (сходу) ярлыков", с уникально-персональным (вкладываемым смыслом, из личного опыта и пристрастий) обозначением: "Начальник - плохо, руководитель - хорошо". Это разные функции (что следует из их имени - типа: техлид, тимлид), без следствий "начальник - самодур, с должностью".
"Местечковый ярлык" - затрудняет понимание другими вашей логики (например, в сравнении с профстандартом - хоть каким-то единым якорем).
Мы уже в будущем
Меня уже заменил
если метрики у нейросеток выше, то можно заменять, вот и всё
Тут не все так однозначно. Метрики действительно важны. Только их собирать можно по разному. И собирать можно не те метрики. А от этого зависит и восприятие того на что смотреть.
Я в командах не смотрю на метрики до тех пор, пока все и каждый не начали работать по одним и тем же правилам. Иначе по метрикам всплывают бестолковые суперспециалисты. Которые по метрикам делают быстро, а по факту - плохо
Как мне кажется статья очень сильно не объяснила кто для автора является разработчик и чем он отличается от программиста, кодера, IT-шника и всех других и сколько процентов программистов это именно разработчики
Возможно. Но в статье речь скорее о специализированных знаниях, зоне ответственности и способности создавать и развивать программный продукт целиком.
Я рассматриваю программиста как более широкое понятие: человек, который пишет код. Разработчик - это специалист, который помимо написания кода понимает задачу, архитектуру, ограничения, принимает технические решения и отвечает за результат.
Я встречал часто разработчиков, которым нужны инструкции что и как делать. И это тонкий момент, потому что спрашивать о том как сделать - это хорошо, это процесс обучения. Но ждать указаний - плохо. Есть и другие - которые супер инициативно делают какую-то дичь. Если такого человека поставить руководителем - его будут называть самодуром. Это тоже плохо. Поэтому разработчик/инженер он понимает что делает, делает это хорошо и готов осознано нести ответственность за результат.
Условно: программист относится к разработчику примерно так же, как оператор набора текста - к автору того-же текста. Оба работают с текстом, но уровни работы - разные.
Вроде, теперь, до меня дошло:
- Кодировщик - это (одна из) функция Программиста;
- Разработчик - это (одна из) специализация профессии (Программиста, Архитектора зданий).
Тогда, идею Автора, можно представить как:
Некоторые специализации - (дольше) будут выполняться/цениться именно людьмиАвтору: Вы напоминаете меня, лет 30 (ладно, 10) назад - тоже считал "Разработчик - это круто. Кодировшик - тьфу, только слова расставить" (правда, до этого в юности - тоже самое про "ученый-инженер"). Но мне удалось встретиться с настоящими мастерами и ситуациями, когда конкретный исполнитель давал Решение, меняющее-выпрямляющее всё остальное (работу остальных).
К чему: в общем (на уровне "температуры по больнице") - может, Вы и правы (функция кодирования - в массе, перейдет к AI), но не в частностях ("Разработчик", но без функции кодирования, зато "в одном флаконе" - с аналитиком, проектировщиком, ведущим (предлагающим/отвечающим за технические решения), и чего Вы еще себе "понавешали (орденов)").И может (только теперь), проявилась Ваша истиная мысль:
Не сохранятся (за человеком) узкие специализации, функции
Имеется в виду работа (в конкретных фирмах), на которой требуется выполнение только одной функции (например, кодирования), внутри конкретной специализации (например, там где занимаются Разработкой)
Согласен с тем, что это очередной этап ускорения выпуска продукта. Вопрос в дальнейшем, не войдет ли в привычку пользоваться этим инструментом у нового поколения и в связи с этим, потерять первоначальные навыки. К хорошему и простому привыкаешь быстрее, а отвыкать гораздо сложнее.
Это, скорее, вопрос подхода к разработке, чем привычки. У нас уже есть методология TDD, - хорошая, но плохо применимая. Тут что-то очень похожее. TDD плох на практике, - но красив в теории. С ИИ он находит новые смысле. Я в следующей статье хочу написать как раз о подходах в разработке через ai-first и разобрать плюсы и минусы каждого.
Будущее поколение программистов не факт, что вообще будет, а если и будет, то крайне малочисленным, ибо большая часть работы будет автоматизирована
Я 20 лет пытался приспособить существующий софт для своих задач. Делал шаблоны, изобретал костыли. Сейчас за несколько вечеров и 20 баксов я навайбкодил себе прекрасный рабочий инструмент, который работает так, как нужно именно мне. При этом я абсолютно ничего не понимаю в коде, но прекрасно разбираюсь в специфике своей работы. В этом и есть беда разработчиков и программистов - они ничего не знают про мою работу, и будут вникать в неё месяцами. В то время как ИИ получил мои файлы, за 15 минут проанализировал их досконально, задал мне вопросы, о которых я даже не догадывался, и сам составил себе ТЗ.
Как тот кто активно изучает бизнес и системный анализ, работая с разными моделями, могу точно сказать что все ИИ и платные и бесплатные часто упускают важные детали, которые легко заметны человеку, и додумывают то чего не существует из-за неспособности правильно понять естественный язык, и вариативность в зависимости от контекста.
Маленькие проекты можно легко генерировать. Но что-то объемное, сложное то что занимает только в генерации несколько месяцев - "по файлом" не сгенерировать. Уже нужны инженерные навыки и понимание области. Иначе получиться либо совсем плохо, либо вообще не получиться.
Слышал подобные рассуждения, год назад как высмеивали вайбкодеров. Теперь уже никто так не говорит, а писать код ии это стандарт. Более того, ии сейчас научился находить дыры и следить за безопасностью. Дальше больше.
Человекбудет нужно только в сложных и важных проектах, или как руководитель. Что сильно сократит число программистов.
Я лично не программист и создаю код через ии. Один проект уже делаю больше года и работа продолжается каждый день.
Поделитесь вашим подходом к созданию кода через ИИ.
Проект начинается с правил и требований и плана. Готовый код переодически проверяется разными моделями, которые находят друг у друга недочëты. А при выходе новых моделей код снова проверяется.
И естественно всë придумывается, постоянные правки и улучшения.
Поверхностно написал, в целом так.
Что-то похожее на SDD. Часто бывает что одно чиниться - другое ломается? Приходилось генерировать, таким образом, что-то больше чем CRUD, какую-то сложную бизнес логику?
Программы, приложения и онлайн сервисы. Было весьма сложное, уходило много месяцев.
Такое, чтобы одно ломало другое, редко, так как всë отделено и не затрагивает друг друга. Поломаться может в случае больших переделок. Но оно также же поломалась, если бы это люди делали руками. Так как серьëзнве изменения, а если там много всего, что-то да сломается. Но и исправляется это также быстро.
Как я понимаю маленькие микросервисы или отдельное и не связанное между собой маленькое ПО. Такое, как правило, дейсвительно хорошо генерируеться
Уже заменяет так-то
Какое здание вы бы предпочли на ближайшие 5–10 лет? Почему-то мне кажется, что первое
Обошли стороной важный момент: цену. Если выбирать между первым домом за 6 млн. и вторым за 200 тыс., результаты моментально поменяются в пользу второго.
На самом деле в этом и есть дилемма. Именно в цене. Первый дом спроектирован по канонам и ГОСТам. Там точно все нормально, если с домом что-то случиться, застройщик сядет. Особенно если люди пострадают. В его интересах сделать все хорошо, пусть не качественно, но надежно. Второй дом спроектирован ИИ, без участия человека. Если что-то случиться с домом, - отвечать некому. Там могут быть разные проблемы: какие-то квартиры могут быть без дверей, другие - без окон. Какие-то без электричества. Как поддерживать такой дом - никто не знает. Купил там квартиру - дальше ты предоставлен сам себе. Если повезло - хорошо. А если нет? Цена переезда в нормальный дом будет больше чем если купить сразу. Ведь стоимость никто не возместит, продать плохую квартиру уже не получиться. Готовы рискнуть? Понятно что можно, когда выхода нет. Но грезы о нормальном доме будут мучать каждый день пребывания в ИИ квартире.
ИТ проект созданный ИИ без нормальной инженерии это такой же дом для бизнеса. Для МВП или одноразового фриланса - сойдет. Сдал и забыл. А для пользования на долгое время - уже вопросы: как развивать? как поддерживать? как решать проблемы? А правильно ведутся расчеты, ведь от этого зависят решения? А учитываються ли важные факторы? Много вопросв...
Вспомните проекты, где все делалось через Ж... Отдать и забыть. Где ПМ кричал - бизнесу нужно вчера! Все они либо ушли в архитектуру и инжиниринг либо умерли. Прямая аналогия. Вопрос цены и последствий.
Вы подняли очень хорошую тему.

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