Comments 60
Тут надо понимать что идеи о том как ИИ заменит погромистов - они в значительной степени берут начало и подогреваются в менеджерской среде. Погромисты - народ дорогой - и кажется очень выгодно заменить их парой запросов к волшебной машине.
Когда чат-гпт только появился, владелец стартапа где я тогда работал чуть ли не первым делом предложил с его помощью "переписать аднроид-приложение наше под айфон". Уж очень не хотелось для этого отдельно людей нанимать ему :)
И эти надежды менеджерские никогда не удастся потушить, как веру в философский камень. Хотя казалось бы - зачем вообще код писать. Попроси ИИ предсказать курс криптовалюты назавтра - и никакой программизьм тебе в жизни не потребуется.
Ну вот вы как раз и привели ту проблему о которой я писал. Я например полностью согласен с менеджерами. И то же бы хотел что бы ИИ за меня делал всё. В конечном счёте держать свой мозг по 8 часов в день в постоянном напряжении - это адская работа.
Но вот не работает так. И не программисты этого не видят. А я как программист попытался описать суть проблемы.
Пока ИИ не станет сильным - он не сможет писать программы от начала и до конца, а только лишь индивидуальные блоки. При этом промт для этих блоков будет такой - что опытному программисту проще этот промт сразу реализовать в коде, чем проходить квест. Напиши код но в виде человеческого языка -> Получи программу->Найди кучу ошибок и исправь.
А когда ИИ станет сильным - то зачем ему вообще человек нужен будет. Давным давно смотрел мультфильм Аниматрица. Что то похожее на Любовь Смерть и Роботы. Тоже собрание короткометражек. Так там очень круто было показано как машины отделились от человечества и создали в Африке своё государство и назвали его 0.
Пока ИИ не станет сильным - он не сможет писать программы от начала и до конца
Зачем писать от начала до конца? Вы и сами так не делаете, за один присест не пишете все от начала до конца. Сначала вы разбиваете задачу на мелкие очевидные подзадачи, которые затем вы либо сами имплементите, либо делегируете мидлам и джуниорам, так вот большую часть таких мелких подзадач уже сейчас можно делегировать LLM.
Ну так смотрите я как раз и пишу про эту проблему. Ваш подход подразумевает наличие программиста.
Который:
Создаст архитектуру программы.
Нарежет на блоки задачи. Создат чёткие описание каждой задачи.
Далее поручит ИИ или мидлу каждую задачу.
В случае с ИИ потом придётся досконально изучать каждую строчку получившегося кода.
Это изучение как показывает практика, сложнее чем самому написать сначала. И зачем тогда нужен такой помошник?
Статья которую я привёл в самом начале, говорит - все программисты будут ненужны. Код 100% будет писать ИИ.
При этом подобные статьи наводит саспиенса - мол ууууу!!!! Ищи программист сейчас любую другую работу!!! A то через год даже в дворники не возьмут.
А на деле появился очередной инструмент, не более. Я говорю про текущие возможности ИИ. Что будет завтра я не говорю.
Upd. Забыл самый важный пункт который выполняет программист. Он получает весьма туманные хотелки от заказчика и переводит это в возможности которые может программа. Часто (если не всегда) заказчик сам не знает что он хочет. И программисту (ладно пусть будет бизнес аналитик) надо выудить это у заказчика. Бизнес аналитик всё равно потом всё передаёт программисту. Часто программист напрямую с заказчиком общается по деталям.
С этой работой ИИ вообще не справится если он не будет сильным.
Статья которую я привёл в самом начале, говорит - все программисты будут ненужны. Код 100% будет писать ИИ.
Нет, не говорит. Из "100% будет писать ИИ" не следует "все программисты будут не нужны". Более того, вся история экономики показывает, что повышение эффективности использования некоего ресурса (программист с ИИ может написать в N раз больше кода в единицу времени) приводит не к очевидному, казалось бы снижению спроса на ресурс ("ага, значит мы уволим (N-1)/N программистов и будем писать столько же кода"), а наоборот, к его росту ("ура, теперь писать код проще, и мы можем автоматизировать то, что раньше было нерентабельно - дайте нам ещё программистов, которые с помощью ИИ это сделают"). В комментарии к той статье я упомянул, как это называется, - парадокс Джевонса.
А вот не факт...
Вспомните времена бухгалтерии до 1С. И сколько бухгалтеров тогда требовалось... А теперь небольшую компанию может вести 2 бухгалтера. Операционист и отчетник. Так что не всегда этот парадокс работает.
У меня нет статистики по количеству бухгалтеров, но что-то мне подсказывает, что с внедрением 1С их число отнюдь не снизилось. Опять же в логике "ура, теперь я могу нанять бухгалтера в свой мелкий бизнес на 1/10 ставки за копейки, поехали!" Хотя, конечно, в российских реалиях на перспективы запуска малого бизнеса куда больше влияют совершенно нерыночные факторы, чем вот это всё...
Я помню. В 90-х годах бухгалтерский баланс был на двух листочках, а отчетность в во все фонды (которые тогда вроде по-другому назывались) и налоговую - ВСЕХ бумажек можно было пересчитать на пальцах одной руки.
В нулевых, когда у всех была 1С 7.7, уже надо было сдавать в каждый фонд и налоговую здоровенные талмуды на десятки листов и еще дискетку прикладывать.
Вспомните времена бухгалтерии до 1С. И сколько бухгалтеров тогда требовалось...
А между тем
Спрос работодателей на бухгалтеров на российском рынке труда вырос на 318% с 2014 года, и на 33% - за последние два года. В ноябре 2024 года общее число вакансий бухгалтеров в России достигло 272 тыс., хотя 10 лет назад их количество составляло всего 65 тыс
В случае с ИИ потом придётся досконально изучать каждую строчку получившегося кода.
Код ревью мясных программистов тоже никто не отменял.
Создаст архитектуру программы.
Нарежет на блоки задачи. Создат чёткие описание каждой задачи.
Далее поручит ИИ или мидлу каждую задачу.
В случае с ИИ потом придётся досконально изучать каждую строчку получившегося кода.
Вывод: ИИ заменит программистов, но не заменит тимлидов. Вопрос - как вырастить тимлидов, если всех программистов заменил ИИ.
"У программистов есть понятие - погрузится в контекст.", Вы не поверите - у ИИ тоже! И пока что контекст маловат, пока что.
Да знаю про контекст. Проблема лишь в том что контекст ИИ может взять только из кода. А вот человеческий контекст намного больше. И каждый день дополняется по проекту.
Он состоит из.
Общения с заказчиком.
Общение с кучей рабочих людей на предприятии заказчика. Например когда программистская контора делает какую нибудь ERP для предприятия.
Каждодневных утренних планёрок и кучи
ненужныхсовещанийСобственного опыта программиста.
Всё это практически невозможно вспомнить и написать подробно в промте. Зато когда программист пишет код - этот контекст без труда автоматически всплывает в его голове. Так устроен мозг и нейроны - один нейрон тянет другой и так далее. Не зря есть такое понятие как "воспоминание разблокировано" Глянул мельком на камень на земле по дороге на работу и вспомнил случай из детства который никогда не вспоминал.
Часто есть отрицательный момент. Программист десять лет вёл проект на работе. И в его голове хранится ТАКОЙ контекст этого проекта - что он становится "незаменимым работником". Кроме него уже никто не может в этом разобраться. И ИИ не разберётся. Т.к. 10 лет не варился в этом проекту и не знает кучи подводных камней.
Вот Вы сейчас в части п. 1-2 программиста с бизнес-аналитиком перепутали :)
И тут как раз есть о чём подумать. В случае автоматизации собственно кодинга и смещения фокуса в сторону формирования функциональных требований, с одной стороны, аналитики начнут претендовать на замену программистов (мы ТЗ сделали, а дальше за нас ИИ напишет) - но не осилят эту задачу, т.к. за любым ИИ code review никто не отменял. С другой стороны, программисты, освобождённые от рутины кодинга, начнут претендовать на нишу аналитиков - но тоже не осилят, т.к. сила аналитика - многолетний опыт и набитые шишки в предметной области (ну да, 95% аналитиков этим не обладают точно так же, но мы ж про идеальную картинку). В общем, распределение труда и функционал участников проектной команды явно будут меняться, но как именно - тут запасаемся попкорном...
Вы правы. Более того про бизнес аналитиков я писал выше. Но на практике я часто видел бизнес аналитиков которые играли роль простого посредника вопросов. И гораздо проще было напрямую связаться с заказчиком и разъяснить все вопросы.
Опять же насколько хорош бизнес аналитик не был он не знает (по крайней мере не в его компетенции) многих нюансов, ограничений и особенностей устройства внутренней кухни баз данных, сервисов и прочего.
Поэтому программисты часто напрямую согласовывают с заказчиком многие моменты. Ну и бизнес аналитик за ними как прилежный учеинк всё согласованное записывает себе в тетрадочку.
И часто в схеме бизнес аналитиков попросту может не быть.
Ну я поэтому и написал, что 95% бизнес-аналитиков не таковы :) Тоже насмотрелся в этой роли на мальчиков сразу после вуза, не имеющих опыта ни в предметной области, ни в программировании, да и BABOK вряд ли прочитавших до конца. Но в идеальном мире бизнес-аналитик - этой такой уникальный человек, имеющий опыт на топ-менеджерских позициях в предметной сфере и при этом не чуждый реалий IT, который стóит как несколько сеньоров, но только он и способен выявить все нюансы, в которых на интервью заказчик сам не признается, и перевести их на понятный программистам язык...
Я бы ещё добавил что часто бизнес аналитик играет роль щита от самадура-заказчика способного изнасиловать тебе мозг так что и программировать не захочешь.
Вместо тебя мозг насилуется бизнес аналитику. И опять же я замечал что если такой аналитик "не сильно умный" - то ему как бы и норм. Это его "суперсила".
И мне кажется что если есть такой бизнес аналитик которого вы описали, то он не останется на этом уровне, что бы ему насиловали мозг, а быстро пойдёт по карьерной лестнице вверх.
Роль щита в идеале должен выполнять проджект менеджер, и для бизнес-аналитика тоже :) Но по факту тут как сложилось в конкретном проекте, конечно, идеала не бывает.
А тем бизнес-аналитиком, которого я описал, я сам был N лет назад в проекте для одной из топ-10 корпораций нашей страны... меньше чем через год сбежал в ужасе, хотя заказчик слёзно уговаривал остаться. Но бороться с бесчисленными службами заказчика за право причинить ему счастье вместо того, чтобы делать содержательную работу, оказалось выше возможностей моей хрупкой психики :) Может, как раз потому, что защиту её от этого всего проджект менеджер оказался не готов на себя взять.
Мне кажется тут проблема в том, что в большинстве своём когда AI просишь написать код, он его просто пишет, вместо того, чтобы самостоятельно уточнять разные нюансы. Если бы AI сам бы задавал все нужные вопросы, то мучиться с промтом и не пришлось бы, он бы в диалоге с программистом сам бы все выяснил бы.
Интересный подход. А если попросить текущий ИИ что бы он задавал вопросы и по ответам писал код.
Ради интереса задал deepseek такой промт
Задай мне вопросы что бы написать программу на C#. А я буду тебе давать уточняющий ответы какая должна быть программа.
На что он мне ответил
Конечно! Давай начнем с уточнения, чтобы я мог понять, какую программу ты хочешь написать. Вот несколько вопросов:
Какой тип программы ты хочешь создать?
Консольное приложение
Графическое приложение (Windows Forms, WPF, MAUI)
Веб-приложение (ASP.NET, Blazor)
Мобильное приложение
Игра (Unity, Godot)
Другое (укажи, что именно)
Какую задачу должна решать программа?
Обработка данных
Работа с файлами
Взаимодействие с базой данных
Математические вычисления
Автоматизация задач
Игра или развлечение
Другое (опиши подробнее)
Какие данные будет обрабатывать программа?
Текстовые данные
Числовые данные
Изображения
Аудио/видео
Базы данных
Другое (укажи, что именно)
Какие функции должна выполнять программа?
Ввод/вывод данных
Хранение данных
Обработка данных (сортировка, фильтрация, анализ)
Взаимодействие с пользователем
Сетевые функции (интернет, API)
Другое (опиши подробнее)
Какие технологии или библиотеки ты хочешь использовать?
.NET Core / .NET 6/7/8
Entity Framework
LINQ
Unity
Другое (укажи, что именно)
Есть ли у тебя конкретные требования к интерфейсу?
Простой текстовый интерфейс (консоль)
Графический интерфейс с кнопками, полями ввода и т.д.
Минималистичный дизайн
Сложный интерфейс с анимациями
Другое (опиши подробнее)
Какая у программы должна быть архитектура?
Простой скрипт
Модульная структура
MVC/MVVM паттерн
Микросервисы
Другое (укажи, что именно)
Есть ли у тебя предпочтения по стилю кода?
Чистый код (Clean Code)
ООП (объектно-ориентированное программирование)
Функциональное программирование
Другое (опиши подробнее)
Какие платформы должны поддерживаться?
Windows
Linux
macOS
Мобильные платформы (iOS, Android)
Веб-браузеры
Другое (укажи, что именно)
Есть ли у тебя конкретные требования к производительности?
Высокая производительность
Средняя производительность
Низкая производительность (например, для простых задач)
Другое (опиши подробнее)
Ответь на эти вопросы, и я помогу тебе сформулировать задачу и начать писать программу на C#!
Программа на C#. Консольная. Задавай следующий вопрос.
Отлично, консольное приложение на C#! Давай уточним детали. Вот следующий вопрос:
Какую задачу должна решать программа?
Обработка данных (например, сортировка, фильтрация, анализ)
Работа с файлами (чтение, запись, редактирование)
Взаимодействие с базой данных (запросы, обновление данных)
Математические вычисления (калькулятор, решение уравнений)
Автоматизация задач (например, выполнение рутинных операций)
Игра или развлечение (текстовая игра, викторина)
Другое (опиши подробнее, что именно программа должна делать)
Математическое вычисление. Должна уметь складывать числа.
Понял! Программа будет консольным приложением на C#, которое выполняет математическое вычисление — сложение чисел. Давай уточним детали:
Какие числа должна складывать программа?
Целые числа (int)
Дробные числа (double/float)
Оба типа (и целые, и дробные)
Сколько чисел должно складываться?
Фиксированное количество (например, 2 числа)
Произвольное количество (пользователь вводит числа, пока не решит остановиться)
Как программа должна получать числа?
Ввод с клавиатуры (пользователь вводит числа в консоли)
Чтение из файла (например, числа хранятся в текстовом файле)
Другое (укажи, если есть особые требования)
Как программа должна выводить результат?
Просто вывод результата в консоль
Запись результата в файл
Другое (например, вывод с пояснением, типа "Сумма чисел: ...")
Должна ли программа обрабатывать ошибки?
Да (например, если пользователь ввел не число)
Нет (программа работает только с корректными данными)
Ответь на эти вопросы, и я помогу тебе написать код!
Пусть складывает int
Отлично! Программа будет складывать целые числа (int). Давай уточним оставшиеся детали:
Сколько чисел должно складываться?
Фиксированное количество (например, 2 числа)
Произвольное количество (пользователь вводит числа, пока не решит остановиться)
Как программа должна получать числа?
Ввод с клавиатуры (пользователь вводит числа в консоли)
Чтение из файла (например, числа хранятся в текстовом файле)
Как программа должна выводить результат?
Просто вывод результата в консоль
Запись результата в файл
Другое (например, вывод с пояснением, типа "Сумма чисел: ...")
Должна ли программа обрабатывать ошибки?
Да (например, если пользователь ввел не число)
Нет (программа работает только с корректными данными)
Ответь на эти вопросы, и я составлю код для твоей программы! 😊
Вывод. Столь простую программу мне как программисту делать 1 минуту. Взял и написал. Потому как я уже в подсознании знаю ответы на все вопросы и знаю что мне надо. Просто сразу пишу нужный код.
А ИИ может мне наверно ещё пол часа вопросы задавать?
Наверно новичку это норм.
А если это будет чуть сложнее сложения 2 чисел? Уточняющих вопросов будет как книга Война и мир?
И кстати - вот нагляднейшний пример кучи пограничных вариантов в простейшей программе сложения двух чисел. Опытные программисты просто на автомате все эти вопросы будут решать.
А новичок даже не подозревать об их существовании.
В очередной раз приведу...
Некоторое время назад попадалось выступление одного программиста (к сожалению, сейчас уже не найду ссылку), где он обращал внимание аудитории на следующий момент. Что, мол, хоть языки программирования всё это время эволюционируют в плане читаемости: машинные коды сменил революционный ассемблер, потом фортраны, паскали, си, и, наконец, нынешние, питоны с джаваскриптами. Тем не менее, покажи кусок кода человеку не знакомому с синтаксисом и он сходу не сможет рассказать, что тот делает. Т.е.за почти 70 лет прогресс практически нулевой в этом смысле. Человека сначала надо обучить быть "переводчиком" с машинного на человеческий и наоборот. И только благодаря ИИ сейчас есть шанс, что программист будущего будет писать программы именно на человеческом языке.
Дальше автор начинал свой стартап рекламировать, но основной посыл мне оказался близок. Что если обучение будущих программистов позволит отказаться от всех этих ".. и не забывайте ставить точку с запятой в конце строки" в пользу умения детально описать работу программы (как, кстати, тот же Макконелл советует) и определения граничных условий? Как минимум, понятие программиста изменится, кмк )
А Вы помните, зачем нужно ставить точку с запятой в конце строки?
Нет, вовсе не потому, что авторы языка козлы были — у неё есть вполне определённое предназначение. Которое, вероятно, никто уже не помнит, а воспринимает как данность.
Как бы это разделитель. Компилятор без этого может склеить код там где этого не должно быть.
Вот пример - я писал минификатор для файлов javascript. Основная операция это выкидывать ненужный текст. А это как раз всякие переносы строки которые могут и 2 байта занимать (\r\n) и куча пробелов. Если всё это выкинуть то всё склеится. А точка запятой будет как раз это разделять. Ну в javascript ещё пробел можно использовать.
Просто мы для читабельности используем форматирование с кучей переносов строк и пробелов. И вроде как использование точки с запятой уже и не надо.
Вот в javascript так и сделали - хочешь используй, хочешь нет.
Опять же есть языки где вместо точки с запятой используют для форматирования другие символы \r\n, begin end и прочее. Но точка с запятой это минимальный и наглядный символ для разделения блоков.
Я на столько привык к ней что без её использования уже и к коду с другими разделителями трудно приступать . Мозг уже как компилятор просто на автомате выцепляет её из сплошного текста и форматирует мне его на самостоятельные программные блоки.
Как бы это разделитель. Компилятор без этого может склеить код там где этого не должно быть.
Совершенно верно. Пробельные символы (" \n\t") игнорируются (кроме #-директив, но это не в сам язык, а в препроцессор), а ; по факту является единственным разделителем «тут оператор закончился, мамай клянус».
В прологе (и эрланге) есть три разделителя: запятая, точка с запятой, точка. В полном соответствии с правилами грамматики английского языка.
Так языки программирования и придумали из-за того, что человеческий язык очень плохо подходит для описания алгоритмов! В нём слишком много неоднозначностей (вероятно, это как раз фишка для общения людей). А эволюция от машинных кодов через ассемблер и далее - это лишь следствие развития вычислительной техники и средств разработки. Как органы управления автомобилем - по сути мало чего изменилось с первых машин, только становилось удобнее и эргономичнее. А хочется управлять машиной силой мысли.
покажи кусок кода человеку не знакомому с синтаксисом и он сходу не сможет рассказать, что тот делает
Это не так в случае кобола (и сиквела), но кобол (и сиквел) тоже не решили проблему написания кода бухгалтерами (и аналитиками), так что проблема где-то в другом месте.
Со временем ИИ инструменты сыграют злую шутку с программистами. По мере их развития станет многим понятно, что если хочешь конкурировать с другими надо их использовать все больше и больше. Но когда вместо человека пишут код, то неизбежно его навыки написания кода будут атрофироваться за ненадобностью, программист постепенно деградирует в промт-инженера и ему будет не так уж и важно чего там ИИ нагенерировал, главное что работает.
Когда-то были слесарь, токари которые умели хорошо работать руками, считались элитой в обработке стали, знали все про стали и обработку. Сейчас они постепенно заменяются операторами ЧПУ. Оператор за то же время производит больше продукции, от него требуется меньше квалификация, а если ему дать в руки резец он не сможет с ним что-то сделать.
Ну и еще лет 25 назад были ассемблер разработчики, которые говорили, что высокоуровеневые языки это тупиковый путь, писать код нужно только на ассемблере! Асм-разработчики конечно остались, но сколько их там в процентном соотношении)
Я бы сказал так:
Со временем ИИ инструменты сыграют злую шутку с программистами мясными мешками человеком
Сильный ИИ заменит просто всех. Продавщиц на кассе. Всех служащих работающих с людьми. Водители. Врачи (кроме хирургов наверно и то спорно). Да вообще не представлю профессии где человек останется нужен.
И программист тоже не нужен будет. Только он станет не нужен не в первых рядах как тут обычно акцентируют, а ближе к концу очереди мясных отходов
LLM оказались сильны в генерации текста, а программы это тоже текст, вот от сюда и тревоги. Не факт что программирование это конец очереди, т. к. как раз именно эта сфера очень сколонна к новациям и мы первыми побежим за этими инструментами, а пациенты будут выбирать доктора-человека, да еще по рекомендации своих знакомых.
В результате рыночной конкуренции упадёт цена на товары и услуги, и инфляция просадит зарплаты до такого уровня, что сильный ИИ станет слишком дорогим удовольствием.
Сильный ИИ заменит просто всех.
«Жаль только: жить в эту пору прекрасную
Уж не придётся — ни мне, ни тебе.»
© мясной мешок Некрасов Н.А.
Ха-ха... Именно по этой причине я долго не мог освоить Си. Искренне не понимал, нахер он нужен, если я то же самое напишу на асме, причем на пару байт короче и на пять тактов быстрее ! :))))
Вот про этот отрицательный эффект можно сказать, что это плохо организованные процессы. Всякое совещание должно заканчиваться составлением кратких итогов, на одно-два предложения. На каждый пофиксенный баг должно приходится несколько тестов. Должна быть документация по бизнес логике и процессам продукта. Отсутствие такой практики будет серьезным припятствием для внедрения ИИ. Есть компании где это уже норма, там внедрении произойдет быстрее. Это даст серьезное конкурентное преимущество, остальным придется подтягиваться.
А собственно программисткий контекст это уже другая проблема. По нему два замечания. Во-первых даже опытные программисты пишут код с ошибками выхода за пределы массива, деления на ноль, обработки исключений и т. д., и этот код работает до поры до времени, так что человеческая голова не панацея. Во-вторых это не бог весть какая премудрость и ИИ уже сейчас способен проводить код ревью и указывать на ошибки такого рода, а значит может писать код без этих ошибок.
Две недели делал веб приложение с помощью квена и грока . Что-то типа Mirо (вайтборд/пинборд) но под свои нужды, легче и проще и конечно бесплатно. Где-то 40 модулей вышло, бэкенд с регистрацией, авторизацией, сохранением сессий в базу данных sqlite (для себя хватит) и indexedDB. Мой уровень знания JS - что-то уроне написать конвертер валют, или калькулятор, т.е практически начальный. Очень понравился процесс, я теперь понимаю почему программистам много платят. даже утилита требующая банального ресайза заметки может занимать 50 строк кода.Теперь +- понимаю как все работает, сам бы такой код не написал, не хватило бы ни знаний, ни времени ни терпения. ОТ ИИ будут в выигрыше все, программисты потому что им теперь будет проще писать код, продвинутые пользователи - потому что теперь им не нужны будут программисты чтобы написать сайт под свои нужды.
Спасибо за статью!Согласен, ИИ ещё далеко до полноценного программиста, не ясно зачем делаются все эти заявления про "заменят...", до этого момента ещё долгие долгие годы
Надоело читать эту ерунду. Сколько программ написал ИИ? Может, одну хоть написал? Какую?
Пока что мы имеем дело с языковыми моделями общего назначения, чатами, которых энтузиасты просят написать алгоритмы. Но пройдет несколько лет и на основе LLM появятся специализированные пакеты для разработки ПО. Они в автоматическом режиме должны будут умееть:
Распознавать ТЗ
Распознавать макеты
Генерировать код, тесты к нему с покрытием около 100%, включая пограничные условия.
Компилировать код, прогонять тесты, в случае ошибок вносить правки.
Запускать программы, проверять на соответствие ТЗ.
Обрабатывать ошибки ручного тестирования и вносить правки с автоматической проверкой результата.
Это все достичь можно, нужно что-бы это направление кто-то развивал, пока только начало пути.
Можно пойти ещё дальше, пишешь ему "хочу продукт, который сделает меня богатым", дальше просишь составить ТЗ, и далее п.1...
На текущем уровне с помощью ИИ можно шахматный движок с нуля написать за один день. Просишь описать ходы фигур, доску, и ИИ агента, но придется самому все ручками вставлять проверять. Качество игры будет достойное, на вскидку первый разряд. Не плохо для одного дня.
В дальнейшем если зациклить его на самосборку, тесты, проверки, то сделает это сам с минимальным участием человека скажем часа за два.
В общем нужна обратная связь, и чтобы он сам ее получал и обрабатывал. Тут как раз с богатством проблемы. От создания продукта до получения первых денег проходят месяцы, слишком много времени ждать, много рисков, их должен разделить человек, его же деньги.
пройдет несколько лет и на основе LLM появятся специализированные пакеты для разработки ПО
Ну да
Ключевой момент - ИИ не заменит программиста, он сократит их количество. Там где над проектом работало 20 программистов, оставят 3 и дадут инструмент - ИИ. Похожим образом прокатило громкие сокращения в Российских ИТ-компаниях.
del
Добавлю офтопа. Как же мне смешно смотреть на мою карму )))) Я уже давным давно понял писать сюда что то не имеет никакого смысла. Что бы ты не написал - тебе попросту напихают минусов в карму. Потому как на хабре должен остаться только рекламный булшит и кривые переводы в коммерческих блогах. Даже этот комментарий не имеет смысла писать.
Сначала следует ответить на вопрос: существует ли такой "человеческий" промт, который приведёт к решению поставленной задачи?
Если да, то это означает, что программистам следует изучать не само программирование, а искусство составления промтов.
Если же физически невозможно создать такой промт, то этот факт уже будет ответом на пост автора.
Хм... А что если использовать ИИ для этого? Например, передавать ему программу и спрашивать: "Какой промт мне написать, чтобы получить нужный результат?"
DWIM Driven Development
Маленькая просьба - не загрязняйте текст зачёркнутыми остроумиями - это как минимум мешает читать, а вообще - портит впечатление об авторе.
Когда-то для отдельного маленького кусочка программы надо было поработать паяльником.
Потом случилась революция, и достаточно было сделать дырочки в нужных местах перфоленты. И на перфоленту можно было записать гораздо бОльший кусок програимы. А в случае ошибки - просто заклеить лишнее отверстие. Ну, или пробить новое. Это же так удобно!
Когда-то люди писали напрямую машинный код. А потом случилась революция, появился asm! Удобно!
Когда-то все писали на asm. А потом - появились языки высокого уровня!
ИИ точно такой же инструмент, который повысит уровень абстракции. Причем я лично не уверен, что революция будет такой же, как от перехода от байт-кода к asm.
Уже с который раз повторюсь...
...давным-давно, когда компьютеры были большими, разработчик набирал переключателями на пульте двоичный код, который потом исполнялся процессором. Потом программист стал писать человекочитаемыми буковками код низкого уровня (на ассемблере), который транслировался в машинный код, который исполнялся процессором. Потом разработчик стал писать код на языке высокого уровня (скажем, C — кстати, у сишных ++ и -- ноги растут из DEC-овских операций с авто{ин|де}крементом), который транслировался в код низкого уровня, который транслировался в машинный код, который исполнялся процессором. Теперь разработчик нового уровня будет писать очень-очень подробное и детальное техническое задание, не допускающее двояких толкований, которое транслируется в код на языке высокого уровня, который транслируется в код низкого уровня, который транслируется в машинный код, который исполняется процессором...
Нет, это уже качественный переход. Вам в любом случае изначально нужен готовый алгоритм. ЯП более высокого уровня всего лишь позволяют описать его более лаконично. Сам алгоритм при этом не искажается.
Языковые модели работают в обратную сторону. Они из упрощённого описания алгоритма пытаются составить сложный алгоритм.
ИИ — напиши мне программу