"Даже если AI будет сверхразумом, существуют фундаментальные ограничения! Он не сможет творить магию!"

Ты берёшь в руки магический прямоугольник, чтобы поговорить с другим человеком через всю планету, и видишь при этом его изображение... ещё 200 лет назад люди сочли бы это буквальной магией.

Единственное предсказание, в котором мы можем быть уверены: когда AI станет в 1000 раз умнее нас, он будет достаточно умён, чтобы перехитрить нас.

Так что да, неорганические существа будут делать вещи, которые покажутся нам волшебством -- точно так же, как люди делают вещи, которые кажутся волшебством обезьянам.

По оценкам Metaculus (платформа прогнозирования научно-технических достижений), сильный ИИ (AGI) появится в течение 4-9 лет, и вообще, очень много ключевых событий в области AI случится в текущем десятилетии.

А ещё в прошлом году большинство экспертов считали, что AGI появится не ранее, чем через 20+ лет. Временные рамки стремительно сокращаются.

+ Ещё немного прогнозов от Metaculus (платформа прогнозирования научно-технических достижений)

- Когда выйдет GPT-5? Декабрь 2024 г.

- Насколько вероятна "зима AI" (заморозка всех исследований) к 2025-му году? 4%

- Будет ли первый AGI основан на глубоком обучении? 90%

- Будет ли один из первых AGI "сознательно" претендовать на наличие сознания? 70%

- Когда мы создадим "слабый AGI", сколько времени пройдет до появления сверхразумного AI? 9 месяцев

- Когда AI пройдёт IQ-тест MENSA (в мире таковых около 150 тыс. человек)? Июнь 2025 г.
Попробуйте кстати пройти, а вдруг вы действительно считанный гений?

- Создадим ли мы AI человеческого уровня к 2040-му? 92%

- Когда AI сможет писать программы для самоулучшения? 2026-й

- Будет ли GPT-5 обладать способностью автономной репликации? 22%

- Убьёт ли AI онлайн-покер? 12% (хоть это хорошо :)

P.S. Из этого всего, кстати, следует важный нюанс: гонка технологий AI между странами -- это полная противоположность гонке вооружений. При гонке вооружений одна из сторон выигрывает, а при создании AGI выигравших не будет: мир сразу захватят неорганические существа с невероятным интеллектом. Пока же топовые научные команды, конкурируя, спешат изо всех сил поскорее создать Разрушителя Миров...

На днях уважаемый Максут Шадаев сообщил, что ширится программа массового обучения программированию, и само по себе это безусловно хорошо:

- в прошлом году на курс по изучению современных языков программирования были зачислены 130 тыс. школьников с 8 по 11 класс. В этом году рассчитываем зачислить еще 140 тыс. человек...
-- количество ежегодно открываемых бюджетных мест в вузах на ИТ-специальности -- 117 тыс. Всего сейчас обучается почти 350 тыс. будущих ИТ-разработчиков и инженеров...
- на цифровые кафедры в вузах было зачислено 112 тыс. студентов...
- за время работы Школы-21 обучение прошли 25 тыс. человек, сейчас учатся еще 5 тыс...

Всего в российском ИТ работает 740 тыс. человек, и нехватка составляет 500-700 тыс. человек.

Скилл программирования по жизни весьма полезный в любом случае.

Но есть нюанс.

"На выходе мы получаем разработчиков высокого класса, которые без проблем трудоустраиваются в ведущие ИТ-компании..."

Вам в это верится? Моё оценочное суждение такое, что проблема российского ИТ совсем не в том, что не хватает 700 тыс. разработчиков, и надо готовить на всевозможных курсах всё больше и больше человек. Проблема в том, что ребят, потенциально готовых для работы в ИТ, полным полно (и число их быстро растёт), однако устроиться на первую работу джуниором без опыта сегодня крайне сложно. Причина ровно в том, что 98% компаний сейчас боятся инвестировать в развитие, в набор малоопытных ребят, в дальнейший рост которых надо вкладываться. И через сколько лет у компаний этот страх роста пройдёт, никому не ведомо.

Поэтому готовить новые и новые толпы кандидатов с прицелом "на работу в джуниоры", из которых в итоге работу находит один из ста (если не из тысячи), ну такое себе.

Сэм Альтман подался в инфоцыганы, в тему успешного успеха? :)

13(!) правил how-to-be-successful

Самая гениальная рекомендация (серьёзно), которая только была у Альтмана -- это легендарная статья "Внимание -- это всё, что вам нужно" 2017-го года, про огромный потенциал архитектуры трансформеров. Но по жизни, буквально, любому программисту важнее всего просто сам этот заголовок как лозунг.

Темплейты C++ статически утинно типизированы )))

Попробуйте помучить разные GPT в плане соответствующих примеров (и чтобы никаких тайпкастов), они совсем слабенько справляются, после неоднократных подсказок и уточнений. С таким пониманием программирования до захвата мира AI пока далеко :)

Хорошая человеческая заметка.

Нередко ребята, ищущие работу миддлом, жалуются, что не получают отзывов на резюме вообще, хотя опыт работы 2-3 года у них есть (или был выдуман :).

Лайфхак: я иногда тестирую адекватность спроса в ИТ, и публикую выдуманные резюме. Пока один из лучших результатов получается, когда я в дополнение к стандартному списку скиллов пишу, что самостоятельно с нуля написал клиент-серверный проект на 30,000 строк кода на C# с использованием MS SQL Server.
(Так то я писал и на 300 тыс. строк, но когда ставишь всего 2-3 года опыта, надо соблюдать адекватность :)

За полдня получил пять офферов. причём один был такой добрый и вкусный, что мне прям жалко было отказываться ))))

Главное тут -- чтобы вы действительно сделали проект подобного объёма, и в идеале, развивали его на гитхабе, где виден весь процесс разработки, и могли бы его быстро из докера стартануть. Очень полезно при этом понаступать на грабли, на собственной шкурке осознать ряд анти-паттернов, а потом про них рассказать.

Техдира/тимлида впечатлит именно ваш не очень удачный опыт (кто говорит, что всё было хорошо, врут 98%) + объём кода: раз вы более-менее успешно нафигачили десятки тысяч строк, значит точно сможете нормально долгосрочно трудиться.
Но 3-5 тысяч строк будет маловато.

Есть и другой лайфхак: для курсантов я выложил материал "9 крутых и необычных сайд-проектов", после которых рекрутеры будут ползать за вами на коленочках :) Они по объёму меньше, но зато впечатлительны в плане сложности. Например, написать свою среду запуска контейнера (container runtime).

Лучше всего, конечно, сделать и то, и то.

Если для того, чтобы проверить, работает ли программа правильно, нужно приложить множество усилий, то, скорее всего, она работает неправильно.

Как говорит Тони Хоар, можно написать настолько простой код, что в нём явно отсутствуют ошибки -- или настолько сложный, что в нём вообще нету очевидных ошибок (но есть множество неочевидных и ждущих своего звёздного часа).

При работе с хорошим кодом думать почти не нужно.

Сервер -- это бесконечный цикл, в котором вертятся воркеры -- по одному на каждый входящий запрос.

Традиционная разработка бэкенда по сути своей ориентирована на серверы: мы мыслим в парадигме серверов.

Однако по мере распространения безсерверных систем нам необходимо учиться мыслить в терминах воркеров.

Мой курс "Ясная архитектура" в помощь.

В Java реализована динамическая диспетчеризация, которая "сама" решает непосредственно во время выполнения программы, какую реализацию метода запускать. Узнать это с помощью статической типизации невозможно.

В чистых функциональных языках вместо интерфейсов предлагается концепция тайп-классов, рассказывал:
Тайп-классы и алгебраические структуры
Тайп-классы

Своим названием однако эта концепция только запутывает. Просто знайте, что тайп-класс имеет очень мало общего с "типом" или "классом".

Если интерфейс в языках ООП говорит "этот класс может выполнить этот метод", то тайп-класс говорит, что "существует нечто, что может выполнить этот метод на этом классе" (где понятие класса совсем абстрактно). Интерфейс обычно "прошивается" в коде в заголовке класса, а экземпляр тайп-класса существует как отдельная "физическая" сущность -- реализация метода не привязывается к "классу рантайма". Компилятор вытаскивает нужный экземпляр тайп-класса, основываясь на эксплицитном типе в исходном коде, а не на конкретном типе во время выполнения. Этот подход конечно не так гибок, как динамическая диспетчеризация в ООП, но имеет то безусловное преимущество, что просто посмотрев на код, мы можем точно сказать, какая реализация метода будет выполнена.

Да, но как тогда мы можем рассуждать о коде в Java на третьем логическом уровне, если не знаем точно, какой код будет выполняться? На помощь приходит принцип подстановки Лисков (точнее, его идеология). Подробнее эту тему разбираю для курсантов в материале "LSP с т.зр. ФП".

Вкратце, абстракция LSP гласит: разработчик! не удивляй своих коллег! )))

То странное чувство, когда увидел, что питон -- лидер функционального программирования... действительно, почему бы и нет.
(а хаскель вообще не видать на горизонте)

Кстати да

В 90-е знакомый ставил банкам "опердень", который переставал работать через 90 дней, если ему не заплатили. Один банк не заплатил, а на 91-й день к нему приехали суровые пацаны с разбитыми кулаками, и жёстко потребовали, чтобы опердень у них быстро заработал. На его возгласы что не заплатили, они сказали, что это твои проблемы, решай с бухгалтерией.
Пришлось запускать...

Через несколько месяцев этот банк к нему уже вежливо обратился с просьбой обновить на новую версию, сделать доработки, ну он запросил двойную цену, и те согласились.

А потом на этот рынок пришли взрослые интеграторы-автоматизаторы, и это уже совсем другая история (разборки были на порядок круче)...

90% правильного программирования -- это молчаливое думание.

LLMs эффективно убивают своих оппонентов, мастерски обманывают других, создают тщательно продуманное алиби и перекладывают вину на других. Речь про игру Hoodwinked, напоминающую Мафию, статья университета Южной Калифорнии. Это в тему странных споров, сможет ли грядущий AI, умнее нас в 100 раз, обманывать человечков ))) уже.

Вы можете поиграть в Hoodwinked по ссылочке из этой статьи.
Напомню, что интеллект AI в конкретных задачах потрясающий: в Go (значительно сложнее шахмат) AI научилось играть на топовом уровне за три дня, просто играя миллионы партий само с собой. И, пока по слухам, мета обещает выложить грядущую GPT-5 (лламу-4 ?), которую можно крутить локально, в опенсорс (я только за :).

Shane Legg (Google DeepMind's Chief AGI Scientist) даёт 30% вероятности, что AGI (сильный ИИ) появится в ближайшие 3 года. И даже главный AGI-скептик Gary Marcus даёт 35% шанса, что оный явится в ближайшие 13 лет.

Однако пока автоматизация разработки ПО с помощью AI -- это в основном производство ещё более дерьмового и практически не сопровождаемого кода :) Никаким переосмыслением и демократизацией производства программного обеспечения тут совсем не пахнет.

Маск на днях заявил, что новая версия Tesla V12 содержит единичные тысячи строк кода по сравнению с предыдущей версией в 300 тыс. строк кода — за счёт активного использования AI.

"drop >300k lines of C++ control code by ~2 orders of magnitude"

Что-то крайне подозрительно.

Лет 10 назад Toyota была оштрафована на $1,2 миллиарда за баг в софте автомобилей, насчитывавшего тогда около миллиона строк кода. Получилось около $1200 за 1 строку кода -- дороже, чем стоило ПО тех времён в самых дорогих американских космических проектах.

К сожалению, в мэйнстриме сегодня вполне достаточно писать код, который "просто работает", и получать за это 300k/s.

В этом году в Вышку на "программную инженерию" конкурс был 305 баллов из 300. Напомню в этой связи, с трека "Элитный программист", что

"Люди поступают в университет не для того, чтобы получить какие-то новые навыки. Практически всё, чему учат в университете, можно получить бесплатно в интернете, или на гораздо более дешёвых и компактных в сравнении с университетом курсах профессиональной переподготовки, как мои. Люди идут в университет прежде всего для того, чтобы погрузиться в определённую социальную среду. В элитных университетах существуют закрытые университетские братства, состоящие в которых потом всю жизнь помогают друг другу. И именно эта особенность делает университетское образование таким ценным."

Как это всё правильно использовать в карьере, рассматриваем на ЭП подробно.

Случайно наткнулся на "I've been trying to code up the Eilenberg-Moore category for a monad in Haskell."

Я не математик, очень слабо к сожалению в этом разбираюсь, но вот подумал, что если мы сделаем DSL по заветам метапрограммиста Алана Кэя, в котором все типы будут моноидами, то для всех них соответственно будут определены моноидные операции. И тогда мы сможем писать код, как если бы мы находились в категории моноидов Эйленберга-Мура (наверное).

"Eilenberg–Moore Monoids and Backtracking Monad Transformers"

Весь код, который я пишу, работает за O(1).

Жить надо так, чтобы вы с гордостью могли сказать, что за последние 10 лет программирования в вашем коде ни разу не возникла ошибка.

"Надо помнить и о том, что на сегодняшний день нам пока не удалось нащупать "потолок" в какой-либо области человеческой деятельности. С развитием обучающих методик появляются все новые рекорды, и люди из самых разных сфер все более совершенствуются в своем деле. И пока что незаметно никаких признаков того, что это когда-нибудь прекратится. С каждым новым поколением горизонт человеческого потенциала отодвигается все дальше."
"Максимум. Как достичь личного совершенства с помощью современных научных открытий"
-- Андерс Эрикссон

Я знаю пару ребят, совершенно фантастических программистов, а по жизни они реально сильные PhD в математике, и им пока 35 лет!

Увы, в России их больше нету.

От девушки, занимающейся на одном из начальных курсов (занятие по знакомству с системами отслеживания тикетов):

"Ранее на работе я сталкивалась уже с джирой, в принципе, идея ясна. Разве что скажу честно, что обычно там не задачи на 2-3 часа, а такие что делаются по несколько дней. Наверное тогда лучше дробить их, но обычно сотрудникам не охота расписывать каждое действие."

Именно так: если вы сеньор или тимлид, и ваши подчинённые всеми фибрами души сопротивляются дроблению их тикетов по точности до 2 часов (идеальная точность -- до получаса), значит, дела с успешной сдачей проектов в срок и в бюджет в вашей конторе весьма печальны :)

Вполне типична ситуация, когда разработчик мычит "ннну... дня три потребуется на эту фичу...". В таких случаях просите/требуйте декомпозировать тикет на более простые.
Подзадача на 4 часа максимум -- это предел в любой ситуации.

Некоторые задачи действительно трудно сперва оценить, ну значит пусть человек оформляет тикет на 0,5-1 час для предварительного изучения темы, насколько будет трудоёмко.

При этом совершенно ничего страшного, если люди будут ошибаться в оценках. Накосячить в 2-3 раза дольше вполне нормально, и ругать за это ни в коем случае нельзя. Просто фиксируйте себе буферный коэффициент по каждому из разработчиков.

Но есть нюанс...