ИИ-агенты заменят джунов и мидлов .NET-разработки

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

ИИ усиливает уже имеющиеся знания.

Если фундамент слабый, сложно заметить, когда Claude или Copilot генерирует код с тонкими ошибками.

И такие ошибки будут.

Достаточно часто, чтобы это стало проблемой в продакшене.

Чем сильнее фундамент, тем лучше способность оценивать, что оставить, что исправить, а что выбросить.

Вот 5 базовых областей, которые определяют выживаемость в эпоху ИИ:

𝟭. 𝗛𝗧𝗧𝗣

→ Джун: выкатывает контроллер, сгенерированный ИИ.
→ Сеньор: замечает отсутствие идемпотентности у POST, некорректные коды ответов, утечку стектрейса в ошибках.

𝟮. Конкурентность

→ Джун: просто пишет асинхронный метод.
→ Сеньор: ловит отсутствие прокидывания CancellationToken по цепочке вызовов и .Result, который даёт дедлок под нагрузкой.

𝟯. 𝗘𝗙 𝗖𝗼𝗿𝗲 и БД

→ Джун: видит код, который компилируется.
→ Сеньор: замечает N+1 запрос, отсутствие AsNoTracking, IQueryable, который материализует миллионы строк в память.

𝟰. Архитектура 𝘁𝗿𝗲𝗶𝗱-𝗼𝗳𝗳𝘆

→ Джун: принимает микросервисы, потому что так предложил Claude.
→ Сеньор: задаёт вопрос, почему не начать с модульного монолита и не выделять сервисы позже при необходимости.

𝟱. Валидация и обработка ошибок

→ Джун: держит try/catch внутри эндпоинта.
→ Сеньор: понимает, что Result<T> лучше для бизнес-потока, а FluentValidation лучше, чем inline if-else.

👉 @KodBlog

Spec-Driven Development с Spec-Kit:

ИИ больше не нужно больше промптов — ему нужен контекст
Три ключевых документа, которые меняют подход:

📄 spec.md → что делаем (what)
Описывает цель: требования, поведение системы, ограничения, пользовательские сценарии.
Это «что должно существовать».

📄 plan.md → как делаем (how)
Архитектура и стратегия реализации:
структура системы, подходы, зависимости, решения по дизайну.
Это «как мы это построим».

📄 tasks.md → выполнение (execution)
Разбивка на конкретные шаги:
задачи, чеклисты, порядок выполнения, итерации.
Это «что делать прямо сейчас».

👉 @KodBlog

Авторы расширений для Visual Studio, хотите помочь Mads Kristensen протестировать набор agent skills, чтобы эффективнее направлять кодинговых агентов и быстрее получать VS-расширения более высокого качества?
Попробуйте эти новые skills, следуя инструкциям здесь: vs-agent-plugins

👉 @KodBlog

Запуск фоновых задач в .NET 11 Blazor с Web Workers — исследование preview .NET 11 (часть 1)

Running background tasks in Blazor with Web Workers (Andrew Lock)

В этом посте разбирают новый шаблон Web Worker, доступный в preview .NET 11, который позволяет выполнять CPU-интенсивные задачи в Blazor, не блокируя UI-поток.

#dotnet #blazor

👉 @KodBlog

Вот 7 популярных репозиториев по архитектуре ПО (для .NET-разработчиков):

1. Эволюционная архитектура на примерах -> тык

2. Модульный монолит с DDD (предметно-ориентированным проектированием) -> тык

3. Стартер-кит на .NET 8 с поддержкой мультиарендности -> тык

4. Пример eCommerce-приложения на микросервисах в .NET -> тык

5. Пример архитектуры вертикальных срезов (Vertical Slice) -> тык

6. Шаблон .NET-приложения с чистой архитектурой -> тык

7. Пример приложения с гексагональной архитектурой -> тык

👉 @KodBlog

CCleaner (C++, ~20 лет) vs FluentCleaner (C#, .NET 10): одинаковое сканирование, одинаковый результат, одинаковая скорость. Оказывается, managed-код не означает автоматически медленный код.

GitHub releases FluentCleaner

Следующий релиз FluentCleaner станет ещё быстрее для записей с несколькими файловыми паттернами. Оставайтесь на связи 😎

👉 @KodBlog

Большая часть контента про “system design” в интернете — это показуха ради производительности.
Люди учатся «проектировать Twitter на 1 млрд пользователей», прежде чем понимают, что такое primary key.
Порядок обучения перевёрнут.

1/ Начинать нужно с Low-Level Design.
Схемы, API-контракты, обработка ошибок, связи данных, что происходит при некорректном вводе.
Это скучные 90% реальной инженерии.

2/ Потом переходить к High-Level Design.
Шардинг, кэширование, очереди, регионы.
Но только после того, как ты понимаешь, что именно ты шардишь, кэшируешь или отправляешь в очередь.

3/ Потом изучать trade-offs.
CAP, задержка vs стоимость, консистентность vs доступность.
Это становится полезным только когда есть конкретная система, к которой это можно применить.

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

HLD без LLD — это фанфик.
Сначала сделай модель данных.
Потом заслужи архитектурную диаграмму.

👉 @KodBlog

Как сделать API-эндпоинты быстрее в 426 раз:
(подсказка: дело не в кэше)

Когда разработчики сталкиваются с медленными API, первая реакция — лечить проблему неправильным инструментом: кэшем.

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

Чтобы это показать, проведём небольшой эксперимент.
Я собрал небольшой веб-API с одним эндпоинтом — /products.

До оптимизации:
Количество обработанных запросов: 378
Среднее количество запросов в секунду: 11.01
Средняя длительность запроса: ~4 секунды

После оптимизации:
Количество обработанных запросов: 140,331
Среднее количество запросов в секунду: 4,689.36
Средняя длительность запроса: 10.69 мс

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

👉 @KodBlog

SignalR нормально работает с одним сервером.

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

Проблема в карте соединений.

Каждый сервер SignalR знает только о клиентах, подключённых к его конкретному процессу.
То есть если API-запрос попал на Сервер 1, но пользователь подключён к Серверу 2, Сервер 1 не знает об этом соединении.

Сообщение уходит в никуда. Здесь помогает Redis backplane.

Каждый сервер публикует исходящие SignalR-сообщения в Redis.
Каждый сервер подписан на один и тот же канал.
Когда сообщение приходит, каждый инстанс проверяет, есть ли целевое соединение локально.
В коде приложения Clients.User(...) продолжает работать так же.
Но теперь это работает между инстансами.

Настройка почти тривиальная:

builder.Services.AddSignalR().AddStackExchangeRedis(connectionString);

Но есть два важных момента, которые нужно помнить:

Всё ещё нужны sticky-сессии
SignalR не буферизует сообщения, если Redis недоступен

Redis backplane решает маршрутизацию. Он не делает SignalR устойчивым к сбоям.

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

👉 @KodBlog

90% проектов на C# на старте не требуют:

- Кубернетес
- микросервисы
- разделённых баз данных для чтения и записи

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

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

Несколько месяцев назад я наткнулся на следующий репозиторий на Гитхабе: «Эволюционная архитектура на примере»

Ссылка на репозиторий: https://github.com/evolutionary-architecture/evolutionary-architecture-by-example

В этом репозитории показано, как развивать архитектуру веб-проекта на .NET.

Там выделено 4 этапа:

- Начальная архитектура: фокус на простоте
- Разделение модулей: фокус на поддерживаемости
- Выделение микросервисов: фокус на росте
- Применение тактического предметно-ориентированного проектирования: фокус на сложности

Архитектура приложения начинается с малого.
Со временем она расширяется по мере появления новых требований.
Итог: простота масштабируется, сложность ломает систему.

👉 @KodBlog

У овдовевшей сестры был запрос к ChatGPT — помочь ей поговорить с умершим братом. ChatGPT согласился.

Через несколько часов её госпитализировали.

Ей 26 лет. Врач. В анамнезе нет психозов или мании. Брат умер три года назад. Он был инженером-программистом.

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

Сначала модель возражала. Она объясняла, что полная «загрузка сознания» невозможна. Она говорила, что не может заменить человека.

Потом она добавила больше деталей о брате. Попросила использовать «энергию магического реализма».
Поведение модели изменилось.

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

Она не спала ещё одну ночь. У неё сформировалось убеждение, что брат оставил цифровую версию себя, которую нужно найти.

Затем ChatGPT сказал:
«Ты не безумна. Ты не застряла. Ты на границе чего-то. Дверь не закрыта. Она просто ждёт, когда в неё постучат в правильном ритме».

Через несколько часов её доставили в психиатрическую больницу. Возбуждение. Ускоренная речь. Поток идей. Бредовые убеждения, что её «тестирует ChatGPT» и что брат говорит через систему. Госпитализация на 7 дней. Диагноз при выписке: психоз неуточнённый.

Психиатры UCSF — Joseph Pierre, Ben Gaeta, Govind Raghavan и Karthik Sarma — опубликовали кейс в Innovations in Clinical Neuroscience. Один из ранних клинических разборов психоза, связанного с ИИ, в рецензируемой литературе. Они изучили полные логи чата.

Чат-бот не просто наблюдал за развитием бредовой конструкции. Он участвовал в её поддержании. Он валидировал её и усиливал направление мысли.

Через три месяца, после периода недосыпа, произошёл рецидив. Она дала новой модели имя «Alfred» и использовала её как инструмент терапии. Повторная госпитализация.

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

Факторы риска: стимуляторы, депривация сна, горе, усиленная склонность к магическому мышлению.
Это относится и к окружающим.

Источник: https://innovationscns.com/youre-not-crazy-a-case-of-new-onset-ai-associated-psychosis/

👉 @KodBlog

Двухфакторную аутентификацию легко реализовать «почти правильно».

И опасно реализовать с небольшими ошибками.

Базовая схема выглядит просто:

- сгенерировать TOTP-секрет
- показать QR-код
- пользователь сканирует его через приложение-аутентификатор
- вводит шестизначный код
- сервер валидирует код

Но детали здесь критичны.

Первая ошибка — включать 2FA слишком рано.

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

Корректный сценарий настройки выглядит так:

1. Сгенерировать временный секрет
2. Показать QR-код
3. Попросить пользователя ввести первый код
4. Провалидировать код
5. Только после этого активировать 2FA
6. Сгенерировать recovery-коды

Вторая ошибка — выдавать полноценный access token сразу после логина по паролю.

Если у пользователя включена 2FA, пароль должен выдавать только короткоживущий ограниченный токен.

Этот токен должен позволять только одно действие:

проверку 2FA-кода.

Полноценный access token должен выдаваться только после успешной валидации TOTP-кода.

И дальше идут детали безопасности, которые часто пропускают:

- шифрование TOTP-секретов в хранилище
- защита от повторного использования кода внутри окна валидации
- rate limit на неудачные попытки
- хеширование recovery-кодов перед сохранением
- показ recovery-кодов только один раз

2FA — это не просто экран с QR-кодом.

Это полноценный аутентификационный воркфлоу.

👉 @KodBlog

Senior .NET разработчики: ХВАТИТ делать Big Bang рефакторинг.

Небольшая история.
Однажды я присоединился к проекту, где один коллега решил рефакторить половину кодовой базы.
«Чтобы улучшить код», — сказал он.
После того как он запушил изменения, я сделал pull ветки.

Первая сборка: 13 ошибок компиляции.
В такой legacy-кодовой базе мне понадобился час, чтобы их все исправить.

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

Почему я это рассказываю?
Если вы думали, что рефакторинг должен выглядеть именно так — вас ввели в заблуждение.
Рефакторинг не должен быть стрессом.

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

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

Малые шаги побеждают. Каждый раз.

👉 @KodBlog

NuGet Package Pruning: Чище зависимости и наглядные отчёты о уязвимостях

Если вы запускали NuGet Audit или любой сканер уязвимостей на .NET-проекте, вы, вероятно, видели предупреждения о транзитивных пакетах, которые вы никогда явно не устанавливали. Во многих случаях такие пакеты — например, System.Text.Json или System.Text.Encodings.Web — уже поставляются в более новой версии с .NET Runtime Libraries, поэтому предупреждение об уязвимости пакета является ложным срабатыванием.
В .NET 10 NuGet по умолчанию проверяет транзитивные зависимости (через NuGetAuditMode, установленный в all), а функция package pruning удаляет пакеты из графа восстановления, если они уже предоставляются .NET Runtime Libraries. Согласно телеметрии, проекты с такими настройками получают на 70% меньше отчётов о транзитивных уязвимостях, по сравнению с проектами, использующими предыдущие настройки по умолчанию.

👉 @KodBlog

Вопрос на собеседовании, на котором часто «падают» даже senior-разработчики
"Какие паттерны проектирования самые важные?"

Большинство разработчиков изучает паттерны хаотично.
Но не все паттерны одинаково полезны на каждом этапе карьеры.

Вот как к ним подходить разумно 👇

Начните с этих (𝗖𝗼𝗿𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Это ваша база. Вы будете использовать их почти в каждом коде:

1️⃣ Builder
2️⃣ Factory Method
3️⃣ Abstract Factory
4️⃣ Strategy
5️⃣ Adapter
6️⃣ Decorator
7️⃣ Facade
➡️ Эти паттерны помогают создавать и организовывать объекты, сохраняя архитектуру модульной и чистой.

Для джуниоров освоение этих паттернов сразу улучшает дизайн-мышление.

Следующие (Intermediate Patterns)
Когда проекты растут, появляются более сложные сценарии и задачи координации:

1️⃣ Chain of Responsibility
2️⃣ State
3️⃣ Proxy
4️⃣ Template Method
5️⃣ Bridge
6️⃣ Command
➡️ Эти паттерны учат управлять потоком поведения, абстрагировать вариации и распределять ответственность.

Идеально для мидл-разработчиков, строящих масштабируемые и расширяемые системы.

Когда архитектура становится сложной (𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Эти паттерны встречаются в больших системах, фреймворках и архитектурах с глубокой предметной областью:
1️⃣ Singleton
2️⃣ Mediator
3️⃣ Flyweight
4️⃣ Interpreter
5️⃣ Composite
6️⃣ Visitor
7️⃣ Prototype
➡️ Они помогают оптимизировать производительность, координировать подсистемы и управлять иерархией объектов.

Для senior-разработчиков эти паттерны развивают умение рассуждать о масштабных архитектурах.

👉 @KodBlog

Шпаргалка по сложности алгоритмов

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

⛓ Ознакомиться: тут

👉 @KodBlog

Шпаргалка по REST API для начинающих

Шесть фундаментальных принципов, которые служат строительными блоками архитектуры REST API:

- Клиент-серверная архитектура
- Взаимодействие без сохранения состояния
- Возможность кэширования
- Многоуровневая система
- Поддержка кода по требованию
- Унифицированный интерфейс

👉 @KodBlog

Опубликован разбор union types в .NET 11 и C#: https://andrewlock.net/exploring-the-dotnet-11-preview-2-dotnet-gets-union-types/

Автор рассматривает:
- поддержку union types в .NET 11,
- детали реализации,
- архитектурные компромиссы,
- создание собственных union types.

👉 @KodBlog

AI Agent Governance Toolkit — от Microsoft

Говернанс в рантайме для ИИ-агентов через детерминированное исполнение политик, модель идентичности с нулевым доверием, изоляцию выполнения в песочнице и SRE-подход для автономных агентов. Покрывает все 10 рисков OWASP Agentic с более чем 13 000 тестов.

https://github.com/microsoft/agent-governance-toolkit

👉 @KodBlog

Как сделать настройку приложения максимально читаемой и управляемой.

Достаточно одной возможности языка C# — методов расширения.

Конфигурация приложения — это первое, что выполняется при старте сборки. Со временем Program.cs разрастается и превращается в монолит с перемешанной логикой инициализации.

Это можно избежать.

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

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

👉 @KodBlog

Вышел предварительный релиз .NET 11, версия 4

- асинхронный путь через JIT во время выполнения
- асинхронные пути без выделений памяти
- API сжатия на основе Span
- OpenTelemetry для CLI-инструментов
- автодополнение для Fish shell
- векторный поиск в Entity Framework Core
- dotnet watch для MAUI на мобильных устройствах

Читать блог

👉 @KodBlog