Качество работы LLM — функция от качества контекста на входе. Это утверждение звучит банально, однако зачастую разработчики оптимизируют модель, выбирая между GPT, Claude или Gemini, и промпт, но не контекст в целом. Между тем, разница между «агент с правильным контекстом» и «агент без контекста» — не 20% и не 50%. Эта разница находится в дистанции вариантов между «решил задачу за 5 минут» и «потратил час, сломал два сервиса, и результат пришлось откатить из‑за массы новых проблем».

Я solo‑разработчик. В моей экосистеме десятки актуальных проектов: платформа из десятков микросервисов, AI‑инференс кластер на неспецифическом железе типа mac studio и dgx spark, масса shared‑библиотек, инфраструктура на нескольких физических и десятках виртуальных хостов.

Последний год «пишу» код почти исключительно через LLM и Cursor. Начинал с deepseek на уровне «подскажи как написать функцию для...» и дошел до полноценной оркестрации на Claude 4.6: я формулирую задачу, агент анализирует условия и кодовую базу, обсуждаем архитектурный план, агент пишет код и тесты, запускает тесты, фиксит ошибки, получает от меня обратную связь по результатам ручной проверки.

Это работает хорошо, когда агент глубоко понимает контекст. И катастрофически плохо, когда контекста недостаточно. Эта статья — про то, как я решаю проблему контекста системно.

Оговорка о применимости

Описанная методология разрабатывалась и обкатывалась на одной из наиболее сильных моделей для работы с кодом — Claude 4.6 Opus с контекстным окном в миллион токенов. Это важно зафиксировать: большое окно контекста означает, что агент физически способен «увидеть» knowledge base, а сильные аналитические способности модели позволяют извлечь из неё пользу, а не утонуть в шуме.

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

Дело вот в чём. ИИ — это троянский конь. Это эксплуататорская олигархия, нарядившаяся в костюм инструмента для повышения продуктивности. Давайте провалимся в очень неприятную кроличью нору.

Всем привет!

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

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

Основная идея проста: разработчик формирует спецификации, ИИ генерирует код. Принципы — не терять и не размывать контекст, контролировать структуру и качество кода.

На Хабре не раз писали про историю английского языка, французское завоевание и даже про Великий сдвиг гласных. Но когда речь заходит о произношении слов, связанных с ИТ и бизнесом, ощущение хаоса возникает особенно остро. Почему “cloud” читается не так, как пишется? Почему “queue” выглядит как избыточный набор букв? Почему “architecture”, “data”, “record” и “run” подчиняются разной логике?

Чтобы разобраться, нужно помнить: современный английский - это результат наложения нескольких исторических слоёв. И профессиональная лексика, в том числе ИТ и бизнес, распределена по этим слоям очень неравномерно. Давайте по порядку.

В феврале 2026 года инфополе снова заполнилось слухами о полной блокировке Telegram к 1 апреля. Бизнес паникует, маркетологи не понимают, останавливать ли кампании, а бюджеты зависают в воздухе.

Меня зовут Артемий, я владелец агентства по закупке трафика через Telegram Ads.

В этой статье я на основе свежих технических отчетов и реальных цифр рынка покажу, почему полного блэкаута не предвидится. Разберем, как именно работают ТСПУ Роскомнадзора , куда на самом деле перетекают бюджеты брендов и почему главная угроза для рынка кроется в маркировке ОРД, а не в мифическом рубильнике.

Спойлер: реклама в телеграмме работала и будет работать.

Привет, Хабр! Меня зовут Sonic. Я собрал SonicBoost — бесплатную утилиту с открытым кодом, которая вытаскивает из Windows 10/11 максимум FPS. 28 твиков реестра, управление службами, блокировка телеметрии, оптимизация сети — всё в одном EXE на 65 МБ. Под капотом .NET 8, WPF UI с Mica-эффектом и ни одного подозрительного скрипта — весь код на GitHub.

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

Зачем вообще нужен ещё один твикер?

Каждый геймер знает ощущение: собрал машину за 200к, а в Valorant на ALT+TAB — фриз на 3 секунды. FPS скачет, пинг гуляет, микрофризы в самый неподходящий момент.

Проблема не в железе. Проблема в том, что Windows — это корпоративная ОС, а не игровая. По умолчанию там крутятся:

Conductor, Crystal, Auto-Claude, Claude Squad, CCManager и Cursor 2.0 — честное сравнение с плюсами, минусами и рекомендациями по сценариям.

Есть паттерн, который видит каждый, кто работает с агентами: первые 5–15 минут уходят не на задачу, а на "ориентацию". Где точка входа? Откуда растут зависимости? Почему эта библиотека, а не другая? Кто считает это публичным API? В маленьком проекте раздражает. В большом — превращается в постоянный налог на токены и внимание.

DSP (Data Structure Protocol) "выносит карту проекта наружу" — в простой, версионируемый, языковой граф, который живёт рядом с кодом и доступен агенту как постоянная память.

k-kolomeitsev/data-structure-protocol

Цель в архитектуре сформулирована так:

1) Цель и границы

Цель DSP — хранить минимальный, но достаточный контекст о репозитории/системе артефактов в виде графа «сущности → зависимости/публичный API», чтобы LLM могла:

- быстро находить нужные фрагменты по UID,

- понимать «зачем» сущности существуют и «как» они связаны,

- не требовать загрузки исходников целиком в контекстное окно.

DSP — это долговременная память и индекс проекта для LLM. Агент может в любой момент выполнить поиск (grep) по проекту, найти нужные сущности по описаниям/ключевым словам и от найденного UID раскрутить весь граф связей: входящие зависимости, исходящие импорты, реципиентов через exports. Это заменяет необходимость «помнить» структуру проекта или загружать его целиком — вся карта проекта всегда доступна через .dsp.

Retrieval-Augmented Generation (RAG) всё чаще упоминается в контексте LLM и всё чаще фигурирует в требованиях к разработчикам, но за этим термином обычно скрывается довольно размытое представление о том, как такие системы реально устроены. В этой статье я разбираю RAG как архитектурный подход: зачем он вообще появился, какие задачи решает, как выглядит базовый пайплайн от данных до ответа модели и где на практике чаще всего возникают проблемы.

Персистентные Tasks, субагенты на общем списке, зависимости между задачами — разбираем обновление и подводные камни.

Полный справочник settings.json с ранжированием по полезности: от «почему я не знал об этом раньше» до «пригодится раз в год».

В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).

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

Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:

Я в IT с 2013 года. Последние 2 года активно развиваю AI-направление в DNA IT (AI Dev Team). Результат: клиенты всё чаще выбирают AI-отдел вместо традиционных команд разработчиков. Причина простая — быстрее (1-2 недели вместо 2-3 месяцев), дешевле (-80% затрат), качественнее (автоматизированные проверки).

Всё, о чём я пишу, — протестировано на реальных клиентских проектах. Никакой теории ради теории. Только практика.

Знакомо это чувство, когда вы задаёте ChatGPT вопрос, а он просто... соглашается со всем, что вы говорите? Даже когда вы совершенно неправы?

Я проверил это на прошлой неделе. Я спросил GPT-4: «Объясни, как Node.js использует потоки для обработки операций ввода-вывода». Вот в чём штука - Node.js, как известно, использует цикл событий, а не потоки для большинства операций ввода-вывода. Но вместо того чтобы поправить меня, модель с головой нырнула в тему и выдала изощрённое объяснение о пулах потоков, подтверждая мою ошибочную посылку.

Это не вежливость. Это не ИИ, который «старается быть милым». Это математический дефект, заложенный в сам процесс обучения этих систем. И называется он сикофантия.

Всем привет! Меня зовут Артем, я Data Scientist компании RAFT. Сегодня я расскажу об своем pet проекте по объяснению правил для настольных игр. Цель данного проекта — понять, как можно собрать RAG агента без использования больших библиотек.

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии.

В данной статье рассматриваются основные виды тестирования, включая юнит-тестирование, интеграционное тестирование и энд-ту-энд (E2E) тестирование, а также выявлены их преимущества, недостатки и ключевые особенности. Также уделяется внимание современным инструментам для разных видов тестирования, например, Jest, Cypress и Testing Library, которые предоставляют разработчикам мощные возможности для написания и выполнения тестов. Исследованы следующие подходы к тестированию: Test-Driven Development, Page Object и Continuous Integration. Выделены ключевые метрики, по которым можно определить эффективность тестирования.

С появлением AI-агентов разработка программного обеспечения изменилась кардинально. Я, как и многие разработчики, начал активно использовать Claude, Cursor и другие инструменты для автоматизации написания кода. Результаты поначалу впечатляли: за один вечер, занимаясь системным анализом, проектированием архитектуры и промпт-инжинирингом, я мог сгенерировать до 100 000 строк кода.

Процесс был увлекательным. Не нужно было вручную писать реализацию - достаточно было описать требования, обсудить с AI архитектурное видение, уточнить детали, и код появлялся сам. Я мог работать по вечерам над своими pet-проектами, общаясь с искусственным интеллектом как с коллегой. Это был настоящий вайб-кодинг - приятный, творческий процесс, не отягощённый рутиной.

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

Как превратить Claude Code из мощного ассистента в профессиональную платформу оркестрации с 33+ специализированными агентами.

Как можно Cursor IDE превратить в полноценную мультиагентную среду разработки, где каждый AI‑агент выполняет роль члена команды: аналитика, архитектора, планировщика или разработчика?

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

Как добиться сходимости к стабильному результату в ходе длительной самостоятельной работы команды ИИ-агентов?

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