Долгое время в продуктовых командах разработчики жили в парадигме «дайте задачу и я напишу код». И я до сих пор вижу, как многие ставят полностью на хард-скиллы, будто этого достаточно.
Но в 2026 году это уже так не работает, к сожалению.
Я всё чаще замечаю, что разработчики, которые умеют ясно формулировать мысли (особенно в тексте), начинают превосходить тех, кто просто “хорошо пишет код”.
Не потому что код стал неважен, а потому что спецификация становится обязательным этапом разработки.
С агентами для разработки есть важный момент: чем точнее спецификация, тем ближе результат к техническим и бизнес-требованиям. Проблема в том, что хорошую спецификацию почти никогда не приносят готовой.
В реальной жизни задачи, зачастую, редко содержат все требования. Чтобы их прояснить, часто нужно:
— задавать вопросы, которые вскрывают неочевидные корнер кейсы;
— убирать избыточность требований (помним же про принцип YAGNI?), но не сжигать мосты;
— принимать решения там, где никто даже не подумал зафиксировать требования.
И что же нам нужно прокачивать уже сейчас, чтобы не получать отказы на собеседованиях и превосходить других разработчиков?
Научитесь уточнять контекст задачи
Спрашивайте не «что сделать?», а «какая проблема решается?». Очень часто «невероятно важная задача» в итоге превращается в фичу, которой будет пользоваться один клиент (это в лучшем сценарии).
Задавайте неудобные вопросы
Часто именно там скрыты риски и несостыковки. Не бойтесь показаться душнилой, но не будьте токсичным. Хорошие, пусть и неудобные, вопросы (мой пост про это) — это драйвер качественного обсуждения задачи и проекта.
Умейте фасилитировать и доводить свою точку зрения
Если вы хотите стать лидером, то умение сводить разные интересы к рабочему решению — очень важный навык. А умение донести свою идею так, чтобы никто не поругался, так вообще основной пункт в чеклистах на собеседованиях лидов.
Развивайте эмпатию
Без неё коммуникация превращается в обмен сообщениями, а не в совместное решение задачи. Ставьте себя на место своего коллеги, пробуйте вникнуть в проблему и ситуацию. Вы идёте к одной цели вместе, а не по одному.
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
10❤17👍4💯1
Недавно официально стал Cursor Ambassador и это для меня не бейджик в профиле (хотя приятно), а новый вектор: теперь я буду делать больше мероприятий вокруг агентского кодинга — митапы, воркшопы, хакатоны.
Почему вообще это важно?
За последние пару лет у нас реально сменилась парадигма: от «Редактор подсказывает следующий символ» к «я описываю цель, ограничения и контекст, а агент делает работу». В 2022-23 годах мой основной режим был простой: Copilot + tab-подстановки и чуть-чуть автодополнения. Сейчас всё иначе: большую часть задач я делегирую агентам — от черновиков решений и рефакторинга до генерации тестов, миграций и прототипов. Я всё ещё держу направление и ответственность, но исполнение всё чаще уходит другие руки.
Отдельно символично, что интерес к этому направлению у меня сильно вырос после доклада Марка на AlmatyJS Light #5 x Altel Digital (28 ноября 2024) — «Эволюция ИИ помощников для разработчиков». Марк показал там Cursor не как “игрушку для автокомплита”, а как инструмент, который начинает приносить ценность, когда ты умеешь ставить задачу и принимать результат как инженер.
Дальше — больше, как говорится. Будем собирать комьюнити вокруг практик: как писать спецификации под агентов, как проверять результат, как строить процесс, где почти готово — это действительно только начало, а не конец.
Для поддержки казахстанских пользователей решил завести отдельное сообщество без привязки к направлению разработки, там же будут и анонсы мероприятий и других активностей — https://t.me/cursor_kz
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19🔥8👍2💯2🌚1
Вчера мы в чате с разработчиками обсуждали проблему, что в век AI агентов очень сложно удержать в голове, чем фактически ты занимался вчера или на этой неделе.
И мне пришла идея — почему бы просто не записывать всё, что я делаю через git hooks. Просто и элегантно. Так и появился проект diddo.
Да, можно смотреть лог проекта, но я сам сейчас работаю над несколькими рабочими и личными проектами. Зачастую даже без таск-трекинга. Поэтому контекст удержать бывает сложно.
Thanks AI gods, что мы теперь можем делать проекты, пока пьём кофе и проводим время со своими близкими.
Проект был сделан полностью агентами в Cursor (про свой воркфлоу я напишу отдельный пост) вместе со всеми тестами и проверками.
Из коробки работает с установленными у вас агентскими CLI, но можно и подкинуть свой ключ к OpenAI.
Дейлик через пару минут, а ты не помнишь, что делал вчера? —
diddo yesterday расскажет (пока без text to speech 😉)Мне очень нравится, как с AI я могу делать то, что раньше у меня бы заняло дни или даже недели разработки всего за пару часов.
Работает на MacOS (проверено), Windows и Linux (нужна верификация).
Заводите issues и открывайте PR, если хотите что-то улучшить — https://github.com/drugoi/diddo-hooks
Установка простая:
brew tap drugoi/tap
brew install diddo
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥5❤4
Я не так часто выступаю, потому что считаю, что лучше создавать условия для того, чтобы выступали другие, чем занимать эфирное время, но так получилось, что за прошедшие две недели мне довелось выступить на AlmatyJS Light от 42 Meetups и в Terricon Valley в Караганде.
Оба митапа прошли под влиянием AI, на AlmatyJS (который впору назвать AlmatyAI) я рассказал вводную историю про скиллы и как их готовить в команде — https://www.youtube.com/watch?v=LQKAl2mj16U
А уже в Терриконовой долине мы обсудили, как менятся работа разработчика в 2026 году, как на это влияет AI и что мы ждём от кандидатов — https://www.youtube.com/watch?v=2ckiV4MaTAU
Подготовка к митапам это всегда повод глубже погрузиться в тему, узнать что-то новое и выйти на новый уровень. Поэтому я всегда советую людям, что если они хотят стать лучше, то один из способов — это выступить перед публикой.
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9🔥8❤2
Я за годы работы и найма просмотрел сотни резюме и Linkedin профилей разработчиков.
И всё чаще замечаю одну проблему: многие пытаются сделать из профиля витрину из ключевых слов, AI слопа и бесконечного списка технологий.
Да, мы живём в эпоху ATS, AI-скрининга и авторазборов резюме. Но, несмотря на это, решения о найме всё ещё принимают люди.
И восприятие кандидата складывается не только из совпадения по ключевым словам.
Несколько вещей, которые всё ещё влияют на то, как выглядит разработчик на рынке:
1. Одностраничное резюме всё ещё лучше всего остального
Резюме не должно превращаться в ваш бэклог из JIRA.
Никто не хочет читать 14 пунктов про «фикс бага XYZ-256». Лучше меньше, но с акцентом на результат и его влияние.
Если достижений много, то можно вынести отдельно к себе на сайт или страницу на GIthub.
Вы всё равно обсудите это ещё на собеседовании.
2. Личный сайт всё ещё выделяет (но it depends)
Шаблон с прогресс баром, который показывает ваши знания технологий никому не нужен.
Намного интереснее видеть проекты, мысли, подходы к разработке и интересы.
3. Активный GitHub важнее красивого README-профиля
Один живой и понятный проект производит лучшее впечатление, чем стена бейджиков из технологий
4. Адаптируйте профиль под компанию
Стартапы смотрят на инициативность и способность быстро делать задачи, а корпораты — на процессы, стабильность и масштаб.
Универсальное резюме редко работает идеально везде.
5. В 2026 году уже странно не упоминать AI
Не потому что «агенты заменят разработчиков», а потому что подход к работе УЖЕ поменялся.
Использование AI-инструментов становится такой же базой разработки, как Git или CI/CD.
6. Самые запоминающиеся кандидаты — не всегда самые "идеальные"
Часто цепляет что-то человеческое: хороший личный проект, блог, выступления, вкус к продуктам, интерес к технологиям, да даже список любимых книг или фильмов.
У нас маленький рынок, не сегодня, так завтра вас могут вспомнить и позвать на работу.
Сейчас на одну позицию могут приходить сотни (а где-то и тысячи) откликов. С одной стороны работодатели укрываются ATS и авторазборами резюме, а с другой стороны кандидаты генерят автоотклики даже не вдаваясь в подробности вакансии.
Сейчас недостаточно просто «писать код». Важно быть человеком. И чем лучше вы, как человек, тем больше вероятность, что вас возьмут
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤19💯3
Cursor Developer Habits Report 2026
Отчётов по реальному использованию AI с большими выборками достаточно мало, но тут Cursor выпустил первый Cursor Developer Habits Report на основе данных за последние 2 года. В отчёте хорошо видно, как AI меняет разработку не в теории, а на деле.
И самое главное, о чём мы говорим постоянно:
1. Разработчики начали двигаться быстрее
2. AI постепенно переходит от простого помощника к автоматизации частей SDLC
Не буду разбирать весь отчёт, но есть две темы, которые мне больше всего зашли
Про продуктивность разработчиков
Самый очевидный эффект — разработчики стали производить больше изменений.
По данным Cursor:
— количество добавленных строк на разработчика в неделю выросли примерно с 3.6K до 8.6K
— по p75 рост строк добавленных в PR — примерно со 126 до 345 строк
— доля PR с 1000+ изменённых строк — с 8% до 13.8%
— среднее число tool calls в агентских сессиях выросло примерно на 30% за два месяца
— выживаемость (сколько кода не удаляют) AI-кода вырос с 76% до 81%
Да, строки кода вообще не идеальная метрика. Больше кода не всегда значит больше ценности.
Но здесь всё таки важен не сам объём, а изменение самого формата работы.
AI позволяет разработчику брать более крупные куски задач: не просто “поправь компонент”, а полноценный (и масштабный) рефакторинг, миграцию, тесты, подготовку PR целиком.
То есть ускорение происходит не только на уровне скорости набора кода .
Меняется размер обычной работы.
Если раньше команда могла управлять потоком небольших задач и PR, то теперь AI помогает быстрее генерировать более крупные изменения. А значит, код-ревью, QA/тесты и даже архитектурные правила должны масштабироваться вместе с ними.
Иначе всё это ускорение легко превращается в ускоренное накопление хаоса.
Про автоматизацию разработки
Вторая тема ещё интереснее.
AI инструменты разработки начинались как инструменты для ускорения отдельного разработчика: автокомплит, чаты, генерация кусков кода, помощь с тестами.
Но сейчас видно движение в другую сторону: AI становится инфраструктурой для автоматизации разработки через агентов.
Доля изменений, которые доходят до коммита без отдельной ручной проверки кода, выросла с 7% в начале 2026 до примерно 36% в мае.
Правда это не значит, что код-ревью больше не нужен (хотя во многих случаях его уже можно избегать). Скорее наоборот: код-ревью становится важнее, но меняет уровень.
Уже нет смысла (и физических возможностей) человеку проверять каждую строку руками, важно создать правильные условия для безопасной разработки.
То есть роль разработчика сильно смещается от «я пишу весь код сам» к «я управляю огромным потоком изменений и качеством результата».
А вот роль технических менеджеров меняется от «как ускорить людей» к «как построить систему, где люди и агенты безопасно релизят продукты».
Что это значит для команд
Для меня главный вывод, примерно, звучит так:
AI adoption в разработке — это история не про купить лицензии и провести воркшоп. Это уже вопрос операционной модели компании/команды.
Если AI увеличивает объём и размер изменений, то нужно пересматривать:
— как мы декомпозируем задачи
— как ревьюим большие PR
— какие проверки автоматизированы
— какие части SDLC можно отдавать агентам
— как измеряем эффект
— как контролируем стоимость всего этого AI балагана
— как растим power users агентов
— как даём AI правильный контекст: код, требования, документацию и другие внутренние стандарты
Разработка — это не только написание кода. Это понимание задачи, архитектура, качество, безопасность, поддерживаемость, релизный процесс и ответственность за результат.
Если инженерная система слабая, то AI просто ускорит хаос.
Если же она зрелая, то AI станет реальным мультипликатором.
Сам репорт доступен по ссылке — https://cursor.com/insights
@drugoi_dev
Отчётов по реальному использованию AI с большими выборками достаточно мало, но тут Cursor выпустил первый Cursor Developer Habits Report на основе данных за последние 2 года. В отчёте хорошо видно, как AI меняет разработку не в теории, а на деле.
И самое главное, о чём мы говорим постоянно:
1. Разработчики начали двигаться быстрее
2. AI постепенно переходит от простого помощника к автоматизации частей SDLC
Не буду разбирать весь отчёт, но есть две темы, которые мне больше всего зашли
Про продуктивность разработчиков
Самый очевидный эффект — разработчики стали производить больше изменений.
По данным Cursor:
— количество добавленных строк на разработчика в неделю выросли примерно с 3.6K до 8.6K
— по p75 рост строк добавленных в PR — примерно со 126 до 345 строк
— доля PR с 1000+ изменённых строк — с 8% до 13.8%
— среднее число tool calls в агентских сессиях выросло примерно на 30% за два месяца
— выживаемость (сколько кода не удаляют) AI-кода вырос с 76% до 81%
Да, строки кода вообще не идеальная метрика. Больше кода не всегда значит больше ценности.
Но здесь всё таки важен не сам объём, а изменение самого формата работы.
AI позволяет разработчику брать более крупные куски задач: не просто “поправь компонент”, а полноценный (и масштабный) рефакторинг, миграцию, тесты, подготовку PR целиком.
То есть ускорение происходит не только на уровне скорости набора кода .
Меняется размер обычной работы.
Если раньше команда могла управлять потоком небольших задач и PR, то теперь AI помогает быстрее генерировать более крупные изменения. А значит, код-ревью, QA/тесты и даже архитектурные правила должны масштабироваться вместе с ними.
Иначе всё это ускорение легко превращается в ускоренное накопление хаоса.
Про автоматизацию разработки
Вторая тема ещё интереснее.
AI инструменты разработки начинались как инструменты для ускорения отдельного разработчика: автокомплит, чаты, генерация кусков кода, помощь с тестами.
Но сейчас видно движение в другую сторону: AI становится инфраструктурой для автоматизации разработки через агентов.
Доля изменений, которые доходят до коммита без отдельной ручной проверки кода, выросла с 7% в начале 2026 до примерно 36% в мае.
Правда это не значит, что код-ревью больше не нужен (хотя во многих случаях его уже можно избегать). Скорее наоборот: код-ревью становится важнее, но меняет уровень.
Уже нет смысла (и физических возможностей) человеку проверять каждую строку руками, важно создать правильные условия для безопасной разработки.
То есть роль разработчика сильно смещается от «я пишу весь код сам» к «я управляю огромным потоком изменений и качеством результата».
А вот роль технических менеджеров меняется от «как ускорить людей» к «как построить систему, где люди и агенты безопасно релизят продукты».
Что это значит для команд
Для меня главный вывод, примерно, звучит так:
AI adoption в разработке — это история не про купить лицензии и провести воркшоп. Это уже вопрос операционной модели компании/команды.
Если AI увеличивает объём и размер изменений, то нужно пересматривать:
— как мы декомпозируем задачи
— как ревьюим большие PR
— какие проверки автоматизированы
— какие части SDLC можно отдавать агентам
— как измеряем эффект
— как контролируем стоимость всего этого AI балагана
— как растим power users агентов
— как даём AI правильный контекст: код, требования, документацию и другие внутренние стандарты
Разработка — это не только написание кода. Это понимание задачи, архитектура, качество, безопасность, поддерживаемость, релизный процесс и ответственность за результат.
Если инженерная система слабая, то AI просто ускорит хаос.
Если же она зрелая, то AI станет реальным мультипликатором.
Сам репорт доступен по ссылке — https://cursor.com/insights
@drugoi_dev
1👍6❤1
Увидел твит Бориса с интересной мыслью, которую мы стабильно обсуждаем в последнее время в AI чатах: по мере того как разработка, управление продуктом, дизайн, аналитика и другие роли начинают смешиваться, привычные названия должностей всё хуже и хуже передают то, чем фактически занимается человек в команде.
Борис пишет, что вполне возможно, что будущие продуктовые команды будут описываться не столько через функции сколько через тип вклада, который человек приносит в конкретный момент жизни продукта.
Как итог, команда будущего может выглядеть примерно так:
Prototyper — быстро находит новые идеи, собирает много черновиков и экспериментов. Большая часть не доходит до прода, но именно здесь рождаются новые направления.
В текущем мире, один из самых важных типов сотрудников, т.к. скорость сейчас как никогда важна.
Builder (мой любимый тип) — превращает идею или прототип в рабочий продукт. То, что последний год называлось “вайбкодингом” уже давно переросло в агентское программирование и builder — это та роль, которая в большей степени эксплуатирует множество агентов.
Sweeper — упрощает интерфейс, чистит код, убирает лишнее, оптимизирует производительность и снижает сложность системы.
Разработка с помощью AI с одной стороны очень сильно ускоряет процесс, а с другой стороны, без должного внимания, создаёт большое количество ненужного и плохого кода.
Grower — берёт уже запущенный продукт и итеративно улучшает его, усиливая product-market fit.
Maintainer — отвечает уже за зрелую систему. Работает с безопасностью, надёжностью, эффективностью и масштабированием самой системы.
Да, все эти роли пересекаются, но что мне нравится в этой модели: она не привязана жёстко к профессии. Дизайнер может быть сильным builder-ом или sweeper-ом. Инженер — grower-ом или maintainer-ом. Аналитик — не только человеком со страницами в Confluence, а участником zero-to-one поиска или оптимизации зрелого продукта.
Пройдёт ещё время, прежде чем команды начнут трансформироваться повсеместно, но стоит признать, что все эти новые типы скорей будут не постоянными в команде. В зависимости от этапа развития, может быть что-то такое:
— новый продукт до PMF: больше prototyper + builder + sweeper
— растущий продукт после PMF: builder + sweeper + grower
— зрелый продукт с сильным PMF: sweeper + grower + maintainer
А к кому бы вы причислили себя уже сейчас?
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤13👍5
Мы в Bereke Bank начали проводить внутренние встречи, где разработчики и не только показывают, как они работают с AI, какой у них рабочий стек приложений и технологий, а также делятся советами в формате стрима (правда пока без донатов и заданий).
И я вспомнил, что 13 лет назад я дал мини-интервью проекту Андрея Олесько Worq, где он изучал, как люди разных профессий работают и какими инструментами пользуются.
Для разработчика тогда это было действительно важно, а по набору инструментов можно было довольно много понять о том, как человек работает.
А сегодня я поймал себя на мысли о том, что большая часть моей работы постепенно сводится к одному интерфейсу — чату.
Код → чат
Чтение → чат
Исследования → чат
Документы → чат
Аналитика → чат
Действия → тоже чат
Понятно, что IDE, Jira, Notion, Figma и остальные приложения никуда не исчезли. Но теперь не обязательно заходить в них, чтобы узнать что-то.
Даже больше — интерфейсы зачастую ограничивают тебя в масштабе того, что ты можешь сделать с инструментом.
Интерфейс предлагает тебе заранее придуманный набор сценариев, а через AI ты скорее описываешь, какой результат хочешь получить.
Раньше мы выбирали приложения, а сейчас скорее выбираем, к чему у AI есть доступ и какие модели, данные и инструменты он может использовать.
И в итоге важным становится то, насколько хорошо человек умеет работать с AI: сформулировать задачу, дать нужный контекст и понять, нормальный ли получился результат.
Я уже писал, что софт-скиллы становятся всё важнее, и с AI это особенно хорошо видно: модель иногда не может понять задачу просто потому, что человек сам её ещё нормально не сформулировал.
Если бы такое интервью делали сегодня, мне было бы уже не так интересно узнать, каким редактором, браузером или приложением для заметок пользуется человек.
Гораздо интереснее спросить: «Как ты работаешь с AI каждый день?»
@drugoi_dev
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3🔥2
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥18👍7❤5 3
В эту среду буду на Podlodka Frontend Crew — участвую в круглом столе про то, что, кажется, сейчас волнует почти всех разработчиков:
«О новых ролях в эпоху AI»
30 сентября в 21:00 по Алматы вместе с Кириллом Мокевниным и Юрием Карповым будем разбираться, что происходит с профессией, когда код всё чаще пишется вместе с агентами, рутина автоматизируется, а границы между привычными ролями постепенно размываются.
Что будет со специализациями? Каких разработчиков будут искать через пару лет? Где заканчивается frontend/backend/mobile и начинаются какие-то новые роли? И, главное, какие навыки имеет смысл качать уже сейчас.
У меня здесь накопилось довольно много мыслей и практики из того, что мы сейчас пробуем с AI в разработке — думаю, будет о чём поговорить 😬
А ещё организаторы дали мне один промокод на бесплатный билет, поэтому разыграю его здесь.
Давайте без репостов и прочей конкурсной механики.
Напишите в комментариях: как, по-вашему, изменится роль разработчика из-за AI в ближайшие 2–3 года?
Завтра выберу случайный комментарий и отдам проходку.
https://podlodka.io/fecrew
Please open Telegram to view this post
VIEW IN TELEGRAM
podlodka.io
Онлайн-конференция Podlodka Frontend Crew, сезон #6
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам frontend-разработки, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🔥11
Media is too big
VIEW IN TELEGRAM
Спасибо всем за участие!
random.org разыграл число 5 и это оказался @alkhipce
Поздравляю!
Напишу в ближайшее время в ЛС.
random.org разыграл число 5 и это оказался @alkhipce
Поздравляю!
Напишу в ближайшее время в ЛС.
🔥3