Управление разработкой *

Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас

Да и вообще всем, кто хочет разбираться в современных AI инструментах, будет полезно

Разбираемся

1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним

Сууупер длинная статья

Этот документ описывает процедуру воспоминания о девушке по имени Аня, с которой пользователь встречался в период с февраля 2011 по декабрь 2024 года. Процедура предназначена для случаев, когда автоматический триггер (запах кофе в кофейне White Swift, песня Animal Jazz “Три полоски на кедах”, фотография красных песков Алтая ближе к монгольской границе) приводит к непредвиденному состоянию системы.

Версия: 2.4.1
Последнее обновление: четверг, в три часа ночи
Статус: deprecated, но не удаляется.

1. Предварительные требования
Перед запуском процедуры убедитесь, что выполнены следующие условия:
* Вы один в комнате
* Уровень освещённости — низкий (рекомендуется настольная лампа с тёплым светом, не верхний свет)
* Все мессенджеры закрыты (особенно Telegram — известный источник побочных эффектов)
* В радиусе досягаемости находится: стакан воды, плед, Chateau Mukhrani Reserve Royale Goruli Mitsvane (опционально, но настоятельно рекомендуется)

⚠️ Внимание: запуск процедуры в состоянии алкогольного опьянения приводит к рекурсивному вызову функции написать_бывшей(), которая, как известно, не имеет корректного выхода.

2. Инициализация
2.1. Загрузка контекста
Откройте папку ~/память/2025/. Внутри обнаружится подпапка аня/. Не открывайте её сразу — сначала выполните:
$ ls -la ~/память/2025/аня/

Вы увидите 247 файлов. Большинство из них — .jpg, несколько .mp3 (в основном — голосовые сообщения), один файл последний_разговор.txt размером 4.2 КБ.

2.2. Проверка целостности
Файл последний_разговор.txt за прошедшие годы мог быть повреждён в результате многократного перечитывания. Это нормально. Не пытайтесь его восстановить — оригинал утерян безвозвратно, а ваша текущая версия содержит правки, внесённые задним числом, на основе того, как должно было быть.

Третья неделя в новой компании. меня спрашивают кто в соседней команде отвечает за конфиги админки и где лежит контракт по realtime-интеграции с витринами партнёров. отвечаю без открытия браузера.

Я ж не гений. просто всё это уже в одном каталоге и достаётся одной командой в терминале.

Сколько людей - столько и мнений о процессах в команде (с). 

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

За отправную точку возьмем несколько потребностей: 

• управлять неопределённостью,

• повышать качество требований,

• снижать риски на этапе разработки. 

Поделимся опытом работы в команде разработки продукта электронного документооборота. 

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

Как превратить десятки неструктурированных описаний участников сообщества в систему поиска

«Занимаюсь бэкендом лет 7, Go и Python, немного ML» — попробуйте найти среди двухсот таких описаний нужного человека. Руками — часы. Я автоматизировал это через гибрид LLM + детерминированного кода, и отловил все возможные проблемы.

Рассказываю про архитектуру, промпты и решения.

* На обложке — Архимболдо «Библиотекарь» (1566): из разрозненных книг складывается цельный образ. Как и профиль участника в системе

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

Конечно, я не считаю, что С++ будет забыт, но с большой долей вероятности ему будет уготована нишевая роль, как сейчас это произошло с языком С, которому С++ и пришел на замену. Причем я предположил, что способ плавной замены С++ на какую то альтернативу должен происходить точно также, как сам С++ пришел на замены старому С, через транспрлайтер (sourse to source translation).

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

«Самые трудные уроки, которые я усвоил, — не о том, как работаешь ты сам, а о том, как работают команды: как на самом деле принимаются решения, где ломается координация, чем отличаются команды, которые доводят дело до конца, от тех, кто стоит на месте. Этот список советов про то, как стать сильнее как отдельный инженер, и больше — про системы вокруг инженерии.» — Эдди Османи, ирландский инженер‑программист, директор в подразделении Google Cloud AI.

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

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

Я Java-разработчик: пишу на Java 5 лет. Последний месяц собираю портфолио через Spec-Driven Development — связку Spec Kit и Claude Code. Первый проект — Telegram-бот для задач. С шести вечера до двух ночи одного вторника я прошёл полный SDD-цикл от конституции до MVP с шестью командами. Восемь часов. Один вечер. Рабочий продукт. Но главное — что-то сдвинулось в моём инженерном процессе.

Если в вашей компании документация живёт в папках на разных дисках, теряется при обновлениях, сложно определить, к какому релизу относится тот или иной документ, а фраза «Кто знает, где последняя актуальная версия?» стала ритуалом, эта статья для вас.
Привет! Я Роман Люкшин, системный эксперт‑аналитик «БАРС Груп». Два года назад мы прошли через этот хаос и нашли выход. Расскажу, как объединили аналитиков и технических писателей в GitLab по соседству с разработчиками и превратили документацию в «код» с историей версий.

Бывает, что фича готова и её пора передавать в тестирование, но при этом не покидает ощущение, что что-то не так. Однажды внутреннее чутьё меня не обмануло и привело в исходники React.

Меня зовут Денис Кондратьев — я фронтенд-разработчик в Точка Банк. В статье поговорим, как работает приоритетный рендеринг в React, что такое проблема разрыва и разберём реальный кейс на примере корпоративного мессенджера.

2ГИС — это не просто сервис о городах, а самобытная культура создания продуктов: от бриф-интенсивов до постов в «Доставили». Мы стараемся, чтобы внутри было меньше бюрократии, больше здравого смысла и даже юмора, при этом сохраняем серьёзность целей и осознанно  управляем ресурсами. 

Я, Стас Мозгель, руководитель B2C‑продуктов, делюсь тем, как работает наша продуктовая культура изнутри: всё про процессы, культуру и принципы, которыми руководствуемся. 

Привет, Хабр! Меня зовут Антон Батищев, я бэкенд-разработчик в продуктовой команде Циан. В этой статье поделюсь опытом: как устроена наша работа, какие плюсы мы видим в таком подходе и с какими проблемами сталкиваемся на практике.

В первой части мы разобрали, как устроены DORA-метрики и что стоит за каждым из пяти показателей. Сложнее другое: одни используют их как инструмент улучшения процессов, другие – как универсальную шкалу зрелости. Разбираемся, почему контекст здесь важнее любого бенчмарка – и с чего начать команде, которая хочет считать метрики осмысленно. 

Второго апреля я наткнулся на статью The New York Times про MEDVi — телехелс-стартап, который якобы вырос до $1.8 миллиарда с двумя сотрудниками и горой AI-инструментов. Честно? Я впечатлился. Сэм Альтман предсказывал компанию на миллиард с одним основателем — и вот она, пожалуйста. Мэттью Галлахер, 41 год, Лос-Анджелес, $20 тысяч стартового капитала, ChatGPT, Claude, Midjourney — и $401 миллион выручки за 2025 год.

Я уже начал набрасывать план статьи. «Вот оно, будущее. Смотрите, как AI меняет правила игры.»

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

Третья статья из шести про инженерный процесс для разработки с ИИ-агентами. Автор, Андрей Юмашев, много лет руководил разработкой и инфраструктурой, полтора года назад отдал весь код агентам. Первая статья про путь от первых проектов до стандарта SENAR. Вторая про то, чем агент отличается от программиста. Эта про то, кем становится человек, когда код пишет не он.

«У нас тут быстро, сразу к делу, документация потом» — знакомая установка? Бросаем всех в бой! Иначе зачем нанимали? Пока новый сотрудник не уволится через месяц, а команда не попросит «поменьше новичков, нам ведь надо успевать работать».

Меня зовут Маша, я QA Engineer в Doubletapp. Мы с 2020 года аутстафим в бигтехах, банках, стримингах, интеграторах, e-commerce и т. д. Поэтому хорошо знаем, где эта модель ломается и как сделать так, чтобы она действительно работала.

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

Навигация по статье 

— Вливаемся в проект, фиксируем ожидания и критерии успеха
— Интеграция в команду: как не остаться «внешним»
— Работа и результат: как быть полезным вопреки неудобствам
— Блокеры, доступы и прозрачность: защита от репутационных потерь
— Как не выгореть между проектами
— Когда аутстаф начинает работать.

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

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

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

Слово «вайбкодинг» в ИТ-среде вызывает неоднозначную реакцию: разработчики морщатся, бизнес интересуется, а все остальные делают вид, что давно разобрались. Ни лагерь хейтеров, ни лагерь евангелистов не дают честного ответа. Разбираемся: почему разработчики правы в своих опасениях, почему бизнес всё равно идёт в эту сторону — и что со всем этим делать.