Как оптика новичка помогает исправлять логические ошибки, UX-изломы продукта и как превратить отсутствие контекста в индикатор реальности.

Когда GPT впервые научился вызывать внешние API, стало понятно: нас ждет эра agentic AI. Вчера «Яндекс» представил «Алису» с AI-агентами, которые могут записать вас к врачу, заказать товар и оплатить услугу.

Удобно? Безусловно. Но что, если агент ошибется — отправит деньги не туда, запишет к не тому врачу или сольет данные партнерам? Кто несет ответственность — разработчики, компания или сама «Алиса»?

Тот же вопрос встает и перед бизнесом. В корпоративной среде agentic AI действуют уже от лица компании. Они сами ставят задачи, создают тикеты, вносят изменения в CRM и принимают решения. Это шаг к самоуправляемой организации — и новая зона риска, где ошибка модели может стоить миллионы.

Меня зовут Сергей Спиренков, я евангелист в KODE и CEO собственных проектов. В статье расскажу, где агентные системы уже приносят пользу, а где превращаются из помощников в источник уязвимостей.

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

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

Пример из практики любого разработчика: ты читаешь статью про новый паттерн проектирования — допустим, про Domain-Driven Design. Хочется сразу внедрить: «О, вот оно, правильное решение!» Но критически мыслящий инженер сначала посмотрит на контекст, изучит критику подхода, попробует на тестовом проекте и только потом решит, подходит ли это под конкретный продукт.

Именно это отличает критическое мышление от просто аналитического: не просто рассуждать, а искать объективность, балансировать между гипотезами и фактами.

В 2025 году стагнация на рынке труда в IT выражается в противоположных процессах: с одной стороны, кадровый голод, с другой — массовые сокращения. Специалисты уровня джуниор месяцами ищут работу в условиях высокой конкуренции. А синьоры либо получают ее легко — например, через знакомых, либо также тратят массу времени на долгий отбор с неизвестным результатом. 

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

О том, сколько стоит потеря опытного специалиста для компании, и о том, какие меры помогут сохранить его в команде, расскажет HR Team Lead KODE Мария Николенко.

Вы откликнулись на вакансию, написали сопроводительное. Через пару минут — автоответ: «Спасибо, вы не подходите». Никакого рекрутера, только модель, которая прогнала ваш текст через NLP-алгоритм и решила, что навыков не хватает. 

Меня зовут Татьяна Горбацевич, я руководитель отдела рекрутинга в KODE. В статье расскажу, где и как компании применяют AI в подборе сотрудников, а где модели пока недостаточно хороши. И главное — что про это думают кандидаты.

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

Исходные условия: у нас было мобильное приложение, написанное на Objective-C (iOS) и Java (Android). Цель — переписать его на современный стек: Swift и Kotlin. Дополнительно нужно было сделать редизайн приложения и обновить бэкенд: поднять Java с 6 до 21. Приложение общалось с бэкендом по HTTP и использовало Protobuf для сериализации данных.

Что важно — никакой документации на существующее приложение не было. У нас была лишь тестовая сборка и сервер с логикой. Поэтому перед стартом разработки нужно было:

Однажды у всех в жизни происходит момент внезапного осознания: я уже взрослый и могу делать все, что угодно (ну почти). Как-то раз я смотрела стрим и обратила внимание на эстетичное и комфортное рабочее пространство в кадре. Меня зовут Анастасия Наумова — я не стример, а редактор в KODE, поэтому тоже провожу много времени за рабочим столом. И кто мне запретит сделать его таким же классным?

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

Привет, меня зовут Диана, я iOS-разработчица в KODE. Но ещё пару лет назад я была вне IT, без проектов, без офферов, без GitHub-портфолио. Я конспектировала статьи про многопоточность, разбирала сложные кейсы GCD и заучивала паттерны проектирования, думая: «Пока не освою всё это идеально — нет смысла откликаться на вакансии».

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

Теперь, пройдя путь с нуля до работы в коммерческом проекте, я хочу честно поделиться опытом. Без абстрактных мотиваций. Только тем, что реально сработало. И главное — показать: soft skills могут быть не менее важны, чем знание языка программирования. Особенно в самом начале.

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

Но рынок изменился — зумерам находить первую работу стало гораздо сложнее. Раньше новички учились на рутине — багфиксы, простая верстка, юнит-тесты, ручная аналитика. Сегодня эти задачи отдают AI. Компании реже вкладываются в рост молодых, предпочитая оптимизацию процессов: здесь меньше рисков и затрат, выше скорость. Это удобно бизнесу, но для тех, кто только начинает карьеру, вход стал намного сложнее. 

Меня зовут Татьяна Горбацевич, я тимлид рекрутинга в KODE. В статье расскажу о том, как меняется рынок, за что ценят зумеров и что делать, если вы только начинаете карьеру.

Пока менеджеры мечтают о мире, где можно просто шепнуть ChatGPT «сделай мне Uber, но подешевле» — и вуаля, готовый продакшен, разработчики делятся на два лагеря: одни паникуют, другие спокойно встраивают Copilot в рабочий процесс и смеются над его гениальными архитектурными решениями.

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

Я Илья Некрасов, Android Team Lead KODE. В этой статье предлагаю разобраться, почему бизнес так любит идею «разработки без разработчиков» и почему она не работает. 

Меня зовут Алексей Цуцоев, я разработчик мобильных приложений в KODE, и я хочу поделиться историей того, как мы внедряли игру в уже готовое React-Native приложение. Как выбирали технологию, с какими трудностями столкнулись и к каким выводам пришли.

С вами снова Кирилл Богатов, дизайнер разговорных продуктов в KODE. В прошлом году я записался на курсы по театральной импровизации. Там мы разыгрывали сценки, работали с зажимами и учились не бояться выглядеть нелепо. Наши занятия часто заканчивались игрой в «Принцессу, Дракона, Рыцаря» — это как «камень-ножницы-бумага», только вместо фигур в ней нужно изображать фэнтезийных персонажей. Своего рода мини-спектакль на пару секунд.

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

AI меняет не только процессы, но и профессии. Полгода назад для того, чтобы запустить MVP продукта, нужен был не только product owner, но и команда разработчиков. Сегодня прототип может сделать один человек без команды, используя только AI. Вы все еще относитесь к этому со скепсисом, но это уже так.

Меня зовут Сергей Спиренков, я евангелист в KODE и CEO собственных проектов. Последние месяцы я провел внутри этой трансформации — собирая продукты в одиночку, без строчек кода руками, с помощью AI и нового подхода к разработке. В статье поделюсь мнением, как изменится профессия product owner и что ждет разработчиков. И главное: расскажу про AI-инструменты, с помощью которых сам делаю MVP продуктов.

Привет! Я — Таня Рашидова, QA тимлид в KODE. Я думала, что все тестировщики уже давно внедрили AI в свою повседневную работу. Но недавно выяснила, что многие либо не пробовали, либо попробовали, запутались, не получили вау-результата и забросили. Раз уж я уже объяснила, как использую AI в работе нескольким коллегам, решила оформить опыт в статью. Может, кому-то из вас она сэкономит время и силы.

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

Меня зовут Сергей Спиренков. Я евангелист в KODE, автор тревел-проекта «Сусанин», и в моем телефоне несколько тысяч контактов. В этой статье — честный разбор, как работает мой нетворкинг в IT: без пафоса, без магических методик, но с кейсами, шутками и наблюдениями из жизни.

Если ты хочешь не просто «заводить полезные знакомства», а понимать, зачем, как и с кем — читай дальше.

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

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

Это история, которая многим из вас покажется знакомой.

Удаленка — часть нашей реальности, у нее есть преимущества и недостатки. Нам стало интересно, что мешает жить удаленщикам, и поэтому мы провели опрос. 

В исследовании приняли участие около сотни сотрудников из десятка IT-компаний. Мы сгруппировали ответы и выделили восемь самых частых проблем. Делимся результатами в виде рейтинга!

Меня зовут Александр Мамонов, и в KODE я занимаюсь разработкой на Flutter. Я столкнулся с бойлерплейтом композиции фич в наших проектах, поэтому решил написать универсальный плагин для создания файловой структуры фич в проекте.

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

А у вас тоже уже глаз дергается от пузырьковой сортировки и балансировки красно-черных деревьев? 

Наём — это решение задачи с двумя неизвестными. Работодатель оценивает кандидата по его резюме, портфолио, тестовому заданию и общению на собеседованиях, но всё равно не может быть до конца уверен в том, что нашёл подходящего сотрудника. Кандидат выбирает работодателя по HR-бренду, описанию вакансии, может запросить в LinkedIn отзыв у сотрудника компании, но на 100% понимает, подходит ли ему рабочее место, только спустя пару месяцев после трудоустройства.

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

Рассмотрим, как выглядит наём глазами обеих сторон и попытаемся понять, может ли ситуация измениться в будущем. 

*Дисклеймер: ничью сторону не занимаем, просто рассуждаем и нащупываем точки взаимопонимания.

Меня зовут Александр Чернов, я фронтенд-разработчик в KODE и я использую React Native в разработке мобильных приложений уже более семи лет. Сейчас расскажу вам, как мы у нативных разработчиков хлеб отбирали.