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

Релиз Veai 5.7 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE) собрал в себе много исправлений неочевидного UX, с которым вы сталкивались ежедневного. Меньше ручных переключений, меньше ожидания между шагами, меньше повторов при сбоях.

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

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

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

Айсберг Claude Code: 30+ возможностей от новичка до автоматизации

Привет! Меня зовут Рамиль, я программист отдела серверных решений ЮMoney. Я собрал полезные советы по claude code и организовал её в интерактивном формате «Айсберга». Это способ подачи материала от очевидного к малоизвестному. На верхушке — то, что знает каждый, кто хоть раз открывал Claude Code. Чем глубже — тем реже встречаются эти знания, и тем больше они меняют подход к работе.

Пришёл в команду, открыл тесты — should render, снэпшоты, CSS-классы в ассертах. CI зелёный, покрытие растёт. Всё хорошо? Нет. Тесты падали при любом рефакторинге, но пропускали реальные баги в логике. Ложная уверенность, которая хуже отсутствия тестов. И проблема была не в отдельных файлах — а в самом инструменте, который провоцировал так писать.

В какой-то момент понял, что у меня открыто четыре IDE с разными проектами. В каждой крутится одна или несколько сессий с Claude AI. А я сижу и жонглирую вкладками. Планирование. Ревью там, где критично. Там, где не критично, накидываю хитрые тестовые сценарии, тестируя проект как black box. Постоянно переключаю контекст у себя в голове чтобы понять, а на каком шаге я на этой вкладке и в этом проекте. И потом бам, пора спать. Или есть. Или идти гулять с ребёнком. И в этот момент все процессы останавливаются. Агенты ждут. И получается по факту, что я слабое звено. Не модель с её косяками, а я. Начинаю меньше спать. Парадокс, вроде как должно было быть все наоборот: модели работают, ты спишь. Ан нет.

Привет. Делаю расширение для VS Code, которое даёт OpenCode CLI полноценный графический интерфейс. Называется PrimeCode.

Суть простая: OpenCode — мощный CLI-агент, но работать с ним в терминале на длинных сессиях не всегда удобно. Хотелось нормально видеть, что происходит — tool calls, изменения файлов, контекст, токены. Не форк, не отдельный продукт — именно UI-слой поверх OpenCode, который общается с ним через SDK и SSE-стриминг.

Если вы уже работаете с OpenCode и у вас есть существующие сессии — можно продолжить работу с ними прямо через расширение. Вся история, контекст, tool calls — всё подхватывается.

Одной из самых сложных частей C++ до сих пор считаются правила поиска имён, и ошибки связанные с name lookup проявляются обычно уже в рантайме. Код компилится и даже работает какое-то время, но при свете луны ведёт себя не так как ожидает программист. За простыми идентификаторами скрывается многоуровневая система областей видимости, категорий имён и специальных правил, и очень многое в нашем текущем стандарте растёт прямиком из восьмидесятых, частенько без изменений. Давайте посмотрим как компилятор видит имена в C++, какие области видимости существуют и почему они ведут себя по-разному.

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

«Происходит что-то масштабное». «Большинство людей не узнает об этом, пока не станет слишком поздно».

Более 85 миллионов человек увидели этот пост. Поделились. Поддержали.

И все ушли с совершенно неправильными выводами.

Не потому что данные неверны — данных не было изначально. А потому что Мэтт Шумер очень хорошо рассказывает страшные истории. Так, что читатель впадает в гипноз и принимает каждый аргумент за чистую монету.

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

Потом, в продолжении, он сказал CNBC, что «не хотел никого пугать» и что «если бы знал, насколько это станет вирусным, переписал бы некоторые части».

Конечно.

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

Я покажу вам одну простую кривую спроса, которая опровергает каждое заявление из серии «ИИ всех заменит».

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

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

В новом переводе от команды Spring АйО рассмотрим, как DPoP меняет эту модель, привязывая токен к ключу клиента, зачем это нужно backend-разработчику и как поднять рабочую реализацию на Keycloak и Quarkus.

Привет, Хабр! Меня зовут Роман, я программист в команде «Гравитон» и моя задача в компании — разработка API/CLI интерфейсов и приложений на языке Python.

Цель данной статьи в том, чтобы показать как через внедрение «типовых подходов» и вспомогательных библиотек/утилит очень сильно упрощается поддержка проекта в настоящем (при передаче другому человеку или разработке в команде) и в будущем (возобновили проект спустя время).

Первое, что нужно сказать — проект на Python это не только сам Python, но и множество технологий используемых вместе (Git, Docker, и т.д.). В этой статье мы сконцентрируемся на самом проекте, а именно с чего начать, что прикрутить, что учитывать при разработке.

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

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

Это будет своего рода дорожная карта подготовки агента к продакшену.

В одной из сессий Claude написал у меня 47 файлов. 1 892 строки. Два новых сценария, рефакторинг шести обработчиков, миграция конфига. 38 минут.

Каждый коммит — автоматический CPG-анализ. Каждый промпт — обогащение контекстом из графа. Каждый пул-реквест — радиус поражения и оценка риска.

Не потому что я не доверяю ИИ. А потому что я не доверяю никакому генератору кода без автоматической верификации. Включая себя.

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

Буквально пару лет назад было весело обсуждать фронтендеров, у которых каждые полгода появлялся новый фреймворк или библиотека. Кажется, сейчас у них всё устаканилось и breaking change изменений в направлении развития уже не видно. Ну или может я о них не слышу.

Зато теперь источником новостей и обсуждений стал великий и ужасный искусственный интеллект и всё, что с ним связано: релизы моделей каждую неделю, новые агенты каждый месяц и инновационные протоколы каждые полгода. Я думаю, вы уже слышали про MCP, вероятнее всего слышали про Skills, но вот с ACP возможно ещё не сталкивались. Сегодня поговорим именно о нём.

Недавно в популярном Facebook-посте: «GPT работает всё хуже. Просишь пересчитать формулу на 600 грамм, он бодро выдаёт две по 300. Пора, видимо, валить».

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

Когда меня просят подсказать, как структурировать веб-сервис, я всегда начинаю с одного и того же: напишите сервер, который в ответ на HTTP-запросы выдаёт текст в формате HTML.

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

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

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

Стоит вам это понять — и Веб откроется вам таким, каким его вижу я: как самый простой, лёгкий и наиболее мощный интерфейс для вычислений, какой только есть на свете.

Привет, Хабр!

Я Анна Круглова, в Диасофт занимаюсь развитием инструментов автоматизации тестирования на базе искусственного интеллекта.

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

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

Я попытался разобраться на примере современной FLUX.2-dev. Чтобы хотябы теоретически влезать в доступную мне VRAM на моем оборудовании я выбрал вариант GGUF Q4_K_M. И вот тут началось все самое интересное.

Сердце стучит, руки дрожат, голова полна мыслей — но ты принимаешь сложное решение.

Меня зовут Иванов Владимир, и сегодня расскажу историю о сложном решении в первые недели моего тимлидства на прошлом месте работы.

Школьные олимпиады по информатике до сих пор воспринимаются как отдельный мир, где дети решают абстрактные задачи, далёкие от реальной работы. Но сильный олимпиадник сегодня уже не просто быстро пишет код. По уровню алгоритмического мышления он близок к junior, а иногда и к middle-разработчику, только без боевого опыта. Он умеет жить в таймлимитах, думать об асимптотике, быстро проектировать решение, дебажить под давлением и работать не только с чистой алгоритмикой, но и с задачами по ИИ, безопасности и робототехнике. Поэтому заключительный этап Всероссийской олимпиады школьников по информатике, который в этом году проходит с 22 по 28 марта, показывает, какой инженер будет нужен индустрии через несколько лет. Чтобы понять, из каких скилов собирается портрет будущего инженера, мы посмотрели, как сегодня устроен финал олимпиады, какие задачи там дают и чему он на самом деле учит.

Собрал свой опыт настройки проектов для кодовых агентов. Как написать правила, чтобы агент не делал глупых ошибок, как научить его работать с окружением, как делиться скиллами между репозиториями и не сойти с ума, когда в команде у каждого свой инструмент — Claude Code, Cursor, Copilot.