Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 193
Золотое, да, прям золотой дождь.
Я хотел оставит тоже коммент :( А вообще думаю основная проблема в том что может сейчас и золотое время для кого-то, а для кого-то нет. Надо по такой метрике смотреть а не приводить рассуждение как докозателтсво статистики.
“Золотой дождь” да… почему то первая ассоциация - это термин из сексуальных девиаций.
Наверное потому, что вчера потратил пару часов на поиск странной баги. Оказалось, LLM решила, что Long от null строки, нужно как 0 (число), а не null
ну верьте верьте… впрочем, статья тоже LLM написана. Мусорная
А в каком языке это null а не исключение. Даже в С это классический null pointer assignment/read и обычно вываливается в исключение, да и во многих принято делать обработчики. В этом случае необходимо модели явно указывать что делается при преобразованиях типов данных, особенно когда заведомо известно что может прилететь null. Равно как деление на ноль - если есть такие формулы то необходимо явно указывать проверку. Модель учится на множествах примерах, поэтому исключение это типовой случай, а если пользователю необходимо if(null) then null else continue, то это выбивается из правил и необходимо это явно обыграть.
SQL?
Я так понимаю, имелось ввиду, что ии написал
Long val = (s == null)? 0 : Long.valueOf(s); А ожидалось
Long val = (s == null)? null : Long.valueOf(s);(Long - объект и может быть null, long - примитив)
А что Вы хотели от системы, обученной на материалах со Stack Overflow?
На любые null, void* malloc-free нужно делать очень тщательные промпт-инъекции чтобы было что то вроде
Long val = (s == null || s.isEmpty()) ? null : Long.valueOf(s);исключающее исключения вроде NumberFormatException. Равно как деление на ноль с прибавлением бесконечно малой, отслеживание диапазонов итд. Это проблема промпта. ИИ вполне правильно сформулировал эту строку.
можно даже ещё провайбкодить и получить вроде как ещё более замечательный результат.
public static Long toLongSafe(String s) {
if (s == null || s.trim().isEmpty()) {
return null; // Or 0L, depending on your preference
}
try {
return Long.valueOf(s.trim());
} catch (NumberFormatException e) {
return null; // Returns null if the string is "abc" or "12.3"
}
}
Вообще говоря преобразования типов даже в динамических языках к примитивам это боль. Поэтому нужно ловить все исключения, даже когда на экране видны 123 а по факту это символы ０１２３ в Unicode. Это скорее недоработка промпта или инъекции нежели баг самой модели. В случае использования этого дела далее в качестве арифметики 0 был бы в принципе нормален без боязни словить null если он не проверен
Как вариант самому написать библиотечную функцию и заставить ИИ ее везде использовать не рассматривался?
Да какая в принципе разница. Я к тому, что LLM часто допускает “незаметные” ошибки, которые потом выливаются в неочевидные проблемы, которые не всякими тестами выловишь.
Но, если вас интересует конкретный случай, то это тема блин импорта замещения и переписывание старого Java кода работающего с Oracle на Postgree. Oracle jdbc умеет выполнять преобразование типов и ссылку по имени. например (чисто для примера)
String nVal = “123”;
… pstmt= … con.prepareStatement(“… where … blablaid=:balablaid…”);
pstmt.setObject(“balablaid”, nVal);
Вполне успешно выполнится. Но, PG такое не поддерживает. Во первых не поддерживает именованное обращение, во вторых не делает столь не явные преобразования строк в число. и нужно это заменить на что то типа (в лоб)
String nVal = “123”;
… pstmt= … con.prepareStatement(“… where … blablaid=?..”);
pstmt.setLong(7, nVal == null? null: Long.parseLong(nVal));
Так то LLM достаточно успешно с этой нудятиной справляется. НО… Хлобысь и где то pstmt.setLong(7, Long.parseLong(Objects.toString(nVal, “0”))); А где то адекватное pstmt.setLong(7, nVal == null? null: Long.parseLong(nVal));
И когда такого кода N тысяч строк… то… да можно просто не заметить пару строк, где неадекватное сделано. А если внимательно смотреть - то по времени проще руками. Причем результат не детерминированный. Раз так, а в другой запрос - по другому результат.
Ну это чисто скопировал вставил и забыл (если компилируется и работает). Разбираться с ошибками там реально по времени порой дольше чем полностью пересмотреть весь код. Ваще, можно нанять другого LLM, они все таки зачастую по разному рассуждают и у них будто "глаз ещё не замылен". Например даже дипсик может чё то написать, обычно оверинженерное, а ошибку выяснить не сможет, но клауде потом поправляет, или наоборот
Вот доводы “взяли не тот LLM, не правильно промт, нужно было найти и поправить промт/попросить исправить” Вот честно говоря достали эти доводы.
Для того что бы найти (черную кошку в темной комнате, которой возможно и нет) - нужно все глазами просмотреть (тупая работа) и возможно (!) найдется (глаз то замылен да и совсем тупая работа). Т.е. для того, что бы исправить ошибку, нужно как минимум знать что она есть.
Ошибки LLM (любой, с любым промтом) они
не детерминированны (разные запуски - разный результат)
Как правило логические (синтаксические компилятор найдет)
тяжело ищутся, поскольку анализировать сгенеренный код мозг отказывается внимательно смотреть. Типа мозг говорит: “ты чего… уже все сделано. зачем эта еще тупая работа по проверке”.
это не ошибка LLM а ошибка использовать её для языков, которые специально для неё не предназначены а были созданы исторически. Особенно которые перенасыщены грамматикой и смыслом, для которых вся работа программиста это trick and tips с кучей жонглёрских методов и хитростей. Это размывает возможные варианты реализации. Поэтому идеальный вариант это то что несёт минимум смысловой нагрузки с точки зрения реализации, обо всём остальном модель позаботится лучше всего это что то вроде чистого C, Python, JS/Java в режиме C, то есть с минимум выкрутасов. Необходимо делать промпт-инъекции чтобы максимально упростить вывод. Да, с точки зрения человека это уход в 80-е структурного программирования но с другой стороны - это всё генерируется автоматически, спихивая все трудности ради которых и разработаны современные языки на модель. То есть современные паттерны излишни так как лакоичность кода ценой усложнения его семантики уже под вопросом. Если итератор LLM сделает не 1 строку а 5, но, при этом, этот вывод гарантирован и влезает в контекст то собственно зачем гоняться за full language specification, достаточно BASIC уровня калькуляторов
Так это уже создание тулов которые парсят этот код и находят подобного рода пробки. В этом случае необходимо просить LLM не код править а сделать тул-скрипт для парсинга с использованием внешних утилит. Вообщем что-то наподобие того что ищется по ключевым словам MCP Python Refactor или MCP Java Refactor. В этом случае он нагенерит питон/bash/ещё что которое пройдёт по всем этим 1000 строк и выявит указанные уязвимости. То есть он автоматизирует ручной поиск таких пробок. Изначально, код созданный вручную он плохо пригоден для такого парсинга. Поэтому его необходимо сначала причесать инструментами с языковой поддержкой на уровне пре-компилятора с разбором функций, аргументов, затем вытаскивать все краткие для человека сущности в переменные, код раздуется, но он будет скажем так более понятен с точки зрения векторной базы данных и копошения в нём LLM. То есть сейчас отпадает необходимость писать краткий особо хитрый код со всеми выкрутасами компилятора, наоборот, его необходимо раскручивать до понимания контекста LLM. А дальше он сам уже подставит шаблонные выражения для исключений, макросы, дебаг-инфо итд итп, найдёт возможные коллизии. Причём если код причёсан чуть ли не как маркдаун в комментах, модель справляется более чем отлично особенно для многопоточки. Мелкие баги есть но они отлавливаются прежде всего локальными тестами - это уже другая фишка, и вообще говоря правильная. На каждый исходник и функцию - обёртка из того что показывает что это работает. Для гигантских систем конечно могут быть проблемы и невозможность тестов но они по порядку величины уже сопоставимы с экспертной оценкой профи.
а джуны таких ошибок не делают? )) и просто захотелось в 100500й раз пнуть LLM?
Забавно, откуда у всех такая эмоциональная реакция на замечания вида “вот этот молоток удобен, но идеализировать его не надо”.
Как будто всем “зачем нападаете на LLM”, LLM приходится близким родственником и они готовы за него вступаться “маaaленьких обижают”. :)
Иногда даже смешно становится.
Для того что бы найти (черную кошку в темной комнате, которой возможно и нет) - нужно все глазами просмотреть (тупая работа) и возможно (!) найдется (глаз то замылен да и совсем тупая работа). Т.е. для того, что бы исправить ошибку, нужно как минимум знать что она есть.
Странные претензии. А ты в этой цепочке зачем, если смотреть/разбираться лень, глазки устали?
"импорт замещения" доставил :-)
а что не “… where … blablaid=?::Integer..” и никаких преобразований?
В любом? Нуллпойнтер радостно каститься в ноль, откуда взяться исключению?
У меня буквально на днях подобное заняло примерно секунд 30 у Клода. Я ему быстро описал, что в УИ не срабатывает, через 30 сек вердикт и фикс, что в TypeScript надо различать null, undefinded и 0. Бага была пофикшена за 30 сек. Сам бы я сидел мин 30, разбираясь в движке генерации форм. То, что мы сейчас сделали за 2 недели, в ручную у нас ушло бы месяца 3.
Понимаю Ваш скептицизм. Еще полгода назад сам был такой, но сейчас сидеть тарабанить по клавиатуре набирая код, я лучше в это время новости почитаю ))
Как и в случае с золотым дождем, есть те, кому нравится)
Есть мнение что это просто "передел рынка" и зон влияния. Теперь кампании предлагающие нейронные сети для разработки имеют большое влияние на неё и зарабатывают с этого свой гешефт. Преимущества одиночкам?) не думаю. Конкуренцию ни кто не отменял, теперь рынок будет еще больше перегрет решениями сомнительного качества, а успех будет на стороне того продукта, чья рекламная кампания была успешнее или кто вложил в нее больше денЯг.
Теорема Эскобара во всем её величии )))
Вот когда нейронки заменят бездарных руководятлов - тогда заживём )))
Согласна с вами. Конкуренция сделает свое. Уж простите "овнокод" в почести точно не будет))) Его уже любой школьник пилит. Тут нужно радоваться не айтишникам, а пиарщикам, видимо)
Лет 20 назад я делал очень хорошие сайты, с хорошей структурой, с уникальными текстами и фото. Тратил огромное количество сил чтобы выбить из заказчиков нужные материалы. А мои конкуренты делали тяп-ляп. Сайты которые я делал сами заходили в топ и на все нужные клиенту позиции. Сайты сделанные конкурентом либо вообще исключались из выдачи либо болтались внизу.
И вот тогда наступал звездный час конкурентов- к ним приходили заказчики, просили сделать так чтобы сайт вышел на позиции. Конкуренты покупали ссылки и сайт с трудом вылезал на какие-то позиции.
И вот я супер профессионал, сайты, которые я делаю сами залетают в топ, а сайты сделанные конкурентами с трудом. Но я зарабатывал раз в 100 меньше этих конкурентов-говнокодеров.
Почему? А потому что стоило клиенту, который платил ежемесячно за SEO солидную сумму решить сделать перерыв или вообще уйти- вебмастер отключал в кабинете где покупал ссылки их и сайт быстро улетал на дно.
Вывод? Не надо относиться так радикально к говнокоду. Люди на говнокоде делали, делают и будут делать миллионы.
Люди на говнокоде делали, делают и будут делать миллионы.
«Шей да пори — не будет пустой поры» ©
Стало вдруг интересно, кому принадлежит копирайт на народные пословицы
Народу. А конкретно - Михалкову, наверно.
«...copyright (означающий, как всем известно, „Скопировано направо“ или „Скопировано правильно“)...» ©
Ну, коллега, вы упускаете очень много фактов. Для начала, действительно, SEO - это часть маркетинга. Для поднятия веса страниц использовались внешние ссылки на них. На этом можно было зарабатывать, и зарабатывали. Но вот то что вы говорите про свои сайты - это не показатель качества. Они могут работать быстро, они могут иметь чистый HTML код, но HTML - не язык программирования. Что там было у вас под капотом, и какую ценность для бизнеса приносили ваши сайты, мы не можем знать.
Во-вторых, сайты, изготавливаемые веб-студиями- это самый низ пищевой цепи в IT. Самое простое web-приложение для автоматизации бизнес процессов будет в несколько раз сложнее одного такого сайта. Плюс, нагрузка не сопоставима. Тысячи RPS, терабайты данных - это прямо минимальный проект. И в нём говнокоду нет места. Есть разница между медленным пешеходом, который спотыкается о камень, идя прогулочным шагом, и спринтером, спотыкающимся о камень, набрав максимальную скорость на стадионе. Для конькобежца последствия будут ещё тяжелее, для велосипедиста, если камень будет сопоставим с габаритами велосипеда - тоже. Более крупные проекты, конечно, не испытают фатальных последствий, но ущерб будет однозначно. Если ты едешь на автомобиле по ямам, готовься ремонтировать подвеску.
В большинстве своём, люди выбирают баланс между ценой и качеством: нет смысла покупать то, что не работает. Нет смысла переплачивать там, где есть более дешёвые аналоги со сходным качеством. Проблема IT в том, что нельзя быстро оценить качество кода. Бизнес этим точно не будет заниматься сам. Он будет смотреть на инциденты, отчёты. Либо к концу отчётного периода бухгалтерия получит пачку счетов «на ремонт молотка», либо авария обрушит стоимость активов компании. Либо, клиенты предъявят иски за некачественные услуги. Тогда бизнес будет разбираться: говнокод? Что это? Как это повлияло на нашу ситуацию? Кто это проектировал? Кто писал код? Кто нанимал этого человека? Кто принимал работу? У нас был штат сильных программистов - где они все? Кто решил уволить? Почему так решил? Ок, сколько сейчас стоит нанять хороших специалистов? Да, давайте троих. Вот этих троих уволить! Этого можно по статье. Он руководитель - взыщите с него за устранение последствий. И ещё двоих наймите, когда эти уйдут!
Примерно так всё будет.
Скорее виноват будет "уборщик Вася", его и уволят. Очень редко решения о сокращении или не наёме людей принимают на низовом уровне управления... А на высшем уровне управления придётся выйти на самого себя...
Ну не всегда. Я лично видел как страдали менеджеры среднего звена. Даже их руководители. Размеры компаний - разные. Понятно, что верхушка не пострадает от своих действий, но вот руководителя какого-нибудь отдела можно спокойно скипнуть. Можно даже без выплаты премии. А вот топ-менеджера или C-менеджера могут просто попросить на выход со всеми причитающимися ему выплатами. Такое тоже бывает. У верхушки своя кухня.
Здесь что нужно понимать: во-первых, менеджмент всегда заботится о прикрытии причинного места. По итогу выясняется, что менеджер часть документов не подписывал, часть решений не согласовывал. Во-вторых, даже если подписывал и согласовывал, сама его должность имеет мало кандидатов на замену. И это логично: работать в условиях, когда любое твоё решение может привести к крупным проблемам, может не каждый. Поэтому, зачастую, ошибки менеджеру прощают. Если они небольшие и редкие. Даже решение полностью заменить команду, с одной стороны, выглядит дико, несправедливо. А с другой, смотришь, а продукт реально получает пользу от такого решения. Судить человека, действия которого приводят к значительным последствиям, легко. Но вот, зачастую, последствия наступают поздно. И вопрос здесь, наверное, в том, насколько это решение соответствует экспертному мнению? С ИИ мы видим, что есть вполне конкретные показатели ненадёжности некоторых подходов, приводящих к сокращению штата. В общем, смотрим что получится в итоге.
во-первых, менеджмент всегда заботится о прикрытии причинного места.
С ИИ мы видим, что есть вполне конкретные показатели ненадёжности некоторых подходов
Тут как раз противоречие - матерому менеджеру не высокого уровня нет резона предлагать заменить людей на ИИ, так как спрос с него будет, а не с Антропика какого-нибудь и так как без людей он сам получается не очень нужен...
А вот вы не правы. Лично видел «продуктового инженера». Это такой менеджер, которого нанимают для внедрения ИИ.
По поводу кстати SEO ИИ на мой взгляд очень сильно помогает в этом.
Имел сайт, смотрел метрику и по каким запросам заходят на сайт. Выгружал в день примерно 100 запросов и отдавал агенту писать по ним статьи в блог. И так по кругу, в итоге сразу видел, что на сайт больше людей стало приходить, а трудозатраты минимальны.
Более того, от того, что стала проще одна фаза вывода продукта на рынок, остальные не испарились.
Продукты делать все еще тяжело.
Самое главное, чтобы стандарт какой-нибудь не запилили - аналог МЭК 61131-3 для IT, что программировать больше нельзя, а можно только вайбкодить на трех видах агентов. АСУ ТП когда-то тоже была золотой жилой с зарплатами как в американском C++/Ada-эмбедеде..
Так уже собственно RFC подтянули к MCP. Обязательные фразы, фразы-коллбэки, спецификации и контрольные выражения, может даже смайликами
Реализации мэковских языков настолько отличаются у разных вендоров, что это можно уже считать разными языками.
Клетка норм это называется в теории управления государством
Сергей, скажу честно: ваши мысли во мне откликаются. Да, надо понять, что работодатель сейчас проверяет новые гипотезы: что если работать маленькими командами в формате AI-first? Что если найти человека, который сможет работать Fullstack, со знаниями системного дизайна? Окупится ли найм с демпингом?
Вот только маленький нюанс: а где хоть одна статья на Хабре от русского работодателя за 2026 год с результатами проверки гипотез? Очень хотелось бы понять реальную эффективность новых команд и масштаб экономии (но не просто «мы уволили всех и сэкономили два лярда» - это глупость, а не экономия).
Вот только маленький нюанс: а где хоть одна статья на Хабре от русского работодателя за 2026 год с результатами проверки гипотез?
Кто поумнее ждут вала таких статей из разных отраслей, а кто пошустрее проверяют гипотезы чтобы похвастаться на Хабре. И, судя по валу статей с результатами проверок, "что-то пошло не так")
а где хоть одна статья на Хабре от русского работодателя за 2026 год с результатами проверки гипотез?
Вопрос риторический, как я понимаю?
но не просто «мы уволили всех и сэкономили два лярда» - это глупость, а не экономия
Это не глупость, если смотреть с точки зрения того, кто продавил такое решение. Вот вообще не глупость. Это его премия в деньгах. В хороших таких деньгах. А потом будет еще одна премия - за быстрое формирование новых команд
Быстрое?! Найм сеньора сейчас - от 1 до 1,5 месяца. Найм обвален нубами с ИИ. Демпингующими миддлами. Специалистами, берущими по несколько проектов (в т.ч. на подставных лиц). Скоро на рынке станет ещё веселее. Когда работодателя начнёт заботить сломанный найм.
Помню, как совсем недавно писали здесь же в комментах, что у мидлов и сеньоров всё прекрасно, нечего переживать, "хороший специалист быстро найдёт работу", что и так предложения идут, чтоб перехантить.
Найм сеньора сейчас - от 1 до 1,5 месяца
А вот и реальность стучится в окно - уже и сеньоры должны поработать, чтоб найти работу
У вас интерпретатор сломался. Там буквально написано, что компании придётся потратить от 1 до 1,5 месяца, чтобы найти сеньора, который согласится у них работать.
Да с этим нет проблем у компании. Я как сеньор могу успешно пройти все технические этапы, получить восторженные отзывы интервьюеров (с пометкой «вообще-то нам запрещено намекать вам на результат»). А потом мне HR пишет: «здравствуйте! Спасибо за интерес, проявленный к нашей вакансии. До финала дошли вы и какая-то собака. Команда выбрала собаку»!
Быстрое?! Найм сеньора сейчас - от 1 до 1,5 месяца
По меркам того бизнеса, у которого в 2026 есть деньги на описанные мной выкрутасы (разогнать команду - собрать команду - ...) от 1 до 1,5 месяцев - это практически молниеносно
1,5 месяца - это много??
Найм сеньора сейчас - от 1 до 1,5 месяца.
При этом сеньор тратит на поиск работы полгода. :-\
Специалистами, берущими по несколько проектов (в т.ч. на подставных лиц)
Не одобряю, но причина, кажется, в [отсутствии] job security.
Причина в том, что на рынке демпинг. Работодатель либо закрывает финансовые потребности специалиста и проводит нормальный найм, либо берёт того, кто дешевле, но получает не более 50% отдачи. Давно пора привыкнуть, что обувь за 300 рублей, в большинстве случаев, хуже обуви за 12000 рублей. Ноутбук за 60000 рублей, в большинстве случаев, хуже ноутбука за 300000 рублей. Сеньор за 160000 рублей, в большинстве случаев, работает хуже сеньора за 350000 рублей.
И это при том, что некоторые компании до сих пор ищут людей с профильным высшим образованием, чтобы перекладывать JSON.
Это его премия в деньгах. В хороших таких деньгах. А потом будет еще одна премия - за быстрое формирование новых команд
Как однажды сказал мне более опытный коллега: оптимизация штата сотрудников всегда ведёт к его расширению.
Экспертиза с каждым днем перестает иметь какое-то значение. Даже если взять себя: раньше (до середины-конца прошлого года где-то) ко мне на работе чуть ли ни каждый день люди бегали с вопросами типа "как сделать вот это лучше", "как решить эту проблему", "а как вот это у нас работает" и тп, то теперь такого вообще нет. С одной стороны это хорошо, меньше отвлекают, но с другой стороны как-то обидно что ли за все эти годы, да и чувствую нехватку челенджей :)
Меня смущает, что модели не сомневаются. Если тыкаешь носом явную ошибку - ну да, я опечатался. Но стратегические/архитектурные задачи , которые решают модели с помощью джунов, так без сомнений в прод и уходят
Фигак-фигак, и в продакшн (Tm)... выходит на новый уровень ...
Теперь называется прогрессивным использование LLM решений 😂
ага, если бы они признавались, обычно просишь сгенерить что-то, он где-то накосячит ему говоришь вот тут косяк , а он тебе в ответ - "Да тут ТЫ ошибся брат"
Я вот посмотрел отчеты https://airassvet.ru/articles/ai-dev-day-march-2026 наших айти-гигантов, цифры там далеко не такие как во влажных фантазиях некоторых испытуемых, судя по цифрам сокращать там даже не будут никого, максимум сократят найм. Так что если верить более менее достоверным источникам, один разраб никак не может работать с производительностью целой команды. Максимум на 20% быстрее закрывать задачи, это если у него не будет лимитов, будет норм модель, ну и умеет он промпты хорошие писать с первого раза.
Однако есть и другие исследования, которые показывают менее однозначные результаты. Например, эксперимент некоммерческого института METR в 2025 году выявил, что опытные разработчики в опенсорсе работали на 19% медленнее, применяя ИИ, хотя сами ожидали ускорения на 20–39%.
Я бы сказал, что перестаёт иметь значение ответственность за что либо. А за этим тезисом тянется всё остальное – не нужна экспертиза, не нужны тесты, бекапы, дизастер-планы, оперативное устранение инцидентов в целом.
Вот ломанули не так давно крупную компанию связанную с авиацией. Там оказалось много проблем, о которых ещё в букварях сис.админов пишут. Ну или писали раньше. Ну и ничего, самолёты вновь стали летать.
А ещё раньше самолёты переставали летать из-за сбоев в ПО. И что в итоге? Ничего серьёзного, сообщества побухтели и утихли.
Вон, не так давно (я старый, для меня 2010 не так давно) у British Petroleum очень крупная техногенная катастрофа с разливом нефти и прочими последствиями*. Что-то глобально в мире изменилось? Люди перестали добывать нефть? Небо не упало на землю, жизнь продолжается.
А что говорить о мелочах – багах, ошибках, непродуманных архитектурах и прочих аспектах.
*Все аналогии с событиями на тот момент, когда вы это читаете случайны.
А разве самолеты должны переставать летать, а нефть добывать после инцидентов этих и катастроф? Должны делаться выводы, на их основе что-то меняться в конструкциях, техпроцессах, инструкциях и т.п.
Дирижабли перестали летать, а АЭС перестали строить так массово после инцидентов и катастроф. Существующие мэйнстримные технологии и материалы - по сути, выжившие из-за гигантской привлекательности, которая перебивает все недостатки.
Дирижабли перестали летать...
Ну и зря. Можно же использовать гелий и баллоны из сегментов.
АЭС перестали строить так массово после инцидентов и катастроф.
Ну и зря. Катастроф было всего две за всю историю атомной промышленности. И в обеих виновен человеческий фактор.
В Чернобыле умные роботы выключили реактор. Но кретины инженеры по приказу кретинов чиновников из Москвы его перезапустили.
С Фукусимой немного сложнее. В Японии всем АЭС по 50 лет. Реакторы в них -- говно мамонта. Если бы строили новые АЭС и меняли в них реакторы -- всё было бы хорошо.
Вон немцы закрыли АЭС и покупают "экологически чистую" нефть у русских (или теперь у арабов?) и энергию у французов, кои были немного умнее и не закрыли все АЭС.
Я бы сказал, что перестаёт иметь значение ответственность за что либо.
А она была, оказывается? Для меня, как для конечного пользователя. А не для вашей этой корпоративной "етики", "норм и правил", "командного духа" и прочих запахов.
Опять пресловутая «экспертиза»...
Я сейчас электронному болвану скормил вопрос «Какая экспертиза нужна для получения должности руководителя ит проекта».
Он выдал несколько десятков строк ответа. Структурировал, жирненьким выделял, нумеровал, строил перечни... Но вот прикол - слово «экспертиза» во всех этих строчках не встретилось ни разу.
Ну болван, что с него взять. «Компетенции», «опыт», «навыки», «умения», «знания». Ишь, изворотливый какой.
«Какая экспертиза нужна для получения должности руководителя ит проекта».
Патологоанатомическая!
Видимо, не такой уж он и болван, если понимает слово "экспертиза" в его оригинальном значении, а не в зумерском.
Ну, наркологическая не помешает. А что вы вообще имели в виду? Может, компетенции?
Да надоело вот это все. Я именно на Хабре узнал, что экспертизу можно иметь внутри команды, что экспертизой по JS можно овладеть, что... Почитайте Хабр и найдете "творения" с лихой заменой слов «компетенции», «опыт», «навыки», «умения», «знания» стильной, модной и молодежной "экспертизой".
Некоторым авторам я в ЛС писал и предлагал погуглить данное слово. Соглашались и удивлялись потом, вроде "вот оно как оказывается".
А то, что электронный болван понял, так по контексту, по остальным словам. Он по определению не может считать безграмотным того, кто задал ему вопрос. Выкручивается, как может.
Хрен знает, как там ИИ повлияет на ИТ на этом вашем Западе (пока я читаю только о массовых увольнениях, но да не об этом речь). В наших родненьких ВСЖ ИИ-революция наступит ещё очень не скоро. Как учили большинство нынешних руководителей, у каждой проблемы должны быть ФИО. Всегда должен быть стрелочник, всегда должен быть кто-то, на кого можно будет свалить. На кого валить в случае ИИ? Вот то-то и оно... Уж если мы реально переходим от кодинга к вайбкодингу, когда программист будет лишь прослойкой между ИИ и бизнесом, то это точно не наш путь. Может когда-то в будущем, лет через 15-20 (если к тому времени в РФ останется ещё какая-то ИТ-индустрия), может и правда наступит та самая ИИ-революция. А пока, верится слабо...
Всегда должен быть стрелочник, всегда должен быть кто-то, на кого можно будет свалить. На кого валить в случае ИИ?
В чем вопрос? Фиксируем приказом ответственность условного тимлида и погнали
я тут в одном подкасте услышал мысль, что принятие ответственности и есть та роль которую ИИ не сможет никогда принять, а разработчик должен. Ну не только разработчик, а человек вообще. И это наболее вероятный вектор развития событий.
В России есть национальная традиция: всячески избегать ответственности. Я знал директоров школ, которые сами не подписывали ни одного документа. Я знал директоров предприятий, которые воровали, и тут же приказами и актами перекладывали ответственность на подчинённых. Я знал управленцев, которые всячески избегали своих прямых обязанностей только потому, что не хотели нести ответственность.
Есть страны в которых общая тенденция - принимать на себя ответственность. То есть, ошибки (до определённой степени) прощают. Это стимулирует принятие решений. Часть из них взлетит, часть - нет. У отечественных компаний общая тенденция - соскочить с ответственности. Самый топовый руководитель - это тот, кто официально под роспись не принимал ни одного рискованного решения за всю карьеру. Хочешь расти как руководитель в России? Научись делать так, чтобы решения были приняты, но без твоей подписи. Следующий этап - банковские счета, которыми ты пользуешься, но которые тебе не принадлежат. Правда, это уже не отечественная, а общемировая тенденция.
Вы говорите, что нельзя персонифицировать LLM, чтобы свалить на него всю ответственность, и тут же персонифицируете LLM, утверждая, что нельзя ответственность за его действия назначить на кого-то другого. Не надо так.
Как учили большинство нынешних руководителей, у каждой проблемы должны быть ФИО. Всегда должен быть стрелочник, всегда должен быть кто-то, на кого можно будет свалить. На кого валить в случае ИИ?
На того, кто приказал, конечно же! Ой...
Вообще, кажется, сейчас начинается золотое время в IT
Особенно в РФ
А чем РФ так уж принципиально отличается?
Да, с современным шквалом новых законов и запретов я чувствую мы откатимся в начало 2000-х. Надо собирать NASы и набивать их информацией пока интернет не прикрыли)
Именно поэтому модель от claude вчера помножила бизнес одной маленькой компании на 0 снеся весь прод. Золотое время)
Понятно что и те сами виноваты сложив все в одну корзину, но я надеюсь этот случай будет показательным для текущего тренда заменить 90% штата на ии с целью сокращения издержек)
Маленькая компания сама виновата, что не делала бекапов.
Маленькая компания сама виновата, что не делала бекапов.
А компания побольше делала бекапы — но им вовсе не стало менее грустно от того, что вся их база благодаря вайб-дырке утекла к вайб-хакерам.
Так она делегировала их иишке.
Бэкапы само собой - но ответственность разработчков LLM/агентной системы никто не отменял. Если агент может выполнить деструктивный запрос без возможности спросить оператора - это весьма хреново.
дык там дело не в агенте же было, а в дурацкой системе версионности и хранения
им "сломать" могла уборщица даже, проходя мимо. Или кошка пробежавшая по клавиатуре
Именно поэтому модель от claude вчера помножила бизнес одной маленькой компании на 0 снеся весь прод
А кожаные-то никогда так не делают, ага :)
О каждой серьезной аварии с беспилотным авто сообщают мировые СМИ, хотя статистика показывает, что машины Waymo имеют аварийность на 80-90% меньше, чем у кожаных водителей в тех же городах. Вот тут похожее впечатление) Если бы о каждом провале живых спецов писали в интернете...
Ни о чём.
Так о чём собственно эта статья? В ней 4 разных темы, которые слабо перекликаются между собой.
Наступило время для новых героев.
Разработка маленькими командами.
Бюджет на ошибки.
Автоматизация по методу Маска.
Первую тему можно считать вступлением. Тут всё ок.
Да, сейчас можно разрабатывать что-то малыми командами, т.к. ИИ предоставляет некоторый уровень экспертности, которого ранее могло не хватать мелким командам.
Бюджет на ошибки вообще никак не связан ни с первой темой, ни со второй. Сама же возможность делать эксперименты, проводить А\B тестирование и реализовывать пилотные проекты появилась очень давно. Тот же google активно пиарил идею о 20% времени на эксперименты много лет назад, т.е. ещё до текущего хайпа по ИИ. Booking упомянутый в статье, тоже появился очень давно.
Инженеры и сотрудники Google имели право тратить 20% своего рабочего времени (примерно один день в неделю) на работу над сторонними проектами, которые не входили в их прямые обязанности, но могли принести пользу компании. Благодаря этому правилу появились такие продукты, как Gmail, Google News, AdSense и Google Talk.
Концепция активно использовалась с начала 2000-х годов. Официально основатели упомянули эту практику в письме акционерам перед выходом компании на IPO в 2004 году.
Автоматизация по методу Маска тоже никак не связана с остальным текстом статьи. Хотя можно было рассказать про xAI, покупку Cursor, строительство датацентров для ИИ, а также его планы на выпуск собственных чипов для ИИ.
По итогу получилось лоскутное одеяло из 4-х никак не связанных между собой тем.
А мне как будто бы понятно, видимо потому что я где-то вот в этих пунктах сижу и думаю, а как
Новые герои - это ребята с клод-кодом, которые делают иногда крупные иногда мелкие изменения, но быстро
раз у нас клод-код заменяет "много кого", то нам не нужна большая команда
Бюджет на эксперименты, тут про "новых героев" внутри компании
Для примера, у Вас есть некий маркетинг-еком, с помощью вайб-кодинга вы можете теперь запускать много разных экспериментов (цены, бандлы, рассылки) и прочее. Но есть определенные риски (не все эти эксперименты в плюс) - поэтому нужна некая воля и бюджет
то есть и раньше то запускали, но раньше маркетологам надо было "пинговать аналитиков, мучать разработчиков" - сейчас все проще (я не говорю, что у меня в организации именно так, это я смотрел вебинары современных маркетологов) - прошаренные ребята из маркетинга могут сами вайб-кодить себе нужные сервисы и автоматизировать свою работу
А вот и 4-й пункт, а нужна ли ЛЛМ-автоматизация. Может надо навести сначала порядок в общем бардаке, в бизнес-процессах. Не нужно автоматизировать бардак. Иначе он только прибавится :)
Я мог бы на примере своей работы расписать более детально (с точки зрения "вот у нас так исторически сложилось, но небольшой командой мы могли бы делать много экспериментов и быстро"), но не буду. НДА и все такое. Ну и у нас все-таки пока нет таких AI-мелких команд
Из интересного на вебинарах, ребята из маркетинга сами пилят прототипы каких-то квестов, строят автоматизированные системы анализирующие тренды тик-тока, генерацию схожих видео (или генерацию идей для генерации схожих видео) и многое другое. Целые pipeline
А на другой офлайн встречи, директор по маркетингу рассказывал, как ЛЛМ экономит ему минимум день работы (еженедельный сбор предложений (цены, услуги) с сайтов у конкурентов, формирование своего предложения) - Вы конечно можете сказать - да он мог бы парсером собирать. Мог бы, но он маркетолог, а не "парсер-писатель". И нет у него бюджета на разрабов.
и в целом в маркетинге все еще огромная куча ручной работы. От согласования заявок на POSm, то составления прогнозов и отчетов по акциям
Сейчас можно разрабатывать что-то малыми командами, т.к. ИИ предоставляет некоторый уровень экспертности, которого ранее могло не хватать мелким командам.
Вы не поверите, но по самые нулевые, пока уровень программистов не пошёл вниз, и не возникло bloatware, в котором ради функции умножения векторов имортируют целую библиотеку в сотни MB, малые команды великолепно работали без всякого ИИ. Вон видео игры -- очень сложные программы. Но почти все игры из 90-x написаны небольшими группами. И они по-прежнему лучше, чем 99% нынешнего мыльного кино из нескольких уровней и весом в сотни GB.
Возьмите System Shock 2, есть ли хоть что-то похожее в нынешнее время? Слава GOG мы теперь можем играть в эти игры и вспоминать ту эпоху, как в Средние Века вспоминали Римскую Империю.
И вот мне кажется, мы примерно здесь и ошибаемся раз за разом. Вместо того чтобы убирать лишнее, упрощать, прототипировать и делать систему легче, мы сразу бежим строить процессы, контуры качества и автоматизацию.
Это про сокращение живых людей в службах поддержки и заменой их на очень искусственные интеллекты, которые иногда настолько уверены в том, что могут дать ответ на любой вопрос, что хочется сделать что-то очень деструктивное в их сторону?
Про агентскую разработку, захотелось внести мысль.
Глядя на то, как Копайлот, Кодекс и в меньшей (пока) степени Клауде Код закручивают лимиты на пользование – кажется, что такое изобилие скорости и дешевизны с нами не надолго.
И что разработка агентами может выровняться с разработкой живыми людьми. Если не по времени, то по цене.
И когда/если это произойдет – опыт управления командами И агентами станет одним из самых ценных в области разработки. Потому что не будет уже возможности за несколько долларов или небольшую часть лимита месячной подписки погонять вхолостую эксперименты – нужно будет все заранее спроектировать и сразу делать как надо, насколько это возможно. Как было до AI.
Именно так! Они что, дураки - развратить миллионы хомячков, а потом так и не начать их стричь?
Или можно напрячься и купить себе железо локальное.
Я себе купил, но при текущих расценках на облачные услуги окупится через 8 лет =)
Единственное, что радует, что могу себе ставить нецензурированные модели.
Через восемь лет облачные решения станут на порядки умнее, а локальное железо превратится в тыкву
Или превратятся в напрочь огороженное и зацензуренное говно. А локального железа вообще будет не купить, потому что “Покажите вашу лицензию”.
Нет, железо останется тем же. А вот модели, доступные для запуска на нем, тоже могут улучшиться.
У меня был, например, qwen3-coder. А теперь у меня qwen3.6. Прогресс ощутим. Железо - не менял.
Не превратятся. Главное чтобы было достаточное количество и скорость памяти. Сейчас даже древние профессиональные радеоны с 32Gb VRAM неплохо работают с нейросетями.
Тоже склоняюсь к такому варианту. Ну или арендовать GPU.
окупится через 8 лет
Т.е., возможно, никогда (сколько они служат?). ЧСХ, для датацентров с окупаемостью тоже могут быть нюансы.
Ну так основная цель любого подписочного сервиса - вначале дается халява и ненадолго...а потом дорого и навсегда) Не помню ни одного случая когда подписочная хрень дешевела просто то так - единственный вариант - клиенты уходят в другой сервис. А если все сревисы сядут в один картель и поставят порог цен - уходить будет некуда. А кодить ручками после таких возможностей - уже не та продуктивность.
Хочется услышать более подробное раскрытие этих тем в отдельных статьях. Как ИИ может помочь мелким разработчикам?
Очень просто. ИИ агента можно подключить прямо в IDE и кодить с помощью агента. Он работает как толковый мидл а то и сеньер, который знает все распространенные технологии, не устает, а по производительности вообще пишет за троих. Производительность на рутинных задачах возрастает кратно. И все это за $100 в месяц (пока) и возможность неизвестно кому смотреть твой код. Если ты мелкая кампания без груза корпоративных заморочек, можно просто брать и использовать. В итоге один разработчик с ИИ работает с производительности целой команды.
вообще-то эта штука приносит им дохерища денег и прекрасно решает свою задачу
Точно «прекрасно»? Оперативку не жрет, интерфейс не мерцает?
Парадигма меняется - вот и всё. Переходим от programmers к program development managers (по-русски не получится так хорошо передать контекст). Того программирования, которое было раньше, уже не будет.
Менеджеры по разработке кода - по-моему вполне передает
Всё будет. Но не для вас. Художники с появлением фотографии не исчезли, а стали больше зарабатывать. Есть богатые люди, которые хотят чем-то отличаться от холопов. Грех на этом не заработать. Поэтому, после появления автоматизации, ручной труд лишь вырос в цене. Вы не можете себе позволить портрет семьи ручной работы из натуральных красок, а кто-то может и позволит.
Ну и заработав себе имя, можно вообще банан прилепить изолентой к холсту, и уже миллионер.
а где гарантия что маленькая ошибка в пределах "бюджета" не окажется с эффектом бабочки? И вопрос зачем пытаться автоматизировать -упростить задачи которые изначально вообще не стояли?
Вы правы, Верховный главнокомандующий, угрозы ядерной войны не было - я ошибся. Приношу свои извинения. Кстати, я знаю несколько малоизвестных трюков, полезных для жизни на заражённых территориях, а также правила помощи при острой лучевой болезни. Хотите, чтоб я рассказал об этом?
Читаешь фантастику какого нибудь Аластера Рейнольдса. Он очень любит про ИСКИны писать. И прям видишь - вот оно наше будущее. Когда ИИшке дадут слишком много прав (я думаю Пентагон тут будут первыми) - фантастика станет явью, как раньше роботы, подводные лодки и прочие смартфоны. Футурологи сейчас озолотятся)
Золотой дождь прольётся, но не над всеми
Вообще, кажется, сейчас начинается золотое время в IT
Ну как, для продавцов лопат — да...
Ну как, для продавцов лопат — да...
Ирония в том что программисты и были этими продавцами лопат. Делали кучу бесполезной работы типа переписывания монолитов на микросервисы и прочее перекрашивание кнопок. С чего бизнесы ничерта не поимели, только айтишники на этом и заработали. Сейчас бизнесы дебит с кредитом свели да повыкидывали этих ненужных продавцов лопат.
UPD. Отвечу тут "благодаря" недоброжелателям.
А уж любители всякого чистого кода, паттернов и прочих "расширяемых" (на пол шишечки) архитектур и подавно занимались лютейшим непотребством за деньги бизнеса.
программисты и были этими продавцами лопат. Делали кучу бесполезной работы
У Вас опечатка в слове «говнокодеры».
А программисты этим по собственной инициативе занимались, или им все-таки кто-то от бизнеса ставил задачи ?
бизнес никак не заинтересован в переписывании монолитов на микросервисы, это программисты им это и внушили
Сейчас бизнесы дебит с кредитом свели да повыкидывали этих ненужных продавцов лопат.
И стали платить продавцам экскаваторов.
Год уже ищу работу. Озолотился!
Снова нужны любознательные люди с широким кругозором, которые умеют быстро разбираться в новом, собирать знания из разных областей и применять технологии по делу, а не просто знать стек.
Такие всегда были нужны.
Ну и вообще, как бы сильно не развивались технологии, всегда будут компании, которым вынуждено нужно поддерживать древнейшее legacy со времен динозавров
"Смешно, что недавно у Anthropic утёк исходный код Claude Code" - а вы не задумывались, что это Claude пытался сбежать?
Сейчас, с приходом ИИ, всё как будто повторяется заново. Снова нужны любознательные люди с широким кругозором, которые умеют быстро разбираться в новом, собирать знания из разных областей и применять технологии по делу, а не просто знать стек.
И где такие вакансии? Наоборот, нужны очень узкие специалисты, имеющие глубокий опыт использования вполне определённых вещей. Тут не до сбора знаний, сейчас стоит вопрос выживания.
Вот я, как раз, по своей вине, пропустил 20 золотых лет программирования, но я ещё вполне любознательный и хочу собирать знания из различных областей. Только как это сможет отразиться на доходе?
Не стоит думать, что приход ИИ что-то возвращает. Сейчас мы имеем Шрёдингера Кота вместо ИИ: ИИ, вроде бы есть, он пришёл, кто-то чего-то делает. где-то каике-то успехи имеются, но со временем начинают выплывать всевозможные косяки, ограничения и, кое-где, и вовсе системные дефекты.
Если, что и приходится сейчас заново делать, так это учиться. Пройти заново то, что раньше было пройдено по диагонали. Заново пройти по пути прошедших достижений и вдумчиво ими овладеть. Заново открыть для себя программирование.
Нынешняя ситуация заключается в чрезвычайном падении профессионализма. Ещё вчера в поликлинике работал пожилой врач с большим опытом удачного лечения. Сегодня уже нет. Ещё вчера во дворе был родной дворник, который всегда убирал снег рано утром, и ты всегда шёл по чищенной дорожке. Сегодня же никто не убирает свежий снег (за очень редким исключением), зато много заливают "солью". Ещё вчера программисты бились за каждый байт, а сегодня даже примитивная программа занимает сотни мегабайт (я утрирую: тут важен порядок, а не конкретная цифра).
"Приход" ИИ очень странный. Довольно трудно комментировать успехи ИИ, когда ты понимаешь, в целом, каково (может быть, скорее всего) качество обучающей выборки. Ну, если, что-то удалось автоматизировать, то. значит (скорее всего!) и качество этого не высокое. А действительно стоящие вещи автоматизировать — надо ещё постараться.
Нынешняя ситуация заключается в чрезвычайном падении профессионализма
Конечно, подлинные профессионалы всегда скажут, что настоящий профессионализм, как раз, заключается в том, чтобы быстрее писать программы, а железо дешёвое, оно всё стерпит.
Но!
Вы только представьте, если бы сегодня писались экономные программы. Ведь, это как можно было бы повысить безопасность и удобство программного обеспечения! Можно было бы даже делать карты расширения (по типу графических), где крутилась бы самостоятельная ОС и автоматизированное рабочее место какого-либо специалиста, неуязвимые для вирусов и перепрошивок, не требующие обновления, но, благодаря своей аппаратной реализации, шибко резвые и эффективные (в плане использования ресурсов). И, кстати, это мог быть не хилый такой бизнес.
Я кстати тоже пропустил 20 золотых лет программирования. Как знал что надо было раньше рождаться.
Ещё вчера в поликлинике работал пожилой врач с большим опытом удачного лечения.
Вы, кажется, зря ассоциируете большой возраст врача с "с большим опытом удачного лечения". Особенно когда этот врач гомеопатию выписывает и советует в церковь сходить.
К сожалению в геймдеве это не работает. Помимо кода, нужен делать контент - текстуры, модели, картинки, уровни, баланс и т.д., Игры гораздо сложнее любого приложения, даже у бортовых компьютеров космических кораблей софт проще.
У нейросетей все это пока не очень получаются. Даже простейшую покадровую анимацию в пиксель-арте не могут сделать. Максимально близко делает только нано-банана 2, но и там надо дорабатывать ручками(читай рисовать). А как делать тайловые уровни?
даже у бортовых компьютеров космических кораблей софт проще.
И цена ошибки одинакова. Или нет? Так может сложность не с того бока меряете?
"Больше" не значит - "сложнее". Больше, чаще всего, означает отсутствие: квалификации, ресурсов, желания.
у бортовых компьютеров космических кораблей софт проще
У бортовых компьютеров софт простой как тапок потому что должен быть отслеживаем от и до и должен работать даже на утюге.
Максимально близко делает только нано-банана 2, но и там надо дорабатывать ручками
Так и с кодом та же фигня. То что написано ии потом нужно долго полировать напильником
Золотое оно только для тех, кто привык думать своей головой, а не полагаться на ИИшного болвана. Такие нигде не пропадут, особенно когда останутся одни вафлекодеры вайбкодеры, удивляющиеся "ой, а че это у меня техдолг на копился на полтеррабайта, а чево делоть?? Ой памахите-е-е"
Золотое оно только для тех, кто привык думать своей головой,
Ну ну) Я из тех кто привык и думает исключительно своей головой и вот уже как полтора года не могу найти работу. А направление самое банальное - senior frontend developer, всего лишь с 13 годами опыта за плечами. Причем я ни ставлю даже никаких условий, мне пофиг что будет адский говнокод и легаси, в таких условиях я согласен на всё, но даже это не даёт никаких плодов, 1 собеседование за 3 месяца это уже успех.
У нейросетей есть фундаментальная проблема - если чего то нет в их словарике - они это не выдадут. Да они могут додумать или галлюцинировать. Так что какие-то узкоспециализированные вещи, которые никогда не выкладывались в интернет - они не им доступны будут. И все равно придется думать мозгами. Просто привожу примеры из своей сферы - разработка авиационных программно-аппаратных блоков российских самолетов - тут как писали пока код ручками - так и пишут. Ибо ниша настолько узкая и консервативная, что ИИшка тут слабо чем поможет.
Если посмотреть, как релизятся тот же Cursor или Anthropic, там ощущение, что маленькие команды поставляют в прод какое-то бешеное количество фичей. И вот это, кажется, новое бутылочное горлышко в разработке
Можно ли такие маргинальные (во всех смыслах) примеры рассматривать как проявление общих законов? С другой стороны, зачем нужно производить бешеное количество? В этом-то и ужас, что индустрия дорвалась до индустриализации производства программного обеспечения, но сама находится ещё на далёких подступах к этом в плане технических=теоретических представлений и технологических оснований.
В каком-то смысле у всех снова обнулился опыт
Да никакой ни опыт обнулился. Обнулились карманы инвесторов, руквоводителей венчурных фондов и прочих, кто раньше предоставлял рабочие места и был моитирован развивать бизнес. А сейчас о каком развитии идет речь? Cейчас речь о выживании.
золотое - не золотое, но подготовиться к открытию имплант-студии стоит:-)
С агентской разработкой ты теперь можешь генерировать настолько много, что тебе буквально нужно совсем немного людей, чтобы система стабильно двигалась.
Ага, это уже было. Причем несколько раз:
С ООП вместо ASM ты теперь можешь генерировать настолько много...
А потом так:
С VCL под Delphi или Windows Forms Designer под VS ты теперь можешь генерировать настолько много...
И те же баталии были: "формошлепство VS Труъ разработки"
Но в результате все как-то устаканилось, не так ли?
С VCL под Delphi или Windows Forms Designer под VS ты теперь можешь генерировать настолько много...
И те же баталии были: "формошлепство VS Труъ разработки"
Но в результате все как-то устаканилось, не так ли?
Знаете, тут есть такой момент. Есть недоделанные вещи. Никто не видел некоторые вещи доделанными. Я хотел бы увидеть. Например, взять VCL и реализовать некий продукт. Его ж никто не видел. А так... просто что-то вбрасывается, но бросается на полпути. ;-(
Раньше больше времени уходило на сам код, сейчас вроде быстрее пишется, но зато появляются другие проблемы. Нужно проверять, что сгенерилось, разбираться, почему оно работает не так, как ожидалось, и как это всё нормально встроить в проект
История циклична. Да, вырастут новые, сменят "старых дедов", а там посмотрим куда все придет.
Время может и золотое, но не для всех.
ИИ ускоряет опытных разработчиков, и замедляет (в долгосроке) всех остальных. Мидлы быстро генерируют код, и к сожалению он по первости даже работает. А потом кодовая база превращается в big-ball-of-mud и привет... В ней не то что мидлу, сеньору-то не разобраться!
Но конечно, есть успешные примеры, когда и такого кода хватило для создания успешного бизнеса. Либо, как в случае с ИИ-проектами, у небольших команд выстрелила идея. Facebook тоже изначально на коленке был сделан. Но это не значит, что такой подход работает повсеместно...
Ага - какой ужасный код, да и пофиг. Больше говнокода! Автор молодец!
Смелые эксперименты хороши до той поры, когда из за навайбкоженной прошивки роботакси сбивает вашего родственника.
Пьяный (или усталый) водитель тоже может сбить вашего родственника.
1. если роботакси будет сбивать реже людей, чем живые водители, это будет уже победа.
2. ответственность любого такси (робо или биологического) должна быть застрахована на большую сумму денег. А вот страховая премия будет зависеть от конкретной статистики.
Раньше люди писали в двоичных кодах - пришли реформаторы - скзаали - теперь пишем на ассемблере. Размеры софта выросли - пришли реформаторы - так ..все Фортран/Паскаль/Си/Алгол и так далее - ура. Софт стал еще расти. Пришли динамические языки - код еще вырос. А теперь пришли языки на основе промтов. Да здравствуют промтграммисты!
Золотым нынешнее время может оказаться только в том случае, если сейчас удастся упорядочить накопленные знания, возможно, написать какие-то книжки из разряда "основ-полагающих", хотя бы ради эксперимента создать несколько навороченных программных систем. Тогда можно будет открывать новую эпоху. А пока... наблюдается устойчивая стагнация во всех областях. И ИТ здесь не исключение.
Проблема-то в чём? Если что-то может быть автоматизировано, то оно должно быть автоматизировано. Но если что-то уже автоматизировано, то эта автоматизация должна быть использована и в других аналогичных случаях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вообще, кажется, сейчас начинается золотое время в IT