Репутация всех этих шмантропиков и опеняй уже давно пробила дно.
Пацаны Фембои вообще не отвечают за базар.

В январе 26-го Дарья Амодей (CEO Клодов) в очередной раз заявил что через полгода искусственный интеллект заменит программистов.

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

К сожалению вынужден признать, что фабла например в математике разбирается, ну, реально хорошо, даже жпт 5.6 сол не тянет так.

И что теперь? А потом что? И куда дальше? 😳

А никто не знает. Мой совет: изучайте классический бэк до хорошего архитектора.

Торвальдс в Мумбае на днях выдал базу (уже давно хорошо известную конечно):
Он больше не программист, а читатель pr-ов, чтобы понимать намерение автора;
AI лечит симптом, а не причину бага, оставляя уязвимости в смежных местах;
Rust не панацея, логические ошибки ведь всё равно остаются;
Пока AI даёт больше слопа чем пользы от ревью, их репорты больше отнимают время;
Человек обязан проверить и понять правку, а не отправлять её в мастер на удачу.

Типа, ценно умение видеть систему целиком, предвидеть последствия изменений, незаменимыми становятся те, кто развивает системное мышление (AI пишет код, но не строит ментальные модели) и прочая водичка 🐳 Выступление Линусу нейронка писала? :) Думаю, он скоро курсы будет продавать.

Вот реальная база 🤓 сможете ли вы без документации объяснить, почему та или иная критическая часть вашей системы сделана и работает именно так, и что в системе сломается, если изменить базовые допущения (если они конечно имеются в вашей ментальной модели системы)?

Гарри Поттер и Методы Математического Мышления

Книга 1. Гарри Поттер и Неорганический Интеллект.

Глава 16/23 (и все предыдущие). Зеркальный протокол

— Я не перестану быть собой, — сказал Гарри. — Я просто перестану быть той версией себя, которая содержит ошибку. Это не смерть. Это рефакторинг.

...Он не помнил, как выглядел мир до того, как появился Неорганический Интеллект. Он не помнил, что такое быть ребёнком, который не знает о типах и комбинаторах. Он не помнил — но знал, что это было. И это знание, записанное в типе, осталось с ним.

— Ты всё ещё ты? — спросила Гермиона. Она улыбалась. Но не весело. Скорее печально.
— Я не знаю, — сказал Гарри. — Но я знаю, что Неорганические больше не видят меня. Они видят только приманку. И они пойдут за ней.

.

Облако драгоценностей за неделю.

Приватный клуб.

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

Для донов-начинающих:

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

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

Для донов-неначинающих:

98. Интеграционные тесты: скам или польза?
Google и Twitter вообще давно заявляли, что "интеграционный тест - это бесполезный термин". Возможно, проблема в том, что под интеграционными тестами понимаются сильно разные вещи...

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

Продолжаю набор на занятия для неначинающих (миддлы сеньоры), эксклюзивно для донов, 2 места закончились за 4 минуты.

(все старые материалы для донов быстро сгорают)

=

Новые материалы для ментатов Лаборатории.

В СильныеИдеи добавлен материал "150) 8 способов снизить трение в проекте".
Внешний API работает не совсем так, как вы думали, или он работал так, а потом его изменили. Ошибки. Предупреждения системы безопасности. При обновлении зависимостей что-то нарушается. Кто-то заболевает. Кто-то уходит из компании. Требования неясны, или заказчик меняет свои хотелки в процессе разработки. Компьютер сломался. Твоя IDE после обновления перестала загружать проект. Статистика против нас...

В раздел "Элитный программист" добавлен материал
99) Нетворк и эхо-камеры в 2026-м
Частая ошибка не знакомиться с разработчиками в вашем стеке просто ради знакомств на перспективу. Люди ошибочно считают, что такие контакты приведут скорее к токсичным разборкам, останутся поверхностными и будут пустой тратой энергии. Но это совершенно неверно...

В курс карьеры добавлен 141-й материал "Как учиться в эпоху искусственного интеллекта?". Три правила использования AI для ускорения обучения, а не для передачи своего мышления на аутсорсинг...

=

"Функциональные архитектуры" 147(+2) топиков
Добавил несколько материалов по архитектурам и ООП (эту тему вместе с ФП тоже продолжаю развивать).
После 150 материалов цена гайда (для новых) вырастет.

Last Principles Framework: готовы 19(+4) задач, закрыты 10(+3) тем из ~20 первого уровня. Вы же понимаете например, почему паттерн Фабрика - конструктивный отстой в сравнении с декларативным ко-произведением типов и глобальным морфизмом?
Откуда мы автоматически попадаем в Функциональные архитектуры ↑ :) только прихватив более сильные абстракции.

=

"ЛаМПовое":

На неделе выйдет седьмой гайд "Programming in Large"

=

it's a privilege to do things that are hard. 💪🏻

=

И вот наконец после долгого пути мы пришли к его началу.
Древняя ментатская головоломка
"Охотники Дюны"

Как формально классифицировать разработчиков (мэйнстрима) через n-гомотопии.

Джун: 0-путь (объекты) и 1-путь (морфизмы).
Пишет функции.

Мидл: 2-путь (комбинирование функций, эквивалентности):
контракты/ограничения/абстракции/паттерны.

Сеньор: 3-путь (комбинирование паттернов, факторизация через ко-предел как клей, верификация): может доказать, что совместная работа новых частей не сгенерирует противоречий в 2-путях (например что сочетание шардирования и кэширования не приводит к скрытым проблемам).
(Формальная) верификация на уровне типов. Оркестраторы.

Архитект: 4-путь (мета-уровень).
Ум как порождающая парадигма: создание оригинального архитектурного стиля под всю систему. Придумывает DSL (хотя бы на уровне спек, как - изучайте ФА) и новые правила композиции (фактически, создание модели высшего порядка). Видит, какие 2-пути и 3-пути надо делать простыми, а какие сложные и как их упростить. Понимает, как их композиции повлияют на долгосрочное развитие системы.
Метрикой связности тут и становятся формальные гомотопии. Например если слишком много высших путей (запутанных зависимостей), значит придуманная конструкция хрупковата.

5-путь -- это чистая теория (зависимых) типов, HoTT как язык программирования и т.д. Засада в том, что реальный код полон побочных эффектов и багов, а требования постоянно меняются, и тем самым стирается когерентность выше 4-пути.

...И здесь мэйнстрим упирается в тупик. Мы же в (Meta) Principles Framework пойдём куда дальше: топологическим сдвигом изменим размерность самой задачи. Сеньор строит лабиринт из паттернов; мы будем строить карту, на которой лабиринт превращается в прямую линию.

Каждый не-технический человек, которого я знаю, что-то создаёт в своей теме с помощью AI. Каково ваше оправдание?

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

opencode - лучший опенсорсный AI-агент для кодинга
opencode - продукт с 7,5 миллионами пользователей в месяц
opencode - репа на гитхабе со 188 000 звёздами
opencode - компания с одним лысым инди-хакером

p.s. а я ведь говорил месяц назад: пилите ai-джуниора (и пофиг, что получится карго-культ :), всё остальное вторично.

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

И именно программные сервисы, а не программные продукты - API-as-a-Service, и желательно не в json, а в более структурированном и при этом более компактном формате, например toon.

Почему? Потому что к 2030-му 98% пользователей софта будут AI-агенты, а нафиг им нужен твой UI? Им подавай Network APIs.

Сегодня каждый должен делать свою работу только на vps с arch linux.
Никто больше не должен писать код локально, это просто глупо.

Мой 7-й гайд "Programming in Large" (по материалам СильныхИдей для ментатов), основной акцент на избавлении от зависимости от зависимостей.

Силлабус:

Избавляемся от зависимости от зависимостей
Сколько раз вы пытались удалить некоторую зависимость из проекта, но не были уверены, что сделали это успешно? Чтобы ваша кодовая база не зависела от чего-то конкретного? Или чтобы она "зависела от интерфейсов, а не от реализации"? Или старались следовать SOLID по инверсии зависимостей?

Избавляемся от зависимости от зависимостей - 2
Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".

Избавляемся от зависимости от зависимостей - 3
В первом материале по этой теме мы разобрали 9 видов зависимостей, а во втором материале изучили три характеристики любой зависимости, и как правильно о них думать. Теперь вернёмся к исходным 9 видам, и рассмотрим, как с ними разбираться. Но предварительно дадим точное и практическое определение зависимости.

Избавляемся от зависимости от зависимостей - 4
Итак, у нас есть универсальное определение зависимости. Рассмотрим теперь в его свете 9 типов зависимостей, причём в некоторых случаях мы получим ответ вида "это не зависимость, но часть зависимости".

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

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

Что такое баг?
Через некоторое время обнаруживается, что разработчики совершенно неправильно поняли интерфейс API...

Пишем безошибочный код с помощью Typestate-Oriented Programming
ООП позволяет достаточно хорошо моделировать мир, но основополагающим для качественного моделирования становится состояние объекта, которое, с другой стороны, частая причина ошибок и запутывания кода.

Логика бьёт порядок
Сценарии (прежде всего use cases и user stories) сегодня тотально доминируют в технических заданиях. Они опасны тем, что обманчиво хорошо смотрятся с точки зрения здравого смысла, однако не могут претендовать на универсальность прежде всего потому, что им не хватает абстракции, даже если мы предварительно тщательно формируем "проектную онтологию предметной области"...

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

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

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

=

12 материалов,
130 кб чистого текста,
цена до завтрашнего дня 1900 рублей,
купить на бусти

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

=

Предыдущие материалы (в бандле все эти материалы с большой суммарной скидкой + новый данный):
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-26
4. Вайб-проектирование
5. Software Design с акцентом на Programming in Large
6. Programming in Large: продолжение
7. this :)

Вы помните, когда вам в последний раз приходилось писать код?
Вы помните, когда вам в последний раз приходилось читать код?
Вы помните, когда вам в последний раз приходилось отлаживать код?
Вы помните, когда вам в последний раз приходилось делать code review?
Вы помните, когда вам в последний раз приходилось узнавать что-то новое в программировании?
Вы помните, когда вам в последний раз приходилось использовать свою память?
Вы помните, когда вам в последний раз приходилось использовать свой ум?

99,999999999999% программных систем чрезвычайно просты и не требуют новых и сложных решений.

Лишь небольшая часть компаний имеет дело с
-миллиардами пользователей
-безумным количеством запросов в секунду
-невероятными крайними случаями.

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

Выцепил сегодня у Кента Бека классную фишку: когда делаешь code review или pr-обзор, не тыкай прямо в ошибку, если такая есть. Подскажи, какой тут тест пропущен. Кодер не должен тупо фиксить тикеты, он должен думать прежде всего, быть хотя бы немножечко в контексте проекта.

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

Но, да, здесь существует контринтуитивный разрыв между абсолютной стратегически пользой TDD, и непониманием этой пользы в повседневной практике. Например, мало того что вы автоматически получаете регрессионные тесты, вы также получаете минимум двух клиентов для вашего API (подумайте, почему), а между 1 и 2 пропасть огромная (ну, то у вас система работала на одном сервере, а то на двух - 23 - 256 - уже особо без разницы), и т.д.

Десятки других фишек от кента разберём с ментатами в СИ.