"Искусственный интеллект - это будущее не только России, это будущее всего человечества. Здесь колоссальные возможности и трудно прогнозируемые сегодня угрозы"
В.В. Путин
Запрос на регуляцию AI-индустрии от Anthropic, отправлен напрямую в Белый дом США:
Anthropic ожидает, что сверхмощные системы искусственного интеллекта уровня «страна гениев в дата-центре» (так и написано) появятся уже к концу 2026 (!) — 2027 годов. В письме в Белый дом компания призывает срочно принять меры, чтобы США сохранили лидерство и защитили критически важные технологии от конкурентов, прежде всего от Китая.
Интересные факты из обращения Anthropic:
• Уже сегодня модель Claude 3.7 Sonnet способна на уровне экспертов поддерживать сложнейшие задачи, включая написание софта, научные исследования и даже аспекты разработки биологического оружия, что подтверждено совместными тестами с институтами безопасности США и Великобритании
• Anthropic предупреждает, что новейшие китайские модели, такие как DeepSeek R1, свободно распространяются онлайн и отвечают даже на явно опасные вопросы, что подчёркивает необходимость ужесточения мер безопасности
• Компания предлагает установить особый экспортный контроль на чипы (например, новейший H200), которые могут помочь Китаю обойти действующие ограничения и догнать американские достижения в области ИИ
• Anthropic подчёркивает, что к 2027 году одна только тренировка одной ИИ-модели будет требовать до 5 гигаватт электроэнергии, что может вынудить компании переносить разработки за границу, если США не увеличат энергомощности
• Компания рекомендует Белому дому внедрять ИИ буквально во все сферы госуправления, где происходит обработка данных (тексты, изображения, аудио и видео), что может существенно повысить эффективность госаппарата
Еще Anthropic запустила собственный экономический индекс (Anthropic Economic Index), чтобы отслеживать, как искусственный интеллект меняет экономику и рынок труда США.
Оригинал письма в Белый дом: https://www.anthropic.com/news/anthropic-s-recommendations-ostp-u-s-ai-action-plan
Комментарии
А как определить правильность составленного Т.З? А как определить правильность восприятия Т.З.?? Один тупо "по теме", а другой "в вариантах" распрашивает/уточняет.. не было? Вас "Claude 3.7" уточнениями ( разумными) будет беспокоить? так что разница гораздо глубже и шире.. кусок кода причёсанным выдать и (к примеру) понять/прописать алгоритм "поведения" объекта и возможности его "реакции" - "дистанции огромного размера"
Слушайте, я разработкой на 7 разных языках программирования занимаюсь больше 25ти лет. И проблем с правильной постановкой ТЗ не испытываю, равно как и с получением должных результатов. Безусловно, LLM далеко не всегда дают то что надо, и в этих случаях требуются дополнительные уточнения. Так извините, и живые кодеры далекооо не всегда отдают в точности то что надо :)
Ну а касаемо Вашего вопроса, извините, как правильно это делать - тянет на отдельную серию лекций, я консультациями не занимаюсь, но буду очень рад если сможете со временем разобраться самостоятельно)
это классика конечно, "жрите как есть" )))
Я не указываю кому как жить, лишь поделился своим опытом по тому, как мы задействовали сей инструмент. Каких-то полгода назад я этого всего чурался (не для кодинга использовали), ибо тогда ещё кодило убого. А теперь более чем.
Кто ей скажет, что нужно переписать с нуля заданный участок? ))
Ну здрасьте приехали) разработчик и говорит (то есть, в данном случае я). Это не замена программисту, а помощник программисту. Просто экономит уйму времени.
Можно такое сравнение сделать: если лет 50 назад нужно было идти в библиотеку чтобы почерпнуть новые знания (трата нескольких часов, и более) то теперь можно загуглить (несколько минут). Аналогичная разница и тут.
SAP ?
Если всё так, как вы говорите, то вам вообще ничего делать не надо.
Ваш проект уже лет 10 как целиком лежит в виде студенческой курсовой на гитхабе ))
Чтобы понять, как оно работает, что делает и почему именно так, уходит вагон времени.
При этом устаешь раза в 4 больше, чем при работе в обычном режиме....
И всё это при условии, что этот код писал ты сам 3 недели назад и 50% его составляют комментарии, причем не стандартные доки, а по-существу...
Слушайте, это ведь не теоретизация а реальная практика, мой личный опыт (речь о конкретном клоде 3.7 и работе в нем с питоном и с JS - другие языки он может тащить слабее). Никаких проблем с пониманием у меня не возникало. То же написание ТЗ как обычному программисту.
Условно говоря, в большинстве случаев я и так знаю, как писать некий новый модуль, но у меня на это уйдёт два-три часа, а он делает за несколько минут. Вот и вся суть.
И да, конечно, многие вещи есть на гитхабе. Но далеко не все, и Вы прекрасно это знаете, особенно когда стоит вопрос неких узких кастомизированных решений.
Он не говорит чё за проект. 7 языков программирования 25 лет, мы тут все если чё такие
Вот и замечательно :)
Есть и постарше товарищи. С 1971 Года. Еще в средней школе было программирование.
Т.е. когда состарятся специалисты прошедшие все ступеньки програмирования и поэтому понимающие, как ставить задачу другим, все и кончится?
Видимо Вы не до конца понимаете, о чём речь. Здесь в любом случае необходима квалификация программиста. Т.е. они никуда не исчезнут и учиться программированию в любом случае надо. Никто не говорит что данная профессия исчезнет.
Единственная разница, что теперь можно больше сосредоточиться на более стратегических задачах и меньше тратить время на тупую рутину.
Это как появление ООП: больше не нужно было писать на машинном, ассемблерном коде и стало возможно писать код структурно, на более высоком уровне.
Условно говоря, примерно так и тут.
Ну а вы-то поняли о чем я? Я уже лет двадцать назад столкнулся впервые с отсутствием навыка у молодежи счета в уме. Мол калькулятор посчитает, а вот ни фига, они не видят ошибки калькулятора, как мы.
Сам факт отупения в определенных областях и паттернах поведения, безусловно, есть. И будет лишь усиливаться в дальнейшем. Однако это не повод переходить с куркулятора на деревянные счёты, и ходить пешком вместо того, чтобы пользоваться метро и автобусами.
А вот не уверен, я так в юности решил пешком походить и очень не жалею, а то ездящим в машине начал чувствовать себя, как в аквариуме. Конечно можно надеяться на совершенствование системы обучения и воспитания, однако изобретение антикитерского механизма совпадает с гражданскими войнами в Риме, после которых уже никогда римские доблести уже никогда не достигали прежней высоты.
Не переживайте, у нас всегда есть шансы вернуться в каменный век))
Отупление (в смысле тренировки мозга) началось с появления дешевой бумаги и книгопечатания.
Да и Бог с ним)
И ещё постановщик сам должен работать тестировщиком.
Не без этого. И это равно как при постановке задачи LLM, так и человеку.
Старые еврейские сказки напомнило
Ну и финал
Один ИИ заменят одного разработчика или двух? Или половину? Нужно повышение производительности, а не замена шила на мыло.
возможно частично заместит индийских кодеров
По моему опыту увеличивает производительность примерно на порядок.
Для начала просто повысит производительность. Разработчик с ИИ будет работать за троих или за десятерых. Уже это кардинально изменит рынок труда.
Вопрос поставлен некорректно. Он не столько заменяет, сколько помогает и здорово экономит время.
Их Claude 3.7 действительно мощная вещь, пользуем в кодинге, прям на 2 головы выше всех аналогов что пробовали. В нашем новом проекте уже 80% кода написано этой LLM, работает как часики, что надо переписывает с ноля, что надо оптимизирует на порядки и т.п.
Сэкономили сотни человекочасов буквально за 3 недели.
Но... надо уметь с этим обращаться грамотно
вы забыли тут тоже про то что у вас 80 процентов проекта написано LLM упомянуть
Защитите нас, а то мы неконкурентны!!!111
Я подозреваю, что современный ИИ действительно может эффективно "осваивать гранты", генерировать всю потребную документацию, убеждать окружающих в том, что он делает что-то полезно. И иметь отличный индекс цитирования. Особенно, если таких ИИ будет много.
Заодно - генерировать тонну говнокода, который выглядит очень симпатично и похож на настоящий, даже компилируется, запускается и "что-то" делает.
Ну а про химическое оружие - разумеется, ИИ проиндексировал "поваренную книгу анархиста".
всё то у них "продумано"
одного только не учтено - всё искусственное создаёт человек
а человеку, как утверждает классик, свойственно ошибаться
Иприт изобретёт? Ну а чо, химию теперь за валдай загнали, спецы скоро окончательно в тираж выходят, вдруг кто то старые книги скопировал и в сеть выложил, а ИИ нашёл...
Там про наркоту из бананов. Про иприт на VK.
Как только ИИ сможет заменить в разработке человека, он сам об этом скажет. И письмо в белый дом направит.
UML. Вам случалось сталкиваться с этим термином? Лет двадцать назад был очень популярен. Опишите задачу в терминах языка, и компилятор напишет по этому описанию программу без участия программиста. Правильная постановка вопроса - сто процентов ответа на вопрос.
Любопытно, что этому языку почему-то не обучают на бизнес-курсах. А ведь, казалось бы, верное средство избавиться от программистов. Но теперь-то другое дело, ИИ сам разберётся, чего хочет заказчик, верно? А если поймёт не так, то есть интуитивно понятный интерфейс, посредством которого железному болвану можно с лёгкостью объяснить, где и в чём он неправ. Ведь болван сможет объяснить заказчику на пальцах, почему он выбрал именно этот вариант, а не другой - и заказчику не составит труда указать болвану вариант правильный. Никаких сложностей, всё очевидно.
Ведь так?
Так UML еще и написать надо и после первых 10 вариантов и согласовании сроков окажется, что необходим неожиданно еще функционал, который меняет всю архитектуру и увеличивает объем работ раза в 3.
Тут проблема чуточку в другом. UML сперва надо выучить. И тут внезапно оказывается, что понимание структуры задачи и перекладывание её на шаблоны имеет массу нюансов. Нюансов очевидных и понятных. Но не только лишь всем. И язык построения моделей становится уделом специалистов. Которые, сцуко - программисты и разработчики.
Я ещё более гадкую вещь расскажу. БОльшая часть языков программирования и разного рода интерактивных оболочек вроде командного языка MS-DOS и разного рода shell-ов - их написали с расчётом на использование силами обычных пользователей-непрофессионалов. Точнее, профессионалов в своей области - не в программировании. Тот же SQL - да, это вырезка из английского языка, на котором делаются запросы к СУБД. Человеком делаются, не через драйвер. Бейсик - он для обычных людей, не для программистов. Кобол - он для бизнесменов.
C++ Builder - он тоже был сделан для пользователй, не для программистов. Визуальный конструктор, в котором программирование не требуется. Можно - но не требуется, там достаточно выбрать те или иные готовые элементы, и всё получится. Честно-честно.
А теперь появились всякие разные ЧАТ-ГПТ. Которые вообще не требуют квалификации от пользователя, всё делают сами в ответ на правильно сформулированный запрос. Вы же все видели - делает доклады, создаёт картины. По щелчку пальцев. Или двум щелчкам. Или трём. Ну десять раз щёлкнул - тогда уж точно сделает ровно то, что нужно. Точно-точно. Есть, правда, нюансы...
Мне интересно, появление курсов по обучению специальности "Работа с ИИ" - они по-разному называются, но не суть - это обо что? Неужто и здесь способностей обычного пользователя недостаточно для понимания и оценки объёма нюансов?
На С для микроконтроллеров влетел в то, что тройной цикл с минимизацией среднеквадратического отклонения с опцией оптимизации О2 компилятор просто выкинул. Только опция О0 помогла - просто циклы начали работать. Потратил пару дней. И теперь
людиагенты ИИ говорят о том, что программисты не нужны?)))Вы скорее всего накосячили, если потребовалось ставить O0. Классический вариант, когда такое случается - переменная изменяется в прерывании, а используется в основной программе. Если не поставить volatile такой переменной, то компилятор сможет корректно оптимизировать код.
Как я понял, малые дельты порядка 1e-4 были приняты как константы, сравнение разниц исключено, что сделало код бессмысленным.
ЗЫ На персоналке код пошел сразу. Но там я научен - оптимизация отключена сразу))). Где-то тоже несколько дней лет 20 назад потратил, чтобы найти, что вместо цикла i++ оптимизатором поставлен цикл с i--. Кстати, тоже были составные циклы.
ЗЫ2 Прерываниями занимаюь постоянно, но описанной Вами проблемы не встречал, от слова совсем))) Это в какой системе? Век живи, век учись)))
А можно ссылку, про пользователя? Вот про конструктор - да, было (но там и был удобный конструктор, сокращающий огромную кучу рутины), но вот, что любой Вася Пупкин, не умеющий программировать, может взять и на коленке слепить приличный софт - не помню такого.
У меня книжка есть, большая и толстая ;) "С++ Builder", 2000-й год, Архангельский А.Я.
Такой внушительный мануал, где описание собственно С++ начинается на странице 651. А до того - описание работы с визуальным конструктором, где код - малюсенькими фрагментами.
А Вам не приходилось переписывать разного рода поделия, слепленные на коленке в дельфях? Или, по-Вашему, Паскаль настолько проще С++?
Паскаль у них был отлажен лучше плюсов, по крайней мере, не было ICE, висящих годами, с которыми никто ничего не делал. Я сам на несколько натыкался, и обнаруживал, что баг открыт уже лет 5 назад. Приходилось плясать с бубном, меняя код, чтобы этот ICE не срабатывал.
Но мы сейчас ведь о другом, о маркетинговой подаче инструмента. Она, конечно, сильно раздувает достоинства и молчит о недостатках, но сами инструменты (что старые RAD, что новомодные LLM) довольно хороши в том, что избавляют от шаблонной-рутинной-тупой работы, не требующей много мозгов, но требующей много времени.
Просто... ну, не знаю - уж больно пользовательски ориентированный инструмент. При том, что база взята ну совсем не бейсиковская. Сам по себе плюс-плюс - это же С, но ещё с колокольчиками-бубенчиками. А из него попытались сделать нечто юзерфрендли. И таки вышло, но... всё равно это инструмент программиста, который обладает пониманием среды, в которой работает.
Т.е. идея была создать такую среду быстрой разработки, которая не имела бы ограничений - как в случае вижуал бейсика или даже Дельфи. А RAD-концепция первоначально заявлялась как программирование без программирования. Т.е. достаточно институтского (в наших терминах) уровня знания какого-нибудь языка программирования, семестра на три - это никак на уровень программиста не тянет. И он разрабатывал бы работающие приложения на С++. Нормально?
А потом традиционно вылезли нюансы.
Нет там ничего пользовательски-ориентированного. Просто очень сильно упрощена рутина, неприятная, но не требующая большого ума. Формочки, контрольчики, подключение к БД, простенькие таблички и запросы (упс, запросы это уже писать SQL надо) - это все делается и настраивается легко и непринужденно (пока объем не превысит некоторый порог), но вот всю логику придется все равно писать в коде.
А база, изначально - это делфи, в билдере почти все оттуда, из-за чего нельзя пользоваться некоторыми возможностями языка. И билдер у них всегда был вторичен, сперва пилили делфи, потом прикручивали нововведения к билдеру.
Таких концепций 100500 было. И, что интересно, в своих узких областях это больмене работает (LabVIEW появился вообще в 86 году, и живет до сих пор), а вот универсального решения никто не тянет в виду сложности задачи.
Но маркетологи могут с этим поспорить .
Ну, будучи - нет, не программистом, звание высокое больно - сервисником, касался бильдера только слегка, как раз четверть века назад. Но мне он тогда приглянулся. Я в те годы с чем только не работал, так что не показатель - но всё же.
С другой стороны, для интерфеса с БД какой я им не пользовался, так что х.з. как у них было организовано. Как у всех, через рекордсет?
К сожалению, UML всего лишь язык, способ оформления, пусть даже и хороший.
Для решения требуется формализовать задачу: ввести термины, правила, зависимости. Принять допущения, ограничить предметную область. Все это легко делается только для совсем простых задач (которые, обычно, на дипломах защищают). Реальные задачи формализовать не только намного сложнее, они еще и усложняются по мере внедрения. Надеяться на ИИ тут, конечно, можно (кто ж запретит-то), вот только практического результата добиться не получается даже для сравнительно простых задач, чтобы там не обещали. Да и обещания тут исходят от людей, которые просто не представляют, что такое поставить и формализовать задачу (что-то где-то слышали, но реально не занимались).
Я как бы и привёл пример - который, между прочим, даёт гораздо более надёжные и отслеживаемые реализации. И поддаётся внедрению в промышленных масштабах, при наличии квалифицированных кадров. Каковые кадры вполне возможно готовить. Но не взлетел - по крайней мере не настолько, чтобы говорить о кардинальных переменах.
Нынешняя итерация ИИ отличается повышенной опасностью, создавая иллюзию средства для решения проблем. Так то проблемы она решает, но надо понимать область применения. А с этим получается неоднозначно. Даже наличие средства анализа принимаемых ИИ решений требует специалистов для понимания получаемых данных. Анекдот про "Петька, приборы! - Шестнадцать! - А что шестнадцать?!! - А что приборы?" и прежде был невесёлым, а здесь и вовсе приобретает мрачный вид.
Особенно, когда рулят манагеры, а не технари.
Не поддается внедрению, к сожалению. Одно дело, создать язык описания, другое дело, выработать принципы формализации. Разница как между изучить текстовый редактор и научиться писать книги. Вообще, теория описывающая процесс формализации существует и относится к разделу теоретическая информатика, но сама теория настолько сложна и скучна, что ей мало кто занимается и нигде ее всерьез не преподают. В принципе, заниматься формализацией можно и без серьезной теоретической подготовки (что обычно и происходит). И самое главное препятствие для серьезного изучения - достаточно большие (объемные) формализации все равно не получается успешно (надежно и без ошибок) закодировать, поэтому они умирают на стадии "благих намерений".
Страницы