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

В результате революции софт подешевеет, но станет хуже (по сравнению с разработанным вручную). Примерная аналогия — промышленное производство одежды. До начала примерно 20 века одежда была дорогой и составляла существенную часть расходов. Затем она начала стремительно дешеветь, упрощаться и ухудшаться в качестве, но зато стала доступна всем в огромном ассортименте.

А может быть и нет. За всё время развития айтишечки количество усилий со временем последовательно смещается «влево», к не-кодовой работе. Время уже тратится не на написание кода, а на формулировку, что же именно нужно сделать. И вот аишечка сможет всё поломать, только если сумеет решить вопрос с анализом потребностей и возможностей.

Больше набросов богу набросов.
https://ai-2027.com/

Вообще предлагаю совместить Часы Судного Дня, Ядерную Зиму и AI-апокалипсис.

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

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

И вот ещё фантазия: к концу 2025 года webarchive закрывает доступ ко всем данным, организует корпорацию и становится единственным владельцем гарантированно чистых природных текстов, созданных живыми людьми.

Тяжела жизнь современного айтишника.

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

История успеха. Понадобилось нагенерить юзеров для AD-контроллера. В гитхабе нашёлся скрипт за секунду, из скрипта выбрана строка со списком полей CSV-файла и дальше промт в нейронку с просьбой сгенерить данные.

Трейлер-тизер Zootopia 2 в стиле GTA.

Вообще надо было под музыку Caravan Palace делать сразу.

Спросил у гугла, сколько стоит захоронение на кладбище, где похоронен Березовский. В принципе адекватно.

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

Читал всякое про архитектуру, много думал и дошёл до очередного инсайта — даже в solution architecture (SA) нельзя обойтись без enterprise architecture (EA). Изолировать SA невозможно в принципе, при углублении неизбежно вылазит motivation (requirements) и структурные особенности организации, где этот solution разрабатывается.

Я уже раньше писал, что основные публично доступные архитектурные фреймворки все с погонами и там очень круто и чётко описаны процессы, solution там относительно небольшой фрагмент, который полноценно проработать невозможно без полноценного архитектурного ландшафта (Architecture Landscape).

(картинка для привлечения внимания)

Погоны, кругом погоны.

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

Это всё инфошум.

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

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

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

Дискретность же тут подразумевает конечность и ограниченность условных колонок/строк в такой таблице. Их можно пронумеровать/обозвать и свести к чёткой и согласованной всеми сторонами номенклатуре.

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

Самый эпичный дикпик был отправлен учёными на «Пионерах».

Суть Claude как раз в том, о чём я неоднократно писал: он не пишет код, он выполяет сам те задачи, которые выполняет код. Пока это на уровне инфраструктурных операций, но дальше неизбежно будет распространяться дальше.

Есть две колоссальные разницы между двумя операциями:

* ИИшечка написала bash-скрипт для автоматизации
* ИИшечка непосредственно занимается автоматизацией

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

Ждем прецедентов.

В англоязычной литературе активно используются формы от слова architect: architecture, architecting, architected. В русском пока не видел такого лаконичного.

Работник кодового склада.
https://www.nytimes.com/2025/05/25/business/amazon-ai-coders.html