Якщо ви .NET-розробник і спостерігаєте за AI-хвилею збоку, бо в усіх туторіалах за замовчуванням пишуть на Python — ця стаття для вас. Я останній рік будував production AI-фічі в C# та TypeScript-бекендах, і чесний підсумок такий: ваші .NET-навички переносяться майже повністю. Стек переписувати не треба. Треба додати три конкретні вміння.
Ось шлях, який я спостерігаю в інженерів із типовим ASP.NET Core бекграундом.
Крок 0: що у вас уже є і це важливо
Перед списком того, що вчити, перерахую те, що перевчати не потрібно. Якщо ви пишете C# професійно, ви вже розумієте:
- Async/await і cancellation tokens — кожен виклик Claude API це long-running async операція, і нормальний cancellation — це різниця між робочим застосунком і рахунком на $5 000.
- Dependency injection і lifetimes — патерни для інжекту
HttpClientті самі, що й дляIAnthropicClient. - Сувора типізація — коли Claude повертає tool call, ви десеріалізуєте його в record. Ви це вже вмієте.
- Обробка помилок і стійкість — Polly, retry policies, circuit breakers. Для LLM-викликів потрібно все. Вони падають частіше, ніж HTTP API.
Інженери зі скриптових мов часто пишуть крихкий AI-код, бо пропускають ці патерни. Ви — ні, бо вони вже на рівні м’язової пам’яті.
Крок 1: опануйте сам Claude API (2–3 вихідних)
Перше, що треба засвоїти: «виклик LLM» — це не як виклик REST-ендпоінту. У Messages API своя ментальна модель: system prompts, стан багатоходового діалогу, визначення tools, streaming-відповіді та prompt caching для контролю вартості.
Що я рекомендую вивчати спочатку, по порядку:
- Основи Messages API — як структурований діалог, що реально означають
role: "user"таrole: "assistant"для стану, чому потрібно ехо-повертати попередні відповіді асистента. - Streaming-відповіді — більшість production-UX вимагає server-sent events; SDK робить це в C# просто, але тільки якщо ви розумієте chunking-модель.
- Prompt caching — головний важіль за вартістю. Зроблений правильно, він ріже API-витрати на 80%+ на навантаженнях зі стабільними system prompts.
- Tool use — визначення схем tools, обробка паралельних tool calls та відновлення, коли Claude галюцинує невалідний аргумент.
- Extended thinking — коли вмикати (складні багатокрокові міркування) і коли ні (дорого і повільно).
Якщо хочете структурований шлях через все це, курс Розробка на Claude API покриває кожну тему як production-патерн, а не іграшковий приклад. Навмисне language-agnostic — приклади на C# та TypeScript.
Крок 2: зберіть одну реальну річ end-to-end (1–2 тижні)
Читання документації — це не навчання. Найшвидший спосіб стати побіглим — зібрати одну невелику production-фічу. Мій улюблений перший проєкт для .NET-інженерів:
Агент «що блокує цей PR?». Даєте URL PR з GitHub. Він підтягує diff, читає CI-логи, резюмує root cause фейлу та пропонує фікс. Близько 200 рядків C#.
Змушує одночасно зіткнутися з усіма чотирма складними речами реальної AI-інженерії:
- Tool use (визначте
get_pr_diff,get_ci_logs,read_file) - Streaming-відповіді (користувач бачить аналіз у міру написання)
- Контроль вартості (швидко зрозумієте, навіщо prompt caching при повторному аналізі того самого PR)
- Обробка помилок (GitHub API rate-лімітитиме, CI-логи будуть по 500КБ, tools падатимуть)
Візьміть щось схожої форми зі своєї повсякденки — bug-triage агент для трекера команди, summarizer релізних нот, on-call помічник, що читає runbooks. Головне: річ має бути корисною настільки, щоб ви продовжили її покращувати після демо.
Крок 3: перехід до багатокрокових агентів (частина, яку більшість пропускає)
Більшість .NET-розробників зупиняються на «я викликав API і отримав відповідь». Це не агент — це chat completion. У справжнього агента є цикл: він викликає tool, читає результат, вирішує наступну дію та повторює до завершення.
Тут вмикаються архітектурні інстинкти, які у вас уже є від мікросервісів. Agent loop — це просто event-driven control flow з:
- обмеженим лімітом ходів (щоб не працював вічно)
- валідацією результатів tools (не довіряйте аргументам від LLM)
- керуванням пам’яттю (коли компактувати контекст, коли персистити?)
- делегуванням sub-agents (коли головний агент передає роботу спеціалісту?)
Патерни майже 1:1 лягають на те, що ви вже знаєте — saga orchestration, mediator pipelines, MassTransit consumers. Новизна не в архітектурі; вона в тому, що один з учасників недетермінований і час від часу вам бреше.
Якщо хочете концентрований шлях по дизайну агентів, evaluation і production-деплою — це зміст курсу Побудова агентів на Claude Agent SDK: agent loops, дизайн tools, evals, мульти-агентна оркестрація та шипінг без спалювання бюджету.
Що я б пропустив
Кілька речей, на які .NET-інженери марнують час:
- Свій RAG-pipeline з нуля. Використовуйте векторну БД (Qdrant, pgvector, Pinecone) і managed-сервіси там, де можна. Своє пишіть тільки якщо є compliance-обмеження.
- Повна автономність агентів від першого дня. Додавайте human-in-the-loop checkpoints. Скажете дякую, коли агент «корисно» відрефакторить 40 файлів.
- За замовчуванням найбільша модель. Sonnet нормальний для більшості production-задач. Opus — для складних міркувань. Haiku — для high-volume класифікації. Різниця у вартості накопичується.
Реалістичний таймлайн
Що я кажу інженерам, які питають, скільки займає такий перехід:
| Етап | Час | Результат |
|---|---|---|
| Прочитати доки Messages API, зібрати hello-world | 1 вихідні | Можете викликати Claude з C# |
| Додати tool use і streaming у реальний внутрішній інструмент | 1–2 тижні | Шипите щось корисне на роботі |
| Зібрати багатокроковий агент із обробкою помилок | 3–4 тижні | Можете спроєктувати AI-фічу на sprint planning |
| Production-рівень: evals, observability, контроль вартості | 2–3 місяці | Ви — той, у кого команда питає поради щодо AI |
Це у вільний час вечорами та вихідними. Повна зайнятість — ділите навпіл.
Кар’єрний кут, коротко
Якщо переживаєте, чи реальна AI-інженерія спеціалізація: реальна, але, ймовірно, не в тому сенсі, як ви думаєте. Робота — не «людина, що пише промпти». Робота — «інженер, здатний взяти розмиту продуктову вимогу, вирішити, чи підходить AI, спроєктувати систему навколо іноді падаючої LLM і зашипити, не розоривши компанію». Це архітектурний навик, не prompt-навик — і саме його .NET-інженери з backend-досвідом розвинуть найшвидше.
Почніть з API. Зберіть одну реальну річ. Потім переходьте до агентів.
Ви ближче, ніж думаєте.
Хочете структурований шлях? Почніть з Вступу до програмування на C#, якщо ви на початку кар’єри, або одразу з Розробки на Claude API, якщо вже знайомі з .NET. Капстоун — Побудова агентів на Claude Agent SDK — там усе збирається разом.
