Тим О’Райли
Американский издатель, основатель издательства O’Reilly.
В СМИ много говорят о том, что разработчики ПО скоро потеряют работу из-за ИИ. Я в это не верю.
Это не конец программирования. Это конец программирования в том виде, в котором мы его знаем сегодня. Первые программисты соединяли физические цепи для выполнения каждого вычисления. Их сменили программисты, писавшие машинные инструкции в виде двоичного кода, который вводился по одному биту за раз с помощью переключателей на передней панели компьютера. Затем программирование на языке ассемблера положило этому конец. Оно позволяло программисту использовать язык, похожий на человеческий, чтобы указать компьютеру перемещать данные в определенные области памяти и выполнять над ними вычисления. Затем развитие еще более высокоуровневых компилируемых языков, таких как Fortran, COBOL и их последователей C, C++ и Java, привело к тому, что большинство программистов больше не писали ассемблерный код. Вместо этого они могли выражать свои пожелания компьютеру, используя абстракции более высокого уровня.
В конце концов, нормой стали интерпретируемые языки, которые гораздо проще отлаживать.
BASIC, один из первых, кто добился большого успеха, сначала воспринимался как игрушка, но вскоре оказалось, что он стал новой волной. Программирование стало доступно детям и предпринимателям в гаражах, а не только сотрудникам бэк-офисов крупных компаний и государственных учреждений.
Потребительские операционные системы также сыграли большую роль в истории. На заре персональных компьютеров каждому производителю компьютеров требовались инженеры-программисты, которые могли бы писать низкоуровневые драйверы, выполняющие работу по чтению и записи на схемы памяти, жесткие диски и периферийные устройства, такие как модемы и принтеры. Windows положила этому конец. Она стала успешной не только потому, что предоставляла графический пользовательский интерфейс, который значительно упростил использование компьютеров для неподготовленных людей, но также то, что Марк Андрессен, чью компанию Netscape собиралась раздавить Microsoft, пренебрежительно (и ошибочно) назвал «просто мешок драйверов». Этот мешок драйверов, скрытый за API Win32, означал, что программистам больше не нужно было писать низкоуровневый код для управления машиной. Эта задача была эффективно реализована в операционной системе. Из-за Windows и macOS, а также iOS и Android (для мобильных устройств) сегодня большинству программистов больше не нужно знать многое из того, что знали предыдущие поколения программистов.
Программистов было больше, а не меньше
Это был еще далеко не конец программирования. Программистов было больше, чем когда-либо. Сотни миллионов пользователей потребляли плоды их творчества. Классический пример эластичности спроса: поскольку создавать программное обеспечение становилось проще, его цена падала, что позволяло разработчикам создавать решения, за которые больше людей были готовы платить.
Интернет стал еще одним «концом программирования». Внезапно пользовательский интерфейс стал состоять из понятных человеку документов, отображаемых в браузере со ссылками, которые, в свою очередь, могли вызывать программы на удаленных серверах. Любой мог создать простое «приложение» с минимальными навыками программирования. «No code» стало модным словечком. Вскоре всем понадобился веб-сайт. Такие инструменты, как WordPress, позволили непрограммистам создавать веб-сайты без программирования. Однако по мере того, как возможности технологий росли, успешные веб-сайты становились все более и более сложными. Наблюдалось все большее разделение между «фронтенд» и «бэкенд» программированием. Новые интерпретируемые языки программирования, такие как Python и JavaScript, стали доминирующими. Мобильные устройства добавили новый, вездесущий фронтенд, требующий новых навыков. И снова сложность была скрыта за фреймворками, библиотеками функций и API, которые изолировали программистов от необходимости знать столько о низкоуровневой функциональности, сколько им было необходимо знать всего несколько лет назад.
Большие данные, веб-сервисы и облачные вычисления создали своего рода «операционную систему Интернета». Такие сервисы, как Apple Pay, Google Pay и Stripe, сделали возможным выполнение ранее сложных, высокорисковых корпоративных задач, таких как прием платежей, с минимальными знаниями в области программирования. Все виды глубоких и мощных функций стали доступны через простые API. Однако этот взрыв интернет-сайтов и сетевых протоколов и API, соединяющих их, в конечном итоге создал потребность в большем количестве программистов.
Программисты больше не создавали статические программные артефакты, обновляемые каждые пару лет, а непрерывно разрабатывали, интегрировали и поддерживали долгоживущие сервисы. Что еще важнее, большая часть работы в этих огромных сервисах, таких как Google Search, Google Maps, Gmail, Amazon, Facebook и Twitter, была автоматизирована в огромных масштабах. Программы были разработаны и созданы людьми, а не ИИ, но большая часть самой работы была сделана специализированными предшественниками сегодняшних ИИ общего назначения. Работники, которые выполняют большую часть тяжелой работы в этих компаниях, уже являются программами. Программисты-люди — их менеджеры. Сейчас сотни тысяч программистов выполняют такую надзорную работу. Они уже живут в мире, где работа заключается в создании и управлении цифровыми коллегами.
В каждой из этих волн старые навыки становились устаревшими. Все еще полезными, но уже не необходимыми, и новые становились ключом к успеху. Есть еще несколько программистов, которые пишут компиляторы, тысячи, которые пишут популярные фреймворки JavaScript и библиотеки Python, но десятки миллионов, которые пишут веб- и мобильные приложения и бэкэнд для них. Миллиарды пользователей потребляют то, что они производят.
Может ли в этот раз быть по-другому?
Внезапно оказалось, что непрограммист может просто поговорить с LLM или специализированным программным агентом на простом английском языке (или на человеческом языке по вашему выбору) и получить в ответ полезный прототип на Python (или на языке программирования по вашему выбору). Для этого даже появилось новое модное словечко: CHOP, или «чат-ориентированное программирование». Рост продвинутых моделей начинает демонстрировать ИИ, способный генерировать даже сложные программы с высоким уровнем подсказок, объясняющих задачу, которую нужно выполнить. В результате многие говорят: «На этот раз все по-другому», что ИИ полностью заменит большинство программистов-людей и, по сути, большинство работников умственного труда. Они говорят, что мы сталкиваемся с волной всепроникающей безработицы среди людей.
Я все еще не верю в это. Когда происходит прорыв, который дает передовые вычислительные мощности в руки гораздо большей группы людей, да, обычные люди могут делать то, что когда-то было прерогативой высококвалифицированных специалистов. Но тот же самый прорыв также открывает новые виды услуг и спроса на эти услуги. Он создает новые источники глубокой магии, которую понимают лишь немногие.
Магия, которая наступает сейчас, самая мощная из всех. И это значит, что мы начинаем глубокий период исследований и творчества, пытаясь понять, как заставить эту магию работать и извлечь новые преимущества из ее силы. Умные разработчики, которые примут эту технологию, будут востребованы, потому что они могут сделать гораздо больше, сосредоточившись на более высоком уровне креативности, которая добавляет ценность.
Обучение на практике
ИИ не заменит программистов, но он преобразит их работу. В конечном итоге многое из того, что делают программисты сегодня, может оказаться таким же устаревшим (для всех, кроме программистов встроенных систем), как и старый навык отладки с помощью осциллографа. Программист и провидец в области технологий Стив Йегге замечает, что будут заменены не программисты младшего и среднего звена, а те, кто цепляется за прошлое и не принимает новые инструменты и парадигмы программирования. Те, кто приобретают или изобретают новые навыки, будут пользоваться большим спросом. Младшие разработчики, которые владеют инструментами ИИ, смогут превзойти старших программистов, которые этого не делают. Йегге называет это «Смертью упрямого разработчика».
Мои идеи сформированы не только моим собственным 40-летним опытом работы в компьютерной индустрии и наблюдениями разработчиков, таких как Йегге, но и работой историка экономики Джеймса Бессена, который изучал, как первая промышленная революция разыгралась на текстильных фабриках Лоуэлла, Массачусетс, в начале 1800-х годов. Поскольку квалифицированных ремесленников заменили машины, управляемые «неквалифицированным» трудом, заработная плата людей действительно снизилась. Но Бессен заметил нечто странное, сравнив показатели заработной платы рабочих на новых промышленных фабриках с показателями бывших надомных ремесленников. Подмастерью ремесленника требовалось примерно столько же времени, чтобы достичь полной заработной платы квалифицированного подмастерья, сколько требовалось новому неквалифицированному фабричному рабочему начального уровня, чтобы достичь полной заработной платы и производительности. Рабочие в обоих режимах были фактически квалифицированными рабочими. Но у них были разные виды навыков.
Бессен обнаружил, что существуют две основные причины, по которым заработная плата оставалась на прежнем уровне или была низкой большую часть первых 50 лет промышленной революции прежде чем она взлетела и привела к повсеместному росту благосостояния. Первая заключалась в том, что владельцы фабрик копили выгоды от новой производительности, а не делились ими с рабочими. Но вторая проблема заключалась в том, что для достижения наибольшего прироста производительности потребовались десятилетия, поскольку знания о том, как лучше всего использовать новую технологию, еще не были широко распространены. Изобретателям потребовались десятилетия, чтобы сделать машины более надежными, тем, кто их использует, чтобы придумать новые виды рабочих процессов, чтобы сделать их более эффективными, чтобы создать новые виды продуктов, которые можно было бы производить с их помощью, чтобы более широкий круг предприятий принял новые технологии, а рабочим — чтобы приобрести необходимые навыки, чтобы воспользоваться ими. Рабочим нужны были новые навыки не только для использования машин, но и для их ремонта, улучшения, изобретения будущего, которое они подразумевали, но еще не сделали полностью возможным. Все это происходит посредством процесса, который Бессен называет «обучением на практике».
Недостаточно, чтобы несколько человек были впереди всех в освоении новых навыков. Бессен объясняет, что «для завода, отрасли и общества в целом важно не то, сколько времени требуется для обучения отдельного работника, а то, сколько времени требуется для создания стабильной, обученной рабочей силы» (Learning by Doing, 36). Сегодня каждая компания, которая будет затронута этой революцией (то есть каждая компания), должна подставить плечо. Нам нужна рабочая сила, владеющая ИИ. Что такое программирование, в конце концов, как не способ, которым люди заставляют компьютеры выполнять наши приказы? Тот факт, что «программирование» становится все ближе и ближе к человеческому языку, что наши машины могут понимать нас, а не нам приходится говорить с ними на их родном языке нулей и единиц или на каком-то специализированном языке программирования, должен быть поводом для празднования.
Люди будут создавать, использовать и совершенствовать больше программ, и появятся новые отрасли, чтобы управлять и развивать то, что мы создаем. Уроки истории говорят нам, что когда автоматизация делает дешевле и проще поставку продуктов, которые хотят или в которых нуждаются люди, рост спроса часто приводит к росту занятости. Только когда спрос удовлетворяется, занятость начинает падать. Мы далеки от этой точки, когда дело касается программирования.
Парадокс Джевонса снова наносит удар! По мере того, как ИИ становится все более эффективным и доступным, мы увидим, как его использование резко возрастет, превращая его в товар, которым мы просто не сможем насытиться. https://t.co/omEcOPhdIz
— Сатья Наделла (@satyanadella) 27 Января, 2025
Неудивительно, что профессор Уортонской школы бизнеса и евангелист ИИ Итан Моллик также является поклонником работы Бессена. Вот почему он так убедительно доказывает, что нужно «всегда привлекать ИИ», вовлекать его в каждый аспект вашей работы и исследовать «острые края» того, что работает, а что нет. Вот почему он также призывает компании использовать ИИ для расширения прав и возможностей своих работников, а не для их замены. Нужно так много узнать о том, как применять новые технологии. Лучшим исследованием для бизнеса является исследование ваших сотрудников, пользующихся ИИ для решения своих проблем и поиска новых возможностей.
Что есть программирование изменится
Сэм Шиллес, один из заместителей технического директора Microsoft, согласился с моим анализом. В недавнем разговоре он сказал мне: «Мы находимся в процессе изобретения новой парадигмы программирования вокруг систем ИИ. Когда мы перешли от настольных компьютеров к эпохе Интернета, все в стеке изменилось, хотя все уровни стека остались прежними. У нас по-прежнему есть языки, но они перешли от компилируемых к интерпретируемым. У нас по-прежнему есть команды, но они перешли от каскадной к Agile, к CI/CD. У нас по-прежнему есть базы данных, но они перешли от ACID к NoSQL. Мы перешли от одного пользователя, одного приложения, одного потока ко всему распределенному. Мы делаем то же самое с ИИ прямо сейчас».
Вот некоторые из технологий, которые собираются в новый стек ИИ. И это даже не включает в себя множество моделей ИИ, их API и их облачную инфраструктуру. И это уже устарело!
Взрыв новых инструментов, фреймворков и практик — это только начало того, как меняется программирование. Одна из проблем, отметил Шиллес, заключается в том, что у моделей нет памяти, как у людей. Даже с большими контекстными окнами им трудно делать то, что он называет «метапознанием». В результате он видит необходимость в том, чтобы люди по-прежнему предоставляли большую часть контекста, в котором работают их соразработчики ИИ.
Шиллес развил эту идею в недавнем посте. «Большие языковые модели (LLM) и другие системы ИИ пытаются автоматизировать мышление», — написал он. «Параллели с автоматизацией движения во время промышленной революции поразительны. Сегодня автоматизация все еще груба: мы выполняем когнитивный эквивалент перекачивания воды и ударов молотком — базовые задачи, такие как создание краткой версии, распознавание образов и генерация текста. Мы еще не придумали, как построить надежные двигатели для этого нового источника энергии — мы еще даже не на локомотивной стадии ИИ».
Даже стадия локомотива была в значительной степени расширением грубой силы, которую люди могли использовать для перемещения физических объектов. Существенным следующим прорывом было увеличение средств контроля над этой силой. Шиллес спрашивает: «А что, если традиционная разработка программного обеспечения здесь не совсем уместна? А что, если создание ИИ требует принципиально иных практик и систем управления? Мы пытаемся создать новые виды мышления (наш аналог движения): высокоуровневые, метакогнитивные, адаптивные системы, которые могут делать больше, чем просто повторять заранее разработанные шаблоны. Чтобы использовать их эффективно, нам нужно будет изобрести совершенно новые способы работы, новые дисциплины. Так же, как проблемы ранней паровой энергетики породили металлургию, проблемы ИИ приведут к появлению новых наук о познании, надежности и масштабируемости — областей, которые еще не полностью существуют».
Проблема внедрения технологий ИИ в бизнесе
Брет Тейлор, бывший содиректор Salesforce, бывший главный технический директор Meta и в прошлом руководитель команды, создавшей Google Maps, теперь является генеральным директором компании-разработчика ИИ-агентов Sierra, которая находится в центре разработки и внедрения технологий ИИ в бизнесе. В недавнем разговоре Брет сказал мне, что, по его мнению, ИИ-агент компании станет ее основным цифровым интерфейсом, таким же значимым, как ее веб-сайт, таким же значимым, как ее мобильное приложение, возможно, даже более. ИИ-агент компании должен будет кодировать все её ключевые бизнес-политики и процессы. Это то, что ИИ в конечном итоге сможет делать сам, но сегодня Sierra приходится назначать каждому из своих клиентов инженерную команду, которая помогает с внедрением.
«Эта последняя миля, когда вы берете крутую платформу и кучу своих бизнес-процессов и создаёте агента, на самом деле довольно сложна», — объяснил Брет. «Сейчас появляется новая роль, которую мы называем агент-инженером, разработчиком программного обеспечения, который немного похож на разработчика веб-интерфейса. Это архетип, который наиболее распространен в программном обеспечении. Если вы разработчик React, вы можете научиться создавать агентов ИИ. Какой замечательный способ переквалифицироваться и сделать свои навыки актуальными».
Кто захочет продираться через дерево телефонов службы поддержки клиентов, когда они могли бы поговорить с агентом ИИ, который действительно может решить их проблему? Но сделать этих агентов правильными будет настоящим вызовом. Сложно не программирование, сложно глубоко понимать бизнес-процессы и думать о том, как новые возможности могут их преобразовать, чтобы воспользоваться преимуществами новых возможностей. Агент, который просто воспроизводит существующие бизнес-процессы, будет таким же неловким, как веб-страница или мобильное приложение, которые просто воссоздают бумажную форму. (И да, такие все еще существуют!)
Эдди Османи, руководитель отдела пользовательского опыта Google Chrome, называет это проблемой 70%: «В то время как инженеры сообщают о значительном повышении производительности с ИИ, фактическое программное обеспечение, которое мы используем ежедневно, не становится заметно лучше». Он отмечает, что непрограммисты, работающие с инструментами генерации кода ИИ, могут выпустить отличное демо или решить простую проблему, но они застревают на последних 30% сложной программы, потому что они недостаточно знают, чтобы отладить код и направить ИИ к правильному решению. Между тем:
Когда вы смотрите, как старший инженер работает с инструментами ИИ, такими как Cursor или Copilot, это похоже на магию. Они могут создавать целые функции за считанные минуты, с тестами и документацией. Но смотрите внимательно, и вы заметите нечто важное: они не просто принимают то, что предлагает ИИ... Они применяют годы с трудом завоеванной инженерной мудрости, чтобы сформировать и ограничить вывод ИИ. ИИ ускоряет их реализацию, но их опыт — это то, что делает код поддерживаемым. Младшие инженеры часто пропускают эти важные шаги. Они принимают вывод ИИ более охотно, что приводит к тому, что я называю «карточным домиком из кода» — он выглядит завершенным, но рушится под давлением реального мира.
В этой связи Чип Хуен, автор новой книги «AI Engineering», сделал в электронном письме мне следующее проницательное наблюдение:
Я не думаю, что ИИ вводит новый тип мышления. Он показывает, что на самом деле требует мышления.
Неважно, насколько это ручная работа, если ее может выполнить только горстка наиболее образованных людей, она считается интеллектуальной. Одним из примеров является письмо, физический акт копирования слов на бумагу. В прошлом, когда грамотной была лишь небольшая часть населения, письмо считалось интеллектуальным. Люди даже гордились своей каллиграфией. В наши дни слово «письмо» больше не относится к этому физическому акту, а к более высокой абстракции упорядочивания идей в читаемом формате.
Аналогичным образом, как только физический процесс кодирования станет автоматизированным, значение слова «программирование» изменится и будет означать процесс организации идей в исполняемые программы.
Мехран Сахами, глава кафедры вычислительной техники Стэнфордского университета, выразился просто: «Компьютерная наука — это систематическое мышление, а не написание кода».
Когда ИИ-агенты начинают общаться с агентами…
…точность в правильной формулировке проблемы становится еще важнее. Агент как корпоративный фронтенд, который обеспечивает доступ ко всем бизнес-процессам компании, будет общаться не только с потребителями, но и с агентами этих потребителей и агентами других компаний.
Вся эта сторона уравнения агента гораздо более спекулятивна. Мы еще не начали разрабатывать стандарты для сотрудничества между независимыми агентами ИИ! В недавней статье о необходимости инфраструктуры агента отмечается:
Текущие инструменты в значительной степени недостаточны, поскольку они не предназначены для формирования того, как агенты взаимодействуют с существующими институтами (например, правовыми и экономическими системами) или субъектами (например, поставщиками цифровых услуг, людьми, другими агентами ИИ). Например, методы согласования по своей природе не гарантируют контрагентам, что какой-то человек будет привлечен к ответственности, когда пользователь поручает агенту выполнить незаконное действие. Чтобы заполнить этот пробел, мы предлагаем концепцию инфраструктуры агентов: технические системы и общие протоколы, внешние по отношению к агентам, которые предназначены для посредничества и влияния на их взаимодействия с их окружением и воздействия на него. Инфраструктура агентов включает в себя как новые инструменты, так и перенастройки или расширения существующих инструментов. Например, для облегчения подотчетности протоколы, связывающие пользователей с агентами, могут основываться на существующих системах аутентификации пользователей, таких как OpenID. Так же, как Интернет полагается на инфраструктуру, такую как HTTPS, мы утверждаем, что инфраструктура агентов будет столь же незаменима для экосистем агентов. Мы выделяем три функции для инфраструктуры агентов: 1) присвоение действий, свойств и другой информации конкретным агентам, их пользователям или другим субъектам; 2) формирование взаимодействий агентов; и 3) обнаружение и устранение вредоносных действий агентов.
Здесь нужно решить огромные проблемы координации и проектирования. Даже самые лучшие ИИ-агенты, которых мы можем себе представить, не решат такие сложные проблемы координации без человеческого руководства. Здесь нужно столько программирования, что даже программисты с поддержкой ИИ будут заняты по крайней мере следующее десятилетие.
Короче говоря, есть целый мир нового программного обеспечения, которое нужно изобрести, и оно будет изобретено не только ИИ, но и людьми-программистами, использующими ИИ как суперсилу. И этим программистам нужно приобрести много новых навыков.
Мы находимся на раннем этапе изобретения будущего
Так много нового нужно узнать и сделать. Так что да, давайте наберемся смелости и предположим, что соразработчики ИИ делают программистов в десять раз продуктивнее. (Ваш показатель может отличаться в зависимости от того, насколько ваши разработчики стремятся освоить новые навыки.) Но давайте также предположим, что как только это произойдет, «программируемая поверхность» бизнеса, науки, нашей построенной инфраструктуры будет расти параллельно. Если будет в 20 раз больше возможностей для программирования, чтобы что-то изменить, нам все равно понадобится вдвое больше этих новых 10-кратных программистов!
Ожидания пользователей также возрастут. Компании, которые просто используют большую производительность для сокращения расходов, проиграют компаниям, которые инвестируют в освоение новых возможностей для создания лучших услуг.
Саймон Уиллисон, опытный разработчик программного обеспечения, который был в авангарде того, чтобы показать миру, как программирование может быть проще и лучше в эпоху ИИ, отмечает, что ИИ позволяет ему «быть более амбициозным» в своих проектах.
Возьмите урок из другой области, где возможности резко ворзасли: рендеринг одного кадра одного из сегодняшних фильмов о супергероях Marvel может занять столько же времени, сколько и рендеринг всего первого фильма Pixar, хотя цена и производительность CPU/GPU выиграли от закона Мура. Оказывается, киноиндустрия не довольствовалась тем, чтобы быстрее и дешевле поставлять грубую анимацию с низким разрешением. Дополнительные циклы пошли на тысячи крошечных улучшений в реалистичности меха, воды, облаков, отражений и многих-многих других пикселей разрешения. Технологическое улучшение привело к повышению качества, а не просто к более дешевой/быстрой доставке. Есть некоторые отрасли, которые стали возможны благодаря выбору более дешевого/быстрого вместо более высоких производственных значений (вспомним взрывной рост количества созданного пользователями видео в Интернете), поэтому не будет выбора или-или. Качество будет иметь свое место на рынке. Так происходит всегда.
Представьте себе десятки миллионов программистов-любителей, работающих с помощью ИИ, которые работают с такими инструментами, как Replit и Devin, или корпоративными решениями, такими как те, что предоставляются Salesforce, Palantir или Sierra. Какова вероятность того, что они наткнутся на варианты использования, которые понравятся миллионам? Некоторые из них станут предпринимателями этого следующего поколения программного обеспечения, созданного в партнерстве с ИИ. Но многие из их идей будут приняты, улучшены и масштабированы существующими профессиональными разработчиками.
Путешествие от прототипа к производству
В предпринимательстве ИИ значительно повысит возможности создания решений теми, кто ближе всего к любой проблеме. Но лучшим из этих решений все равно придется пройти оставшуюся часть пути, который Шьям Санкар, технический директор Palantir, назвал «путешествием от прототипа к производству». Санкар отметил, что ценность ИИ для предприятия заключается «в автоматизации, в автономности предприятия». Но, как он также отметил, «автоматизация ограничена крайними случаями». Он вспомнил уроки Stanley, беспилотного автомобиля, который выиграл DARPA Grand Challenge в 2005 году: он способен делать что-то выдающееся, но требует еще 20 лет разработки, чтобы полностью справиться с крайними случаями вождения в городе.
«Рабочий процесс по-прежнему важен», — утверждает Санкар, и работа программиста будет заключаться в том, чтобы понять, что может быть сделано традиционным программным обеспечением, что может быть сделано ИИ, что все еще должно быть сделано людьми, и как связать все вещи вместе, чтобы фактически выполнить рабочий процесс. Он отмечает, что «цепочка инструментов, которая позволяет вам получать обратную связь и изучать пограничные случаи, чтобы достичь цели как можно быстрее, является выигрышной цепочкой инструментов». В мире, который представляет себе Санкар, ИИ «фактически освободит разработчиков, чтобы они могли гораздо больше вникать в бизнес и быть гораздо более вовлеченными в оказываемое ими влияние». Между тем, ведущие специалисты в предметной области станут программистами с помощью помощников ИИ. Это не программисты останутся без работы. Это будут люди, на каждой должности, которые не станут программистами с помощью ИИ.
Это не конец программирования. Это начало его следующего переосмысления.
Комментарии (291)
Illivion
07.02.2025 13:49Согласен с идеей статьи. И что интересно, возникают новые необычные сложности. Сейчас тоже тесно использую AI, и недавно поймал себя на мысли, что такой способ позволяет ускорить работу и открыть новые горизонты разработки. Но при этом в ближайшем будущем очень легко прийти к ситуации, когда результат работы программиста совместно с AI будет недоступен для понимания человеком. И для того чтобы хоть как-то разобраться, опять же AI будет необходим.
mixsture
07.02.2025 13:49А это может разрушить область ИБ. Раз код пишет АИ и разбираемся в нем с АИ, а по-другому не можем - то мы понятия не имеем, что там может быть скрыто дополнительного. У нас пропадает второй канал информации в виде прямого понимания кода. И если протестировать "что должно делать приложение" относительно легко, то протестировать "что не должно" - на порядки сложнее, сродни проблеме доказательства отсутствия чего-либо.
skymal4ik
07.02.2025 13:49Пусть другой АИ анализирует код на безопасность. Или изначальный делает на нем акцент.
Но да, с этой точки зрения безопасность становится все более абстрактной и туманной
edogs
07.02.2025 13:49Раз код пишет АИ и разбираемся в нем с АИ, а по-другому не можем - то мы понятия не имеем, что там может быть скрыто дополнительного. У нас пропадает второй канал информации в виде прямого понимания кода.
Это ведь не качественно новая проблема.
Условное среднестатическое приложение подключает в себя сотни (по цепочке зависимостей) либ и мы понятия не имеем что там скрыто дополнительно, особенно когда они регулярно обновляются, без чего тоже нельзя.
Когда мы бьем приложение на микросервисы или модули, то отдаем модули разным разработчикам (командам/фирмам) и у нас нет ни прямого понимания кода, ни понятия о том, что там скрыто дополнительно.
Современная разработка слишком разрослась, чтобы тешить себя иллюзией контроля и пониманием происходящего. Всё в конце концов сводится к тестированию ПО, при чем как на тему "что должно делать", так и на тему "что не должно делать", при этом даже тестировщики ПО говорят что даже 100% покрытие кода тестами невозможно.
Поэтому - да, проблема есть, но она не качественно новая, это та же старая проблема, которой еще и до появления ИИ не было решения.
Из современного - можно вспомнить боинг, который без всякого ИИ отдавал код на аутсорс. Из старого - можно вспомнить ошибку вычислений с плавающей точкой на интеловском пентиуме, на правильность вычислений которых полагались приложения хотя и не знали что там скрыто и ничего не понимали. Из глобального можно вспомнить уязвимости в роутерах.
antonk42
07.02.2025 13:49Из-за ИИ эта проблема выйдет на качественно новый уровень.
RichardMerlock
07.02.2025 13:49Так как приложение нельзя модифицировать за приемлимую цену, которая в большинстве случаев будет выше цены создания, то обретут актуальность рантаймы и песочницы для таких приложений, где даже вирус, пусть он даже пожрётъ приложение его распаковавшее, не затронет других частей системы. А это еще овердофига слоёв всяких абстракций, т.к. окажется, что песочницу будут надиктовывать тоже чоповцы (модное словечко?). А тут еще больше ресурсов потребуется! Слава роботам!
accsentive
07.02.2025 13:49В системах с чувствительными данными почти всегда есть многоуровневые процедуры согласования/блокировки доступов и пермишенов, причем даже между внутренними ресурсами. Некоторые из таких алгоритмов принятия решений не отражены даже в регламентах и хранятся в коллективном понятийном мышлении дабы "неслучайный дровосек" по открытому алгоритму не наломал дров. Учитывая, что польза от изолированного АИ примерно как от подушки безопасности в бронепоезде, опасаться распространения ИИ в критических инфраструктурах сильно преждевременно. Из без них "течет" гигабайтами.
diakin
07.02.2025 13:49Против лома (социальной инженерии) нет приема. Кстати нет статистики по взломам в разрезе социальная инженерия vs все остальное?
Хотя конечно СИ это только метод входа, а уж что там троян может наворотить - это на совести операционки.
guest2342
07.02.2025 13:49Да и смысл открытого исходного кода изменится. Безопасность и отсутствие бэкдоров в том, что непонятно человеку изначально, будет полностью опираться на доверие ИИ
CrazyOpossum
07.02.2025 13:49Какому классу задач нужен настолько сложный код?
Illivion
07.02.2025 13:49Я это начал чувствовать на примере реализации кастомной структуры данных на основе кольцевого сегментированного буфера. И чтобы эта штука была thread safe c максимальной эффективностью.
Dooez
07.02.2025 13:49LLM помог Вам в написании такой структуры?
Большинство эффективных многопоточных структур сложны для понимания без участия ИИ. Для обеспечения производительности и корректности нужно довольно строго и точно понимать все переходы между состояниями, а со строгостью у LLM как раз проблемы насколько я вижу из отзывов. Довольно необычно если Ваш опыт говорит о полезности ИИ в данной задаче.
CrazyOpossum
07.02.2025 13:49Вот вот. В наиболее сложных технически вещах (сам ml, компиляторы и вообще ЯОП), всё должно быть верифицировано, а LLM - противоположность строгости. Собственно, все истории успеха "начатгпшил новый модный стартап" - это крайне примитивный с точки зрения CS код. Современный стек технологий часто сложный для понимания не потому что ракеты в космос запускает, а потому что фреймворки - перегруженное свистелками кю.
Illivion
07.02.2025 13:49Эксперимент скорее неудачный оказался. Мне не удалось заставить написать AI версию кода, которая прошла бы многопоточные тесты. Именно поэтому я написал про ближайшую перспективу, а не про сейчас. Но с текущей динамикой развития ИИ выглядит реально в будущем
alexeibs
07.02.2025 13:49LLM конечно такую структуру данных не напишет самостоятельно. Но это не означает, что LLM не будет полезной.
Если взять в качестве примера тот же Cursor, то LLM там поможет вот так:"Простое" автодополнение, которое уменьшит объем механического набора текста. Это хорошо работает для генерации каких-то стандартных конструкций языка, написания комментариев.
Можно попросить сгенерировать некий скелет/основу: какие-то классы, параметры конфигурации и пр. Дополнять скелет, конечно, придется самому
Можно попросить сгенерировать тесты для той самой многопоточной структуры. Вот тут LLM может сделать очень много полезного и то, что обычно писать человеку лень.
LLM очень хороши в написании кода, который логирует ошибки и не только. В сообщение можно добавить сколько угодно хорошо отформатированного контекста: вместо "shit happened" написать "shit happened in thread ${thread_id}, x = ${x}, y = ${y}". Это же работает и с сообщениями об ошибках в исключениях (exceptions).
LLM хорошо справляется с механическим рефакторингом типа переименования или добавления нового параметра в вызов какой-то функции. Можно пытаться делать и чуть более сложные вещи типа "залогируй все вызовы вот этого метода и оберни это в какой-нибудь helper".
LLM хорошо справляется с написанием небольших изолированных компонент с простым API. К примеру, можно сгенерировать код на основе Reflection API из Google Protobuf - обойти поля протобуфа и чего-то с ними сделать в процессе. Поскольку протобуф поддерживает очень большое количество разных типов данных, то генерация код тут полезна. Однако нужно быть внимательным и направлять LLM в правильное русло.
Чат можно использовать как источник справочной информации. Можно задавать вопросы по языку/библиотеке/технологии. Тут нужно быть осторожным, т.к. есть простор для галлюцинаций.
В целом, LLM - хороший инструмент, но не серебряная пуля. Нужно уметь этим инструментом пользоваться и понимать ограничения.
ptr128
07.02.2025 13:49Например, для прогнозирования, оптимизации и планирования. А так как их результаты дают явное конкурентное преимущество бизнесу, то спрос весьма велик.
Другое дело, что тут требуется больше аналитики, чем кодирования. Поэтому я предполагаю, что программисты в будущем будут больше аналитики и прикладные математики, чем кодеры. Может я и не прав, но у меня уже сейчас так и получается, судя по соотношению списанных часов на кодирование и на проработку постановок с клиентом.
engine9
07.02.2025 13:49Это сверхусложнение может стоить потери стабильности всего мира, когда код написанный ИИ приведет к масштабному сетевому сбою и окажется, чтобы его отладить без доступа к датацентру с ИИ нет связи.
Возможно мои рассуждения наивны, т.к. я не программист, но я вижу какое беспомощное говно современные девайсы и софт в местах где банально нет связи или она нестабильная и медленная.
sdramare
07.02.2025 13:49Вы даже не представляете на каком говнокоде держится стабильность мира сейчас
WebPeople
07.02.2025 13:49Я думаю, что понимание там и не нужно. И это даже не проблема, потому что такое явление существует много десятков лет.
Когда вы проектируете автомобиль - вам не нужно придумывать и понимать работу каждой мелочи. Например, вам не нужно разбираться в сплавах для создания какой-либо особо прочной детали, достаточно указать требования. Потом эту задачу будут решать профильные специалисты. И это касается буквально всего. Топлива, масел, материалов, вплоть до целых деталей, типа коробки передач.
Представьте на секунду мир, где разработчик способен в одиночку запрограммировать сложнейшие сервисы, типа гос.услуг при наличии хорошей документации, которую собрала команда с потребителей + ИИ помог с формализацией.
Если сейчас разработчику доступны "готовые" функции языка, библиотеки и фреймворки, то в будущем ему даже печатать ничего не надо будет (конечно, это не в самом близком будущем). Достаточно голосом озвучивать желаемый результат, а ИИ сам из скормленного ему ТЗ выдернет нужные требования (учитывая госты, стандарты безопасности и т.п.) и создаст что надо. Задача же разработчика - собрать из всех этих "кубиков" цельный сервис, проектируя общую архитектуру, контролируя процесс и исправляя "ошибки".
По аналогии с операторами современных ЧПУ-станков, они тоже не работают "руками", но ставят задачу станку и следят за корректным исполнением, вмешиваясь при необходимости.
scarab
07.02.2025 13:49мир, где разработчик способен в одиночку запрограммировать сложнейшие сервисы, типа гос.услуг
Вообще говоря, любой приличный олдскульный разработчик способен это сделать. Да, возможно, это займёт неприемлемое по нынешним меркам время, поскольку сейчас все хотят MVP через неделю и прод через месяц - но в принципе ничего сверхъестественного в госуслугах нет, это довольно простой сервис.
WebPeople
07.02.2025 13:49Дело не в "сверхестественном". Вы же не будете отрицать общую сложность сервиса. К тому же, это лишь пример. Можете заменить на любой сложный сервис, что вы знаете.
И вы правы насчет времени, надо было это явно указать в моем комментарии.
Ну и еще есть такой момент - даже олдскульный сеньор разработчик не запилит такой сервис и за десяток лет. Потому что это результат работы большой команды - дизайнеров, аналитиков, тестировщиков, девопсов и т.д. Вряд ли в природе существуют такие сеньоры, что сильны во всем.
А вот ИИ может помочь в этом. Например, я не художник, но могу симпатичные картины делать с помощью нейросетей, почти мгновенно. Аналогично я могу создать симпатичный дизайн для лендинга с помощью ИИ, не умея ни рисовать, ни верстать. Мне достаточно знать структуру лендинга (тоже ИИ подскажет). Ну и, в конце-концов, я про будущее писал. Причем не столь отдаленное. Тенденция же видна. И статья об этом же.
P.s. Я тут подумал, есть в этом развитии еще и положительный эффект для психики. Мир становится сложнее, программирование в частности. Все больше технологий надо знать, чтобы быть конкурентным. Это давит. Выгорание и депрессия у каждого второго. Но ведь куда лучше выучить что-то одно, но очень очень хорошо. Это избавляет от мук выбора и стресса от того, что знать надо все. И сильно облегчает работу узких специалистов. Ведь все непрофильное может помочь сделать ИИ. Как вы считаете?
scarab
07.02.2025 13:49Про помощь ИИ не спорю, сам им пользуюсь, весьма ускоряет решение простых задач.
Что же касается "сильны во всём" - я не зря упомянул олдскульных разработчиков. Просто потому, что где-нибудь в середине 90-х тупо не было ни девопсов, ни аналитиков. Ты хочешь себе сайт? Не вопрос - собери себе сервер, поставь туда линукс или фрю, апач, перл, настрой это всё, потом бери html, perl-cgi - и напиши.
Ну то есть не было (да и сейчас нет) разницы между аналитикой (инженер, не умеющий в декомпозицию, вообще не мог называться инженером), админством, кодингом - это всё были знания одного человека. И, поскольку упомянутых в статье средств высокоуровневого абстрагирования ещё попросту не существовало - знания эти были весьма глубокими. Любой приличный программист в студенчестве хотя бы пробовал написать прототип операционной системы; любой приличный админ мог пропатчить линуксовое ядро или какой-нибудь софт. Того же Игоря Сысоева вспомнить, который написал nginx, работая простым админом в рамблере. Без всяких аналитиков, тестировщиков и девопсов, просто "потому что могу" - сделал один из самых популярных веб-серверов в мире. И он не был каким-то уникумом, то же самое мог сделать любой спец приличного уровня.
Inoriol
07.02.2025 13:49Проблема в том что тогда не было ещё хайлоада. Интернетом пользовалось сравнительно немного людей, на небольших скоростях, с десктопа - и работать исходя из идеи, что один сервер вытянет любую нагрузку пока у него достаточно ресурсов можно было.
Сейчас портал в интернет есть буквально у каждого в кармане. Часто даже больше одного. Нагрузка на сайты выросла кратно. Требования к безопасности выросли кратно.
Да, хороший программист в одно рыло может написать что-то похожее на госуслуги. У него займёт это кучу времени, правда, но в целом это возможно. Но как только речь зайдёт о деплое, конфигурации на хайлоад, масштабировании, регуляций безопасности для патчей разных уязвимостей и так далее и в том же духе - этот проект одного человека посыплется.
scarab
07.02.2025 13:49Нагрузка на сайты выросла кратно.
Мощность серверов также выросла кратно. Сейчас любой смартфон мощнее тогдашних серверов. Поэтому умели в оптимизацию.Когда тому же Сысоеву стало понятно, что имеющейся мощности не хватает - он не к начальству пошёл с выкладками из графаны и требованиями нового железа, а написал сверхпроизводительный по тем временам свой веб-сервер
с блэкджеком и шлюхами.Году в 2000-м делали мы вебчат для одного проекта, как раз с расчётом на хайлоад. Чат был написан на сях и представлял собой фактически вебсервер, причём даже однопоточный - просто ни одной блокирующей операции у него в основном цикле не было. Он стартовал, загружал в память все нужные ему темплейты и ресурсы - и больше не обращался к диску вообще, действуя полностью в оперативке. На 10k rps он грузил процессор на 3% (что по тем временам было невозможным хайлоадом), занимая в памяти несколько метров.
Требования к безопасности выросли кратно.
А результаты куда хуже тогдашних, потому что кругом дево-псы, ставящие монгу без пароля ансибловыми плейбуками по статье с хабра. Тогда как в олдскульные времена паранойя являлась обязательной для админа профдеформацией, а "бизапасников" не было вообще, они были не нужны.
Я довольно много работаю с корп сегментом, в том числе с аудитами, в том числе безопасности. От того, что приходится наблюдать, волосы дыбом встают во всех местах.
scarab
07.02.2025 13:49куда лучше выучить что-то одно, но очень очень хорошо. Это избавляет от мук выбора и стресса от того, что знать надо все. И сильно облегчает работу узких специалистов. Ведь все непрофильное может помочь сделать ИИ. Как вы считаете?
Я могу ошибаться, но за 35 лет в IT у меня, скорее, обратное впечатление.
Если есть разноплановые узкие специалисты Вася и Петя, каждый из которых "хорошо умеет" что-то своё, а всё остальное за них делает ИИ - то логично предположить, что раз ИИ может сделать для Васи - работу Пети, а для Пети - работу Васи, то они оба уже оказались за бортом.
В то же время я наблюдаю дефицит как раз базовых знаний у молодых специалистов. Ну выучит он, условно, Питон - а через десяток лет об этом языке забудут, как забыли сейчас про Перл, Фортран, Кобол, Руби, ColdFusion и множество других языков и технологий. И чего в итоге - отправляться на свалку истории?
В то же время человек, хорошо знающий базу, матчасть - легко освоит любые новшества. Мне понадобилось достаточно немного времени, чтобы достаточно прилично разобраться в технологиях devops - ну потому что я администрирую линукс с 1997-го и происходящее в системе знаю куда лучше, чем современные девопсы-ямлописцы. Появится что-то ещё - разберусь и в этом.
А вот узкому специалисту это, в силу нехватки кругозора, не светит.
vkni
07.02.2025 13:49Я могу ошибаться, но за 35 лет в IT у меня, скорее, обратное впечатление.
Есть старый текст (не мой), который я выложил в качестве коммента https://habr.com/ru/articles/878266/comments/#comment_27871602
Единственное, что на самом деле влияет на эффективность процесса разработки - это наша способность раньше находить ошибки. А вот оттягивание этого на потом - отличный способ проект убить.
...
В частности, "традиционный" конвейер с отделами "анализ", "программисты", "тестировщики" - это сраный пиздец драматически увеличивающий среднее время жизни ошибки. Врата ада раскрываются, если добавить к этому "отдел архитектуры".То есть, в случае узких специалистов драматически увеличивается время коммуникации, которое катастрофически уменьшает скорость разработки.
Wesha
07.02.2025 13:49как забыли сейчас про Перл, Фортран, Кобол, Руби, ColdFusion
Алё, гараж, что это за новости такие? Мы сейчас на ruby пишем как не в себя!
scarab
07.02.2025 13:49Да есть и кто на перле пишет - у меня друг работает в финтех-компании, недавно они портировали один из банков Top5 с оракла на скрепный постгрес, конвертор при этом был как раз на перле. И на коболе до сих пор кто-то да пишет.
Но в целом это языки уже не на слуху. Хотя мне руби в целом нравился, а RoR вообще предопределил путь развития всех современных веб-фреймворков.
arielf
07.02.2025 13:49Перл, Фортран, Кобол, Руби...
Ну, про них никто не забыл. Фортран и Кобол -- вообще в топе по популярности. И вообще, это специализированные языки, глупо верить, что на них будут писать веб сайты.
arielf
07.02.2025 13:49Например, я не художник, но могу симпатичные картины делать с помощью нейросетей, почти мгновенно.
Нет, не можете.
Я могу создать симпатичный дизайн для лендинга с помощью ИИ, не умея ни рисовать, ни верстать.
Нет, не можете.
Вы слишком хорошего мнения о себе, и ещё больше о ИИ. Но поверьте, чтобы ставить задачу даже живому профессионалу, нужно самому разбираться в этом. Чтобы ставить задачи художнику и дизайнеру, нужно самому выучить базу живописи и дизайна.
Cerberuser
07.02.2025 13:49Может, потому что значение слова "симпатичный" полностью зависит от используемого диалекта русского языка.
Wesha
07.02.2025 13:49в принципе ничего сверхъестественного в госуслугах нет, это довольно простой сервис.
Более того, я как олдскульный разработчик скажу, что тех, кто накропал госуслуги (в их нынешнем виде) надо гнать ссаными тряпками за сто первый километр.
Dr_Faksov
07.02.2025 13:49Когда вы проектируете автомобиль - вам не нужно придумывать и понимать работу каждой мелочи. Например, вам не нужно разбираться в сплавах для создания какой-либо особо прочной детали, достаточно указать требования.
Тут вы глубоко неправы. Вы должны знать граничные условия прочности имеющихся сплавов, к примеру, чтобы не заложить невозможные габариты, к примеру.
MrCina32
07.02.2025 13:49Зная лишь основы HTML, CSS и JS на уровне синтаксиса и базовых алгоритмов, я за два вечера написал на qwen (+дипсик частитчно) сайт канбан-доску без этих ваших коммерческих to-do, doing, done. ламповую пробковую доску для личного пользования, на которую могу кинуть картинку, текст, заметку, стикер, связать веревочками объекты, сгруппировать их в фрейм. думаю еще маркер добавить. данные пока храню в JSON, запускаю на локалхосте.
randomsimplenumber
07.02.2025 13:49Я, зная лишь основы Паскаля, делал когда-то на Delphi веб-броузер и таблицы типа Excel.
GospodinKolhoznik
07.02.2025 13:49Зная лишь популярный в начале нулевых мем с баша я пропатчил KDE2 под FreeBSD.
iskatel-tut
07.02.2025 13:49Мой старый друг Володя, которого уже нет с нами - просто гений, однажды, после троекратного пересчёта сметы для капризной бухгалтерии, наутро пришел с программой, напоминающей Excel (лет за 10 до его рождения), написанной на … Бейсике! И «одной левой» многократно пересчитывал эти грёбаные сметы) Это было в 80-е годы прошлого столетия. «Да, были люди в наше время!»
Kobystan
07.02.2025 13:49До Excel вполне себе были таблицы. SuperCalc был завезен вместе с IBM PC совместимыми компьютерами еще под DOS. Первая SuperCalc это 1981 год. Пишут, что был еще Lotus 1-2-3, но его в моем окружении видели только в журналах и книгах.
Alexsey
07.02.2025 13:49Это все классно, но нет ничего удивительного что LLM вам нарандомила код на типичную tutorial задачу, решений которой в интернете тысячи. Что ей скормили, то она вам с успехом и выдала. Это совсем не показатель того что она адекватно справится с чем-то более сложным на чем ее не обучали.
engine9
07.02.2025 13:49GhatGPT актуальных версий (но не самой новой) не смог нарисовать схему симметричного мультивибратора на двух транзисторов. Просили его вывод делать в виде netlist, он пытается что-то похожее нарисовать, но схемы получаются неработоспособными. Чувствуется, что такой специфической информацией его не учили...
N-Cube
07.02.2025 13:49ChatGPT 4o в платном аккаунте выдает такое, что стоит запостить:
С тестовым сообщением "Here is the schematic diagram of a symmetrical transistor multivibrator circuit using two NPN transistors. Let me know if you need modifications or additional details."
Стоит ли после такого ему уточняющие вопросы задавать?:)
inkelyad
07.02.2025 13:49Добавить в запрос что-то в духе 'zirkel sigil' - и можно демона вызывать. А так - на обложку очень даже ничего.
vaslobas
07.02.2025 13:49Не зная ничего я просто посмотрел 30 секундное видео на ютьюб и сделал туду-лист!
TestNickname
07.02.2025 13:49Теперь осталось попросить квен/дипсик/гпт написать Jenkinsfile...
vasiaplaton
07.02.2025 13:49Сам разработчик, но по долгу работы в стартапе начал разбираться с Jenkins.
Первые часов 5 попыток пасовал и мой вполне естественный интеллект)
Кажется, чтобы ИИ такое смог, он должен иметь совсем другой уровень агентности, и в длииином цикле запускать -> тестировать -> править
То есть, как и с o1, еще больше вычислений необходимо переносить в момент ответа на запрос,
Расширять окно контекста, научить модель еще лучше самостоятельно сжимать старые данные в контексте, с возможностью их обратно развернуть, убрав что-то другое
Так, как собственно это и устроено и у человека - думаем мы в узком контексте, но при этом произвольно «подгружаем» в него гораздо более широкий опыт
4wards1
07.02.2025 13:49И вот как только вы захотите что-то посерьёзнее, чем "канбан на локалхосте с JSON-хранилищем", то быстро обнаружите, что LLM чудесным образом перестаёт справляться с задачей.
Все языковые модели вызывают искреннее восхищение у тех, кто с программированием знаком лишь поверхностно. Новичкам кажется, что раз LLM смогла сделать шаблонный ABC-проект, то она так же легко справится и с созданием полноценного приложения.
Вот только она не справляется. Ни Deepseek, ни OpenAI до сих пор не дошли даже до того уровня, чтобы хотя бы корректно разделить чётко описанную логику по слоям DDD. Я уже не говорю о том, чтобы с нуля написать эту логику и не превратить её в лапшу из непонятно как переплетённых друг с другом классов.
Derevtso
07.02.2025 13:49С одной стороны, полностью согласен, с другой - не до конца.
Я пробовал просить ллмки что-то в духе "а теперь организуй код в виде проекта согласно DDD" (не цитата), и оно, в ряде случаев, на уровне "прототипа", опять же, в целом, справлялось. Не идеально, но декларировало какие папки, какие в них файлы, и так далее.
Разумеется, для "взрослого" проекта оно всё ещё страшный геморрой, но для прототипов и базового их сшивания друг с другом - вообще, на удивление неплохо, и игнорировать это - зарываться головой в песок.
TestNickname
07.02.2025 13:49Луддиты орут о том, что LLM не могут ничего и проигрывают.
Гики орут о том, что LLM могут всё и падают лицом в грязь.
Инженеры знают границы применимости LLM как инструмента и пользуются им, раздуясь появления "экскаватора для знаний"(c) Станислав Лем.
geher
07.02.2025 13:49Проблемы начинаются тогда, когда "экскаватор для знаний" превращается в костыль для калеки, уже неспособного перемещаться без этого костыля
Derevtso
07.02.2025 13:49Гугл, кстати, тоже такой "костыль для калеки". В идеале, человек должен сам всё знать, все источники для всего необходимого лично себе, и легко находить без помощи бездушной машины всё важное, в идеале - в своей памяти, а не в железке.
А залезть на stackoverflow - вовсе тяжелейший грех, это для невежд, нищих духом.
</sarcasm>
geher
07.02.2025 13:49Гугл может быть как полезным инструментом, так и костылем для калеки.
Использование инструмента не грех. Плохо, когда без инструмента человек станочится абсолютно беспомощным
Если кто-то без гугла (нейросети, калькулятора и т.п.) совершенно неспособен ничего сделать (например, поискать в книгах, вывести или вычислить нужное самому), это печально. Да, это может быть менее эффективно (хотя бывает и наоборот). Но при недоступности инструмента (хотя бы и временной) по какой-то причине результат деятельности этого кого-то будет на период недоступности нулевым. А мог быть хоть и меньшим, но вполне реальным.
Derevtso
07.02.2025 13:49Если честно, у меня на это нет веских доказательств, но мне, признаться, кажется, что если человек не умеет работать с информацией, то ему и гугл не поможет. А если умеет, то, даже, привыкнув к нему, худо-бедно, как-то, осилит сделать что нужно и без него.
Это как с "помогут ли конспекты на экзамене по электротехнике".
Так и с нейронками. Подавляющее большинство людей всё ещё не могут выжать из ллмки то, что можно с её помощью сделать даже в своей профессии. А это значит, что и без ллмки у них есть определённые внутренние ограничения.
unreal_undead2
Всё таки есть вечные темы. Умножение матриц до сих пор не теряет актуальности (и до сих пор там приходится опускаться до ассемблера)
MaxLevs
Что в умножении матриц принципиально требует ассемблера? И почему условный с++ для этого не подходит?
randomsimplenumber
Например если хочется применить магию SIMD.
Dooez
Интринсиксы намного удобнее в использовании чем ассемблер. И компилятор генерирует очень хороший код. std::experimental::simd просто пушка, очень жду C++26.
MaxLevs
Хотел лайкнуть, но, к сожалению, не могу. Поэтому отпишусь так.
Согласен с Вами. Особенно, если учесть, что современные компиляторы очень хорошо умеют в оптимизацию. На https://godbolt.org/ это прекрасно можно увидеть.
NNMK
«Искусственный интеллект» — пафосный термин, но интеллекта там нет. То что сейчас называют ИИ, на сегодня, даже нормальный текст скопилировать не может, а тут идёт диалог о программировании с помощью ИИ. Проще код самому написать с "нуля" чем править бред написанный ИИ.
„Чтобы правильно задать вопрос, нужно знать бо́льшую часть ответа.“ — Роберт Шекли «Верный вопрос»
Если я знаю большую часть ответа, то и сам смогу решить задачу. Надеюсь в ближайшем будущем появиться более менее реальный ИИ, а так запасаемся попкорном и смотрим шоу.
DrAlexa
Да, и так будет если не всегда то ещё очень долго
diakin
Ну это если умеешь.
И они ж говорят, что "любой может написать программу в режиме чата с ботом". То есть заказчику нужно "просто сформулировать ТЗ" , какая мелочь )))
okhsunrog
Современные компиляторы прекрасно справляются с SIMD. Советую глянуть, очень увлекательное чтиво: https://matklad.github.io/2023/04/09/can-you-trust-a-compiler-to-optimize-your-code.html
unreal_undead2
Покажите мне компилятор, который эффективно запользует AMX. Почему то серьёзные дяди пишут вот так.
N-Cube
simd сейчас доступны хоть в питоне, с помощью numba.
IUIUIUIUIUIUIUI
Можете показать пример? Как будет с numba выглядеть, например, строковые операции, доступные через сишный интринсик
_mm_cmpestrm?N-Cube
Никогда не интересовался ускорением строковых операций. А вот для работы с терабайтными растрами хоть на лаптопе можете посмотреть мой проект https://github.com/AlexeyPechnikov/pygmtsar Там используются numba с numpy, и распараллеливание и векторизация есть. Аналогичный софт на си (однопоточный, но в консоли утилиты могут быть запущены параллельно на всех ядрах) далеко позади по скорости работы и требует в 10-100 раз больше оперативной памяти.
Wesha
..а потом они удивляются: «а чё оно так тормозит?»
N-Cube
Что тормозит, трололо вы наш? Передача имени файла для открытия и работы с терабайтным растром? И как вы предлагаете ускорить эту передачу указателя интрисиками?:)
khajiit
Кодировки с переменной длинной внесли некоторое разнообразие в скучный
str* + N * m(этот не будет ручаться за точность, ибо последний раз на сях писал лет 12 назад, на специфическом диалекте, но смысл должен быть передан верно)N-Cube
И как вам тут помогут оптимизации, направленные на работы с фиксированным количеством байтов?.. Речь идет о блочных операциях типа шифров или хэшей, а не про обработку символов юникода.
khajiit
Э?
N-Cube
Еще раз - интрисики используют не для обработки кодировок (переменной длины), ваш комментарий бессмысленный в данном контексте.
khajiit
Вы взяли комментарий каджита, перефразировали его не меняя смысла, и заявляете что он бессмысленный? В таком случае, вы опубликовали уже два бессмысленных комментария.
Попробуйте подумать над тем, кто на ком стоял. И, раз уж заговорили от контексте, над тем, кто кому на что отвечал.
N-Cube
Вот обсуждаемый комментарий:
В ответ на мой:
Вы же влезли в разговор со своими идиотскими замечаниями не в тему и утверждаете, что речь шла о вас. Научитесь читать, а еще лучше, и думать.
khajiit
А вы смешной, взять произвольный комментарий, явно не на тот, на который отвечал каджит, и пытаться доебаться до столба.
IUIUIUIUIUIUIUI
Даже в кодировках переменной длины нулевой байт конца строки — это всегда нулевой байт конца строки, и искать его желательно побыстрее, например.
И даже в задачах с кодировками переменной длины, скажем, искать пробелы — обычные, ASCII, вместо произвольных уникодовых пробельных символов — часто более чем достаточно. Или, несмотря на всё буйство красок уникодовой пунктуации, в жсоне (даже содержащем уникодовые строки) кавычки, указывающие ключи, и разные скобочки, указывающие объекты и массивы, всегда ASCII.
Более того, даже в UTF-8 simd оказывается очень полезен, о чём регулярно пишет, скажем, Дэниел Лемир (если это имя о чём-то говорит, конечно).
khajiit
Не говорит, но спасибо за наводку )
Будет что почитать в утренней электричке
IUIUIUIUIUIUIUI
Так это автовекторизация, что совсем не то же самое, что использование SIMD а-ля ассемблер или интринсики. Сравнивать их в таком контексте — это подменять тезис (но, впрочем, вспомнил ваш ник и каждую прошлую дискуссию с вами — для вас это норма).
Onito
скорость
mbait
Для 99% задач линейно алгебры используется та или иная реализация BLAS/LAPACK. Покажите, пожалуйста, где там ассемблер?
SergeyVSorokin
Да, вы правы, всё хуже. Там Fortran
N-Cube
Для многомерных массивов фортран как раз удобнее всех, разве что в питоне numpy библиотека умеет подобное.
coctic
Например,
https://github.com/amd/blis/blob/master/kernels/zen5/3/bli_dgemm_avx512_asm_8x24.c
Это реализация BLAS для AMD. Там почти все ядра написаны на ассемблере, даже не интринсики.
unreal_undead2
В исходниках той или иной реализации BLAS/LAPACK от вендоров железа.
Hardcoin
Вот только этот навык мало кому нужен. Blas умножит матрицы намного эффективнее многих любителей ассемблера. Но и пользоваться им не требуется, keras сделает это за вас.
Конечно, человечеству нужно, что бы хотя бы сотня человек могли это сделать и понимали, что там находится внутри, но остальным этот навык полезен не будет
SergeyVSorokin
Вот как раз неделю назад DeepSsek продемонстрировал, что оптимизировав свое решение под свое железо опустившись на один уровень библиотек ниже можно сделать немного шороху.
Это тоже вполне нормальный способ выживания в новом мире- быть высоко квалифицированным специалистом в узкой сфере. И да, там скорее всего ещё и интересно.
Hardcoin
Только если интеллекта очень много и он в нужном направлении заточен. Тогда конечно, быть крутым технарем в известном на весь мир стартапе интересно.
Для подавляющего большинства это не подходит, не могут же все входить в топ 1% разработчиков, там мест маловато. Автор статьи наверняка про других разработчиков. Хороших, но не тех, кто может сделать лучше всех в мире.
WebPeople
Абсолютно с вами согласен. Даже добавил бы: в Deepseek команда разработчиков - это кванты, а не рядовые разработчики. Т.е. это молодые высококлассные инженеры и математики, победители олимпиад, студенты, аспиранты и ученные из топовых вузов Китая. Это даже не 1% разработчиков, а 0.001%. И эти ребята сотворили свое чудо не за месяц другой, а за годы кропотливой работы.
unreal_undead2
Кто то же должен придти на смену Гото-сану и прочим зубрам ) Да, согласен что это не массовое направление - но если хорошо разобраться, опыт будет востребован.