Я никогда не был поклонником правил.

Ну... не тех правил, которым другие люди говорят нам следовать беспрекословно.

Такие правила меня раздражают...

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

Особенно когда речь идёт о том, чтобы стать лучшим программистом... или вообще стать лучшим в чём-либо.

Это не значит, что вы никогда не должны нарушать свои собственные правила...

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

За последние несколько лет я открыл несколько правил, выработанных за почти 45 лет программирования, создания бесчисленных программных продуктов... и оказания специализированных консультационных услуг серьёзным компаниям и стартапам, но главное -- благодаря регулярному изучению научных конференций по программированию и computer science. Главное, что в этих правилах собраны очень сильные, официально рецензируемые рекомендации с подобных конференций, чем кроме меня больше никто в России не занимается.

Послушайте, есть множество людей, которые стали отличными разработчиками и заработали много денег...

Но они редко тратят время на деконструкцию того, что они узнали, и создание правил о своих знаниях...

И КАК они достигли огромных прорывов.

Я нашёл время, чтобы сделать это.

Я изложил эти правила в виде простого в исполнении процесса -- практического тренинга по проектированию и программной инженерии.

Он называется Higher Work.

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

Вот и всё.

Я всегда подчёркиваю важность изучения глубоких концепций, а не поверхностных примеров. Например, сейчас готовлю материал для СильныхИдей, с помощью которого хочу научить программистов отключаться от мусорных каталогов со схемами рефакторинга и понять, что большинство знакомых им рефакторингов вытекают из единичных основных алгебраических законов, таких как тождество X^2*A = X^A * X^A, которое легко выводится из аксиом школьной алгебры, и соответствует замене функции, принимающей булевы аргументы, двумя функциями. Все приёмы рефакторинга, которые я знаю, легко выводятся буквально одношаговыми сокращениями конструкций языка программирования через простейшие алгебраические законы.

Есть например такое преобразование, которое заменяет функции высшего порядка эквивалентными функциями первого порядка. С его помощью в частности, было показано соответствие между многими парадигмами семантики языков программирования. Я понял (с помощью сингапурского профессора :) вездесущность этого преобразования как техники рефакторинга: оно неявно используется в самых разных задачах -- от придания рекурсивной функции итеративности до создания распределённой программы. И тем не менее, в литературе по рефакторингу об этом совершенно нигде не упоминается.

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

P.S. За мои почти 45 лет работы в ИТ могу сказать определённо только одно: есть очень мало вещей в программировании, которые однозначно и безоговорочно можно считать хорошей идеей. Почти всегда всё зависит от ситуации и контекста использования. Поэтому с особой тщательностью отбираю такие золотые крупицы ценных знаний в СильныеИдеи для курсантов, сейчас там около 50 материалов + формат Higher Work (практика в этом всём).

Про ИТ-стартапы -- в какой области создавать?

Мета-идею вам расскажет любой инфоцыган: посмотрите, где есть спрос, и идите туда. Более инженерный подход таков:

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

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

-- Подобные ресурсы будут реально ценны для многих людей.

Из моего недавнего опыта, такая темка как управление версиями REST API. Как вы разрабатываете свои схемы данных, стараясь обеспечить как расширение API, так и сохранение обратной совместимости. Однако в ряде ситуаций отказ от обратной совместимости тоже будет хорошей идеей + надо также учитывать разницу между управлением версиями внутренних и клиентских API и т. д. и т. п.

В мире сегодня только официально насчитывается около 70 тысяч SaaS-компаний (ну и REST API как таковой вообще в любом проекте наверное сегодня имеется). Допустим, что из них как минимум 10 тысяч организаций явно интересуются этой проблемой. Сколько таких в России? Многие сотни точно, особенно с учётом вала проектов по импортозамещению.

Пусть на создание курса/учебника по версионному управлению REST API потребуется даже год работы, а в результате его применения средняя компания сэкономит в год 500 человеко-часов программистов на избавлении от кривых и несогласованных апишек. Если бы я был глобальным министром ИТ, пытающимся улучшить отрасль в целом, имело бы смысл заплатить одному человеку миллион рублей за написание учебника или курса по управлению версиями API. Это тема, с которой сталкивается далеко не каждый разработчик, но ею занимаются сотни или даже тысячи компаний, и хотя тема довольно широкая, она достаточно специфична, чтобы можно было объединить опыт и идеи в одном ресурсе.

И таких точечно-актуальных тем самого разного масштаба полным полно, ну например навскидку: миграции баз данных, корпоративные поисковые системы, рекомендательные системы, системы управления рабочими задачами, преобразование данных между разными форматами, тэгирование, как использовать конкретные популярные API (Github или OpenAI) и т. д.

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

Не перестаю удивляться глубине падения мэйнстрима :)

Ну например, вы создаёте очередной поисковик котиков, для чего берёте готовое key-value хранилище, в котором храните индексы в вашем поисковике (b-tree).

Да, но ваше готовое key-value хранилище внутри себя, в файле файловой системы на своём внутреннем уровне тоже хранит свои индексы (b-tree).

Да, но ваша файловая система на своём уровне тоже хранит свои индексы файловых дескрипторов (b-tree)...

Ну и зачем нужны эти три эквивалентных по сути уровня?

Если хотите получить выигрыш в производительности в 1000 раз, пишите б-три на сишечке для bare metal, ну как минимум как можно более нативно.

Очень хорошо погуглить например "erlang bare metal"

Простой пример логических уровней думания о коде. Есть общеизвестные правила DRY и SoC, которые плохо обученные программисты (сокр. попы) реализуют примерно так: завидя схожие куски кода, бездумно бросаются рефакторить их в одну функцию с настроечными параметрами (DRY), а завидя один здоровый монолитный кус кода, бездумно бросаются делить его на несколько автономных, изолированных, иногда даже чистых функций (SoC).

Подождите, это совсем неверный подход, сплошная робертмартинфаулерщина.

Правильно так: если две (возможно, вообще не похожих) части кода реализуют одну бизнес-концепцию, то их надо объединить (возможно, не в одну функцию, но как минимум в одну синтаксическую или семантическую единицу -- в один файл, в один класс), а если часть кода реализует две или более бизнес-концепций, то её надо соответственно разделить.

Принцип SRP должен превалировать именно в смысле бизнес-логики.

Про хипстерский полиморфизм в не-очень-хипстерских языках.

"Обычный" полиморфизм (как в дженериках Java) позволяет писать функции над конкретными контейнерами с произвольным типом данных, например: написать функцию над List<X> для любого типа X. Но чтобы писать функции над любым контейнером -- например, одну функцию, которая работает и со списками, и с деревьями -- нужно уметь абстрагировать и List<X>, и Tree<X>, в F<X>, где F представляет функцию произвольного типа.

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

У меня есть небольшой дополнительный курс "Быстрая прокачка в ООП" - 9 контринтуитивных правил, одно из которых предлагает в частности выделять все перечислимые сущности в программе в отдельные типы. И тут даже профессиональные разработчики допускают типичные ошибки, и потом жалуются, что код дескать со временем только усложняется.

Например, список инвентаря героя желательно делать не как обычный стандартный контейнер List<Item> , для которого допустима куча совсем ненужных и потенциально опасных операций, а как класс HeroItems. Для него допустим лишь небольшой набор операций -- например, по Id предмета изменить его износ или стоимость, или выбросить предмет, и т. п.

Человек пишет класс, в котором объявляет приватный список List<Item> и публичные методы с наглядными именами и удобными параметрами для работы с ним. Вроде как всё получилось здорово?

Однако по мере развития проекта оказывается, что над элементами списка требуется ещё много чего другого делать; в класс напихиваются методы, во многом аналогичные операциям над стандартным списком, и код просто впустую разбухает и разбухает. И через некоторое время принимается волевое решение вообще избавиться от класса HeroItems и вернуться обратно к List<Item>)))

(Что, впрочем, со временем всё равно приводит к множеству других проблем...)

Да, потому что тут (в обоих этих случаях) был нарушен важный и весьма глубокий универсальный принцип хорошего дизайна, который начинается не с выписывания классов "здравым смыслом", а с проектирования алгебры автономных АТД со своими операциями; соответствующую методику разбираем в частности на третьем курсе по ООАП.

Засада в том, что любая подобная методика подразумевает довольно много абстрактного и глубокого думания в далёком отрыве от кода, и вот 98% прошедших этот курс нифига особо не думают, а просто отделываются интуитивным коротеньким описанием множеств классов, которые ум генерирует на быстром мышлении S1, без тяжёлого интеллектуального напряга.

И в результате получают именно тот "результат", на который я исходно и рассчитывал: когда в последнем задании они собирают прототип, то оказывается, что он вообще получился не работоспособным, в проекте зияют огромные дыры и пустоты :) Тут и возникает то самое важное понимание, которого я планировал добиться, ну и на следующей паре итераций по методике результаты уже получаются достаточно удовлетворительные.

Как Amazon Prime Video повысил масштабируемость и сократил стоимость сопровождения проекта в 10 раз, отказавшись от безсерверной лямбда-архитектуры в пользу монолита :)

Ещё в 90-е, когда я писал свои первые книги по программированию, довольно быстро обнаружил в существовавших учебниках систематическую ошибку подразумеваемых коротких расстояний в понимании (а у меня всяческих книг по программированию и computer science до сих пор дома сотни). Интернет позволил оперативно получать обратную связь, и я быстро выяснил, что у 90% начинающих большая проблема в понимании понятия "переменная".

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

Сегодня множество курсов тоже разбирают понятие переменной достаточно подробно, но по-прежнему остаются только на одном понятийном шаге. Они рассказывают например такую ересь, что дескать Python отлично подходит для начального обучения программированию, предлагая на своих курсах унылую метафору "переменная -- это просто коробка для хранения".

Почему это не так?

Состояние -- это крайне вредная концепция для начинающих, особенно если язык допускает его свободное использование. Конечно, State нужно уметь применять, но очень осторожно, редко и максимально безопасно. Продвинутое программирование стремится к иммутабельности и stateless (и на уровне кода, и на уровне архитектуры, и на уровне тестов), а раннее или излишнее использование состояния быстро приводит к беспорядку и запутыванию (прежде всего в голове разработчика). Недаром в Оксфорде с первого же курса принуждают к хаскелю, и в итоге человек становится способен общаться на уровне цивилизованного undergraduate.

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

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

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

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

Какой метод обучения проектированию и system design самый лучший?
Ну, если бы я точно знал, что у кого-то есть такой метод более лучший, чем у меня, я бы сразу пошёл к нему учиться, а потом стал бы сам его преподавать :)

Поэтому я и учился так не один раз, и продолжаю изучать темки, которые преподаёт небольшое число продвинутых PhD (по всему миру их меньше пальцев на руках!), и адаптирую их для моей Школы.

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

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

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

И это отнюдь не даётся легко. По крайней мере, с языками программирования и этими вашими веб-фреймворками, у вас есть куча онлайн-курсов и гайдов начиная с уровня “hello world”. Всё в мире проектирования и формальных подходов спрятано в научных статьях, толстых книгах по 5000 рублей и курсах по нескольку тысяч долларов.

GPT4ALL -- отличный десктопный локальный AI, дюжина опенсорсных LLM на выбор, код пишет ничуть не хуже хвалёной ChatGPT. Жаль, почему-то поддержку GPU не сделали (причём даже хвастаются этим), но и так на среднем процессоре генерит ответы и код практически в реальном времени.

Можно самостоятельно дообучать под свои задачки: Our released model, GPT4All-J, can be trained in about eight hours on a Paperspace DGX A100 8x 80GB for a total cost of $200.

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

...Всё же не рекомендую в плане фриланса прямо уж так вовсю ориентироваться на массовые сервисы типа fl или upwork. Да, это контринтуитивно, но в этом и заключается ключевая стратегическая линия моей Школы, напомню: не бегать за возможностями с толпами голодных бедолаг -- ваших конкурентов на одну вакансию/заказ, а развиваться так, чтобы возможности сами стали бегать за вами. Почасовые ставки на таких сервисах для новичков долгое время будут невысокими, режимы работы каторжными, а конкуренция очень жёсткой.

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

Я и сам живой пример этому подходу: вокруг сотни онлайн-курсов по программированию и тысячи репетиторов и менторов, среди которых доктора наук и преподаватели МГУ, к которым вы можете попасть в любой момент, просто заплатите; а ко мне на месяцы очередь из желающих заниматься и конкурсный отбор (при том, что по карьере я помогаю бесплатно).

Причём конкуренция в нише "собственного апворка" вообще нулевая: сколько не искал, знаю буквально 1-2 блога/канала в тг, которые хотя бы немного было действительно интересно читать по теме ИТ, и всё.

=

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

P.S. Кстати, убьёт ли AI фриланс? Дальше расскажу.

Вот что сказал по поводу "AI vs фриланс" Хейден Браун, генеральный директор Upwork: появляются совершенно новые рабочие роли, такие как промпт-инженеры, на которые формируется взрывной спрос, поскольку практически в каждой отдельной профессии теперь ожидается интеграция инструментов генеративного AI на основе LLM в их работу.

Хейден также утверждает, что благодаря появлению сильного искусственного интеллекта вроде ChatGPT и других LLM, спрос на квалифицированную рабочую силу только растёт.

Развитие AGI в ближайшие годы заставит большинство компаний отказаться от своих традиционных методов и перейти к новым способам организации сотрудников, и тут фриланс как способ такой организации труда будет очень выигрышным.

Изменения неизбежны в ближайшие годы, и более гибкие умом профессионалы получат значительное преимущество. Лучше быть фрилансером с диверсифицированным набором услуг, продающим свои специализированные знания сразу нескольким компаниям по всему миру, чем сотрудником, продающим свои навыки одной организации, что всегда сопряжено с высокими рисками. А если банкротство, увольнение, AI, придёт новый придурошный начальник, как в сериале "Консультант"?

... Но вот в чём загвоздка: фрилансер ты или наемный работник, рано или поздно мы все будем сбиты AI с толку. И это произойдёт гораздо раньше, чем многие из нас ожидают. Ещё год назад предполагалось, что AI, пишущий код, появится не раньше следующего десятилетия.

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

Что нам следует делать? Я не знаю. В идеале, надо бы инвестировать в (а лучше всего, срочно создавать самим) компании, которые явно выиграют от появления AI. Как минимум, создавайте свой собственный апворк.

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

В любом случае, очевидно, что объёмы данных и технологии их обработки будут стремительно расти и развиваться в текущем десятилетии, и вы можете сделать ставку либо на перемены, изучая AI, оставаясь в курсе передовых технологий и осваивая для этого фундаментальные темы, которые я предлагаю в Школе, либо на то, что остаётся дефицитным и постоянным во всё более цифровом мире (например, блокчейны).

P.S. Однако я не консультант по инвестициям -- я просто фрик из Рунета :)

P.P.S. Кстати, третье, на что вы можете сделать ставку -- это стать консультантом по этому всему, в первую очередь по AI.

Как программисты, люди мы или нет :) , мы должны адаптироваться или умереть.

Когда несколько десятилетий назад Google выпустила свою поисковую систему, программист, способный эффективно её использовать, оказывался в 10 раз продуктивнее того, кто этого не делал.

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

То же самое сейчас относится и к большим языковым моделям: используйте LLM ежедневно в своей работе, или станете "неактуальными".

Весьма достойный в целом материал из вики "Composition over inheritance", разошедшийся по куче статей и учебников, где приведена большая диаграмма наследования из известного учебника по паттернам Фрименов, который я рекомендую начинающим, но в котором, например, самый важный паттерн Visitor вообще не упоминается.

Но посмотрите, тут например Duck выполняет композицию с интерфейсами Flyable и Quackable, а не наследуется от них. Но вы что, собираетесь создавать свободно плавающий экземпляр Flyable в своём проекте? лол

А вот MallardDuck наоборот, зачем-то наследуется от Duck, хотя этого как раз хотелось бы избежать. Опять-таки, главный смысл наследования -- это обеспечить полиморфизм подтипов, но он подразумевает создание экземпляра родителя Duck, ну и зачем он нужен, свободно плавающим объектом в коде, как и Flyable? Тут как раз используйте композицию и паттерн делегирования.

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

Цель каждой строки кода - сделать какой-то факт истинным. Сложность кода вытекает из того, насколько трудно установить факт из того, что уже является истиной.

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

Идея не в том, что если вы просто перестанете думать, у вас будет лучший код. Идея в том, что если вы обнаружите, что при работе над кодовой базой вам часто приходится думать на медленном мышлении S2, возможно, вам следует серьёзно переосмыслить свой дизайн.

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

В целом, рекомендую вообще исключить практику переопределения родительских методов. Как правило, это просто кривая версия композиции. Вообще, переопределение существующих реализаций опасно всегда.

Например, в вашей структуре данных есть метод put(), у которого внутри меняется счётчик элементов. Если вы переопределите put(), добавив в свою версию увеличение счётчика (без вызова родительской версии), то счётчик также будет увеличен во время вызова дочернего метода.

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

Композиция вместо этого работает только с интерфейсом внешнего класса и будет надёжной.

В 2022-м мировой рынок AI составлял 136 млрд. долл., а к концу текущего десятилетия он вырастет в 13 (!) раз. Уже в ближайшие 2-3 года работу из-за AI потеряет 85 млн. человек, но появится 97 млн. новых (вроде промпт-инженеров).

Обычно, в комфортных условиях, фраза "адаптируйся или умри" была лишь метафорой, но перед лицом искусственного интеллекта она внезапно оказалась пугающе уместной.

Сейчас те, кто шустро пилят AI-стартапы, делают сразу по 3-5 проектов одновременно, потому что сегодня они устаревают за считанные месяцы. Вообще, очень интересный тренд: старые стартаперские схемы "сделать нетленку" в расчёте выпуска долгоиграющего продукта на годы, безнадёжно устарели. Сроки создания продуктов с помощью AI ускорились в десятки раз, и это лишь начало, и парадигма ИТ-инноваций меняется более чем полностью:
- создаём за пару недель уже не прототип, а нечто работающее,
- потом продаём этот сервис несколько месяцев и на эти деньги пилим что-то другое,
- потом появляется куча бесплатных аналогов, текущий проект сдыхает, а мы тем временем запускаем новые.
Аджайл-подходы наконец-то становятся естественным культом.

Например, что произойдет с криптоиндустрией, когда миллиарды экземпляров продвинутой версии AutoGPT будут управлять параллельной экономикой BTC? Когда стремительно развиваются такие децентрализованные сети, как Lightning?