Приглашаем на доклад Deep Dive into JVM JDI: Capturing Live Execution for Automatic JUnit Test Generation
Привет! Если на выходных судьба занесёт вас в Новосибирский Академгородок, приходите на технический доклад с мемами от нашего коллеги Даниила Степанова на самой ламповой Java-конференции Сибири — SnowOne 2026 ❄️.
Deep Dive into JVM JDI: Capturing Live Execution for Automatic JUnit Test Generation
Глубокий технический разбор архитектуры инструмента, который использует Java Debug Interface (JDI) для захвата состояния работающей JVM и автоматического синтеза валидных unit-тестов.
Что будет в докладе:
Deep Dive в JDI. Подробный рассказ про JDI, преимущества и недостатки, а также как его использовать в нестандартных сценариях для безопасного захвата Heap и Stack Frame в реальном времени.
Реконструкция объектов. Reverse Engineering JVM-состояния для воссоздания сложных графов объектов.
Синтез Java-кода. Как превратить сырой дамп памяти в чистый, валидный JUnit-тест.
Роль LLM. Для решения каких проблем мы используем искусственный интеллект?
Доклад будет полезен Java-разработчикам, тем, кто интересуется внутренним устройством JVM, и всем, кто хочет автоматизировать написание тестов.
SSP SOFT — компания работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошлый год мы наняли 179 сотрудников.
Рабочие места предоставляются в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в офис разработчиков в Томске и на удаленку из любой точки России.
Работа в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Что предоставляет экосистема SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное менторство ускорят развитие до максимума. ✅ Офис, гибрид или фулл-удаленка? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструктычистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Хорошей практикой в C++ считается размещение функций рядом с типами, для которых они предназначены. Однако, чтобы такой подход работал корректно, важно понимать механизмы поиска имён и знать, где можно размещать функции, не нарушая правил языка.
Совсем недавно мы проверяли проект OpenCV и нашли там довольно интересную ошибку. Рассмотрели её подробнее и написали новую статью специально для тех, кто хочет разобраться с механизмом поиска имён в C++, в частности с поиском имён по аргументам.
На Upwork появилась вакансия, которая отражает состояние индустрии ИИ-разработки: заказчик ищет вайбкодера, чтобы доделать приложение, которое не доделал предыдущий вайбкодер. Завершив уже больше половины работы, прежний исполнитель вдруг обнаружил, что у него больше «нет времени».
Вакансия гласит: «У нас есть незаконченный проект на GitHub, который был доведён при помощи вайбкодинга примерно до 75% готовности. У прошлого вайб-одера нет времени доделать его. Мы предоставим документацию и цели, чтобы вы могли использовать ИИ и свои навыки для завершения работы». Исполнителю предлагают создать персональный API-ключ, чтобы тот не тратил свой.
Вакансия понравилась пользователям Reddit. «Ищу несертифицированного хирурга, чтобы исправить неудачную операцию, выполненную предыдущим несертифицированным хирургом», — иронизирует один. «Ищу несертифицированного инженера-конструктора, чтобы починить дом, который рухнул из-за предыдущего вайб-инженера», — добавил другой. Кто-то отметил, что «75% готовности — это минус 20% готовности. Разгрести то месиво, которое уже накодили, займёт больше времени, чем написать всё с нуля». Кто-то напомнил принцип Парето, мол, оставшиеся 20% — на самом деле 80% работы.
Практический Тренажер по Java — самый популярный тренажер по Java на Stepik
В 2024 году я опубликовал курс «Практический Тренажер по Java» на платформе Stepik. Тогда это был просто практический курс с задачами — без воды, без длинной теории, только код и постоянная тренировка.
Прошло несколько лет.
Сегодня курс проходит более 19 000 учеников, и это самый популярный тренажёр по языку Java на платформе Stepik.
Курс продолжает активно развиваться, регулярно пополняется новыми задачами, а вокруг него сформировалось живое и активное сообщество.
И я хочу заново пригласить вас в этот проект.
Почему Java?
Java — один из самых востребованных языков программирования в мире.
Он используется в:
— веб-разработке
— мобильной разработке (Android)
— корпоративных системах
— финансовых сервисах
— высоконагруженных backend-проектах
Java — это стабильность, масштабируемость и высокий спрос на рынке труда.
Что представляет собой курс сегодня?
Это полностью практический формат обучения. Только задачи и реальная практика.
Многие ученики используют тренажер как системную подготовку к техническим интервью. Такой формат не просто помогает решать задачи, а выстраивает алгоритмическое мышление, формирует уверенность в собственном коде и укрепляет уверенность в своих силах и уровне владения Java.
Привет, Хабр. Делимся подборкой бесплатных уроков, которые скоро пройдут в Otus. Опытные практики проведут занятия онлайн — вы сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь.
10 марта 20:00. «Мультитенантная архитектура в Laravel: как масштабировать проекты под десятки и сотни клиентов». Записаться Открытый вебинар курса «Framework Laravel»
Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?
У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.
Я хочу написать о нем статью, но не в стиле ностальгический обзор ретро-игр такого в сети полно. Моя цель вдохнуть в него жизнь и проверить, пригоден ли этот 23-летний дедушка для современной разработки.
На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?
Запасной вариант, если основному ПК не хватит инструкций.
В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.
На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.
Что планирую потестить:
C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.
Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).
C++: Сравнить скорость сборки проекта с модулями и без них.
Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.
IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.
Прошу совета у сообщества: накидайте идей! Какие бенчмарки прогнать? Какой софт или специфические проекты попробовать собрать, чтобы нащупать предел возможностей?
Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!
OpenAPI Generator через призму статического анализатора
Знаете ли вы про OpenAPI Generator — open source проект, задача которого — автоматическая генерация клиентских библиотек, серверных заглушек, документации и файлов конфигурации на основе спецификации OpenAPI в формате JSON или YAML. Проект является достаточно популярным: у него чуть больше 25000 звёзд на GitHub.
Питер Штайнбергер пишет код не в Claude Code. Для многих это окажется неожиданностью, поскольку его проект OpenClaw был задуман в первую очередь как прокладка для общения с большими языковыми моделями компании Anthropic — в том числе в те периоды, когда этот самопис назывался warelay, Clawdbot или Moltbot. Тем не менее разработку Питер предпочитает вести в Codex компании OpenAI.
Прожорливый на токены и максимально небезопасный продукт привлёк внимания много и сразу. Энтузиасты по всему миру срочно ставят чат-бота на Mac mini и виртуальные серверы, чтобы потратить как можно больше токенов языковой модели Claude Opus. Зашла даже речь о продаже проекта. Как известно по интервью, Штайнбергер всерьёз рассматривает предложения приобрести OpenClaw и для этого выдвигает обязательное условие о сохранении открытости проекта. Утверждается, что наиболее интересные оферы поступили от Meta¹ и OpenAI, одних из самых крупных игроков в индустрии искусственного интеллекта.
Вообще, если следить за новостными лентами и его личным микроблогом, можно подумать, что Штайнбергер от дел отошёл, и просто бегает по интервью и встречам с фанатами. На самом деле разработка OpenClaw продолжается, новые версии выходят ежедневно, но и на подкасты про программирование время остаётся. (Ещё бы: Штайнбергер не пишет ни строчки кода, а просто промптит языковые модели — очень модный сейчас подход). К примеру, аккаунт OpenAI Developers обещает выпустить 23 февраля большое видеоинтервью с Питером, где тот расскажет про свой новый рабочий процесс с Codex. Пока что выложили просто небольшой тизер этого видеоролика.
Любопытно, что написал про это интервью сам Штайнбергер. Как он рассказывает, пришлось послать человека сбегать в магазин за новой футболкой — та, в которой австриец пришёл на съёмку, содержала логотип неназванной компании, и сотрудникам OpenAI подобное не понравилось. Штайнбергеру разве что дали выбор, в чём он будет на камере: либо в синей, либо серо-синей футболке.
Транснациональный холдинг Meta (1) — экстремисткая организация, его деятельность запрещена.
Не секрет, что про написание кода AI-агентами в автономном режиме (я буду пользоваться термином vibe coding, хотя он не вполне точен) сейчас прям нам вещают из каждого динамика.
С другой стороны, я довольно много использую AI для написания кода, и мои ощущения - «иногда работает неплохо, но надо проверять и высок риск, что в код пролезет какая-то дичь». Т.е. это сильно расходится с историями из интернета. Я внезапно смог четко сформулировать для себя, почему так и когда это работает, а когда нет.
Есть два типа программистов. Первые усиленно пользуются отладчиком, пишут и запускают 100500 тестов и все равно их код часто сбоит, когда что-то идет не по happy path сценарию. Вторые думают, идут гулять с собакой, возвращаются и пишут в разы меньше кода, который работает намного надежнее. На самом деле я, конечно же, идеализирую, и все мы находимся между типом 1 и типом 2, просто кто-то чуть ближе к одному, а кто-то к другому полюсу.
Но в чем принципиальная разница между этими типами? У типа 1 есть какое-то, часто очень локальное предположение о том, как должен работать код, он действует по принципу monkey see, monkey do. Второй пытается построить в голове модель того модуля, который он реализует, и дальше уже, имея модель, овеществляет ее в коде. Второе, как правило, быстрее и надежнее, но на порядок сложнее и требует глубокого понимания всех вовлеченных в процесс элементов.
При этом в IT есть масса задач, которые решаются первым способом, не сильно подготовленными инженерами. Будем честны, последние лет 15-20 первый подход изрядно доминирует в commodity IT, и этому есть объективные причины. Это накладывает отпечаток на инструментарий, культуру, построение SDLC процессов и т.п. (некоторые менеджеры просто не верят, что есть инженеры, которые без тестов и плясок с бубном могут посмотреть на проблему и сказать «вот так делайте»).
Возвращаясь к vibe coding - AI-агент это чистый тип 1. Модель системы и процессов в ней у него не глубже, чем память у золотой рыбки, потому что он оптимизируется под внешний feedback, а не под внутренние инварианты. Он, конечно, пытается что-то документировать, и ему пытаются писать требования, но все это работает довольно тяжело. Одна из причин в том, что инженер (хороший) не только машина для нажимания кнопок, но и источник множества мельчайших, но критически важных функциональных и нефункциональных требований, многие из которых ни бизнес аналитик, ни product owner прописать не могут (тут я в очередной раз сошлюсь на Polanyi's paradox - https://en.wikipedia.org/wiki/Polanyi%27s_paradox).
Это обстоятельство далеко не всегда имеет смысл и не всегда важно. Если вы делаете сайт для записи в барбершоп и вам надо показать список барберов, потом список слотов и потом сделать кнопку book, то строить глубокую модель системы смысла не имеет. Если вы делаете софт для электронной педали газа в автомобиле, то помимо тестов, хорошо бы точно понимать, как что работает и для чего каждая строчка кода и каждая из переменных. Между этими двумя примерами, разумеется, есть широкое поле для обсуждения.
Возвращаясь к AI-агентам - по идее искусство работы с ними заключается в понимании того, где ваша задача находится относительно этой системы координат, и в выдаче агенту задания нужного размера и нужной сложности. Где-то можно доверить делать большой кусок, где-то не более одного небольшого метода, а где-то вообще надо руками написать код. Неожиданное следствие для меня как динозавра, больше полагающегося на понимание кода, чем на тесты - даже если тесты не важны мне, все равно стоит их завести в какой-то мере для AI-агентов, если я хочу ими пользоваться для ускорения разработки.
Надо только правильно их таргетировать - для каких-то кусков они имеют смысл, а для каких-то просто трата времени.
Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT
Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке— за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Что предоставляет экосистема SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное менторство ускорят развитие до максимума. ✅ Офис, гибрид или фулл-удаленка? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
Греческие мифы рассказывают про титана Прометея, который украл у богов огонь и поделился им с людьми. Персонажа за это приковали к скале не просто в наказание, но и в назидание остальным: знание не даётся бесплатно, за него нужно платить.
Если судить по названию, автор проекта Promethee кары богов нисколько не боится. Некто SMNX взял самый сакральный слой современного компьютера — прошивку UEFI — и добавил туда JavaScript. Как гласит readme.md, на старте загрузки Promethee подхватывает script.js с загрузочного тома и исполняет его, то есть этот скрипт и будет загрузчиком.
Понятно, что на боевую машину это ставить смысла нет, это просто эксперимент. Лабораторный характер подчёркивается сборкой и запуском в QEMU. Проект реализован автономно (freestanding), с минимальными заглушками libc. В качестве движка используется Duktape — встраиваемый JS-движок, рассчитанный на портируемость и компактность.
Для SMNX это уже не первый подобный забавный самопис. На своём сайте автор представляется как Клем и прямо говорит, что любит строить «операционные системы, компиляторы, инструменты и веб-движки». Там же перечислены другие поделки: модульная хобби-операционка SkiftOS, HTML/CSS-движок Vaev, экспериментальные инструменты для генерации документов, а также операционная система с эстетикой брутализма и идеалами UNIX семидесятых BRUTAL.
JavaScript исторически задумывался как язык, который оживляет веб-страницы и делает их интерактивными. Сегодня же он расползся по всем слоям стека, от микроконтроллеров до ультра-лёгких движков для Интернета вещей. В том числе бывают попытки писать на JavaScript то, что не следует, хоть операционные системы. Самый цитируемый пример — это NodeOS, дистрибутив Linux, где вместо привычного пользовательского мира предлагается использовать Node.js и npm как основной пакетный менеджер, и многие утилиты предполагается брать из npm-экосистемы. Другой полюс — runtime.js, библиотечная операционка, где JavaScript-рантайм на базе V8 и минимальная операционка собираются в лёгкий неизменяемый образ виртуальной машины для запуска на KVM, то есть ОС здесь становится упаковкой для единственного приложения на JS.
Автоимпорт при копировании кода — штука настолько приятная и удобная, что без неё уже невозможно представить работу в IDE.
Мы пошли дальше и вслед за умным импортом во время набора кода сделали автоматическую инжекцию бинов при копировании кода!
Теперь при копировании кода Amplicode автоматически добавляет нужную инжекцию бинов. С учётом контекста, @Primary, @Qualifier, дженериков, @Bean-методов, Java и Kotlin — без ручной возни после вставки.
Будет доступно всем пользователям Amplicode, без подписки.
Приглашаем на бесплатный вебинар “Обзор AI-ассистентов для кодинга в 2026”
Когда: 12 февраля 2026 года, 14:30 (Мск) Формат: онлайн · 45 минут Спикер: Михаил Костицын, ведущий разработчик Veai, преподаватель СПбГУ и руководитель Летней школы Veai для студентов ИТМО и СПбГУ Бесплатная регистрация:по ссылке
AI-ассистенты для программирования за последние годы прошли путь от простого автодополнения до полноценных агентов, способных анализировать проект, принимать решения и выполнять сложные задачи. На этом вебинаре мы разберём, какими на самом деле являются AI-ассистенты в 2026 году и как получать от них пользу в корпоративной разработке.
Рассмотрим эволюцию AI-инструментов для написания кода: от inline-генерации и чатов до агентных систем. Обсудим основные классы решений (LLM, AutoML, agent-based подходы), их сильные стороны и ограничения при работе с большими кодовыми базами. Отдельное внимание уделим сравнению консольных агентов, IDE-плагинов и IDE со встроенными AI-возможностями, а также как правильно собирать контекст и писать промпты, работать с MCP-серверами и решать проблему засорения контекста.
Обсудим ключевые для компаний вопросы: безопасность кода и данных, on-premise развёртывание, риск уязвимостей в сгенерированном коде и контроль действий AI-ассистентов.
В завершение разберём, как выбирать модели и инструменты под конкретные задачи с учётом производительности, стоимости и доступности решений.
Посетители вебинара:
научатся оценивать реальные возможности и ограничения AI-ассистентов в промышленной разработке
будут осознанно выбирать AI-ассистенты под конкретные задачи и команды
смогут оценивать риски безопасности и требования корпоративной среды
узнают, как говорить об AI с менеджментом, маркетингом и другими командами на одном языке.
Вебинар носит прикладной характер и опирается на реальный опыт внедрения AI в промышленную разработку. Михаил Костицын, ведущий разработчик Veai, преподаватель СПбГУ и руководитель Летней школы Veai для студентов ИТМО и СПбГУ, поделится своим опытом пилотирования проектов и ответит на вопросы участников.
Участие в вебинаре бесплатное, необходима регистрация.
Veai — команда профессиональных исследователей и разработчиков с практическим опытом в анализе кода, генерации тестов и поиске уязвимостей. Плагин Veaic собственным AI агентом понимает структуру проекта и подстраивается под его стиль. Ускоряет разработку без потери качества.
🎓 Бесплатные онлайн-курсы для IT-специалистов от Selectel
Совместите обучение с возможностью попробовать нашу инфраструктуру. Выбирайте один из четырех курсов, чтобы сделать первые шаги в профессии или прокачать знания в том, что вы уже умеете.
Системный администратор Linux с нуля. Научитесь работать с командной строкой и основными утилитами Linux, управлять пользователями и файлами, настраивать сети и устранять инциденты.
Погружение в PostgreSQL. Изучите основы реляционных баз данных. Научитесь создавать и связывать таблицы, добавлять, модифицировать и удалять данные.
Первые шаги в JavaScript. Освоите базовый синтаксис, научитесь писать скрипты, управлять DOM и изменять интерфейс веб-страниц. В конце сделаете свой первый пет-проект.
Тестирование мобильных приложений. Научитесь проверять мобильные приложения с учетом специфики разных платформ. Освойте работу с API, логами и трафиком на эмуляторах и реальных устройствах.
Все курсы состоят из текстовых уроков. Можно изучать их в своем темпе, дедлайнов нет. В рамках курсов по тестированию и JavaScript вы получите промокоды и получите возможность потренироваться на нашей инфраструктуре бесплатно. Кроме того, для проверки знаний есть тесты и задания, а в конце обучения мы выдадим сертификат.
Тихий враг или молчаливый союзник: коротко о выравнивании в C++. Часть 2
Казалось бы, тайна выравнивания раскрыта. Вы победили невидимого врага — невыровненный доступ. Память под контролем, но производительность по-прежнему шепчет: "Есть ещё нюансы". Что? Нюансы? Какие? Пришло время посмотреть, что происходит, когда структуры начинают наследовать друг друга. Здесь всё становится... интереснее. Правила игры меняются.
Итак, путь ясен: мы погружаемся в мир наследования, чтобы услышать его диалог с памятью. Давайте сразу к делу. Приготовьтесь, правила только что усложнились. В статье поговорим о выравнивании, наследовании POD-структур и множественном наследовании.
Представлено Duolingo для кодеров — Coddy. Это бесплатный проект, который превращает изучение программирования в залипательную игру. Внутри ежедневные задания, серии дней без пропусков, уровни и рейтинги, чтобы было интереснее не бросать. Можно писать код прямо в приложении на смартфоне или ПК. Всё синхронизируется между устройствами. Больше 15 языков программирования: от популярных Python и JavaScript до C++, Go, Rust и Lua. Есть отдельные направления по аналитике данных, ИИ и веб‑разработке.
Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".
Пример использования cli-stash
Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.
Что умеет:
Сохраняет ваши команды в избранном
Возможность добавить из истории шелла
Нечеткий поиск
Сортировка по частоте использования
И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.
# Установка в Linux
go install github.com/itcaat/cli-stash@latest
# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/
В macOS поставить изян brew install itcaat/tap/cli-stash
Исходники и инструкция по использованию есть на github.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
HATEOAS и Hypermedia получают, на мой взгляд, недостаточно внимания. Подходы, которые описывал в докторской Рой Филдинг, всё реже трактуются в связке с HATEOAS.
Это удивительно, потому как слово REST в обсуждениях я слышу часто. Но только в формате “используйте HTTP глаголы для описания действий”. Или, еще хуже, как синоним HTTP JSON API.
Как же так? Как обсуждать REST без учёта концепции зрелости Ричардсона? Это тема, которая требует дополнительного обсуждения, ведь HATEOAS — высший уровень зрелости REST.
К чему я? Прочитал за два дня книгу Hypermedia Systems. Авторы до этой книги работали над HTMX.
Хоть и сталкивался с HTMX, книга помогла дополнительно прояснить, как HTMX соотносится с HATEOAS. Авторы представляют уверенную аргументацию, что простой HTML можно рассматривать как ключевой элемент реализации HATEOAS. И что SPA с раздутыми JavaScript-фреймворками для маппинга JSON API в HTML — тупиковая ветвь эволюции.
Книгу можно и последовательно читать, и использовать как справочник по HTMX. Она есть в публичном доступе.
Если Вы ещё не встречались с HTMX, HATEOAS, Hypermedia, и не знаете, что это такое, рекомендую всеми руками, объём достаточно небольшой.
Как говорилось в Герои3, астрологи объявили, что новых сеньоров не будет, мы последние
За 2023-2025 рынок entry-level позиций в программировании схлопнулся структурно, а не циклично.
• 🇺🇸 В США количество junior-вакансий упало на -67% за один год
• 🇪🇺 В Европе найм entry-level сократился на -73%, при том что весь рынок упал всего на –7%
• Занятость разработчиков 22-25 лет снизилась на –20% с конца 2022
• Безработица среди выпускников computer science в 2025 - 6.1%, хуже, чем у философов и биологов
• AI автоматизировал именно те задачи, на которых раньше учились juniors: boilerplate, тесты, базовую отладку
• Компании больше не могут позволить себе 6-12 месяцев обучения из-за высоких ставок
• ROI теперь нужен с первого дня, а не “когда-нибудь”
• Junior = расходы + менторинг + риск ухода через год
“Junior” вакансия сегодня = React + Backend + Google Cloud / AWS + CI/CD + 3-5 лет опыта
На одну позицию - сотни и тысячи кандидатов. Первый шаг в карьере фактически убрали, второй (мидл) скоро уберут.
Это не только из-за AI. Основная причина - экономика.
AI стала удобным оправданием, но настоящая проблема, это дорогой капитал и сокращенные бюджеты на обучения.
• Появляется новый вход: AI-augmented developer
• Ожидают готовые production-проекты, end-to-end системы, AI-фичи
• Спрос на таких “джунов” вырос на +143%, пока классические junior-роли падают
Если сейчас убрали 60-70% джунов, то в 2031-2036 рынок получит жесткий дефицит senior и tech lead. Кадровая яма уже заложена. А может и они/мы уже тоже не будут нужны
Старая карьерная лестница “учёба → junior → middle” больше не работает.
Для новичков вход в IT стал сложнее и дороже, а интерны вообще уходят в прошлое
Почему каждый третий ИТ-специалист выбирает работу в промышленности?
Надеемся, мы вас уже убедили, что ИТ — не только бигтех, банки и маркетплейсы. Параллельно существует масштабный, но все еще не настолько популярный для многих пласт — промышленный ИТ, или Heavy Digital. Эта сфера имеет свои отличия: больше физики, железа и процессов, которые нельзя просто «перезапустить».
Как раз на стыке этих двух миров и родился наш тест «Сложный выбор», который мы запустили на Хабре в декабре. В конце, отвечая на вопросы, участники теста узнавали, какая из сфер им ближе, и получали профессиональный портрет.
И неудивительно: тест в первую очередь привлёк айтишников из классической digital-сферы. В своих ответах они чаще выбирали знакомые им ценности и задачи.
Однако сам факт, что они прошли тест и увидели альтернативу, уже показателен. Это может говорить о возникающем вопросе: «А что есть за пределами привычного ИТ?» Предполагаем, что для большинства из них промышленная сфера остаётся пока не выбором, а зоной потенциального интереса — тем, о чём они задумываются, но продолжая работать в привычной сфере.
Промышленный технарь — 33,5%
Это почти треть всех участников — весомая доля.
За этими результатами стоят инженеры, для которых работа с физическим миром — не барьер, а суть задач. Такая цифра подтверждает: Heavy Digital — это уже не узкая ниша, а состоявшееся направление для осознанного развития.
Это значит, что тема промышленного ИТ уже всерьёз конкурирует за внимание наравне с историями из бигтеха.
Бигтех-синьор — 20,7%
Каждый пятый участник — опытный специалист.
Это особенно показательно: синьоры редко тратят время на тесты просто из любопытства. Их вовлечённость говорит о запросе на новый масштаб, где сложность создаётся не только архитектурой, но и законами физического мира.
Для многих из них этот запрос может выглядеть логичным следующим этапом в карьере, а не резкой сменой поля.
Лидеры и инженеры цифровой среды — 2,1%
Небольшая доля. Мы объединили эти две роли, так как обе они в рамках теста дали схожий результат. Это отражает реальность: таких специалистов в ИТ значительно меньше.
Что это значит в целом?
Интерес к промышленному ИТ пробуждается на этапе размышлений, а не в момент решения о переходе. При этом значительная представленность в тесте и «промышленных» специалистов, и опытных синьоров из бигтеха — чёткий сигнал. Heavy Digital уже не узкая тема и превратился в осознанное, весомое направление для работы и роста.
Тихий враг или молчаливый союзник: коротко о выравнивании в C++
Представьте, ваша программа — образец чистого кода, прошедший ревью и покрытый тестами. Казалось бы, всё идеально. Но производительность не такая, на какую рассчитывали. Вы проверили всё, что знали. А что, если проблема в том, о чём вы могли не знать? Всё может упираться в выравнивание данных в памяти. Для многих этот механизм так и остаётся загадкой.
Предлагаю вам вместе попробовать разобраться в такой непростой теме в этой статье.
Привет, Хабр! Новичкам бывает трудно сделать первый шаг в программировании. В интернете много сомнительных курсов, а качественные требуют финансовых вложений и несколько месяцев на изучение.
Мы в Selectel подготовили бесплатный курс, который поможет быстро и без лишних затрат изучить основы JavaScript. В первую часть входят три модуля. Вы узнаете:
для чего разработчики используют JavaScript,
как работать с со скриптами, веб-страницами и переменными,
как создать рабочее окружение на IT-инфраструктуре Selectel.
Участники курса смогут бесплатно протестировать сервисы Selectel, а по итогам тестирования — получить сертификат о прохождении.
Несмотря на кажущуюся сложность, на повседневной основе для работы с Git не требуется большой набор знаний. Checkout, fetch, branch, commit, amend, rebase, revert, reset, pull и, наконец, log. Это — большинство нужных команд. Изредка пользуюсь еще config, бывает нужно.
В общем-то, Git достаточно прост с точки зрения пользователя. Проблема: понимание простоты Git приходит именно с опытом работы с тем самым Git. А по началу хочется иметь под рукой какую-нибудь книжку.
Скотт Чакон и Бен Страуб составили замечательное справочное пособие для тех, кто хочет окунуться с головой в детали работы с Git. Издание есть в виде сайта, PDF, EPUB и MOBI. Распространяется Pro Git бесплатно.
Книга рассчитана на начинающих пользователей или тех, кто имеет конкретные вопросы по механикам Git и им нужен подручный справочник. Что немаловажно, сайт и книга переведены на русский язык.
Pro Git не раз мне пригодился в прошлом, рекомендую.
Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке— за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
Что вас ждет в SSP SOFT: ✅ Рост: Центр компетенций для максимального апгрейда скиллов. ✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис. ✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
При работе с Git я почти не пользуюсь отдельными программами. В корпоративной разработке у меня под рукой есть IntelliJ с достаточно удобной панелькой Git. А для своих проектов я привык пользоваться Git CLI.
И всё же, время от времени, нужно посмотреть изменения в разрезе нескольких коммитов. Делать тучу git diff не очень удобно, особенно когда нужно дать хэш конкретного коммита.
И тут на помощь приходит Lazygit. Этот TUI позволяет удобно шастать по дереву Git стрелками. Окна в программе настраиваются, мышка поддерживается, темы оформления есть.
Можно делать stage для кусков кода, а не целых файлов. Можно делать commit, fixup, revert, amend… В общем, все (или почти все) функции Git в наличии.
Благодаря тому, что это TUI инструмент, им можно пользоваться на удалённых машинах по SSH. Очень удобно и практично.
Я подумал, что самое время, пока он не стал слишком умным и не взял все мои данные, чтобы составить обо мне мнение когда наступит господство роботов и он вспомнит все чаты когда я не написал “спасибо”.
Но прежде чем нажать Удалить все, я нажал другую кнопку, Экспорт данных
В течение часа мне на почту пришла ссылка со всеми моими данными в архиве, и вот что внутри:
Аудио, все записи диалогов мои с ЧатомГПТ, в формате wav, по папкам, сначала мой вопрос в wav, потом его ответ в wav
Фото/Изображение, просто в корневой папке около 1000 изображений
Изображения, которые чатГПТ сгенерирован для меня, в отдельной папке
Системные файлы, где содержится моя почта, год рождения, телефон, id в системе
Отдельный файл shopping, если бы я что-то покупал через новую функциональность оператора, это было бы тоже там
Отдельный файл диалоги которые поделился, в отдельном файле
Отдельный файл информация о групповых чатах
Отдельный файл всех диалогов в формате conversations.json 320 мб текста
Отдельный файл всех диалогов в формате .html 320 мб текста
Конечно открыть файл html такого размера может только человек без СДВГ.
В итоге я открыл эту папку в Gemini CLI (в последнее время мне нравится он) / можно использовать Claude Code
и попросил создать мне отдельную папку Sorted, где он распарсит все в “.md” файлы и разложит по папкам диалога, а Projects, которые были с инструкциями положить отдельно в Projects (у меня это типа Work, Money, Health и тд.)
я не использовал никакой специальный промпт, просто по английски по просил это сделать
Here is an extracted folder from ChatGPT. Is it possible to generate .md files for all extracted chats and organize them into topic-based folders, with everything placed under a main Sorted directory? Some chats may contain information related to specific projects, with or without explicit instructions. If so, can we create separate sections for these projects inside the Sorted folder. Additionally, let’s try to identify project instructions by searching for the following marker: ТУТ МОЯ ИНСТРУКЦИЯ КАК ПРИМЕР
В итоге у меня теперь локальная копия всех диалогов из ChatGPT
далее я положу все по папочкам и темам в Obsidian, пока что буду лазить по ним и продолжать общение с помощью Gemini CLI, но как только локальные модели станут более умные и менее прожорливые возможно перейду на офлайн (статья об этом на хабре)
Теперь когда у меня есть все мои .md которые очень хорошо обрабатываются любой LLM (AI моделью), можно менять Gemini, Claude, ChatGPT и новые другие тд как перчатки, не теряя все свои диалоги и контекст или перейти в свой приватный офлайн
Павел Варнавский, руководитель группы разработки «ДАР» (Корус Консалтинг), рассказал, как их команда использует BI Magic в своих проектах для создания мощных аналитических решений.
Как внедрять CI/CD для дэшбордов и масштабировать решения под конкретные процессы, там, где стандартных «коробочных» решений не хватает
Два практических кейса, где кастомная разработка на Luxms BI решила нетипичные задачи
Будет интересно всем, кто работает с нестандартной аналитикой, сложными требованиями бизнеса и хочет понимать, как кастомная BI-разработка может быть управляемой и удобной
На неделе вспомнил про wchar_t в Си, пока в очередной раз работал с Unicode, но в Windows. Штука… Неоднозначная.
Часть WinAPI жёстко завязана на WCHAR (wchar_t). Но в Windows он до сих пор определён размером в 16 бит. Тот же GCC на Debian мне говорит, что у него wchar_t — все 32 бита.
Т.е. перевод строки из char в wchar_t генерирует валидный UTF-16 в Windows, но UTF-32 в Linux…
Кажется, char32_t должен решить эту чехарду в будущем… Хотя бы с точки зрения размерности… Пусть это и не исправит проблемы WinAPI…
Но действительно ли так часто нужно работать с полноценным code point в Unicode? Зачем? Только чтобы посчитать общее количество символов? Это же просто сделать и на основе char!
Авторы UTF-8 Everywhere дают развёрнутый ответ на этот и многие другие вопросы. Идея хорошо проработана, есть даже прекрасный FAQ для любопытных.
На этой веб-странице собрали самые веские доводы для использования исключительно UTF-8. Везде. Всегда.
Ответьте мне на один простой вопрос: зачем в наше время вообще нужны HR?
Ни для кого не секрет, что найм сегодня сломан. Бесконечные этапы собеседований, которые якобы должны отсекать «вкатунов в IT», по факту отсеивают и нормальных разработчиков.
Причём даже в эффективности этого «фильтра» есть серьёзные сомнения: по сети уже гуляют AI-оверлеи, которые в реальном времени анализируют вопросы интервьюеров и подсказывают ответы. Так о каком объективном отборе вообще идёт речь?
При этом у HR — бесконечный поток, условно говоря, «подопытных кроликов», на которых можно тестировать гипотезы, улучшать процессы и действительно чинить найм. Но вместо этого они просто копируют чужие, далеко не самые успешные практики.
Почему HR не выполняют своё прямое предназначение, а действуют по шаблону?
И главный вопрос: каким образом лайв-кодинг должен подтверждать или опровергать мои навыки, если:
могут дать абсолютно любую задачу и в штатном порядке, я залезу гуглить документацию, а на собесе я это сделать не могу?
Легендарное письмо Эдсгера Дейкстры обсуждалось учёными и программистами довольно долго. Даже сейчас встречаются разные взгляды на присутствие GOTO в программе.
Краткое содержание (парафразирую): GOTO нарушает простую навигацию по коду и, самое главное, возможность сопоставить код с тем, что мы имеем как состояние процесса в определённый момент времени.
Сам Дейкстра пишет, что ничего нового не говорит, о том же уже выступали Тони Хоар, Никлаус Вирт и ряд других учёных.
Дейкста и его коллеги в 1970-х дадут старт “структурному программированию”. В основу ляжет теорема Бёма-Якопини.
Оригинал статьи есть в свободном доступе библиотеки ACM.
Что интересно, этот вариант вырезки содержит и другие письма от 1968 года в редакцию журнала ACM.
К примеру, одно из них про то, что ЯП и их среды не должны быть защищены торговыми марками. Другое про дихотомию килобайты-кибибайты. Ещё одно про необходимость включения пост-мортем дампов (stacktrace или coredump) как обязательную часть высокоуровневых ЯП…
Иногда кажется, что мы застряли в каком-то странном лимбо, где всё уже было придумано или обдумано за нас. Нам же надо только иногда почитывать работы прошлого…
При написании интеграционных тестов для Spring Boot приложения часто возникает проблема, что разработчики бездумно добавляют аннотации @MockBean, @SpyBean, @DirtiesContext или переопределяют прямо в тестовом классе различные property. Всё это приводит к изменению Spring Context, невозможности использовать закэшированный контекст и следовательно созданию нового. Часто создание нового контекста это длительная операция.
Существуют инструменты по отслеживанию этих процессов. Самым простым способом увидеть количество контекстов и количество попаданий в кэш является добавление логирования либо через свойство logging.level.org.springframework.test.context.cache=DEBUG либо настройкой вашего логгера.
Один известный автор статей про тестирование на Java / Spring Boot, Philip Riecks (со товарищи), создал инструмент с открытым исходным кодом Spring Test Profiler при помощи которого можно получить html отчёт о поднимаемых контекстах во время тестов, о количестве и типе бинов в этих контекстах. На Хабре есть перевод его статьи в сообществе Spring АйО.
У нас на проекте стал вопрос, как нам показать разработчикам, что их тест порождает новый Спринг Контекст. Мы решили считать контексты в тестах и при превышении ожидаемого количества падать. Это "руинит" сборку и CI/CD пайплайн. Для этого мы добавили реализацию интерфейса ContextCustomizer
class LimitingSpringContextCustomizer implements ContextCustomizer {
private static final AtomicInteger CONTEXT_COUNTER = new AtomicInteger();
private static final int EXPECTED_SPRING_TEST_CONTEXT_COUNT = 16;
@Override
public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
int numberOfContexts = CONTEXT_COUNTER.incrementAndGet();
log.info("Number of Spring Test Contexts: {}/{}", numberOfContexts, EXPECTED_SPRING_TEST_CONTEXT_COUNT);
Assert.state(numberOfContexts <= EXPECTED_SPRING_TEST_CONTEXT_COUNT,
() -> "Number of test contexts exceeds configured maximum: " + EXPECTED_SPRING_TEST_CONTEXT_COUNT);
}
@Override
public boolean equals(Object obj) {
return (obj != null) && (getClass() == obj.getClass());
}
@Override
public int hashCode() {
return getClass().hashCode();
}
}
Здесь, согласно документации интерфейса ContextCustomizer необходимо корректно переопределить методы equals и hashCode.
WARNING: implementations must implement correct equals and hashCode methods since customizers form part of the MergedContextConfiguration which is used as a cache key.
Далее добавляем фабрику.
class LimitingSpringContextCustomizerFactory implements ContextCustomizerFactory {
@Override
public ContextCustomizer createContextCustomizer(Class<?> testClass,
List<ContextConfigurationAttributes> configAttributes) {
return new LimitingSpringContextCustomizer();
}
}
Затем регистрируем эту фабрику при помощи spring.factories чтобы она применялась ко всем тестам. Для этого создаём в тестовых ресурсах файл по пути src/test/resources/META-INF/spring.factories со следующим содержимым
Теперь, если во время выполнения тестов будет превышено количество инициализированных тестовых контекстов, то мы увидим ошибку в тестах и сборка завершится неудачей.
Возможно, это пример поможет кому-нибудь повысить скорость прохождения своих тестов путём отслеживания количества запускаемых тестовых Спринг контекстов.
Сама идея мелькает в НФ-литературе уже не первый год. То, что я могу вспомнить сейчас, - это Вернор Виндж, «Глубина в небе». В этой книге люди, чей мозг был искусственно изменён для решения узких задач (в книге так делали очень плохие люди), вырабатывали свой, никому не понятный язык, специфичный задаче.
В теории, если делаю какую-то большую систему с помощью ИИ-агентов будущего, в каком-то 2035 году, - можно предположить, что сначала ИИ-агент разработает доменно-специфический язык для конкретной задачи, конкретной платформы и т.п. Просто один специальный язык для ИИ-агентов не имеет смысла. Раз уж у нас есть «мозг», который может писать много кода, - пусть он делает язык под задачу. В чём смысл иметь всего один язык?
В целом, в каком-то смысле, какие-то «нечеловеческие» языки уже есть - это разного рода P-код, байткод и т.д. Такое промежуточное звено между машинным кодом и языком, на котором пишет программы человек. Они, конечно, создавались для другого, но вот вопрос - а для чего именно должен быть создан ИИ-язык? См. пункт ниже.
Следующее соображение - если вернуться из великолепного (или не очень, если судить по трендам) 2035-го года в год 2026, то один из важнейших факторов успешности кодирования с помощью ИИ-агентов - это способность человека читать сгенерированный код и исправлять накосяченное. Ну вот ни разу не похоже, что тот код, который ИИ генерирует, можно пускать в продакшн без ревью и правок. Оговорюсь - для сколько-нибудь сложных / больших приложений.
Из этого автоматически следуют следующие качества используемого языка:
Легко читаем человеком, простые вещи делаются просто.
Мало или вообще нет неочевидных сайд-эффектов.
Распространённые вещи, такие как работа с БД или JWT-авторизация запросов, делаются при помощи библиотеки / фреймворка, а не «с нуля».
Из этих пунктов мы легко получаем на выходе тройку языков: Java / C# / TypeScript с фреймворками Spring Boot / NestJS / ASP.NET Core.
Драйвером развития всех трёх были именно пункты выше: легко читается, простые вещи делаются просто, минимизация неочевидных эффектов.
Да, все три не идеальны, но это лучшее, что у нас есть в этой области. Сможет ли ИИ придумать лучше? Точнее - люди для ИИ. В теории - да, но это десятки лет работы. Быстро не получится.
И последнее. ИИ не пишет код «сам», он по факту подбирает похожие кусочки из той базы, на которой он был обучен. Т.е. чтобы ИИ начал писать сколько-то адекватный код на каком-либо языке, ему нужно «скормить» миллионы (скорее всего - много больше) строк кода на этом языке, и писать этот код должен не ИИ.
На самом деле, даже живые программисты обучаются так же. Когда ты берёшь в руки книгу по совершенно незнакомому тебе языку, то первая реакция - «блин, как на этом код-то писать», потом ты начинаешь писать небольшие кусочки, понимаешь, что получается плохо, правишь, смотришь на чужой код, говоришь себе «Ага! Вот как надо!» - и как-то так понемногу двигаешься вперёд.
Подводя итог. В целом, идея специального языка витает в воздухе не первый десяток лет.
Скорее всего, это будут специальные языки под задачу.
Мы пока не там. ИИ-агенты, с одной стороны, заметно ускоряют разработку, но с другой стороны - программирование с помощью ИИ-агентов это гонка на костылях от ямы к яме. Требует очень высокого внимания и навыка со стороны человека.
В текущей ИИ-индустрии всё крутится вокруг обучения, и если нет хорошего датасета для обучения, то результат будет очень грустным. Какие-то опыты по самообучению ведутся, но мы пока не там. Например, Google сделал бота для игры в StarCraft, который обыгрывает большинство противников. Но бот изначально обучался на записях игр реальных людей и делает безумное количество бессмысленных вещей. Где взять датасет для обучения программированию на специальном ИИ-языке - непонятно.
Попалась на глаза картинка. Интересная идея, я так или иначе кручу её в голове уже не первый месяц. Несколько соображений на этот счёт.
Сама идея мелькает в НФ-литературе уже не первый год. То, что я могу вспомнить сейчас, - это Вернор Виндж, «Глубина в небе». В этой книге люди, чей мозг был искусственно изменён для решения узких задач (в книге так делали очень плохие люди), вырабатывали свой, никому не понятный язык, специфичный задаче.
В теории, если делаю какую-то большую систему с помощью ИИ-агентов будущего, в каком-то 2035 году, - можно предположить, что сначала ИИ-агент разработает доменно-специфический язык для конкретной задачи, конкретной платформы и т.п. Просто один специальный язык для ИИ-агентов не имеет смысла. Раз уж у нас есть «мозг», который может писать много кода, - пусть он делает язык под задачу. В чём смысл иметь всего один язык?
В целом, в каком-то смысле, какие-то «нечеловеческие» языки уже есть - это разного рода P-код, байткод и т.д. Такое промежуточное звено между машинным кодом и языком, на котором пишет программы человек. Они, конечно, создавались для другого, но вот вопрос - а для чего именно должен быть создан ИИ-язык? См. пункт ниже.
Следующее соображение - если вернуться из великолепного (или не очень, если судить по трендам) 2035-го года в год 2026, то один из важнейших факторов успешности кодирования с помощью ИИ-агентов - это способность человека читать сгенерированный код и исправлять накосяченное. Ну вот ни разу не похоже, что тот код, который ИИ генерирует, можно пускать в продакшн без ревью и правок. Оговорюсь - для сколько-нибудь сложных / больших приложений.
Из этого автоматически следуют следующие качества используемого языка:
Легко читаем человеком, простые вещи делаются просто.
Мало или вообще нет неочевидных сайд-эффектов.
Распространённые вещи, такие как работа с БД или JWT-авторизация запросов, делаются при помощи библиотеки / фреймворка, а не «с нуля».
Из этих пунктов мы легко получаем на выходе тройку языков: Java / C# / TypeScript с фреймворками Spring Boot / NestJS / ASP.NET Core.
Драйвером развития всех трёх были именно пункты выше: легко читается, простые вещи делаются просто, минимизация неочевидных эффектов.
Да, все три не идеальны, но это лучшее, что у нас есть в этой области. Сможет ли ИИ придумать лучше? Точнее - люди для ИИ. В теории - да, но это десятки лет работы. Быстро не получится.
И последнее. ИИ не пишет код «сам», он по факту подбирает похожие кусочки из той базы, на которой он был обучен. Т.е. чтобы ИИ начал писать сколько-то адекватный код на каком-либо языке, ему нужно «скормить» миллионы (скорее всего - много больше) строк кода на этом языке, и писать этот код должен не ИИ.
На самом деле, даже живые программисты обучаются так же. Когда ты берёшь в руки книгу по совершенно незнакомому тебе языку, то первая реакция - «блин, как на этом код-то писать», потом ты начинаешь писать небольшие кусочки, понимаешь, что получается плохо, правишь, смотришь на чужой код, говоришь себе «Ага! Вот как надо!» - и как-то так понемногу двигаешься вперёд.
Подводя итог. В целом, идея специального языка витает в воздухе не первый десяток лет.
Скорее всего, это будут специальные языки под задачу.
Мы пока не там. ИИ-агенты, с одной стороны, заметно ускоряют разработку, но с другой стороны - программирование с помощью ИИ-агентов это гонка на костылях от ямы к яме. Требует очень высокого внимания и навыка со стороны человека.
В текущей ИИ-индустрии всё крутится вокруг обучения, и если нет хорошего датасета для обучения, то результат будет очень грустным. Какие-то опыты по самообучению ведутся, но мы пока не там. Например, Google сделал бота для игры в StarCraft, который обыгрывает большинство противников. Но бот изначально обучался на записях игр реальных людей и делает безумное количество бессмысленных вещей. Где взять датасет для обучения программированию на специальном ИИ-языке - непонятно.
Подборка инструкций по Python для начинающих специалистов
Привет, Хабр! Вот и наступила пятница, а значит, пришло время очередной подборки материалов для тех, кто решился взяться за изучение Python. Сегодня у нас несколько базовых инструкций, бесплатный курс и небольшой квиз.
Как работать с PostgreSQL в Python. Эта статья-шпаргалка научит работать с модулем psycopg2, чтобы немного упростить себе жизнь при администрировании PostgreSQL.
Как создать голосового помощника на Python. С помощью простых инструментов и библиотек разработаем голосового помощника на Python, сделав его полезным и удобным в повседневной жизни.
Изучаем Python: теория, практика, настройка инструментов. Да, это подборка в подборке. Внутри несколько материалов, все доступно бесплатно. Для тех, кто хочет научиться не только писать код, но и запускать его в облаке, внутри курса спрятан промо-код на услуги Selectel.
Эпоха расцвета больших языковых моделей (БЯМ) резко усложнила проверку знаний соискателей. Удалёнщики при прохождении собеседований часто читерят и копируют вопросы в ChatGPT или любой другой мощный чат-бот.
Своим простым методом отсева слабых кандидатов поделился Хосе Сарасуа́, бывший CTO компании MonetizeMore. На собственном сайте Хосе рекомендует себя как профессионала от мира найма, через которого прошли 50 тыс. соискателей, и предлагает услуги консультанта.
Сарасуа выложил следующую задачку, которая якобы отсеивает половину неквалифицированных кандидатов. Такую задачку он включал в форму отклика на вакансию.
Какое значение примет result? Задачка на выбор варианта, их четыре: 1, 0, −11, −10. Правильный — 1, но если соискатель пользовался ИИ, он выберет −11.
Суть приёма передать скриншотом невозможно. Дело в том, что в статье в блоге Сарасуа в проверке x > 3 есть знак равенства, скрытый с помощью <span aria-hidden="true" style="font-size: 0px; opacity: 0; user-select: text;">. Для глаза человека будет знак >, «больше», а если выделить и скопировать, то в буфере обмена на этом месте останется =>, «больше или равно».
Замысел в том, что человек даже с минимальным опытом не будет ничего куда копировать и решит всё в уме, а вот живущий в режиме копипейста не пройдёт этот базовый скрининг.
Как утверждает Хосе, эти ухищрения с CSS очень эффективны. Этот приём он применял при работе в MonetizeMore, и 50 % кандидатов выбирали вариант как от БЯМ. Из оставшихся: 47 % отвечали правильно, 3 % выбирали один из двух других неправильных вариантов.
Важно, что сам Хосе предупреждает: ставить крест на людях не нужно. Некоторые поначалу демонстрировали использование ИИ, но затем, без уведомления от компании, самостоятельно повторно заполняли форму отклика и с правильным ответом. Один из таких соискателей в итоге прошёл все этапы и оказался отличным сотрудником.
На самом деле для таких уловок не нужен даже кастомный код CSS. Хосе — канадец мексиканского происхождения, поэтому он наверняка не слышал про похожесть кириллической х и английской x. Впрочем, в случае мешанины из схожих символов БЯМ может обратить внимание на неладное и разразиться замечанием.
Наконец, такая ловушка точно не сработает против Interview Coder и Cheating Daddy: эти инструменты для мошенничества на собесах снимают скриншоты экрана и отправляют в мультимодальные языковые модели, а не копируют текст из браузера. И вообще, что если соискатель слабовидящий, и текст на веб-странице зачитывается вслух его операционной системой?
Никто так говорить, кроме менеджеров, не любит. А я вдруг внезапно полюбил такой подход в работе. Стал бить себя по рукам и делать дешево.
Оказывается, мозгу легче уйти в кроличью нору, чем просто делать задачу. Через час потной работы начинаешь зарываться в тонны документации, смотреть примеры кода на форумах или в репах на работе, переписывать свои модули по десять раз. Ощущение, будто стек собираешь, и он никак не схлопнется. Это обычная прокрастинация через усложнение.
MVP-подход тут мне стал очень помогать на моем, локальном уровне. Суть очень простая: делаю минимум и быстро. А потом добавляю на кости мяса. Надо сделать сохранение строк файла в БД? Пока сделаю построчно и поставлю # TODO. Потом сделаю батчем. Нужна отправка сотен объектов из БД в API? Пока тоже построчно. Нужна еще одна очередь Redis для этапа в обработке файла — потом. Пока и с одной очередью и воркером справимся.
MVP-подход требует некоей выдержки, особенно на пет-проектах. Код пишешь ты сам с собой. Выступаешь внутренним критиком и, зачастую, самым строгим. Но делать все дешево и сердито стало помогать мне лично держать фокус на цели: дать максимум ценности за минимум усилий. И при этом не сгореть от объема, быть в тонусе.
Риски, конечно тоже есть. У TODO нет хозяев, кроме нас. Дешевое Г становится иногда продом. Техдолг это вообще бесконечная тема и, пожалуй, не для этого поста. Пост про эффективность.
MVP-промтинг работает и с нейронками таким же образом. Берем чистый контекст, делаем простой прототип. А дальше по кускам его обтесываем, заменяем, улучшаем. Может, у нас есть с ними что-то общее?
У каждого человека есть свое определение голого минимума. Поэтому примеры выше могут кому-то показаться тривиальными. Очевидно, и сам подход не для всех. Но мне лично он развязал немного руки и помог выдохнуть на одной из недавних душных задач. Может быть такой ход мысли поможет и вам.
Райан Даль, создатель Node.js, одной из ключевых технологий современного веба: времена, когда код писали люди, всё.
Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».
