👩‍💻 Cursor теперь доступен в IDE JetBrains

Cursor пришел в IDE JetBrains: IntelliJ IDEA, PyCharm, WebStorm и другие теперь подключают его через Agent Client Protocol (ACP). А это значит, что работать с агентом можно прямо в JetBrains-IDE.

Cursor ACP дает выбор модели под задачу: OpenAI, Anthropic, Google и модели Cursor. Под каждую модель у Cursor своя агентная обвязка, чтобы держать качество и скорость.

Как включить:

– установить Cursor ACP из ACP Registry
– авторизоваться существующей учеткой Cursor

Плагин является бесплатным для пользователей на платных тарифах Cursor.

🔗 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1006764/

🔓 Copyright больше не защищает ваш код

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

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

• Сначала собираю спецификацию (конечно, с помощью ИИ);
• По спецификации делаю план реализации;
• План отдаю ИИ-агенту.

В плане есть:

• гейты перехода между этапами;
• тесты;
• definition of done.

Дальше агент просто проходит по плану. Конечно, я сильно упрощаю, но общий принцип понятен.

И вот здесь возникает интересный момент.

Спецификацию можно собрать практически из чего угодно.

Например, из проекта под «заразной» лицензией вроде GNU GPL.

Можно внимательно изучить проект и написать подробную спецификацию:

• какие есть модули;
• как они взаимодействуют;
• какие алгоритмы используются;
• какие интерфейсы между компонентами.

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

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

• он работает;
• код другой;
• структура файлов может быть другой;
• даже язык программирования может быть другим.

Но по сути это та же система, просто переписанная по спецификации.

Фактически получается что-то вроде автоматизированной clean-room реализации.

И вот тут возникает вопрос:

Защищает ли open-source лицензия от такого сценария?

Кажется, что нет. Потому что copyright защищает:

• конкретный код;
• конкретную реализацию.

Но не защищает:

• идеи;
• алгоритмы;
• архитектуру системы.

ИИ просто делает переход от чужой архитектуры к новой реализации очень дешёвым.

Раньше clean-room реализация требовала команды инженеров. Теперь это можно провернуть с помощью одного человека и пары ИИ-агентов (умножить на X).

Поэтому у меня появилась мысль:

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

Потому что лицензии регулируют копирование кода, а не пересборку системы по её описанию.

Утекшие исходники

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

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

❓ Интересно, обсуждалось ли это уже где-нибудь.

🧩 Разница между параллельными и распределёнными вычислениями

Ускорение работы приложения можно получить двумя способами: распараллелить работу между ядрами одного компьютера или разнести ее по нескольким машинам.

Параллельные вычисления живут внутри одного узла: части задачи выполняются одновременно на CPU-ядрах, нескольких процессорах или ускорителях GPU/TPU.

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

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

🔗 Подробности в нашей статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1008990/

Для JetBrains IDE вообще есть нормальный AI без проблем в РФ?

Периодически в @spring_aio_chat и на Хабре прилетают вопросы про то, какие сейчас есть варианты использования ИИ внутри IDE.

Один из вариантов – Kodacode.

Работает:
— в OpenIDE и JetBrains IDE
— в VS Code
— и даже в CLI

Что кажется наиболее полезным:
— агентный режим: без него от ИИ-помощника смысла не так много
— доступ к разным моделям: GLM, Gemini, DeepSeek, и другие
— работает без танцев с VPN и оплатами: у многих это сейчас главный стоп-фактор для AI-инструментов
— есть бесплатная модель: хватает для повседневных задач

📚 Подробнее про Koda для JetBrains IDE читайте на Хабр: https://habr.com/ru/companies/koda/articles/986976/

👩‍💻 JEP 524 в JDK 26 — второй preview PEM API.

Наконец-то работа с PEM в Java становится похожа на API, а не на набор ручного парсинга, Base64 и странных телодвижений.

Справка: PEM или Privacy-Enhanced Mail - это текстовый контейнер для криптографических данных. Проще говоря – это способ хранить или передавать ключ, сертификат или другой crypto-объект не в бинарном виде, а в текстовом.

Раньше с PEM работали так:

String pem = "-----BEGIN PUBLIC KEY-----\n"
        + Base64.getMimeEncoder(64, "\n".getBytes())
                .encodeToString(publicKey.getEncoded())
        + "\n-----END PUBLIC KEY-----";

А в обратную сторону, но уже с ручной нормализацией PEM, Base64-декодированием и KeyFactory:

String normalized = pem
        .replace("-----BEGIN PUBLIC KEY-----", "")
        .replace("-----END PUBLIC KEY-----", "")
        .replaceAll("\\s", "");

byte[] der = Base64.getDecoder().decode(normalized);

PublicKey key = KeyFactory.getInstance("EC")
        .generatePublic(new X509EncodedKeySpec(der));

По факту PEM в Java долгое время был не отдельным API, а набором низкоуровневых шагов, которые разработчик собирал руками.

А теперь это выглядит так:

var encoder = PEMEncoder.of();
String pem = encoder.encodeToString(keyPair);

var decoder = PEMDecoder.of();
KeyPair decoded = decoder.decode(pem, KeyPair.class);

То есть ключевую пару можно закодировать в PEM и декодировать обратно буквально в несколько строк.

Во втором preview:
— PEMRecord переименовали в PEM
— добавили decode()
— расширили поддержку KeyPair и PKCS8EncodedKeySpec
— упростили шифрование через EncryptedPrivateKeyInfo

А так, как все это дело еще в preview, не забываем использовать --enable-preview.

❓ Минус еще один кусок криптографической копипасты из Java-кода. PEM в Java постепенно перестает быть унылым?