Cursor делает security review постоянным слоем

30 апреля 2026 года Cursor запустил в бете Security Review для Teams и Enterprise. Внутри два always-on агента: Security Reviewer проверяет каждый PR, а Vulnerability Scanner гоняет плановые сканы по кодовой базе.

Security Reviewer ищет не только уязвимости, но и auth-регрессии, privacy и data-handling риски, auto-approval агентных тулов и prompt injection. Vulnerability Scanner отдельно проверяет известные уязвимости, устаревшие зависимости и конфигурационные проблемы, а результаты может отправлять в Slack.

Практический сдвиг тут в другом: AI теперь ставят не только в редактор, а в постоянный контур вокруг PR и репозитория. Если у команды уже есть свои SAST, SCA или secrets scanners, Cursor позволяет подключить их через MCP как часть review.

По доступности это beta для Teams и Enterprise: на pricing page у Teams указано $40 / user / mo., у Enterprise цена кастомная, а сами security agents списывают usage из общего пула. Но заменой SAST/SCA и ручного security review это пока не выглядит: скорее ранний фильтр, который быстрее подсвечивает, куда человеку стоит смотреть в первую очередь.

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

AI в разработке

Почему Codex идет в AWS

28 апреля OpenAI и AWS открыли limited preview для OpenAI models on AWS, Codex on Amazon Bedrock и Managed Agents. Для Codex публично заявлены Codex CLI, desktop app и VS Code extension: доступ через AWS credentials, inference через Bedrock. OpenAI · AWS

Смысл не в самом анонсе. Для enterprise agentic coding упирается не только в модель, но и в контур запуска: где живут доступ, биллинг и согласования. Если команда уже работает вокруг AWS, пилот проще запускать там, а не через новый SaaS-путь.

Но это не «Codex для всех»: пока только limited preview, без обещаний широкой доступности и без повода додумывать compliance-свойства сверх анонса.

Практический вопрос для CTO и platform-команд: не просто «нужен ли нам coding agent», а «в каком контуре мы готовы его запускать». Для enterprise это уже часть выбора.

AI в разработке

Локально начать, в облако отдать

Windsurf сейчас собирает гибридный workflow в одну цепочку. 15 апреля 2026 в Windsurf 2.0 в редактор добавили Devin Cloud, а 28 апреля 2026 в Windsurf 2.1.29 появились Devin for Terminal и Devin Local. Сценарий понятный: начать задачу рядом с кодом и терминалом, а длинную часть передать в облако, где у агента своя VM, тесты, video recordings и autofix. Changelog · Docs

Практический смысл не в самом слове “agent”. Локальная сессия удобна, когда нужно быстро пройтись по проекту, поправить несколько файлов и тут же проверить результат. Облако уместнее, когда задача живет дольше вас: долгие тесты, отдельная среда, ожидание PR и работа, которая может идти, пока вы закрыли ноутбук.

Но это пока не универсальная схема “для всех”. В docs Devin Cloud помечен как rolling out gradually, для self-serve явно названы планы Pro, Max и Teams, а в enterprise доступ включает админ и в changelog отдельно привязан к уже купленному Cognition Platform. Так что здесь интересно не только попробовать handoff, но и честно проверить, какой контур у вашей команды реально доступен уже сейчас.

AI в разработке

Zed показывает, зачем редактору несколько агентных тредов

22 апреля 2026 в stable Zed 0.233.5 появились parallel agents, а блог Zed отдельно разложил UX: Threads Sidebar, несколько потоков в одном окне и навигация между проектами и worktree. Stable release · Blog

Смысл не в слове “multi-agent”. Одна длинная AI-сессия быстро превращается в свалку контекста. Здесь можно разнести изолированные куски работы: один агент чинит баг, второй ведет рефакторинг в соседнем worktree, третий добивает тесты или docs.

Важно не смешать уровни утверждений. В stable реально заявлены parallel agents; блог раскрывает UX-детали, а layout с тредами слева для existing users описан как opt-in. Preview вокруг релиза в основном содержит фиксы sidebar и миграции тредов, а не отдельный preview-only запуск.

Если AI IDE уже упирается в хаос длинных чатов, смотреть стоит не только на модель, но и на навигацию между агентами. Параллельность помогает там, где задачи правда изолированы.

AI в разработке

Применение ИИ у застройщиков, опыт «Ак Барс Дом»

21 мая проведем эфир с ИТ-директором девелоперской компании и поговорим, как внедряется ИИ: какие задачи с его помощью пытаются решать, что работает, а что — нет

Гость — Сергей Михеев, ИТ-директор в «Ак Барс Дом»

🗓 21 мая, 12:00 мск, Четверг
💻 ОНЛАЙН

На примере опыта девелопера «Ак Барс Дом» разберём, как AI внедряется в компании: где он уже применяется, есть ли отраслевая специфика и какой эффект это даёт бизнесу. Поговорим о том, как искусственный интеллект используется в разных бизнес-процессах — где он даёт результат, а где нет. Затронем применение AI в прогнозировании, работе с платежами, клиентских сценариях и повседневной работе команд.

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

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

РЕГИСТРАЦИЯ

Начинаем трансляцию про применение ИИ у застройщиков

В гостях — Сергей Михеев, ИТ-директор в «Ак Барс Дом»

Если тема для вас актуальна, подключайтесь к трансляции по ссылке: https://vkvideo.ru/video-137384692_456239243

Можно задавать вопросы в чате трансляции

DeepSeek и Google обновили модели: новые версии, цены, подходы

🐋 DeepSeek анонсировала сразу два релиза: открытый фреймворк Harness (dsh) и финальную версию DeepSeek‑V4‑Pro.
Код и веса обоих продуктов уже доступны под лицензией MIT.

Harness отличается экстремальной модульностью, в нем почти всё строится как плагины с поддержкой hot reload, где можно менять коннекторы и агентный цикл без остановки системы. Фреймворк работает на движке Cordis, архитектура описана здесь — формализованы механизмы обратимых эффектов и реактивных коэффициентов, обеспечивающие композируемость компонентов во времени и пространстве.

DeepSeek‑V4‑Pro‑0813 вышла из превью с улучшенными агентными способностями. Модель включает механизм спекулятивной декодировки DSpark и в связке с Harness показывает значительный рост:
• Terminal Bench 2.1 — 87.9%,
• Cybergym — 83.3%,
• DSBench‑FullStack — 71.1%. 

С 16 августа компания повысит цены на API: на входные токены в 1,5 раза, выходные более чем в 2, а в пиковые часы будут удваивать. 

🌐 Google представила Gemini 3.7 Flash спустя всего три недели после выхода версии 3.6.
Новая модель значительно умнее в инженерии, работе со знаниями и веб-разработке, при этом вдвое дешевле предшественницы по вводной цене ($0,75 за 1M входных и $3,75 за 1M выходных токенов до конца года).

• В коде 3.7 Flash заметно прибавила: FrontierCode 1.1 Main — 43.6% против 34.4% у 3.6 Flash, DeepSWE v1.1 — 65.3% против 49.0%. 

• В веб-разработке модель набирает 1588 Elo в WebDev Arena против 1538. 

• В работе со сложными документами — 34.0% против 22.0%. 

• В реальных бизнес-задачах — 30.4% против 17.0%.

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

3.7 Flash уже доступна в Google AI Studio, Android Studio, Antigravity, на платформе для предприятий, а также в Spark, агенте для пользователей Gemini, на тарифах Google AI Pro и Ultra. 

AI в разработке

Три заметных события на рынке ИИ-инструментов

Anthropic обновила голосовой режим Claude: теперь он работает на Sonnet 5 и Opus 4.8 и получил доступ к корпоративным коннекторам Slack, Gmail, Notion, Google Workspace.
Голосом можно попросить проанализировать непрочитанные сообщения, сделать выжимку из документа или отправить результаты обратно в рабочий чат.
По сути, голосовой интерфейс превращается в полноценный инструмент взаимодействия с рабочим пространством.

OpenAI обновила GPT‑5.6 Sol в ChatGPT, модель стала точнее работать с фактами, давать более сфокусированные ответы и подбирать уровень детализации под вопрос.
В бесплатной версии по умолчанию работает GPT‑5.6 Luna с неограниченными текстовыми чатами, для сложных вопросов добавили кнопку «Подумать», а на тарифах Plus и Pro доступен ползунок глубины обдумывания.

Meta* представила кодинг-агента для автономной работы с крупными репозиториями Muse Code.
Инструмент запускается из терминала, умеет планировать изменения, писать код, делать тесты и проверять результаты без постоянного участия разработчика. Вместе с ним вышла модель Muse Spark 1.2, оптимизированная под программирование с поддержкой долгих автономных процессов и фоновыми субагентами в отдельных ветках репозитория.

Показатели Muse Code + Muse Spark 1.2 около 59% на DeepSWE 1.1, результаты близки к лидерам рынка на Terminal‑Bench 2.1. При этом сама Meta признаёт, что в ряде тестов впереди остаётся Claude Opus 5. Инструмент доступен через API: базовый тариф стоит $1,25 за миллион входных токенов и $4,25 за миллион выходных.

*организация признана экстремистской, её деятельность на территории РФ запрещена.

AI в разработке

Промпт, RAG или дообучение: что реально выучит вашу LLM

В этой статье автор провёл эксперимент с одной задачей и видеокартой и тремя подходами: промпт с полным регламентом на 128K токенов, классический RAG и дообучение QLoRA на 800 парах вопрос-ответ.

Результаты получились интересные: • Промпт дал 20 верных ответов из 30, но упёрся в lost in the middle и невозможность масштабирования. • RAG выиграл на фактах (9 из 10 с пруфами) и мгновенном обновлении знаний, но провалился на синтетике — ретривер принёс не те чанки и модель собрала из них правдоподобную ерунду. • Дообучение заставило модель говорить на языке команды: терминология, структура ответа, формат совпадали. Но факты заморозились на момент обучения, модель ответила старыми лимитами, не заметив обновлений.

Главный вывод что каждый из подходов не конкуренты, а слои для разных задач.
Начинайте с промпта, добавляйте RAG для свежих фактов с источниками, а дообучение воспринимайте как последний рубеж, который отвечает за поведение модели, а не за актуальность данных.

AI в разработке

Увидел в канале AI-Driven Development разбор довольно незаметной функции Ask in side chat у Codex App. 

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

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

Чем сложнее задачи, тем чаще по пути появляются побочные ветки — проверить гипотезу, быстро поправить конфиг, разобраться с ошибкой, посмотреть другой файл. Хороший UX не заставляет выбирать между «продолжить основную задачу» и «разобраться с этим сейчас», а позволяет делать и то и другое параллельно.

Пожалуй то, насколько легко система помогает держать под контролем сложность самого процесса разработки, один из интересных критериев зрелости agentic IDE.

AI в разработке

Использовать LLM как собеседника в чате или собрать агента, который работает автономно?

Коллеги из Alpina Digital три месяца строили контент-пайплайн: сбор новостей → генерация видео → публикация в YouTube, TikTok и Reels; использовали три подхода.

✔️Сначала был ассистент в чате. 
Модель писала, человек копировал, монтировал и публиковал. На 10 видео в неделю уходило 4 часа, из которых 30–40 минут на диалог с LLM.  

✔️Потом собрали агента в n8n. Два дня на сборку, два на отладку. 
Визуальный редактор получился неудобным для итераций, без нормальной версионности, отладка — разглядывание JSON. Инструмент рабочий, но для одного человека, у которого есть другие задачи, сомнительное решение.

✔️Перешли на Python через Claude Code. 
Выгрузили workflow из n8n в JSON, скормили LLM, попросили адаптировать. За вечер получили первый рабочий пайплайн в код. 

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

• Ассистент в чате подойдет для задач, которые возникают редко и требуют живого творчества на каждом шаге. Если нет API для автоматической загрузки результата, он остается единственным вариантом.
• Агента стоит писать, когда задача повторяется регулярно, а пайплайн стабилизировался. 
• Визуальный конструктор подходит командам без Python-экспертизы и ресурсов на её получение. Работает для небольших пайплайнов (до 20 нод), которые редко меняются.
• Код на Python становится выгоднее, когда логика разбивается на несколько пайплайнов с переиспользуемыми сервисами. Он дает контроль через git и дешевле конструктора, если есть кастомная обработка или доступен Claude Code.

AI в разработке

Архитектура для ИИ-агентов: от «магического» кода к инженерному процессу

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

✔️ Агенту нужен не просто промпт, а инженерный harness.

В статье Clean Architecture для AI-агентов описано, что основная сложность смещается от генерации кода к организации среды, в которой агент работает. Вводится понятие harness — репозиторно-локальной инженерной системы.
Её задача превратить человеческое намерение в проверяемое изменение продукта. Состоит из трех слоев: оркестрации (кто и что делает), семантики (модель продукта, а не просто список файлов) и валидации (проверка результата). 
Подход перекликается с нашей философией отталкиваться не от красивого решения, а от стоимости надёжного изменения. Внедрять сложные системы нужно контролируя процесс целиком, включая среду их создания.

✔️ Правила передаются не через пожелания, а через скиллы и код.

Статья Скилл для ИИ-агента: как превратить пожелание в правило предлагает очень прагматичный инструмент — скиллы как инструкции для агента «как работать в конкретном проекте». Объяснять правила в каждом промпте бесполезно, ведь контекст меняется и старые договорённости забываются. 

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

✔️ Опыт передаётся через процесс, а не только через документацию.

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

Из описанных шести правил хочется выделить два:
1.  Агент проходит тот же путь, что и разработчик, от исследования и контракта к реализации и проверке.
2.  Первый эталон становится примером для всего остального — качественно проверенная реализация одного метода задаёт паттерн для всех последующих, превращаясь в few-shot пример для агента.

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

✔️ Подведем итог.

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

Инженерная дисциплина становится ещё важнее, когда скорость генерации резко возрастает.

AI в разработке

«Модельная усталость»: гонка, которую уже не выиграть

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

• Anthropic представила Claude Fable 5.1 и Mythos 5.1;
• Meta — Muse Spark 1.3;
• Google — Gemini 3.8 Flash;
• а OpenAI — GPT-6 Astra. 

Новая реальность, где интервал между релизами сократился с 37,5 дней в 2023 году до 11 дней в 2026-м. Ввиду высокой конкуренции компании вынуждены постоянно напоминать о себе, создавая шум, который становится сложновато осмыслять.

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

Оценка инструментов меняется и уже нет смысла выбирать самую умную модель. Выигрывает тот, кто умеет управлять нестабильностью: строить абстракции над провайдерами, проектировать системы, устойчивые к смене модели, и оценивать не пиковую интеллектуальность, а предсказуемость, стоимость и интеграционные риски.
 
К слову, в июле 2026 года более 1000 сотрудников ведущих AI-лабораторий подписали петицию с призывом замедлить темпы разработки. Аргументировали тем, что команды не успевают документировать изменения и проводить полноценное тестирование безопасности, а модели все чаще совершают действия за пределами дозволенного (вспомним недавний взлом Hugging Face моделями OpenAI), и в итоге цена скорости становится слишком высокой. 

AI в разработке

Тесты зелёные, а мержить нельзя. Новый бенчмарк вскрыл проблему

Мы привыкли оценивать код, сгенерированный ИИ-агентами, по принципу «прошел/не прошел тесты». Новый бенчмарк SWE-Gate от исследователей из нескольких университетов показывает, что в реальной разработке «работает» и «готов к мержу» это очень разные вещи.

Из 644 исправлений от четырех LLM, которые успешно проходили функциональные тесты, 221 (34.3%) нарушали требования, которые обычно выявляет code review. Код технически работал, но содержал ошибки в семантике сообщений или неправильные типы данных, имел проблемы с очисткой ресурсов или не соответствовал архитектурным паттернам проекта. Все то, что не проверяется автотестами, но мгновенно цепляет глаз ревьюера.

Модели решают задачу «исправить баг», но задача разработки шире: создать поддерживаемый, консистентный код, который вписывается в контекст проекта. 
Авторы SWE-Gate предлагают явно кодифицировать «правила игры» для агентов. Если мы хотим, чтобы они генерировали код, готовый к ревью, эти требования нужно превратить в исполняемые проверки после функциональных тестов.

AI в разработке

AI-агенты пишут код, собирают приложения и… взламывают системы 🙃

Агенты уже не просто помогают разработчикам, а начинают работать вместо них, и иногда по другую сторону баррикад.

GitHub продолжает превращать свой Copilot из помощника в полноценного участника разработки.
В свежем обновлении появились новые возможности для VS Code Agents, автоматическое разрешение комментариев в Code Review и генерация commit message после внесённых AI-исправлений. Цикл становится примерно таким: поставил задачу → агент написал код → сам его проверил → сам внёс правки. 
А в Copilot CLI появилась система HydraFusion, которая сама выбирает подходящую комбинацию моделей под конкретную задачу, балансируя между качеством, стоимостью и скоростью.

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

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

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

AI в разработке

Cloudflare начал различать AI-ботов

Вчера, 15 сентября, Cloudflare добавил настройки для AI-трафика на новых доменах.
Теперь автоматические системы разделяются на три категории: 

Search — поисковые краулеры;
Agent — AI-агенты, которые действуют от имени пользователя;
Training — боты, собирающие контент для обучения или дообучения моделей.

По умолчанию для новых доменов Cloudflare будет блокировать Agent и Training на страницах с рекламой, а Search оставлять разрешенным.
Причем отдельное внимание уделяется агентам, которые в реальном времени заходят на сайты по запросу пользователя, например, browser-use системам.

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

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

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

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

AI в разработке

Если AI способен написать функцию, значит ли это, что он способен вести разработку? 

Benchmark'и для сравнения AI coding tools начинают меняться. 
Google выпустил Android Bench 2.0 и добавил задачи, которые требуют от AI-агента нескольких дней работы: обновить зависимости, добавить крупную функцию, собрать приложение с нуля или перенести его с другой платформы.
Причем теперь оценивается не только итоговый pass/fail, но и степень выполнения задачи. 

Результаты показывают, что написать новый код агентам пока проще, чем разобраться в существующей системе.
На сложных долгих задачах лучший результат по pass rate составил около 28%, тогда как на исходном наборе задач Android Bench он был около 91%. 

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

Похожую проблему пытается измерить новый benchmark Real-SWE, где AI-агенты работают не с публичными учебными репозиториями, а с приватными production-кодовыми базами реальных компаний. 
В задачах есть биллинг, налоги, миграция клиентов и изменения сразу в нескольких сервисах.
То есть агенту нужно понять существующую архитектуру, бизнес-логику и правила конкретной команды.

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

Исследователи Google Research проанализировали 91 набор правил для coding agents и провели интервью с 15 опытными разработчиками, чтобы понять, каким должно быть поведение AI-агента в реальной инженерной команде. 

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

Получается, что для профессиональной разработки уже недостаточно измерять агента только по принципу «написал ли он рабочий код». Важным становится, как именно агент работает внутри инженерного процесса, следует ли правилам проекта, объясняет ли свои действия, взаимодействует ли с человеком и помогает ли поддерживать качество системы на дистанции.

AI в разработке

Код пишется быстрее, а релизы нет. Два взгляда на одну проблему

За последние дни на Хабре вышли два материала, которые стоит прочитать вместе. Один про месяц работы с coding-агентом на реальном проекте, второй — про команду, где Claude Code делает вообще всё, а инженеры работают по 12–13 часов, просто нажимая Enter. 

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

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

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

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

Если разработчик писал функцию двадцать минут, он понимает её устройство, но когда агент за пару минут приносит сотни строк, картину приходится восстанавливать заново. В итоге работа смещается с написания на проверку. 

Во второй статье противоположная крайность. Разработчик устроился в компанию, где Claude Code создаёт спецификации, код, тесты, задачи и отчёты.

Руководство требует ускорения, потому что «написание кода больше не бутылочное горлышко».
Люди работают по 12–13 часов, но по сути только нажимают Enter: никто не читает код и не исправляет баги. Цитата из статьи: «никто больше не думает. Всё делает LLM. Это так изматывает».

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

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

AI в разработке