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

Я такой:
- вот эта фича позволит реализовывать популярный класс твоих задачек в 2,7 раза быстрее.

Они такие:
- супер! здорово! спасибо! только сейчас нету времени это изучать.

ну штош :)

Современные разработчики практически больше не имеют возможности получить следующий профессиональный опыт:

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

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

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

.

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

Вроде бы академические темки "кабанчика" (по highload у нас целый трек уже много лет) на неделе внезапно стали более чем актуальными :)

Так же и computer science + math в айтишке, вот увидите, с развитием сверхинтеллекта станут критической информационной инфрой, и изо всех онлайн-школ полезут тематические курсы, как сегодня по AI. Но с 24-го вообще любые новые онлайн-курсы теперь везде чистый нейрослоп, а у меня есть абсолютное конкурентное преимущество: я занимаюсь cs и теорией типов много лет, и у меня мегабайты честного человеческого контента.

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

Перегрузил свой эндпоинт побочными эффектами? Вот как правильно =>
Добавляйте как можно меньше кода в алгоритм планировщика, сводите его к анемичной модели. В идеале, всё что должно быть внутри scheduleTask(task), это только queue.push(task) :) Ну и лог.
Соответственно, сама идеальная таска ...


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

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

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


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

Четвёртый квартал начался на днях. Примерно через 90 дней закончится 2026-й год.
Может показаться, что этого времени у вас предостаточно. Кроме того, оно достаточно короткое, чтобы быстро исчезнуть, если вы начнёте этот квартал, не решив, что нужно сделать для вашей цели.
Вы же выполнили ежеквартальный обзор и планирование своей карьеры?
...Без этих решений новый квартал просто повторит предыдущий. Все те же срочные рутинные задачи продолжают вас побеждать....

Продолжаю выкладывать для донов материалы СильныхИдей.
110. Интерфейсы vs Контракты vs Абстракции
Общепринятое понимание интерфейса такое, что это коллекция абстрактных методов, которые задают некоторый "контракт" для класса, который он должен реализовать. Почему это не совсем так?
109. Почему функциональные языки (например, Haskell) так плохо работают в продакшене
При разработке бизнес-логики формирование хороших типов предметной области действительно означает весьма точное её определение.
Но домен и бизнес-логика -- это ещё далеко не всё приложение. Гораздо чаще в кодовых базах бизнес-логика представляет собой небольшую часть прочей функциональности, которую необходимо запрограммировать, чтобы всё работало...

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

=

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

В курс карьеры добавлен 148-й материал "Инди-хакерство 2026 - 4".
Если вы сильно хотите чего-то в жизни, и действительно сосредоточены на достижении, вы практически всегда можете этого добиться. Если вы в это верите и готовы работать достаточно долго и упорно, чтобы в конечном итоге достичь цели, то самой важной задачей становится именно ...

=

"Функциональные архитектуры" 179(+1) топиков.
Тесты как исполняемые спецификации.

LPF закончен, куда и как дальше => (Meta)Principles Framework (сделано 0% :)

=

"ЛаМПовое":

линукс как макось

=

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

=

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

Один из ментатов попросился на работе вот на эту конфу => AI Native Conf 20 окт
типа оплатите билетик, и ему отказали 🙈

Для физика кстати билет стоит 20 тыс, а для юрика 50 тыс.

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

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

2. "Экономика ИИ без иллюзий: как отличить эффект от самообмана"
Никак :) С одной стороны, безумная скорость кодогенерации, с другой стороны, куда большая куча проблем просто сдвигается на чуть попозже, но менеджерам это невозможно объяснить. Познать это можно только через собственную боль :)

3. "Почему сотрудники не используют AI: организационные барьеры и ошибки внедрения"
Ровно потому, что тупые/трусливые начальники, и ничего с этим снизу не поделать.

4. "AI Agent Design Canvas: как оценить идею AI‑агента и собрать требования"
Пока в организации нету чёткого и детально прописанного рабочего процесса для каждой роли, скрипач агент вообще не нужен.
А когда такой процесс есть (от силы в 2% организаций), всё становится очевидным само собой.

зашлите сотку баксов.

(продожение следует)

Продолжаем прохождение конфы AI Native Conf 20 окт
(в программном комитете обнаружен экс-ментат 🔥)

"Когда Delivery перестаёт быть узким местом: агентная архитектура продуктовой работы"
Когда наймёте хорошего девопса, а не самозванца-сисадмина за 2 копейки.

"Карта AI-инструментов разработки: от GPU до агентики, без слепых зон"
Отправь этот промпт в дипсик :)

"ИИ в аналитике — отчеты уже не будут прежними"
💯, теперь будут отстойные нейрослопы, где 20% правдивых цифр будут смешаны с выдумками.

"Эволюция агентной разработки в Сбере"
Про гигачад по инсайдерским отзывам ребят кто там работает, могу много рассказать, но лучше не буду :)

"Агенты как часть штата с первого дня: роли, найм и управление при запуске продукта"
Кстати да, ну я давно уже говорю, что где собственно сервис "AI-Джуниор" хотя бы, которого можно было посадить вместо кожаного джуна, и он начал бы фигачить тикеты 24/7 как минимум не хуже, и сжигая токенов не более чем на 50 тыс рублей в месяц?
А нету и не будет, только развод гоев на "ai-помощники", польза от которых весьма мутная, а обходятся дорого.

"Миграция с Pega силами ИИ: реверс-инжиниринг логики и агентная разработка"
no comments

"Из идеи в продажу: работающая методология AI RnD"
В продажу курсов? ;)

"Не ускорять старую организацию, а построить новую: опыт AI-native трансформации бизнес-юнита"
На самом деле, с таким подходом очень даже согласен.

"Дизайн в агентном SDLC: разработку ускорили — упёрлись в дизайн"
Ну как бы да, база :) об этом пишу всё время.

"Кто сломал прод? Как граф зависимостей сокращает путь от алерта к причине"
Ok, графы и другую аналитику конечно всячески поддерживаем.
В СильныхИдеях об этом в частности "156) First principle для внедрения AI в проект"

А прод сломал джун, 100%

(перерыв на обед)

Завершаем прохождение конфы AI Native Conf 20 окт

"Опыт внедрения агентской разработки в Avito" / "опыт внедрения AI First парадигмы"
ок, но я лично вообще против AI First.

"Как переехать на ИИ в 17-летней продуктовой технологической компании"
Полноценно переезжать на ИИ крайне не рекомендую на самом деле. Тут скорее стоит пообсуждать, а вообще "зачем 17-летней продуктовой технологической компании переезжать на ИИ?"
тоже кстати "За 3 месяца всё перевернулось и мы перешли на AI-first"
Да, но "Дизайн в агентном SDLC: разработку ускорили — упёрлись в дизайн".

"Как освободить себе два дня в неделю с помощью ИИ, если ты менеджер"
Волчара детектед?? :)

"C-Level Клуб ЗАКРЫТАЯ ВСТРЕЧА" приватный эскорт для випов? :)

"Продуктовый инженер, кто это и откуда их брать?"
Норм тема. Вообще, прокачка своих инженеров в продуктовые темы, и внедрение их в компанию заказчика на помощь по AI очень приветствую.

"Мы открыли продукт для prompt injection, и это круто"
Кликбейт; наверное имеется в виду prompt injection как механизм управления агентами?
"как заменил весь GUI продакшн-сервиса одним чатом на агенте OpenClaw, не тронув бэкенд" - а, ок. Одобряем :)

"Проблема сопротивления сотрудников внедрению AI: почему AI-трансформация буксует"

Только кнут (с) :)

Помню ещё из 90-х, постоянно обсуждали "Проблема сопротивления сотрудников внедрению ERP: почему ERP-трансформация буксует"
Тогда, точнее, была ещё в основном MRP(2), но обсуждения, почему сотрудники автоматизацию массово саботируют, можно буквально копировать из статей того времени. Вечная темка :)

=

Первые 90% вашего работающего прототипа с помощью AI получить несложно. Важны остальные 190%.

С вас 50,000 рубликов.

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

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

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

Мир, к счастью, явно оборачивается к аналоговым формам, а тотальный негатив к AI этот тренд заметно усиливает.

Этот отчёт ментата заслуживает быть приведённым полностью =>

Итоги. Часов 8 "одним подходом", около 2 тыс. руб. и оно работает) Пришлось потом пару мест поправить, но это я некорректно описал эти места.
Выводы и впечатления.

1. Общее эмоциональное.
Нахожусь "под впечатлением" от такого способа разработки.
С одной стороны - в "один подход" часов за 8 (и около 2 тыс. рублей) с нуля сделан проект. Ещё и актуальная документация при проекте. И "вау!" ощущение от возможностей. AI же в SDD не просто прописывает спеки и код, но и уточняет мутное, напоминает забытое, проверяет согласованность требований. При этом работа ощущается очень плотная, но это не программирование, а именно формулирование требований, принятие решений. При обычной работе такое получается не так плотно, а "размазано". Можно пописать требования, потом код какой-то сделать, потом вернуться к требованиям. И больше кода, чем требований.

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

2. Размышляя над предыдущим пунктом появились следующие тезисы.
1) Вопрос не только в AI. Я стокнулся с коллективной работой, которая мне не так привычна. Мне привычна "self" работа, когда если и разбираешься, то, в основном, в своём коде. А здесь масса новых решений, хотя бы просто применение функций, которыми не пользуюсь. И это хорошо, это развитие и некоторая возможность почувствовать себя внутри команды, даже не общаясь при этом с людьми)

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

3. Получился не big конечно, но "small ball of mud". Большая связность модулей, переменные, которые "протаскиваются" насквозь через кучу функций, хотя вроде как файлы отдельные и некоторое архитектурное разбиение присутствует: вот конфигурация, вот преобразование, вот выгрузка и т.д. Но такой результат ожидаем, так как проект я задавал в основном"декларативно". Прописывал именно требования к проекту, но почти ничего про реализацию (не считая предпочтений по библиотекам, базе данных и какие константы использовать). Поэтому AI делало по своему усмотрению. И если спеки мне понятны, то модули их связность были оставлены "на усмотрение" AI. Благо, проект небольшой всё достаточно понятно, но некоторые связи уже долго отслеживать. Вывод - нужно над архитектурой проекта работать самостоятельно, не давая на откуп AI и прописывать в требования.

4. Более узкие моменты.

4.1.Пока не полностью понял логику где что должно быть - поищу ещё в документации. Сейчас весь "architecture-skeleton" отправлен как финальная стадия в архив, который в папке changes (там и proposal .md и design .md). То есть самый верхнеуровневый взгляд в архиве. А в спеках (то, что не в архиве) только сами исполненные спеки - но это же более низкий уровень представления. То ли так и должно быть, то ли я что-то не так сделал. Поразбираюсь.

4.2. LLM конечно деньги тратит очень бодро. И мелкие правки рождают много движения (например, в сводном отчёте в одном поле изменил на его значение на разность того, что было, и соседнего поля - сразу масса обращений к LLM). Сначала моделью выбрал привычную Claude Sonnet 5. Потом решил экономить и заменил на дешёвый Deepseek v4.1 flash, но он слишком косноязычный оказался. А Deepseek V4 Pro получилась вполне подходящим компромиссом. Также, думаю, нужно работать меньшими задачами. Я, по сути, весь проект сразу делал. И AI для проверок все документы перечитывала. Также, возможно, для больших проектов стоит добавлять RAG и/или graphify.

P.S. Немного о эмоциях в процессе. Восхищение магией AI и вместе с тем некоторый лёгкий страх касательно трансформации мира в целом в связи с AI) Понятно, что LLM, что просто некоторый подбор очередных самых подходящих слов (токенов). Но когда машина тебе пишет "Сами правила конвертации, проверок и формирования строки отчёта вы опишете отдельно." (в изначальном задании писал, конечно, что позже напишу). Или аккуратно уточняет мутные формулировки "Это разные направления, и они оба выглядят правдоподобно, но я не хочу угадывать. Из вашей фразы «превышение второй суммы допустимо» я читаю именно ваши исходные формулы:". Или написал правила конвертации, а также дал пример исходного файла и результата - а оно взялось проверять правила на этом примере. Плюс чёткое подтверждение действий, перепроверки (со спеками, тесты). Появляется внутренний вопрос, а точно ли это компьютер и он неодушевлённый?) Короче, я его иногда боюсь))

Каждый месяц мой рабочий процесс разработки с использованием AI полностью заменяется совсем другим. Но потом я жду ещё несколько недель, и этот рабочий процесс тоже оказывается полностью устаревшим, так что я не так уж и расстраиваюсь.
(но при этом золотая пора у тех, кто "курсы по AI продаёт":)
 
Помню, как были организованы процессы разработки в крупных ит-конторах ещё до AI: всё шевелилось еле-еле-еле-еле, и вот интересно теперь узнать, как они адаптировались (ну, на самом деле все ревью и дифы, сборки и деплои, внедрение изменений и т.д. стали просто ещё более серьёзным узким местом).
 
А ведь существует великое множество проблем, которые сбивают агентов с толку, о которых сам программист не знает, не говоря уже о техдире. Но сначала мы перестали писать код, затем мы перестали читать код, а теперь перестали читать и сообщения агентов.
 
Пол Грэм на днях отмечал:
 
Многие вещи в ИТ работали только потому, что у людей есть предел скорости, с которой они могут действовать. Нам только предстоит узнать, какие именно пределы существуют, когда эти пределы начнут давать сбои...
 
Код по-прежнему является инструкциями для машины. Но он также является моделью понимания. В эпоху AI эта вторая роль становится ещё более важной. Будущее программирования заключается не просто в написании большего количества кода быстрее. Оно заключается в создании более совершенных концептуальных моделей, более совершенной лексики и более прочных основ, на которых могут работать как люди, так и нейронки...
[развиваем эту темку на Функциональных архитектурах]
 
P.S. Учёный Ноам Браун из OpenAI утверждает, что отключение компьютеров от сети далеко не факт что предотвратит атаку AI на человечество, поскольку например две изолированные машины всё равно смогут взаимодействовать, нагревая процессор и считывая изменение температуры, а также кучей иных стеганографических способов.

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

1. Какие инструменты он применяет, и как.
2. Какой стиль кодинга, какие паттерны использует.
3. Как он доказывает правильность своего решения.

Я гарантирую, что вы в течение часа точно поймёте, принесёт ли этот человек пользу вашей команде, или нет.

Уничтожаем всю мировую AI-индустрию и бизнес на цодах-шмодах одним сетапом.

Старенький системный блок на 12 гб оперативки + юзанная RTX 3060 + моделька 8B под конкретную тему.
винда 10, лучше линукс конечно (а вот мак не потянет ахаха)

И получаешь до 50 токенов/сек.

Например, чисто под кодинг на таком сетапе сейчас есть хорошие модельки 8B уровня квена3.6 35B, просто спросите нейронку. Если хорошо знаешь архитекторство и software design, более чем достаточно; неплохо RAG и graphify прикрутить.

Различная аналитика, создание документации, ETL, ревью кода, devops -- под каждую темку вполне можно точечно найти маленький подходящий опенсорс.

И в целом, стратегически крайне рекомендую (срочно) уходить максимально в локальную инфру, как можно дальше от любых облаков. В крайнем, дедик или vps с ежедневным архивом всего образа.

Graviora manent.

И вот куда же в этом десятилетии придёт айтишка с эйайкой??

Ладно, спалю базу. Вот о чём тебя будут спрашивать на собесах буквально через год-два =>

1. Поясни за infrastructure as code через Мартина-Лёфа.

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

Хотя сворачивать ast пайпа можно разными алгебрами (запуск, валидация, косты...), но все они будут над одним и тем же функтором. И вполне можно обойтись сборкой результата из сумм, произведений и констант (поля, варианты, списки, деревья) -- ровно то, что обычно лежит в ваших YAML/JSON.

А если бесконечный reconcile loop в кубере? А это уже коалгебраическая история...

2. Пилим gRPC-стриминг для геймеров на 100500 миллионов юзеров, поясни за правильный протокол.

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

3. Надо выполнить каноникализацию всех наших конфигов, манифестов, стейтов и артефактов.

Абстрагируем операции devops (merge, overlay, patch, apply, compose) в кольцо, и задаём кастомные эквивалентности, чтобы семантический нормализатор был устойчивым и сходящимся на всех операциях.
В первом приближении вместо кольца можно взять полурешётку, или даже моноид, потому что apply или delete особо не отменить.
А дальше можно уходить в поля (бюджеты токенов) со своими алгебрами, векторные пространства (веса канареечного релиза, ага)...

etc

Думаете, шучу? ну штош.