Книжный куб

ASML Statement on Strengthening Focus on Engineering and Innovation (Рубрика #Engineering)

Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.

Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.

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

#Engineering #Management #Leadership #Software #Processes

AI Periodic Table Explained: Mapping LLMs, RAG & AI Agent Frameworks (Рубрика #AI)

Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системы Менделеева "AI Periodic Table". У этой таблицы, как ни странно, два измеренияя

Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)

Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности

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

Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов

Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели

Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain

Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference

Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей

Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))

Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?

#AI #DevOps #Software #Engineering #Architecture #SystemDesign

CS230 Lecture 2 @ Stanford (Рубрика #AI)

Раньше я уже рассказывал про то, что начал изучать этот курс и посмотрел первую лекцию Andrew Ng. Дальше пришло время второй лекции, которую вел Kian Katanforoosh, со-автор этого курса, CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai. Лекция выглядела как "recap про supervised" после изучения лекций с Coursera, но на деле это разбор инженерных рычагов в AI‑проектах: постановка задачи → данные/разметка → архитектура → loss → эксплуатация embeddings. Основные тезисы примерно следующие

1️⃣ Supervised ML решение - это обычный прод‑сервис
- В проде «модель» = архитектура + веса (два артефакта), вокруг которых крутятся пайплайны, метрики и деплой.
- Меняете задачу (binary → multi‑label) - меняется контракт лейблов, loss и метрики. Это не «добавили классы в датасет».
- Capacity: размер модели должен соответствовать сложности + разнообразию данных + compute/latency. Иначе получите красивый dev и боль в реальном трафике.
- Embeddings - когда расстояния в пространстве имеют смысл. Это фундамент поиска, рекомендаций, retrieval/RAG и «переиспользуемых представлений».

2️⃣ Три кейса, где всё решают данные и постановка
1) Определение day/night по картинке: сначала scope (одна камера или «весь мир»? indoor/outdoor? рассвет/закат/полярный день?) → потом сбор данных. Разрешение подбирают через human‑эксперимент: печатаем/показываем людям разное качество и ищем нижнюю границу информативности. Типичный компромисс: ~64×64×3 + небольшая CNN.
2) Работа с триггер словом типа "Алекса"/"Алиса"/"Siri", тут предлагается “activate”: классический паттерн каскада (дешёвое → дорогое): VAD/activity → trigger → ASR/intent. Чтобы не разметить руками бесконечные аудио, делают synthetic data + programmatic labeling: позитивы (“activate”), hard negatives (“deactivate” и похожие), фоновые шумы; скрипт миксует всё в 10‑сек клипы и генерит временные метки. Часто выигрыш даёт не «ещё данных», а правильная схема разметки по времени.
3) Face verification: «сравниваем пиксели» и «классифицируем каждого человека» не масштабируются. Решение - face embeddings + triplet loss (A,P ближе, чем A,N + margin). Дальше один embedding‑слой закрывает сразу три продукта:
- verification: distance < threshold
- identification: nearest neighbor по базе
- clustering: k‑means/agglo

3️⃣ Как масштабироваться без дорогих меток
- Self‑supervised: contrastive (SimCLR‑стиль) - две аугментации одного объекта должны быть ближе, остальные дальше; и next‑token prediction (GPT) - данные «размечают себя».
- Weak supervision: используем естественные пары модальностей (image↔️text, video↔️audio, subtitles↔️video). Отсюда CLIP/ImageBind‑подходы и единые multimodal embedding‑spaces.

Что можно почерпнуть для техлида DL/ML проекта
- Начинайте проект с постановки + распределения + edge‑кейсов, не с выбора модели.
- Ревьюйте свои ML модели как код: labels contract + loss + метрики (и их связь с бизнес‑ценой ошибок).
- Делайте быстрые human‑тесты до траты GPU‑недель.
- Оптимизируйте iteration speed: чуть меньшая модель/разрешение часто быстрее приводит к правильной системе.
- Стройте архитектуру вокруг embedding‑API: «выучили представление один раз → решаем N задач».
- Ищите в домене неразмеченные потоки и слабые связи (логи↔️действия, текст↔️телеметрия) - это топливо для self/weak supervision.

#Software #ML #AI #Engineering #Architecture

[2/2] Prompt Engineering for LLMs (Рубрика #AI)

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

3️⃣ Продвинутые темы: разработка чат-агентов с памятью и инструментами (метод ReAct), разбиение сложных задач на шаги (workflows), оценка качества решений моделью.
8. Conversational Agency - tool use в деталях: как проектировать инструменты (имена/аргументы), разруливать ошибки и опасные действия; reasoning‑паттерны (CoT, ReAct и дальше); контекст для task‑диалогов; сборка агента, управление диалогом и UX.
9. LLM Workflows - когда «чат‑агент» не нужен, а нужен workflow: задачи как кирпичики; реализация через шаблонные промпты или tools; усложнение/вариативность; идея «eval начинается на уровне task»; пример end‑to‑end workflow; продвинутые схемы: agent‑driven workflow, stateful task agents, роли/делегирование.
10. Evaluating LLM Applications - что вообще тестируем; offline: example suites, gold standard / functional testing / LLM‑as‑judge, SOMA; online: A/B и метрики.
11. Looking Ahead - куда всё едет: multimodality, UI/UX как часть качества, рост «интеллекта»/скорости/доступности моделей.

В общем, контента в книге много, но возникает вопрос, а насколько он полезен сейчас (в 2026 году). И действительно с момента выхода книги LLM-технологии шагнули вперёд, и некоторые в 2025-м провозгласили «prompt engineering мёртв». Качество моделей выросло – они всё лучше понимают пользователя даже без хитрых подсказок; кроме того, лучшие техники уже встроены в инструменты (готовые шаблоны промптов). В реальных продуктах поведение модели всё чаще определяется системными настройками или fine-tuning’ом, а не текстом пользовательского запроса. В итоге роль "prompt engineer" вскоре слилась с более широкими ролями AI/LLM-разработчиков.

Однако книга не потеряла ценности – её фундаментальные принципы по-прежнему полезны каждому инженеру. Авторы честно предупреждали, что конкретные API могут устареть, но базовые идеи останутся актуальными. Так и вышло: например, подход RAG теперь повсеместно применяют для подключения знаний модели, а техника chain-of-thought стала стандартным приёмом в современных AI-агентах. А в 2025 году Андрей Карпати ввёл термин «контекст-инжиниринг» – фокус на предоставлении модели полного окружения (данные, история, инструменты) вместо подбора идеальной формулировки запроса. Такой подход требует уметь динамически находить и подставлять нужные сведения, ужимать их под контекстное окно, чётко задавать роли (system/user) и подключать внешние инструменты по мере необходимости. Кроме того, появились практики вроде PromptOps – управление промптами (версионирование, мониторинг качества запросов). А некоторые команды уже пытаются полностью автоматизировать подготовку контекста и инструкций (т.н. workflow-подход).

#AI #DevOps #Software #Engineering #Architecture

[1/2] Prompt Engineering for LLMs (Рубрика #AI)

Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать» с большими языковыми моделями (LLMs). Авторов интересно читать, так как они – создатели одного из самых успешных AI-продуктов (GitHub Copilot) и шарят в теме.

В 2024 году тема prompt engineering была горячей, ее много обсуждали и эта книга стала одним из первых гидов - от основ до продвинутых тем, также в ней были готовые шаблоны с примерами кода. Все это сделало книгу ценным пособием для разработчиков. Если говорить подробнее про содержание книги, то она состоит из трех частей

1️⃣ Основы LLM: устройство и эволюция моделей, их обучение и переход к диалогам.
В первой части было 4 главы
1. Introduction to Prompt Engineering - почему LLM выглядят как «магия», краткая эволюция языковых моделей и где в этой картине prompt engineering как инженерная дисциплина.
2. Understanding LLMs - LLM как completion engine: токены/токенизация, автрорегрессия, галлюцинации, temperature/probabilities, основы трансформера; почему порядок текста и «нагрузка» на модель реально влияют на качество.
3. Moving to Chat - переход от completion к chat: RLHF (как он собирается), instruct vs chat, «alignment tax», эволюция API и почему следующая остановка — tools. Идея промптинга как «постановки пьесы» (сцены/роли/реплики).
4. Designing LLM Applications - ключевой фрейм: LLM loop (перевод проблемы пользователя в домен модели → completion → пост‑обработка обратно). Внутри: retrieval → snippetizing → scoring → prompt assembly; где добавляются state, внешний контекст, глубина рассуждений, tools и eval.

2️⃣ Ключевые техники: few-shot примеры, добавление внешних данных (подход Retrieval-Augmented Generation) для снижения галлюцинаций, форматирование длинных запросов
Во второй части было 3 главы
5. Prompt Content - из чего «собирать» промпт: static (инструкции, few-shot + типовые риски) vs dynamic (контекст на лету); RAG (lexical vs neural), эмбеддинги/векторное хранилище; суммаризация (в т.ч. иерархическая) и выбор «общей» vs «под задачу».
6. Assembling the Prompt - как упаковать всё в лимит контекста: «анатомия» промпта, выбор формата документа (advice conversation / analytic report / structured doc), форматирование сниппетов и few-shot, elastic snippets, зависимости между кусками (position/importance/dependency). Плюс важная практика: середина промпта часто “проседает” (условная valley of meh), важное лучше держать ближе к концу.
7. Taming the Model - «анатомия completion»: preamble, узнаваемые start/end, postscript; stop‑sequence/стриминг; logprobs для уверенности/классификации; как выбирать модель (качество/цена/латентность/фичи).

В продолжении я расскажу про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.

#AI #DevOps #Software #Engineering #Architecture

Книжный куб pinned «Сайт по system design (Рубрика #Architecture) Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System…»

Дискуссия на T-Sync Conf на тему "AI меняет инженерную культуру — быстрее, чем мы это осознали" (Рубрика #AI)

Конференция T-Sync состоится уже 7 февраля, я там буду на стенде презентовать результаты нашего исследования про влияние AI на SDLC, а также поучаствую в крутой дискуссии на тему инженерной культуры и о том, как AI влияет не только на скорость разработки,но и на мышление, ответственность и подходы инженерных команд. Планируем обсудить следующие темы
- Как меняется роль инженера в эпоху AI,
- Что происходит с качеством решений и инженерной экспертизой,
- Усиливает ли AI культуру или размывает её,
- Какие эффекты мы уже видим в реальных командах — и какие пока игнорируем.
Это разговор не про инструменты, а про людей, практики и инженерную идентичность.

P.S.
Если еще не зарегестрировались на конфу, то самое время

#AI #DevOps #Software #Engineering #Culture #Management #Leadership

Современные методы описания функциональных требований к системам (Writing Effective Use Cases) (Рубрика #Software)

Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.

К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.

На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.

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

1️⃣ User Story

A user story is a short, informal explanation of a software feature, written from the perspective of the end user.

Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.

2️⃣ Jobs to be Done (JTBD)

Jobs to be Done is a framework that helps product teams understand what job a customer is hiring a product to do — what problem, challenge, or opportunity is so important to them that they're willing to hire your product to address it.

JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.

3️⃣ Job Story

An exciting alternative for some teams is the job story. A job story is focused less on the user performing some function than on the job to be done by that story.

Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.

4️⃣ Design Thinking

Design thinking is a problem-solving approach that focuses on understanding users’ needs and creating innovative solutions.

Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.

В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes

🇨🇳 Китай строит «ИИ‑вертикаль» в образовании: от детсада до университета (Рубрика #AI)

В Forbes (12.01.2026) сделали разбор, как КНР делает ИИ массовым образовательным инструментом. По ощущениям инженера/CTO: это программа уровня платформы с регуляторикой и KPI. Собственно тезисы статьи примерно такие

🧭 Какие меры принимаются
1. Стратегия и дорожная карта
- «План развития ИИ нового поколения» (2017) с вехами 2020 → 2025 → 2030.
- Образование - ключевой полигон: после «Education Informatization 2.0» (2019) - десятки документов по AI‑in‑education; цель - к 2030 ИИ как повседневный инструмент во всех школах.
2. Масштабирование через пилоты
- В феврале 2024 Минобр КНР выбрал 184 пилотные школы/площадки для ИИ‑образования (эталонные практики для тиражирования).
3. «ИИ с пелёнок»: контент + инструменты
- Детсад: разовые занятия/игры с роботами‑ассистентами учителя.
- Начальная школа: учебники, где ИИ - «чудесный друг», далее - простые эксперименты/кейсы + этика.
- Средняя/старшая: виртуальные собеседники (пример - «Анна» для английского), персонализированное ДЗ, автопроверка части работ.
- Отдельно: ИИ‑поддержка обучения детей с РАС (адаптация темпа по эмоциям/состоянию).
4. Высшая школа: расширение кадров + участие BigTech
- В списке бакалаврских направлений (04.2025) - 845 AI‑связанных треков (29 новых); около 620 вузов предлагают бакалавриат «Искусственный интеллект».
- BigTech открывают лаборатории/институты и свои академии (Alibaba, ByteDance, Tencent, Huawei и др.).
5. Регулирование и академическая честность
- Китайская академия наук (09.2024): где ИИ допустим (поиск/структурирование, правка, перевод, графики) - и что запрещено; нужна маркировка/декларация и выбор «зарегистрированных» сервисов.
- Вузы вводят локальные правила (пример: Фудань - только «некреативные» задачи, с согласованием у научрука).

📈 Что видно по результатам (цифры из статьи)
- 1‑я половина 2025: 515 млн пользователей ген‑ИИ (36,5% населения).
- 83% в Китае считают, что у AI‑продуктов/сервисов больше плюсов, чем минусов.
- Зарегистрированные ИИ‑разработки: 117 (04.2024) → 801 (08.2025), +585%.
- Внедрение по регионам неравномерно: местами остаётся «просто цифровизация».
- Автопроверка не идеальна: в 2024 Zuoyebang на задачах уровня гаокао набирала <4/5.

⚠️ Обратная сторона
- AI‑плагиат и разрыв «домашки vs знания» (высокие баллы за письменное, слабое устное).
- Риск непроверенной/сгенерированной информации в науке и падение критического мышления - отсюда рост правил и контроля.

🧩 Насколько реально повторить вне Китая
Повторяемо
- Пилоты + измеримые метрики эффекта (успеваемость, нагрузка учителя, вовлечённость).
- Возрастной AI‑curriculum + этика/верификация.
- ИИ в рутину, но human‑in‑the‑loop на критичных точках.
- Политики «что можно/нельзя» + изменение формата оценивания (устное/практика/проекты).

Труднее
- Супер‑масштаб и скорость централизованной модели + единая инфраструктура/регуляторика.
- «Навязывание стандарта» (например, обязательность локальных/зарегистрированных сервисов).

#AI #ML #Education #Kids #Software #ML #Economics

Оливер Хьюз - про уход из Tinkoff Bank, Узбекистан и бизнес (Рубрика #Management)

Интересно было посмотреть интервью Оливера Хьза в подкасте Alter Ego, что вышел 14 января 2026. Оливер долго работал в Т, а потом ушел в TBC отвечать за рост и международный бизнес, включая тот, что в Узбекистане (собственно, подкаст Alter Ego как раз отсюда). Оливера всегда интересно слушать, но в этот раз интересно было интересно послушать рефлексию про его опыт, отъезд из России и новые вызовы в Узбекистане. Тезисно можно забрать из этого рассказа следующее

1️⃣ Лидерство = дисциплина + открытость
Лидер обязан держать темп и форму - не ради статуса, а чтобы команда видела: “мы в одном окопе”. И второе - реально слушать идеи снизу. Не «я самый умный», а «давайте найдём лучший ход».

2️⃣ Любовь важнее уважения
Провокационно, но точно: уважение легко превращается в дистанцию, а “любовь” - это когда люди с тобой, потому что “мы вместе в этом”. Его стиль - маленькая “d”-демократия: минимум рангов, максимум совместной ответственности.

3️⃣ Культура важнее стратегии
Стратегия - это roadmap, который устаревает быстрее, чем вы закрываете Q1. Культура - ваш runtime: как вы принимаете решения, спорите, меряете, учитесь и адаптируетесь. Фаундеры задают стартовую конфигурацию, дальше появляются подкультуры - и культурой нужно управлять осознанно, как системой.

4️⃣ Люди vs система - ложная дихотомия
Сильные люди без процессов не вывозят масштаб. Процессы без сильных людей не едут вообще. Модель TBC у него звучит просто: «сильные люди внутри понятной системы» (данные, процессы, IT-фундамент). Самое честное: собрать консистентную систему на масштабе адски сложно - всегда будут разрывы, где одна часть бизнеса убежала, а другая догоняет.

5️⃣ Скорость важна, но выигрывает качество
Оливер выбирает “быть лучшим”, а не “быть первым”. Early adopters (5–10%) дадут шум и фидбек, но бизнес - это следующие ~70%, которые покупают стабильность и качество. И да, он сам “поздний адоптер” - успех не требует быть техно-евангелистом первой волны.

6️⃣ Скепсис к MVP (особенно в финсфере
MVP показывает только, что идея “не мертвая”. Реальное понимание приходит по когортам и часто через 12–18 месяцев. Месседж: не паниковать от первых метрик, а “допушивать и дотягивать” продукт.

7️⃣ Скейлинг - «ад каждый день» + две смертельные ошибки
Ошибки такие
- Растянуться быстрее возможностей (часто через долг)
- “Порваться изнутри”, когда компания расплывается и метрики поплыли, а вы поздно заметили.
Слишком быстрый рост, по его мнению, опаснее стагнации.

Отдельно были интересные факты про Узбекистан/TBC:21 млн уникальных пользователей и 5,7 млн MAU; кредитный портфель порядка $905 млн. И сильный AI-фокус: узбекоязычные LLM, on‑prem развёртывание, voice agents закрывают >40% ранней просрочки.

Если попробовать сократить тезисы до чеклиста самопроверки, то получим примерно следующее
- Опишите “runtime” команды: какие решения принимаем только через данные, какие через принципы.
- Проверьте, не держится ли скорость на героизме. Если да - вам нужна система.
- Меряйте продукт когортами, а не эмоциями первой недели релиза.
- Инвестируйте в качество как в долгосрочный moat.

#Leadership #Management #Economics

Сайт по system design (Рубрика #Architecture)

Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.

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

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Техкомьюнити №1: выпуск про космос (#Engineering)

Посмотрел пилот нового подкаста Сбера «Техкомьюнити №1» - его делают инженеры для инженеров. Ведёт Кирилл Меньшов (SVP Сбера, блок «Технологии»), а в гостях - Алексей Шелобков, CEO «ИКС Холдинг» (там «Ядро» - российское ИКТ/железо, и «Бюро 1440» - частная космическая история). В первом выпуске разговор шел про "новый космос", что больше похож на IT: ребята обсуждали: distributed systems, связь, надёжность, апгрейды. Ниже ключевые тезисы

1️⃣ Почему «Бюро 1440» и откуда коммерческий «бум»
1440 - символическое число: столько оборотов вокруг Земли сделал первый спутник Королёва (запуск 4 октября 1957).
Сейчас космос уходит от чисто гос/научных программ к коммерческому low‑orbit. Драйверы понятные:
- AI и вечный голод по данным
- "Always online" для людей и бизнеса
- Цифровые гос/банк/логистика, которым нужен интернет «везде»
- Автономный транспорт/логистика, где связь вне городов - не “nice to have”, а must.

2️⃣ «Старый» vs «новый» космос - как мэйнфрейм vs облачный дата-центр
Старый подход (геостационар):
- Один супернадёжный аппарат на 10–15 лет;
- Спец. радиационно-стойкая схемотехника;
- Долгие циклы и цена уровня «мэйнфрейма».

Новый подход (низкие орбиты):
- Спутник = нода в кластере (умер - неприятно, но не конец света);
- Надёжность даёт избыточность группировки + быстрые замены;
- Серийное производство и регулярные обновления (почти rolling upgrade).

3️⃣ Спутник сегодня - это базовая станция + роутер + автономный робот
Низкоорбитальный аппарат - "летающая базовая станция" и умный коммутатор одновременно:
- Uplink/downlink к абоненту + межспутниковые каналы (лазеры);
- На борту непрерывно считаются положение/ориентация (звёздные датчики + данные с Земли), крутятся контуры управления, коррекция орбиты, наведение лазерных линий
- Тестовые запуски 2023–2024 - чтобы вживую проверить модели и стандарты связи, в т.ч. 5G‑NTN.

4️⃣ Боли: энергия/тепло, latency, безопасность
- Edge computing “прямо на спутнике” пока сомнительно: мощность дорогая, а тепло в вакууме отводить - отдельный вид спорта.
- "Орбитальные дата-центры" звучат красиво, но упираются в КПД солнечных панелей и деградацию аккумуляторов.
- Latency: LEO даёт десятки миллисекунд - уже ок для realtime. А вот >300 мс - и живое общение становится мучением.
- Кибербезопасность: 100% защиты не бывает, поэтому важнее архитектура под резервирование и быстрое восстановление после сбоев/атак (resilience > "неуязвимость").

5️⃣ Практика и планы
Про РФ: чтобы покрыть страну, звучала оценка ~250 аппаратов, целевой горизонт - 2027. Идея - закрыть «белые пятна» даже в освоенных регионах и на длинных магистралях
Про глобальный рынок к 2029:
- «Околоземная экономика» может вырасти примерно с ~$600B до $1.8T за 7–8 лет;
- Сети будут срастаться: 5G‑NTN → 6G‑NTN, где связь станет реально «бесшовной»;
- Терминалы станут меньше, и в устройствах будет больше интеграции: связь + точное позиционирование.

6️⃣ Про инженеров: без гибрида "классика + IT" не поедет
Нужен микс: фундаментальная инженерия (системность, высокая цена ошибки) + IT‑культура (скорость, итерации, нормальное отношение к ошибкам).
Из цифр: у ИКС/«Ядра» - ~25 магистерских программ с вузами

Советы молодым инженерам:
- Найти трек, который реально драйвит
- Пробовать разные области и собирать T-Shape
- Качать soft skills наравне с hard
- Метанавык №1 - быстро учиться и адаптироваться

«Тёмная лошадка» по технике - гибридные штуки вроде нейроинтерфейсов + (возможно) новые открытия в физике, которые потом внезапно сделают “sci‑fi” рабочей реальностью.

7️⃣ Партнёрства
В конце обсудили, что стратегическим партнёрам пора уходить от модели «заказчик‑поставщик» к совместному R&D: общие команды, гипотезы, эксперименты и «мечты о будущем», где каждая сторона приносит свои суперсилы.

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

#Engineering #Leadership #AI #Space #Software #RnD

Head First. Паттерны проектирования (Head First. Паттерны проектирования) (Рубрика #Architecture)

Сегодня хотел вспомнить эту книгу про паттерны проектирования, которая вышла в серии Head First и выглядит как комикс:) Автор этой книги Эрик Фримен, экс-CTO Disney Online и один из создателей серии всей серии Head First.Сама книга вышла в середине 2000-х и быстро стала хитом среди разработчиков. В ней простым языком разбираются 23 классических шаблона проектирования. Авторы применили "визуально насыщенный формат, разработанный с учётом работы мозга", снабдив текст множеством иллюстраций, шуток и упражнений. Вместо сухой теории — живые примеры и головоломки. Уникальный стиль подачи сделал изучение паттернов увлекательным. Сравните эту подачу с классической "Паттерны объектно-ориентированного проектирования" от Gang of Four (Банды Четырех:)

Шаблоны в книге Head First объясняются на ярких метафорах из реальной жизни. Например, паттерн Стратегия иллюстрируется поведением разных уток 🦆, а паттерн Декоратор — добавками к базовому рецепту кофе ☕️. Такой подход помог читателям сразу увидеть практическую пользу шаблонов. Неудивительно, что книга уже помогла сотням тысяч разработчиков прокачать навыки проектирования.

Сейчас основные идеи книги остались такими же актуальными, хотя сами языки поменялись. Поэтому в 2019 году вышло обновлённое издание. Многие паттерны до сих пор в основе современного софта: одни встроены в языки (итераторы, наблюдатели событий), другие реализованы во фреймворках. Книга ценна и тем, что обучает базовым принципам ОО-дизайна (например, "программируйте на уровне интерфейсов, а не реализаций" и "предпочитайте композицию наследованию"). Эти идеи легли в основу более поздних правил вроде SOLID и не потеряли значимости.

Конечно, кое-что изменилось за годы. Некоторые классические приёмы сегодня реализуются иначе - например, Singleton всё чаще заменяют инъекцией зависимостей, а лямбда-функции упростили использование Strategy. Но сами концепции никуда не делись: понимание шаблонов по-прежнему помогает строить гибкую архитектуру и поддерживаемый код.

Если же в общем поговорить про развитие паттернов, то часть классических паттернов Gang of Four критиковалась экспертами за то, что многие из них лишь компенсируют ограничения языков. Так, Питер Норвиг выяснил, что 16 из 23 паттернов GoF фактически не нужны или упрощаются при реализации на Lisp. Но в то же время появились новые каталоги шаблонов для разных сфер. Шаблоны проникли на уровень архитектуры: от Enterprise Patterns для корпоративных систем, паттернов интеграции этих корп систем, и дальше до паттернов микросервисов для облачных сервисов. Сегодня инженеры широко применяют паттерны вроде API Gateway, Circuit Breaker и Event Sourcing - стандартные решения типовых проблем распределённых систем.

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

#Patterns #Software #SoftwareArchitecture #SoftwareDevelopment #Architecture #SystemDesign

[4/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

И зафиналим этим постом сравнительный разбор отчетов Octoverse за последние три года.

Помимо тройки лидеров (Typescript, Python Javascipt), отчёты отмечали рост интереса к системным языкам и языкам для работы с облачными технологиями.
- В 2023–2024 гг. заметно набирал популярность HashiCorp HCL (+36% за год) благодаря распространению Infrastructure-as-Code практик
- Язык Rust также демонстрировал высокие темпы (+40% в 2023) - его ценят за безопасность и производительность; Rust стал наиболее "любимым" языком по версии опросов разработчиков, а в 2024 продолжил рост за счёт использования в системном ПО и ядре Linux.
К 2025 году шесть языков фактически доминируют в новых репозиториях, покрывая ~80% проектов: это Python, JavaScript, TypeScript, Java, C++ и C#. Такой ландшафт указывает, что ИИ не заменил разработчиков (как некоторые опасались), но изменил их предпочтения и инструменты: сообщество адаптировалось, выбирая технологии, которые лучше сочетаются с ИИ-усилением разработки.

Если подводить итоги, то видно, что
- C 2023 по 2025 годы GitHub пережил рекордный приток новых разработчиков и проектов, во многом стимулированный распространением ИИ
- Open-source сообщество активно приняло ИИ-инструменты: к 2025 году они рассматриваются как неотъемлемая часть работы, повышающая продуктивность и позволяющая разрабатывать больше программ быстрее.
- Количество проектов, связанных с ИИ, выросло на порядки, а языковой ландшафт начал смещаться в сторону технологий, максимально эффективных при поддержке ИИ (это важный тренд и я думаю, что это будет происходить и внутри больших компаний).
- При этом общий тренд позитивный: данные GitHub показывают, что приток ИИ-инструментов не ухудшил качество вкладов или здоровье open-source сообщества - напротив, разработчики стали сотрудничать ещё активнее, осваивать новые области (AI/ML) и вместе двигать экосистему вперёд.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

CS230: Deep Learning от Stanford (Рубрика #AI)

Начал смотреть лекции с курса CS230 про глубокие нейронные сети от Стэнфорда за 2025 год и пока мне все нравится. В курсе два преподавателя
- Andrew Ng - основатель DeepLearning.AI и сооснователь Coursera, экс-главный ученый Baidu, основатель Google Brain
- Kian Katanforoosh - CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai
В курсе интересная структура - студенты смотрят лекции онлайн (из Deep Learning Specialization на Coursera), а очные занятия посвящены практическим разборам, дискуссиям и работе над проектами (собственно это можно видеть в лекциях на Youtube, что следуют за первой вводной).

Стурктура курса примерно такая

1️⃣ Основы нейросетей и Deep Learning
- Построение нейросети с нуля на Python (без фреймворков!)
​- Понимание внутреннего устройства, а не просто использование TensorFlow/PyTorch

2️⃣ Hyperparameter Tuning и оптимизация
Ng откровенно признается: "Каждый мой PhD-студент просиживал до 2-3 часов ночи, подбирая гиперпараметры". Навык быстрой настройки может сэкономить вам часы работы — разница между отладкой в 3 утра и в 7 утра.

3️⃣ Стратегии построения ML-проектов
Критически важно для инженеров:
- Как принимать системные решения в сложных проектах (распознавание лиц, security systems)
​- Дисциплинированный процесс разработки: разница между завершением за дни vs месяцы
​- Когда НЕ нужно собирать больше данных или покупать GPU (частая ошибка бизнеса)
​- Реальный пример из лекции: Ng рассказывает о встрече с CTO крупной компании, который купил кучу GPU и дал племяннику-студенту бюджет "делать AI". Без стратегии это пустая трата денег.
​
4️⃣ Convolutional Networks (Computer Vision)
Специализированные модели для работы с изображениями и видео.

5️⃣ Sequence Models и Transformers
- Работа с временными рядами и текстом
​- Архитектура Transformer - основа GenAI революции

Если говорить про интересные моменты именно первой лекции, то они такие

🔥 Почему Deep Learning доминирует
Ng объясняет через простую визуализацию:
​- Традиционный ML: производительность выходит на плато при увеличении данных
- Deep Learning: продолжает улучшаться с масштабированием данных и моделей
- Scaling Laws: производительность предсказуема - можно заранее рассчитать, сколько GPU купить для достижения целевой точности
​
🛠 Когда использовать Deep Learning vs GenAI
Промптинг LLM отлично работает для:
​- Текстовых задач
- Прототипирования ($20-100/месяц приемлемо)
Deep Learning нужен когда:
​- Промпты месяц не дают результата
- AI-биллинг становится слишком дорогим (с ростом пользователей)

🎯 Работа с аудио, изображениями, видео, структурированными данными
- Fine-tuning под специфичные задачи
- Цитата Ng: "Многие наши счета от LLM-провайдеров были действительно захватывающими. Не хочу называть цифры, но это значительно больше, чем мы хотели платить".
​
📊 Иерархия AI-навыков
CS Fundamentals (базис) -» Machine Learning (работа с данными) -» Deep Learning ← (курс CS230 здесь) -» Generative AI (Transformers, LLMs)
Ng подчеркивает: понимание CS-фундаментов критично даже при использовании AI-ассистентов кода (Cursor, Copilot).

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

#Software #ML #AI #Engineering #Architecture

[3/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

Продолжим сравнительный разбор отчетов Octoverse от GitHub темой developer productivity.

Влияние ИИ на продуктивность и процессы разработки
- В 2023 году подавляющее большинство разработчиков верило, что ИИ-инструменты улучшат эффективность командной работы, удовлетворённость и продуктивность. 81% респондентов считали, что ИИ-средства повышения кода сделают команды более сплочёнными, облегчат сотрудничество.
- В 2024 году Octoverse привёл конкретные данные о влиянии Copilot на работу. Предыдущее исследование показало до +55% роста продуктивности при решении задач у разработчиков, использующих ИИ-помощник. В самом отчёте отмечена корреляция: те, кто регулярно пользуется Copilot, демонстрируют большую активность на GitHub. Например, среди активно работающих на платформе разработчиков, применяющих Copilot, объём видимой работы (коммиты, пул-реквесты и т.д.) примерно на 12–15% выше (для ежедневно активных) по сравнению с их коллегами без ИИ. Это напрямую подтверждает и количественно, и по субъективным ощущениям, что ИИ-инструменты экономят время и увеличивают результативность разработки. При помощи ИИ инженеры успевают решать больше задач за единицу времени.
- В 2025 году влияние ИИ проявилось не только в количестве кода, но и в быстроте его доставки и исправления проблем. Благодаря новым функциям (например, Copilot Autofix) разработчики стали устранять уязвимости в коде значительно быстрее. По данным GitHub, автогенерируемые исправления снижали время на фиксы безопасности в разы: некоторые баги (SQL-инъекции, XSS) устранялись в 3–12 раз быстрее по сравнению с ручным исправлением (минуты вместо часов). Автоматизация обновлений зависимостей через Dependabot тоже стала нормой (разработчики сливают всё больше auto pull requests, ускоряя закрытие уязвимостей). В совокупности, 2025 год продемонстрировал рекордный объём выпусков: за месяц сливалось более 43 млн PR, а за год выполнено почти 520 млн слияний pull requests. Такой масштаб работы стал возможен во многом благодаря росту эффективности с ИИ.

Сдвиги в популярности языков под влиянием ИИ
Ежегодные отчёты Octoverse фиксируют заметные перемены в рейтинге языков программирования, связанные в том числе с влиянием ИИ.
- В 2023 году JavaScript сохранил звание самого популярного языка на GitHub, однако TypeScript стремительно набирал долю - впервые обогнав Java и заняв 3-е место по используемости в open-source (рост сообщества TS +37% за год)
- По итогам 2024 года Python вышел на первое место, обогнав JS. Этот сдвиг связывают с бумом анализа данных и машинного обучения на GitHub: Python доминирует в сферах AI/ML, научных вычислений, образования, что и подтолкнуло его на вершину. Одновременно отмечен всплеск популярности Jupyter Notebook на 92% – знак притока на GitHub специалистов по данным и исследователей.
- В 2025 году произошёл беспрецедентный сдвиг: TypeScript впервые стал языком №1 по количеству разработчиков на GitHub, обойдя и Python, и JavaScript. По данным отчёта, это крупнейшая перемена в рейтинге языков за десятилетие. Главная причина - влияние ИИ и «агентов» на выбор технологий. Типизированные языки вроде TS дают более надёжные подсказки и код при использовании ИИ-инструментов, особенно в production-системах. Разработчики переориентируют свой стек в пользу TypeScript, поскольку автодополнение и генерация кода работают точнее при строгой типизации. К тому же практически каждый современный фронтенд-фреймворк (React, Next.js и др.) теперь по умолчанию предлагает TypeScript, а не JavaScript. Важно: хотя TS вышел на первое место, экосистема JS/TS в целом продолжает доминировать (вместе они всё ещё генерируют активности больше, чем один Python). При этом Python остаётся безоговорочным лидером для проектов в области ИИ, анализа данных и научных исследований - эти области продолжили интенсивно расти на платформе.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

AI Engineering Interviews (Рубрика #AI)

Наткнулся тут на новую книгу от издательства O'Reilly, которая сейчас находится в процессе написания и будет готовва к декабрю 2026 года. Но ее уже можно начинать читать на платформе, где доступны три главы Prompt Engineering, Machine Learning Foundations и Transformer Architecture. Аннотация книги говорит о том, что это руководство будет включать 300 реальных вопросов с интервью, которые помогут вам подготовиться к собеседованиям и проведет через все этапы интервью, предлагая инсайдерский взгляд, который поможет обрести уверенность и выделиться среди других кандидатов:)

Для каждого вопроса даётся чёткое описание того, каким должен быть хороший ответ, указаны распространённые ошибки, которых стоит избегать, и ключевые моменты, которые нельзя упустить. Книга выгодно отличается тем, что Мина Гашами и Али Торкамани умеют упрощать сложные концепции, превращая их в интуитивно понятные объяснения и дополняя наглядными иллюстрациями, делающими обучение увлекательным. Авторы обещают научить
- Уверенно проходить собеседования по GenAI - от базовых до продвинутых ролей
- Разбирать 300 реальных вопросов из индустрии с примерными ответами и подробными пояснениями
- Пошагово объяснять архитектуру, обучение, инференс и оценку моделей
- Получать практические инсайты, которые помогут выделиться даже в самых конкурентных процессах найма

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

#AI #Interview #ML #Careeer

[2/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

Продолжим сравнительный разбор этих отчетов от GitHub обсуждение AI:)

Проекты с искусственным интеллектом
Здесь можно говорить про рост количества и проникновения.
- В 2023 году был дан взрывной старт ИИ-проектов. Количество проектов, связанных с генеративным ИИ, увеличилось на 248% по сравнению с 2022 годом. Уже к середине 2023-го число новых репозиториев с генеративным ИИ превысило итоговое значение всего 2022 года. Впервые такие проекты вошли в топ-10 самых популярных репозиториев по числу контрибьюторов (например, Stable Diffusion и LangChain). Кроме того, 2023 год стал переломным: open-source разработчики активно экспериментировали с моделями (OpenAI и другие), что выдвинуло ИИ-проекты из исследовательской ниши в мейнстрим. Число разработчиков, участвующих в генеритивных ИИ-проектах, выросло на 148% за год.
- В 2024 волна ИИ в разработке продолжила нарастать. На GitHub к концу 2024 г. насчитывалось около 137 000 публичных проектов, связанных с генеративным ИИ - почти двукратный рост (+98%) год к году. Объём вкладов в такие проекты тоже резко вырос: число совокупных contributions в ИИ-репозитории увеличилось на 59% по сравнению с предыдущим годом. Интересно, что 6 из 10 самых быстрорастущих open-source проектов по количеству контрибьюторов в 2024 году были связаны с инфраструктурой ИИ (модели, оркестрация, оптимизация). Это свидетельствует, что сообщество всё активнее вовлекается в разработку ИИ-инструментов, выходя за рамки одной лишь генерации кода.
- В 2025 ИИ-проекты уверенно перешли в категорию массовых. Всего на GitHub к 2025 г. насчитывалось ≈4,3 млн репозиториев, помеченных как связанные с ИИ (учитывая и приватные). Из них более 1,1 млн публичных репозиториев используют SDK больших языковых моделей (LLM), причём 693 тыс. таких проектов были созданы всего за последний год (+178% по сравнению с августом 2024). Другими словами, почти каждый четвёртый новый репозиторий в 2025 содержал ИИ/ML-компоненты. Более того, 60% из топ-10 самых популярных open-source проектов 2025 года (по числу участников) имеют ИИ-фокус.

В итоге можно сделать вывод о том, что с 2023 по 2025 год ИИ прошёл путь от экспериментального тренда до неотъемлемой части экосистемы разработки.

Внедрение ИИ-инструментов среди разработчиков
- В 2023 году 92% разработчиков так или иначе пробовали инструменты с ИИ для программирования (например, GitHub Copilot). Это указывает на почти полное проникновение ассистентов на базе ИИ в рабочие процессы разработчиков по всему миру. Кроме того, почти треть всех open-source проектов со звёздами на GitHub имела хотя бы одного мейнтейнера, использующего GitHub Copilot. GitHub предоставил бесплатный Copilot для поддерживающих OSS мейнтейнеров, и многие воспользовались этим: ИИ-автодополнение кода стало повсеместным помощником в open-source сообществе. Кажется, что это проникновение обусловлено тем, что Copilot был встроен в сам GitHub:)
- В 2024 году GitHub отметил, что более 1 000 000 студентов, преподавателей и open-source разработчиков воспользовались Copilot через бесплатную программу для образования и OSS. За год число таких пользователей выросло на 100%. В общем, ребята продолжили работать над расширением охвата Copilot внутри GitHib и начали прививать его новичкам с первых их дней на платформе.
- Выпуск GitHub Copilot Free в конце 2024-го привёл к заметному скачку регистраций и активности на платформе. В результате в 2025 году новые пользователи практически сразу начинают работать с ИИ: 80% разработчиков-новичков включали Copilot в работу в первую же неделю на GitHub. Иными словами, для нового поколения кодеров ИИ-ассистент стал ожидаемым по умолчанию инструментом. В итоге, в 2025 году почти каждый новичок сразу осваивает ИИ-кодогенерацию, закрепляя её роль как стандартной части рабочего процесса разработчика.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture