Программирование *

Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы

У бэкенд-разработки есть неприятная особенность: большинство сложностей проявляется не в момент, когда пишется первый сервис, а позже — когда API начинает обрастать интеграциями, фоновые задачи конкурируют за ресурсы, поиск и хранилище требуют разных подходов к данным, а архитектурные решения внезапно начинают влиять на скорость разработки не меньше, чем качество кода.

В этой подборке — бесплатные демо-уроки от преподавателей-практиков про те части бэкенда, которые обычно и забирают больше всего времени в реальной работе. Это хороший способ посмотреть на чужой инженерный подход, познакомиться с экспертом, задать вопросы по своей ситуации и заодно закрыть конкретные пробелы: в API, тестировании, нагрузке, инфраструктуре, работе с данными и проектировании систем.

• 22 апреля 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript

• 22 апреля 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 23 апреля 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 23 апреля 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

• 28 апреля 20:00. Фоновые задачи в Django: работа с Celery

• 30 апреля 20:00. Поиск в базе знаний: где векторы ошибаются, а графы помогают

• 4 мая 20:00. Интерфейсы в Golang изнутри

• 5 мая 20:00. Postgres + JSON: реляционная мощь, документная гибкость

• 5 мая 20:00. Архитектурные решения в бэкенд-разработке

• 6 мая 19:00. Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ-команды

• 6 мая 20:00. Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI

• 7 мая 20:00. От кода до Kubernetes за полтора часа

• 7 мая 20:00. Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS

• 13 мая 20:00. Kafka Streams DSL

• 13 мая 20:00. ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой

• 14 мая 20:00. Взаимодействие с базой данных и миграции на Go

Полный список бесплатных уроков от преподавателей курсов по программированию, инфраструктуре и не только уже доступен в календаре мероприятий.

Как разработчикам монетизировать свои игры в 2026?

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

Традиционный подход подразумевает, что разработчик заключает договор с площадкой (Steam, VK Play, Itch и т.д.). Игрок покупает игру, и деньги идут на счёт платформы. После этого в определенные даты происходит выплаты на счета разработчиков за вычетом комиссий. Где-то больше, где-то меньше, где-то по-другому. Но смысл тот же. Этот подход позволяет, во-первых, брать комиссии, во-вторых, легче работать с возвратами и в-третьих, быстрее распознавать отмывание денег и мошенничество.

Мы решили использовать схему маркетплейсов, где каждый разработчик приходит со своим статусом (ООО, ИП, смз). Но приходит он в первую очередь не к нам, а к платёжным агрегаторам типа Юкасса, Робокасса, любая …касса. Одним словом, подключает себе интернет-эквайринг, такое делает любой банк. Банк ему даёт API для подключения, ID магазина, ключи для проведения оплат и всё, действуй.

Где здесь мы? Мы предоставляем бесплатный хостинг для игр. Сама площадка + страница игры + страница разработчика. Всё тоже самое что у itch[.]io. Заодно есть консоль разработчика, в которую добавляется всё больше и больше возможностей. Соответственно, в этой консоли разработчик указывает тот самый идентификатор магазина, суперсекретный ключ и дальше надеется на магию.

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

Опережу (почти) все вопросы и сразу отвечу:

Q: На что вы будете существовать если у вас комиссии 0%?

A: При покупке игры рядом есть еще кнопочка “поддержать платформу”, надеемся, что это сработает

Q: Вы делаете очередного убийцу стима?

A: Нет

Q: Это точно не развод?

A: Точно нет, чесслово

На остальные вопросы обязательно ответим. Так как это не реклама, то прямо указывать название площадки не буду, но подскажу, что наш канал https://t.me/dustore_official

Переосмысление библиотеки LDL.

Я полностью пересмотрел концепцию библиотеки LDL.

Что такое LDL?
Это графическая библиотека с единым API для всех систем как старых, так и новых.

Раньше я писал её на C++98, что давало хорошую портабельность. Но сейчас я пересмотрел многие тезисы, которые декларировал на GitHub, чтобы наконец добраться до первого релиза.

Новая стратегия

Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.

• Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.

• Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.

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

Лицензия и целевые платформы

• Лицензия меняется на LGPLv3.

• На старте поддерживаются Windows и Linux.

Качество и инструменты

При разработке использую:

• AddressSanitizer (ASan)

• UndefinedBehaviorSanitizer (UBSan)

• Различные анализаторы кода

Я считаю, что такая стратегия полезнее, чем годами доводить библиотеку до версии 1.0 в офлайн-режиме.

Примеры и бэкенды

• Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.

• Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.

• API остаётся единым для всех бэкендов.

Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.

 2D-рендер без границ

Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.

Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).

• Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.

• Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.

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

Философия: Машина времени в вашем коде

Зачем тратить силы на поддержку систем, которые многие считают «трупами»?

1. Борьба с цифровым забвением

Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.

2. Инженерный аскетизм

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

3. Преемственность поколений

Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.

Итог

LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.

Один API. Один код. Тридцать лет компьютерной истории.

30 беплатных уроков недели: AI, Spark 4.0, C++, REST API, Angular и Linux

Привет, Хабр. Собрали подборку ближайших бесплатных уроков, которые проведут преподаватели курсов Отус в преддверии старта новых курсов. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Выбирайте свою тему и присоединяйтесь.

20 апреля, понедельник:

• 20:00. Unit-тесты для iOS приложений, работаем над качеством изнутри

• 20:00. Качество данных (data quality) на практике: от технических метрик до внедрения в команде

• 20:00. От интерфейса до корзины: создаём мини интернет-магазин на языке JavaScript

• 20:00. Эффекты в Scala

• 20:00. Балансировка и геораспределение: как создать быстрое и надёжное приложение для всего мира

• 20:00. Менеджер в перегрузе: как выжить и не выгореть

21 апреля, вторник:

• 19:00. BPMN для 1С: Как правильно моделировать интеграции? (Разбираем 4 уровня детализации)

• 19:00. Значение корпоративной архитектуры для реализации стратегии цифровой трансформации

• 20:00. Функции в SQL: вычисления и переиспользование кода

• 20:00. Оптимизация запросов 1С

• 20:00. Архитектура мониторинга ИБ инфраструктуры на SIEM

• 20:00. Производительность кода на примере алгоритмов сортировки

• 20:00. Как BPMN помогает видеть узкие места

• 20:00. Архитектура Angular-приложения: как писать масштабируемый frontend

• 20:00. Связанные списки в ядре Linux: от API до реального кода

• 20:00. Использование BGP для маршрутизации IPv6

22 апреля, среда:

• 19:00. Основы балансировки нагрузки в Angie и Nginx

• 20:00. Бизнес-процессы CRM. Стандартные активити CRM

• 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript (Bun — современная среда выполнения JavaScript; ИИ — искусственный интеллект)

• 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 20:00. Делегирование без боли: как перестать быть “главным исполнителем” и не скатиться в микроменеджмент

• 20:00. Программируемые реле в АСУ ТП: гибкий инструмент для решения инженерных задач

• 20:00. Создание нейро-сотрудника на базе Telegram-бота и GPT: от регистрации до рабочего прототипа

23 апреля, четверг:

• 18:00. Cоздаём ИИ-ассистента для системного аналитика за 1 час

• 19:00. Интегрируем EDT в процессы непрерывной интеграции. Подключаем 1С к CI/CD

• 20:00. Что нового в Spark 4.0

• 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

27 апреля, понедельник:

• 20:00. Рисуем в формате онлайн модель процесса BPMN в Camunda Modeler

• 20:00. Настройка кластера Elasticsearch

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.

Пока везут в Zed нативный diff выделенных кусков кода, с подсветкой, преферансом и барышнями, мы будем пить то, что есть 😁

Скрипт намбер ван:

#!/bin/bash

FILE1="/tmp/clp.saved"

# xclip -o -selection primary > "$FILE1"
wl-paste --primary > "$FILE1"
notify-send "Diff" "Первый фрагмент сохранён"

вешаем на одно сочетание клавиш (у меня, например, для удобства, Alt+Shift+1)
(выбираем на вкус для X11 или Wayland)

Скрипт намбер ту:

#!/bin/bash

FILE1="/tmp/clp.saved"
FILE2=$(mktemp /tmp/clp.XXXXXX)

trap 'rm -f "$FILE2"' EXIT

# xclip -o -selection primary > "$FILE2"
wl-paste --primary > "$FILE2"

if [ ! -s "$FILE1" ] || [ ! -s "$FILE2" ]; then
	notify-send "Ошибка" "Нет текста для сравнения"
	exit 1
fi

meld "$FILE1" "$FILE2"

вешаем на другое сочетание клавиш (у меня, например, Alt+Shift+2)

Изолента и реактивный двигатель — вот всё, что нам нужно. Лучше, чем ничего, по крайней мере…
Первый скрипт сохраняет выделенный текст во временный файл /tmp/clp.saved.
Второй скрипт сохраняет выделенный текст в другой временный файл /tmp/clp.XXXXXX, открывает их оба в нашем любимом Meld, мы на всё это дело любуемся, сравниваем, закрываем Meld, после чего скрипт удаляет этот второй временный файл со случайным постфиксом, чтобы не болтался зря. Первый, /tmp/clp.saved пока остаётся, чтобы было удобно с одним и тем же «первовыделенным» сравнивать несколько вариантов, и его всегда можно переопределить первым скриптом.

Итого: Выделили кусок, Alt+Shift+1, выделили другой кусок, Alt+Shift+2 — смотрим, радуемся! 😁

Как устроен компилятор?

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

Под капотом скрывается целый конвейер, который включает в себя построение дерева, оптимизацию и генерацию кода. Мы разобрали все этапы на конкретных примерах и написали статью для тех, кто хочет понять, как работает компилятор.

Дорожная карта Agentic AI. Level 3. Первые артефакты — LLM API и структурированный вывод

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

— А куда обращаться? — спросите вы.

Есть несколько вариантов.

1. Первый — на серверы производителей: старым добрым ChatGPT, DeepSeek, Gemini, Qwen.

2. Второй — к хабам опенсорс-моделей, например HuggingFace.

3. Третий — к провайдерам-агрегаторам, которые предоставляют и то и другое: Openrouter, Together, Fireworks.

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

Но, к счастью, OpenAI был впереди планеты всей, и его формат стал стандартом де-факто.

Поэтому начните с интерфейса OpenAI, возьмите провайдер Openrouter. Изучите спецификацию, форматы сообщений, поэкспериментируйте с системным промптом, параметрами генерации, потоковым выводом. Изучите мета-информацию в ответе — количество токенов, время генерации.

Обязательно разберитесь со структурированным выводом: это когда модель возвращает не просто текст, а JSON строго по вашей схеме. В агентных пайплайнах без этого никуда — именно так агенты передают данные друг другу и вызывают инструменты.

Сгенерируйте своего первого ИИ-ассистента, благо кодовые агенты отлично умеют генерировать код для OpenAI-библиотек. Изучайте основы, не гонитесь сразу за фреймворками верхнего уровня — с ними познакомимся позже.

📚 Материалы

• Наш видео-туториал по OpenAI API

• OpenAI Quickstart · Python SDK · Streaming

• HuggingFace Inference API

• Openrouter Quickstart · Together AI · Fireworks AI

🔔 Следующая тема: мультимодальность — голос, изображения, видео.

⬅️ Предыдущая тема: Level 2. AI-driven разработка

Подписывайтесь, пожалуйста, чтобы не пропустить!

Наши курсы по ИИ-агентам. По вопросам — пишите мне.

13 демо-уроков апреля для разработчиков: от REST API и SQL до Bun, C++ и микросервисов

Привет, Хабр. Эти уроки проведут преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Участие бесплатное. Присоединяйтесь!

15 апреля, среда:

• 18:00 — Основы протокола HTTP

• 20:00 — OpenAPI + Spring

• 20:00 — Локализация текстов в Symfony: от статических переводов к динамическим данным из базы

• 20:00 — Основы проектирования бизнес-логики в микросервисной архитектуре

16 апреля, четверг:

• 20:00 — Облегчённые (Slim) примитивы синхронизации

• 20:00 — Архитектура ИИ-сервисов для High-Load и Low-Latency инференса

21 апреля, вторник:

• 20:00 — Функции в SQL: вычисления и переиспользование кода

• 20:00 — Производительность кода на примере алгоритмов сортировки

22 апреля, среда:

• 20:00 — Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript (Bun — современная среда выполнения JavaScript; ИИ — искусственный интеллект)

• 20:00 — Symfony Workflow: конечный автомат для реализации бизнес-логики

23 апреля, четверг:

• 20:00 — Многопоточность в C++: как писать быстрые и безопасные приложения

• 20:00 — Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

29 апреля, среда:

• 20:00 — PHP-разработчик. Продвинутый уровень

Как научиться печатать вслепую за час.

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

Способ обучения состоит из трех шагов.

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

ЙЦУ КЕНГуру ШЩаЗ ХЪ

ФЫВА ПРО ЛоДЖЭя

мЯЧ СМИТ ЬБьЮ,

в которых нужно пропускать строчные буквы.

Для запоминания английской раскладки запомните три последовательности

Q WERTY U I OP!

AS DFGHiJKL

ZXCVBNM,.

Второй шаг. Располагаем кисти так, чтобы указательные пальцы опирались на клавиши с бугорками - А и О. Печатаем на ощупь в течении получаса. Если у вас нет своего текста, можно воспользоваться Гонками на клавиатуре https://www.google.com/search?q=гонки+на+клавиатуре. При этом если расположение буквы уже запомнилось, то нажимаем ее правильным пальцем. Если расположение клавиши не запомнилось, то, не глядя на клавиатуру, ощупываем слева на право клавиши в нужном ряду, пока не найдем искомую букву. Например, для нажатия буквы Т ощупываем мизинцем левой руки букву Я, безымянным - букву Ч, средним - С, указательным левой - М, указательным левой руки - букву И, указательным правой руки - букву Т.

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

По необходимости повторяем предыдущие шаги.

Метод слепой печати позволит ускорить ввод текста в несколько раз, не думать о расположении клавиш, на зависеть от наличия света. Навык слепой печати пригодится тем, кто часто пользуется компьютером, подчеркнет ваши высокие профессиональные качества. Слепой метод позволяет печатать двести знаков в минуту. Модифицируйте предложенный способ обучения под ваши обстоятельства и особенности.

Пятничный пост. Рубрика - узнай себя и что было дальше?

— Привет. В этом спринте наш главный приоритет — это обработка больших данных из файла, который загружает пользователь. Тебе предстоит сделать пошаговую форму и предварительную проверку перед отправкой, — уверенным голосом сказал Виталий — руководитель проекта.
— Бизнес очень хочет эту фичу и ждёт, — добавил он, повышая уровень ответственности и важности задачи.
— Но… перед этим есть маленькая задачка: нужно в форме группового добавления товаров в корзину показать ошибки, которые возвращает сервер.

Подключились ребята с бэка.
— Раньше у нас этого не было, мы просто падали. Сейчас для каждого отдельного запроса может быть своя ошибка. Мы обсудили это с Виталием и Викой на прошлой неделе и быстро всё сделали, — декларировали они, явно удовлетворённые результатом своей работы.

— Да… там простой процесс: пользователь нажимает кнопку, и для каждого поля уходит свой запрос. Нужно просто показать ошибки, — подтвердила Вика — аналитик.

Вдруг я ощутил, что все смотрят на меня, и даже бизнес, которого не было в комнате.

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

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

— Ну, так… форма же уже работает. Это простое отображение ошибок. Бизнес хочет, чтобы в конце недели это было на проде. Ок…? — закончил вопросом-утверждением Виталий.

— Ок… — зачем-то ответил я. «Б…!!! Зачем я это сказал?!» — тут же промелькнуло у меня в голове, и две половинки моего тела чуть ниже спины нервно сжались в предвкушении нюансов…

Кого узнали и что было дальше?

Дорожная карта Agentic AI. Level 2. Ускорение — AI-driven development

Кодовые агенты — вторая тема дорожной карты, и я поставил её сюда не случайно.

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

Для начала ознакомьтесь с разнообразием инструментов:

• Онлайн-прототипирование: V0, Bolt, Lovable, Replit

• Консольные агенты: Claude Code, Codex CLI, Gemini CLI, Warp

• AI-coding IDE: Cursor, Windsurf

• Spec-Driven IDE: Kiro, Qoder

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

Три вещи, которые я настраиваю первым делом:

• Skills — для меня это самый мощный и пока сильно недооценённый инструмент. Скилл — инструкция-специалист: агент читает SKILL.md и получает роль, знания и алгоритм. Аналитик, архитектор, тестировщик, DevOps — можно собрать целую команду специалистов под проект. Формат уже стал кросс-платформенным — один SKILL.md работает в Cursor, Claude Code и Codex.

• Rules — постоянные инструкции: стиль кода, архитектурные решения, запреты.

• MCP — подключение внешних инструментов и актуальной документации. Попробуйте начать с MCP Context7.

Крайне рекомендую изучить Spec-Driven методологию и лучшие практики работы с кодовыми агентами от Anthropic.

На выходе с этого уровня у вас будет персональный кодовый ИИ-агент, который берёт рутину на себя, а вы фокусируетесь на архитектуре.

📚 Наши материалы

• Умный вайб-кодинг

• 300 дней с AI-агентами

• Лучшие практики от Cursor

• Третья эпоха AI-разработки

• Видео: AI-driven разработка · Qoder · Claude Code · Gemini CLI

🔔 Следующая тема: работа с LLM API.

⬅️ Предыдущая тема: Level 1. Основы LLM и промпт-инжиниринг

Подписывайтесь, пожалуйста, чтобы не пропустить!

🎓 Приглашаем на бесплатный мастер-класс
📅 13 апреля, пнд 16:00 МСК — AI-driven практикум «ИИ-агент с нуля за один эфир»
👉 Записывайтесь в наших ботах: Telegram или ВКонтакте

Наши курсы по ИИ-кодингу ИИ-агентов. По вопросам — пишите мне.

Подключайся ко второму онлайн-митапу MWS для Python-разработчиков 🎙️

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

Будет интересно Python-разработчикам, аналитикам и другим ИТ-специалистам, кто интересуется применением ИИ в разработке.

• 📅 Когда: 15 апреля (среда) в 15:00 по мск

• 📍 Где: онлайн 

• 👉 Зарегистрироваться

Дорожная карта Agentic AI. Level 1. Основы LLM и промпт-инжиниринг

Начну нашу дорожную карту Agentic AI с языковых моделей.

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

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

• параметры моделей и основные термины (размер, веса, токены, контекстное окно, галлюцинации),

• способы оптимизации (квантизация, прунинг, дистилляция),

• способности к размышлению, ведению диалога, следованию инструкциям, обработке не только текста, но и медиа-контента.

Главное — практиковаться. Я взял себе за правило: каждую задачу сначала через ИИ. Пишу код? Промпт. Анализирую данные? Промпт. Пишу письмо? Промпт. Делаю презентацию? Промпт.

Чтобы делать это качественно — прокачивайте навык писать промпты, изучите гайды по промпт-инжинирингу от вендоров. Результат на выходе зависит от качества контекста и точности инструкций.

Изучите гайды, пробуйте разные модели, начните с топовых: ChatGPT, Claude, Gemini, DeepSeek, Qwen. Отечественные: YandexGPT, GigaChat.

Прокачайте насмотренность, набейте руку, пройдите по аренам, лидербордам, бенчмаркам — научитесь понимать, в чём одни модели сильнее других.

На выходе будете как рыба в воде: выбирать модель под задачу и качественно с ней работать.

📚 Материалы

• Как работают LLM: Prompting Guide, визуализации — LLM Visualizer и Transformer Explainer, наш плейлист с объяснениями основ.

• Промпт-инжиниринг от вендоров: OpenAI Cookbook, Anthropic Prompt Engineering, Claude 4 best practices.

• Выбор модели: видео-гайд, лидерборды — LM Arena, LLM Arena RU, SWE-bench. Хаб моделей: Hugging Face.

🔔 Следующая тема: AI-driven разработка — как грамотно ускорять разработку в X раз.

⬅️ Предыдущая тема: Дорожная карта Agentic AI. Интро

Подписывайтесь, пожалуйста, чтобы не пропустить!

🎓 Бесплатные мероприятия на этой неделе

• 📅 9 апреля, чт 18:00 — Онлайн-разбор продакшен-кейса «ИИ-агент консультанта 1С»

• 📅 13 апреля, пнд 16:00 — AI-driven практикум «ИИ-агент с нуля за один эфир»

👉 Записывайтесь на мероприятия в наших ботах: Telegram или ВКонтакте

Ознакомьтесь с нашей траекторией роста по AI-driven разработке и ИИ-агентам.

ИИ-код и линтеры: статический анализ проекта на 85 000 строк

ruff (Python) — 73 замечания на 63 000 строк. 1.2 на 1000 строк.

Состав: 39 неиспользуемых импортов, 17 неиспользуемых переменных, 6 forward references, 5 f-строк без подстановок, 5 лямбд вместо def. Ноль ошибок, от которых код падает в рантайме.

ESLint (React/TypeScript) — 0 ошибок, 5 warnings на 21 000 строк. Все пять — рекомендация Next.js использовать <Image> вместо <img>.

Для сравнения:
- Зрелый проект с CI-линтингом — 0–2 замечания на 1000 строк.
- Без линтинга — 5–15.
- Легаси — 20–50.

У нас 1.2 и 0.24, при том что CI-линтинга в проекте нет. Claude и Codex запускают ruff и eslint сами на каждое изменение — я вижу это в логах. Результат соответствующий.

Безопасность

ruff и ESLint проверяют стиль, не безопасность. По совету из комментариев прогнал bandit — security-сканер для Python.

1 432 находки. Реальных уязвимостей: 0.

• 2 HIGH — SHA1 для fingerprint'а шахматных партий. Это не криптография, а генерация коротких ID для внутренней классификации. Подделывать бессмысленно.

• 5 MEDIUM «SQL injection» — bandit видит f-string в SQL-запросе и сигнализирует. Но внутри f-string стоят только ?-плейсхолдеры, данные идут параметрами. Классическая параметризация, инъекция невозможна.

• 4 MEDIUM «url open» — HTTP-клиенты Lichess, Chess.com, OpenRouter. URL из конфига, пользователь не контролирует.

• 1 421 LOW — 1 250 assert'ов (bandit предупреждает, что assert удаляется при запуске с -O, но Django и Celery никто так не запускает), остальное — try/except/pass в опциональных ветках.

Фронтенду отдельный security-сканер не нужен: React экранирует HTML автоматически, dangerouslySetInnerHTML не используется, фронт не работает с БД, файлами и процессами.

85 000 строк, три сканера, ноль реальных уязвимостей. ИИ-код не нуждается в оправданиях — он нуждается в проверке. Проверили. Чисто.

p.s. Проверку проходил код из статьи Вайбкодинг по Chess’ноку. 1. e4

Как за 11 лет разучиться дебажить: когнитивная атрофия от AI-инструментов

На Reddit разработчик с 11-летним стажем описал тревожный момент: он не смог отладить баг в собственном коде без Claude. Не потому что баг сложный, а потому что разучился генерировать гипотезы самостоятельно.

Что произошло

Разработчик столкнулся с нестабильным багом сетевых таймаутов в продакшене. Сервис писал сам, два года назад. Раньше подобная проблема решалась за час методичной работы. Теперь 40 минут пинг-понга с Claude без результата.

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

Баг он в итоге нашёл. Но медленнее, чем три года назад, когда AI ещё не использовал.

Почему это не про «AI плохой»

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

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

Классический пример — GPS-навигация. Исследование в Nature Communications (2017) показало: люди, которые постоянно ездят по навигатору, хуже справляются с задачами пространственной ориентации, чем те, кто периодически строит маршруты сами.

Где это ломается у разработчиков

На практике выделяются три зоны риска:

Генерация гипотез
AI отлично проверяет гипотезы. Но если перестать генерировать их самостоятельно, навык быстро деградирует. Через полгода становится сложно просто «посидеть» с проблемой.

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

Коммуникация
Некоторые прогоняют через AI даже сообщения коллегам. Возникает размывание авторства мысли: это ты формулируешь или инструмент за тебя.

Контраргумент: а Stack Overflow?

Частое возражение: разработчики годами копировали решения с Stack Overflow и не деградировали.

Разница в модели взаимодействия:

1. Нужно сформулировать проблему

2. Найти релевантный ответ

3. Адаптировать решение под свой контекст

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

Что делать: практические подходы

Правило 5 минут
Перед тем как открыть Claude, потратить 5 минут на самостоятельный анализ stack trace. Это простой способ «включить» мышление.

Unplugged-сессии
Периодически дебажить без AI. Например, один час в неделю. Это не ограничение, а тренировка.

Приходить с гипотезами
Разница между джуном и сеньором в работе с AI: джун ждёт решение, сеньор приносит несколько гипотез и использует AI как инструмент проверки.

Рефлексия после решения
После решения с помощью AI зафиксировать, какие гипотезы ты мог бы выдвинуть сам. Это возвращает осознанность процессу.

Честно

Я не демонизирую AI-инструменты. Сам использую ежедневно. Но когнитивная атрофия — реальный риск, который стоит учитывать.

Если вы программируете много лет и замечаете, что раньше справлялись быстрее без AI, это не паранойя. Навык требует практики, а делегирование мышления — это решение с определённой ценой.

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

Если кто-то вдруг использует мой Licensedog для сбора информации о техстеке.

С сегодняшним обновлением, оно успешно разыскало в интернете и проверило все 5546 зависимости одного из наших проектов, кроме 4 мусорных внутренних библиотек.

Научил работать с Java (раньше были только Python, JS и Go). Починил целую пачку багов.

Это такой краулер, который принимает на вход SBOM (в виде CSV или cyclonedx) и потом сомневается в нем: старается обойти интернет, и на самом деле физически найти файлы с лицензиями. Выкачать их репозиториев, распаковать из архивов, или даже открыть в барузере их сайты и распарсить веб-странички. И фактически проверить на соответствие. В отчете описывает, что и откуда взялось, и почему она думает что лицензия на самом деле не MIT а GPL. На выходе получается CSV или JSONL файл, который можно отгружать безопасникам на ревью.

Исходники - как всегда, на GitVerse.

https://gitverse.ru/anarchic/licensedog

Дорожная карта Agentic AI: от основ до production-ready агентных систем

Друзья, я решил в апреле разобрать горящую тему этого года - что надо знать и уметь для разработки production-ready ИИ-агентов.

По сути, это будет своеобразная дорожная карта Agentic AI Engineering — по этапам, от основ до зрелых систем.

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

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

• Основы языковых моделей и промпт-инжиниринг,

• Работа с LLM API и структурированный вывод,

• AI-driven разработка с ИИ-агентами,

• Мультимодальность — голос, изображения,

• Local inference — локальный запуск моделей,

• RAG — как передать агенту знания о вашем бизнесе,

• Agents — агенты с памятью, инструментами и планированием,

• MCP — стандарт интеграции агентов с внешними системами,

• Observability & Evaluation — мониторинг и оценка качества RAG-систем и агентов,

• Security & Guards — безопасность агентных систем,

• Управление датасетами и промптами,

• Сontext-engineering — работа с большим контекстом,

• Skills — навыки агентов,

• Agent harness — решение сложных задач, субагенты и планирование,

• Multi-agents — мультиагентные системы.

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

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

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

🔔 Следующий пост: основы языковых моделей — с чего всё начинается.

Больше про ИИ-кодинг и ИИ-агентов в ТГ и ВК.
Приглашаю ознакомиться с нашими онлайн-курсами по ИИ-разработке ИИ-агентов.

Разработчик Александр Гомес Гайгалас (Alexandre Gomes Gaigalas), автор библиотеки coral для создания переносимых shell-скриптов, опубликовал проект C89cc.sh. Это компилятор для языка C, написанный целиком на Shell.

Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.

Будет слишком по девчачьи сказать, что я плакала из-за код ревью?

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

Ничего такого, вроде все ок. Но я смотрела на него и зависла в моменте: а что именно не так то? Есть какие то правила в новой команде, о которых я еще не знаю? Нужно переименовать только эту переменную или мне нужно пройтись по всему файлу?

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

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

Мне захотелось поделиться своими мыслями на тему код-ревью, о том как формулировки влияют на скорость работы и состояния людей:

Ссылка на статью

Если хоть раз сидел и думал: «что от меня тут вообще хотят?» — ты точно поймёшь :)

Как делать бизнес-процессы как в n8n — безопасно и масштабируемо? Узнаете на конференции GoCloud 2026 ☁️

Расскажем, как обойти лимиты n8n для enterprise- и ИИ-систем: живой трейсинг и метрики из коробки, предсказуемое масштабирование, нативная работа с кастомными моделями машинного обучения и мультиагентными системами. Плюс бесшовный импорт сценариев из n8n без простоев. В финале — живая миграция реального воркфлоу за минуты.

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт