Кот Денисова

👨‍💻 Менеджер - это еще не бизнес. Кто на самом деле принимает решения? Разработчики часто говорят: «Бизнес не понимает, чего хочет», «Бизнес опять поменял требования», «Бизнес принимает кривые решения». И под этим «бизнесом» обычно подразумевают своих менеджеров, продактов или кого-то выше по иерархии. Но это ошибка. В большинстве случаев те, кто ставит задачи и меняет требования, к бизнесу имеют косвенное отношение. Они наемные сотрудники, у которых свои KPI, свои риски и своя ответственность. Но это не уровень владельцев бизнеса. Чтобы понять, кто есть кто, нужно разобраться с устройством компании. Фаундеры - настоящий бизнес: На самом верху находятся фаундеры. Это люди, которые вложили свои деньги, время и репутацию. Если компания прогорит, они не смогут просто уволиться и найти другую работу. Банкротство, суды, обязательства перед кредиторами - это их реальность. Именно фаундеры принимают стратегические решения, которые могут либо поднять компанию, либо утопить ее целиком. Они смотрят на деньги и риски. Все остальное - вторично. Акционеры и инвесторы: Рядом с фаундерами находятся акционеры и инвесторы. Они тоже вкладывают деньги и оценивают перспективы. Их интересы - прибыль и рост стоимости компании. Если они видят, что что-то идет не так, они могут потребовать изменений. Иногда кардинальных. C-level - мостик между бизнесом и операционкой: Генеральный директор, финансовый директор, коммерческий директор, операционный директор - это уже наемные сотрудники. Но их ответственность максимальна среди всех наемных менеджеров. Задача гендиректора - зарабатывать деньги для акционеров. Они работают с отчетностью, бюджетами и стратегией. Их решения напрямую влияют на финансовые показатели. Продакты и руководители направлений: Ниже находятся CPO, руководитель отдела продаж, директор по маркетингу. Они уже более узко сфокусированы: продукты, продажи, маркетинг. Здесь тоже есть ответственность за деньги, но уже в рамках своего направления. Разработчики и остальные: А где разработчики? Где-то дальше. Они выполняют задачи, которые ставят продакты и менеджеры. У них нет денежного KPI в том смысле, в каком он есть у фаундеров. Их ответственность - качество кода, сроки, архитектура. Это важно, но это не про деньги и риски в масштабах всей компании. 🔗 Читать подробнее 💡 Вывод: Бизнес - это про деньги и риски. Фаундеры и акционеры несут полную ответственность за компанию. C-level отвечает за выполнение стратегии. А все, что ниже - про операционную работу. Разработчики - важная часть компании, но они не про бизнес. Они про технологию и реализацию. И если вы хотите влиять на бизнес-решения, нужно понимать, кто их принимает и почему. А не жаловаться на бизнес, который на самом деле просто выполняет свою работу. Подписаться на канал: ➡️ Кот Денисова

👨‍💻 Роль разработчика в эпоху ИИ-агентов. Вопрос, который сейчас звучит чаще всего: «Если ИИ уже пишет код, в чем моя ценность?». Ответ простой - ценность смещается в другую область. Не туда, где пишут код, а туда, где проектируют системы, выстраивают процессы и создают архитектуру для агентов. Прежнее ИТ и новое ИТ: Прежнее ИТ - это разработка до того, как появился ИИ, который способен писать код. Раньше это была привилегия разработчиков. Теперь писать код может любой человек, владеющий естественным языком. Уровень абстракции для создания программного обеспечения повысился. Это фундаментально меняет процесс. Раньше мы учили синтаксис, паттерны, конкретные языковые особенности. Сейчас это перестает быть главным. Становится неважно, на каком языке написан код. Важно, как спроектирована система. Кто такой ИИ-инженер: В новой картине мира ИИ-инженер - это человек, который создает систему вокруг ИИ-агента. Сам по себе агент - просто штука, которая делает запрос к LLM и возвращает информацию. Иногда несколько запросов. Но она галлюцинирует, ошибается, не понимает контекста. Задача ИИ-инженера - построить инфраструктуру вокруг модели. Архитектуру, которая заставляет модель выдавать стабильный результат. Процессы, которые превращают хаотичную генерацию в предсказуемый инструмент. Claude, Cursor, Codex - это все инструменты, созданные ИИ-инженерами. Они запоминают, индексируют, работают с контекстом. Именно эти слои позволяют получать высокое качество от модели. Что меняется в процессе разработки: ИТ-компании уже перестраивают свои процессы. В дополнение к коду появляется архитектурный слой для агентов. Чтобы ИИ мог понимать проект и работать с ним оптимально. Часто без привязки к конкретной модели. Разработчик больше не просто пишет код. Он проектирует систему, в которой агенты могут эффективно работать. Ставит задачи. Строит контекст. Создает инструменты. Управляет памятью и контролирует качество. 🔗 Читать подробнее 💡 Вывод: ИИ не делает разработчиков ненужными. Он меняет их роль. От кодера - к архитектору систем и процессов. Теперь важно не то, как написать код, а как спроектировать систему, в которой код будет создаваться правильно и предсказуемо. Те, кто перестраивается, осваивает новые концепции и учится работать с агентами, остаются востребованными. Те, кто цепляется за старую модель «я пишу код», рискуют оказаться за бортом. Это не катастрофа, а естественная эволюция профессии. Такая же, как была с переходом от ассемблера к высокоуровневым языкам, от ручного управления памятью к сборщикам мусора. Просто сейчас это происходит быстрее. Подписаться на канал: ➡️ Кот Денисова

👨‍💻 Скорость или контроль. Как балансировать с ИИ-агентами. Один из главных вопросов в разработке с ИИ-агентами - как понять, что можно доверить машине, а что требует человеческого контроля. Ответственность всегда остается на разработчиках. Тот, кто настроил агента, организовал процесс и дал задачу, тот и отвечает за результат. Это правило работает всегда. Два базовых принципа: Есть два простых принципа, которые помогают разделять задачи. 🔹Первый: чем дороже исправление, тем больше человеческого внимания нужно уделять задаче. Архитектурные решения, выбор технологий, проектирование системы - все это менять дорого. Такие задачи требуют пристального контроля. 🔹Второй: уровень внимания должен быть достаточным, чтобы минимизировать критический риск. Достаточность определяется аппетитом к риску. Больше готовности рисковать - выше скорость. Меньше - больше контроля. Как всегда, компромисс. Что меняется в работе разработчика: При повышении автономности кодинговых агентов разработчики должны смещать фокус. Вместо написания кода - проверка ожидаемого поведения. Кликать руками, запускать агентов, автоматизировать тесты и код-ревью. Задача человека - управлять потоком агентной работы. Формировать требования и ожидания. Авторизовывать результат. Задача команды разработчиков - повышать автономность агентов и сокращать количество петель обратной связи. Когда агент ошибся, работа возвращается к человеку. Чем меньше таких возвратов, тем эффективнее процесс. Главный вызов следующих лет: Наша текущая задача - научиться безопасно обменивать внимание человека на скорость. Отдавать часть работы агентам, сохраняя качество. Именно этот размен дает эффективность: рост производительности при снижении затрат на единицу результата. В ближайшие несколько лет индустрия будет двигаться в этом направлении. Баланс будет смещаться в сторону автономности, но не за счет качества. Ответственность за результат всегда остается на человеке. 💡 Вывод: ИИ-агенты - это инструмент. Как и любой инструмент, он требует правильного применения. Задачи с высокой стоимостью ошибки остаются за человеком. Рутинные и предсказуемые операции можно отдавать агентам. Разработчик перестает быть просто исполнителем. Он становится управляющим, который настраивает агентов, контролирует их работу и принимает решения. Это не делает профессию проще. Это делает ее другой. И тем, кто освоит эту роль, открываются новые возможности. Подписаться на канал: ➡️ Кот Денисова

👨‍💻 Рынок ИТ остывает: вакансии падают, конкуренция растет. Еще пару лет назад ИТ-специалисты выбирали из нескольких офферов, а компании сражались за каждого разработчика. Сегодня картина обратная. Спрос на айтишников резко обвалился, а конкуренция за каждое место стала жесткой. Цифры: За первое полугодие 2026 года число ИТ-вакансий сократилось на 21% на hh.ru. На «Хабр Карьера» падение составило 56%. Количество резюме выросло на 21%, а специалистов, открытых к предложениям, стало больше на 69%. В итоге на одну вакансию в ИТ сейчас приходится 22,6 резюме. Зарплаты тоже отражают тренд. В июне 2026 года средние доходы ИТ-специалистов выросли всего на 3,9%, это ниже инфляции. Зарплата айтишников сжигается инфляцией из года в год. Исключение - только мидлы и сеньоры в дефицитных нишах. Почему так происходит: ИТ - отрасль роста, которая живет на инвестициях. Расширение команд и новые проекты финансируются в расчете на будущую отдачу. Высокая ключевая ставка делает капитал дорогим. Компании замораживают найм, переносят проекты и закрывают позиции внутренними ротациями. Денег становится недостаточно даже на поддержку текущей разработки. Дополнительный фактор - внедрение ИИ. Часть рутинных задач автоматизируется, что позволяет держать штат меньше. Темпы роста ИТ-рынка замедлились. В 2024 году выручка сектора выросла на 49%. В 2025-м - только на 14%. В первом квартале 2026-го прирост составил 8%, что не покрывает даже инфляцию. Интересный парадокс: спрос упал в высокотехнологичном секторе, а низкопроизводительные отрасли по-прежнему испытывают кадровый голод. В рознице доля незакрытых вакансий достигает 17%. Что делать разработчикам: Паника на рынке - не повод опускать руки. Это повод пересмотреть подход к своей карьере. Компании перестали нанимать всех подряд, но лучшие специалисты по-прежнему нужны. Чтобы оставаться востребованным, нужно смещать фокус с «я умею писать код» на «я решаю бизнес-задачи». Разбираться не только в технологиях, но и в продукте, в пользователях, в метриках. Уметь не просто выполнять задачи, а предлагать решения. Понимать, как твой код влияет на прибыль компании. ИИ автоматизирует рутину, но не заменяет инженерное мышление, архитектурные решения и умение работать в команде. Те, кто развивает эти навыки, остаются незаменимыми. Те, кто застрял на уровне «исполнитель задач», рискуют оказаться за бортом. 🔗 Читать подробнее 💡 Вывод: Рынок труда в ИТ переживает серьезный кризис. Вакансий меньше, конкуренция выше, реальные зарплаты не растут. Это следствие дорогого капитала и глобального замедления. ИИ добавляет давления, но не является главной причиной. Для разработчиков - время жесткого отбора. Для компаний - период оптимизации. Но если вы не просто пишете код, а решаете задачи бизнеса, понимаете продукт и умеете адаптироваться - вам нечего бояться. В кризис увольняют исполнителей. Специалисты, которые приносят реальную ценность, остаются. Подписаться на канал: ➡️ Кот Денисова

👩‍💻 .gitignore - не единственный способ заставить Git игнорировать файлы. Большинство разработчиков знают про .gitignore. Файл в корне проекта, куда складывают node_modules, .env, логи и прочий мусор, который не должен попасть в репозиторий. Но Git умеет игнорировать файлы не только с помощью .gitignore. Есть еще два уровня и каждый решает свою задачу. Три уровня игнорирования: 🔹Первый уровень - .gitignore. Это классика. Файл лежит в репозитории, попадает под контроль версий и работает у всех, кто клонирует проект. Сюда пишут все, что относится к проекту целиком: зависимости, артефакты сборки, локальные конфиги IDE. 🔹Второй уровень - .git/info/exclude. Файл внутри директории .git. Он работает так же, как .gitignore, но не попадает в коммиты. Это место для личных правил, которые нужны только вам: черновики, заметки, экспериментальные скрипты. 🔹Третий уровень - ~/.config/git/ignore. Глобальный файл для всех репозиториев на вашей машине. Сюда добавляют то, что мешает везде. Например, на macOS это .DS_Store. На Windows - Thumbs.db. Настройка делается один раз и забывается. Когда что использовать: 🔹.gitignore - для командных правил. Если файл должен игнорироваться у всех, кто работает над проектом, он идет сюда. 🔹.git/info/exclude - для личных правил внутри одного репозитория. У вас есть файл notes.txt с пометками для себя. Добавлять его в .gitignore не хочется - коллегам он не нужен. В exclude он не отслеживается только у вас. 🔹~/.config/git/ignore - для системных файлов. .DS_Store, Thumbs.db, .swp - все, что создается автоматически и раздражает в каждом проекте. Как проверить, кто именно игнорирует файл: Когда правил много, легко запутаться. Git дает команду git check-ignore -v, которая показывает, какой именно файл игнорирует конкретный файл. $ git check-ignore -v .DS_Store /Users/user/.config/git/ignore:2:.DS_Store .DS_Store Если файл игнорируется .gitignore, вывод начнется с .gitignore. Если exclude - с .git/info/exclude. Если глобальным ignore - с путем в домашней директории. Если команда ничего не выводит - файл никто не игнорирует. 🔗 Читать подробнее 💡 Вывод: Git дает три уровня игнорирования и каждый решает свою задачу. .gitignore - для командных правил. .git/info/exclude - для личных исключений в одном репозитории. ~/.config/git/ignore - для глобальной чистоты на всей машине. Разделение уровней помогает не засорять общие правила личными исключениями и не тащить в коммиты то, что нужно только вам. Правильный выбор уровня избавляет команду от конфликтов и лишних правок .gitignore. Подписаться на канал: ➡️ Кот Денисова

👨‍💻 Почему ваш пет-проект все еще не бизнес. У многих разработчиков есть проект, который вот-вот станет бизнесом. Осталось дописать пару фич, показать продукт пользователям и дальше все поедет само. Спойлер: не поедет. Давайте разберемся, где заканчивается код и начинается бизнес. Бизнес начинается не с технологии: Разработчик смотрит на то, что он умеет делать и ищет, куда это применить. Бизнесмен смотрит в обратную сторону: видит чужую проблему и только потом думает, какой технологией ее закрыть. Если вы думаете о своем продукте с позиции «у меня есть классная технология, давайте найдем ей применение», вы еще не бизнесмен. Вы ищете покупателя на свой код. Бизнес начинается с чужой проблемы. Сейчас многие разработчики увлекаются ИИ и строят проекты вокруг нейросетей. Это выглядит логично: нейросети популярны, можно сделать что-то на них и заработать. Но это все та же ловушка: технология есть, проблема - потом. Такие проекты часто остаются просто демками, потому что никто не проверял, нужна ли кому-то эта возможность. ИИ-агенты могут помочь написать код быстрее и даже сгенерировать первую версию продукта, но они не помогут понять, какую проблему этот продукт решает. Придумать пользу из головы не получится: Следующий соблазн - сесть и придумать, в чем состоит проблема пользователя. Построить логику: «вот такие люди, вот такая боль, вот наше решение». Это звучит неплохо, но на практике почти никогда не работает. Ценность решения определяете не вы. Ее определяют те, кто будет с ним работать. Их критерии - не всегда то, что кажется логичным вам изначально. Самое правильное, что можно сделать - пойти и пообщаться с целевой аудиторией. Узнать, как человек реально делает свою работу. Он сам расскажет, что ему мешает. ИИ здесь тоже не помощник. Можно попросить нейросеть сгенерировать портрет пользователя или список его болей, но это будет выдумка. Реальную проблему можно узнать только у живого человека. Бизнесмен vs менеджер: В ИТ есть распространенная логика карьерного роста: джун -> мидл -> сеньор -> тимлид -> руководитель. Кажется, что следующий шаг - собственный бизнес. Но это совершенно другой путь. Менеджер начинает с активов. У него есть команда, бюджет, инфраструктура. Его задача - использовать это максимально эффективно. Бизнесмен начинает с возможности и как правило, без активов вообще. Он видит проблему и собирает под нее ресурсы. Тимлид оптимизирует спринт с теми людьми, которые у него есть. Бизнесмен проектирует то, чего еще нет. Это принципиально разные задачи и разное мышление. Сейчас многие менеджеры и тимлиды увлекаются внедрением ИИ-агентов в процессы. Это правильный подход для оптимизации существующей системы. Но это все еще менеджерское мышление. Продукт и бизнес - это не одно и то же: Рабочий сервис, первые пользователи и даже выручка - это еще не бизнес. Это продукт. Бизнес - это система, которая производит этот продукт регулярно, в нужном объеме и без того, чтобы все держалось на одном человеке. Простой тест: уйдите в отпуск на две недели. Если без вас все встало - у вас пока не бизнес. У вас есть продукт, а главный производственный ресурс - вы сами. Ценность бизнеса не в коде и не в алгоритме по отдельности, а в том, как все это собрано и работает вместе. Задача бизнесмена - спроектировать систему, в которой продукт выходит регулярно, с нужным качеством, и в которой ключевых специалистов можно заменить или нанять. 🔗 Читать подробнее 💡 Вывод: Код - это инструмент. Бизнес - это система, которая использует инструменты для решения чужих проблем. Если вы создали рабочий сервис, у вас есть продукт. Но бизнесом он станет только тогда, когда сможет существовать и развиваться без вашего постоянного участия. ИИ-агенты и нейросети не меняют этого правила. Они могут ускорить разработку и автоматизировать рутину, но они не строят бизнес за вас. И даже самый продвинутый агент не ответит на главные вопросы: кому нужен ваш продукт и почему они будут за него платить. На эти вопросы придется отвечать вам. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 QUERY: новый метод для передачи параметров в теле GET запроса. IETF утвердила новый HTTP-метод под названием QUERY. Он получил статус «предложенного стандарта» и описан в документе RFC 10008. Метод закрывает проблему, которая долгие годы мучила разработчиков API: как отправлять сложные запросы с параметрами в теле запроса, сохраняя при этом все преимущества GET. POST не подходит для запросов на чтение: Раньше приходилось использовать POST для передачи параметров в теле - это работало, но нарушало семантику, потому что POST предназначен для изменения данных, а не для чтения. И главное - POST-запросы не кэшируются CDN и прокси-серверами. Каждый раз сервер получает новый запрос и обрабатывает его, даже если параметры и результаты не менялись. Это создает лишнюю нагрузку на бэкенд. GET не подходит для сложных запросов: GET с параметрами в URL кэшируется, но имеет ограничение по длине и не подходит для сложных структур. Получался выбор: либо кэширование и ограничения, либо без кэширования и без ограничений. Решение - QUERY: QUERY наконец-то дает официальное решение: параметры в теле, как у POST, но при этом кэширование и безопасность повторения, как у GET. Как это работает: Новый метод QUERY работает так же, как POST - параметры передаются в теле запроса. Но при этом он безопасный и идемпотентный, как GET. Это значит, что его можно повторять без опасений, кэшировать ответы и использовать в сетях с ненадежной связью. Пример запроса: QUERY /feed HTTP/1.1 Content-Type: application/json {“q”:”sport”,”limit":20,"sort":"-published"} Метод явно говорит серверу, прокси и CDN: это запрос данных, он не меняет состояние ресурса, его можно безопасно повторить, а ответ может быть закэширован. Как проверить поддержку QUERY: QUERY поддерживается не всеми серверами. Но есть стандартные способы проверить это. Самый простой - использовать OPTIONS: Host: example.com В ответе сервер вернет список поддерживаемых методов в заголовке Allow: HTTP/1.1 200 OK Allow: GET, QUERY, OPTIONS, HEAD Еще один способ - отправить QUERY-запрос и посмотреть на ответ. Если сервер вернет 405 (Method Not Allowed), значит метод не поддерживается. Какие форматы запросов поддерживаются: Метод QUERY не привязан к конкретному формату. Тело запроса может быть отправлено в разных форматах. В спецификации упоминаются application/x-www-form-urlencoded, JSONPath, XSLT и даже SQL. Сервер сообщает о поддерживаемых форматах через заголовок Accept-Query. Это позволяет использовать наиболее подходящий формат для конкретной задачи. Кэширование и производительность: QUERY поддерживает кэширование через стандартные HTTP-механизмы. Ответ можно кэшировать и использовать для последующих запросов с теми же параметрами. Клиенты могут использовать Conditional Requests (If-Modified-Since, If-None-Match) для проверки актуальности данных. Также сервер может вернуть заголовки Content-Location или Location, указывающие на URI, по которому можно получить результат через GET. Это позволяет переключиться на более эффективный GET для повторяющихся запросов. 🔗 Читать подробнее 💡 Вывод: QUERY закрывает пробел между GET и POST, который существовал десятилетиями. Это безопасный, идемпотентный метод с поддержкой тела запроса и кэширования. Пока рано ждать повсеместного внедрения - стандарт совсем свежий. Пройдет еще какое-то время, прежде чем его начнут поддерживать серверы, библиотеки и прокси. Но для тех, кто проектирует новые API, этот метод стоит взять на заметку. Особенно если предстоит работать со сложными поисковыми запросами или большими объемами данных. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Почему ИИ не вытеснит джунов, а просто изменит их работу. В разговорах все чаще звучит опасение: если внедрить ИИ, то джуны перестанут расти. За них будет делать работу нейросеть и чему они тогда научатся? Тезис спорный. Навыки образования - это навыки. Их не заменишь заменой инструмента. Экономисты не стали хуже от того, что перешли со счетов на калькулятор. Рутина - это не обучение: При верстке однотипных экранов, перекраске кнопок, постой работе с JSON или XML джун ничему не учится. Он просто выполняет работу. Да, он запоминает синтаксис. Да, набивает руку. Но это не навык, который делает из него сильного разработчика. Это механическая работа. ИИ освобождает от этой механической работы ровно так же, как когда-то автокомплит освободил от запоминания названий методов. Навыки от этого не исчезли - они сместились на уровень выше. ИИ не делает работу за джуна: ИИ действительно может сгенерировать код. Но код - это лишь верхушка айсберга. За ним стоит понимание бизнес-логики, умение задавать правильные вопросы, способность видеть неочевидные последствия изменений. Этому ИИ не учит и этому не научит. Джун, который просто копирует сгенерированный код, ничем не отличается от джуна, который копировал с StackOverflow. Оба не понимают, что делают. И оба не вырастут. А вот тот, кто использует ИИ как тренажер - заставляет его объяснять решения, проверяет код, переписывает под свои нужды - растет быстрее, чем раньше. ИИ обесценивает знания: Кто-то считает, что раз нейросеть может написать любой код, то учить синтаксис и алгоритмы бессмысленно. Но это ошибка. Знания не обесцениваются. Они просто становятся другими. Раньше ценность разработчика определялась тем, сколько строчек кода он может написать в день. Сейчас - тем, насколько быстро он может найти проблему, разобраться в чужом коде, объяснить команде, почему одно решение лучше другого. Это требует более глубоких знаний, а не менее. 🔗 Читать подробнее 💡 Вывод: ИИ не мешает джунам расти. Он меняет условия, в которых происходит рост. Кто-то увидит в этом угрозу. Кто-то - возможность. Как всегда, выбор зависит не от технологии, а от человека. И если вы джун и боитесь, что ИИ вас заменит, посмотрите на это иначе. ИИ - это инструмент, который может ускорить ваш путь от джуна до сеньора. Если вы готовы учиться, анализировать и задавать вопросы, вы станете сильнее, чем любое поколение до вас. Потому что у вас есть то, чего у них не было - ИИ, который экономит ваше время на рутине и дает больше пространства для настоящего роста. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 ИИ в резюме: что написать, чтобы не испортить впечатление. Все больше разработчиков добавляют в резюме упоминания об ИИ-инструментах. ChatGPT, Claude, Cursor, Copilot - все это появляется в списке навыков. Но правильно ли это? И как написать о работе с ИИ так, чтобы не испортить впечатление о себе как о специалисте? Просто перечислить инструменты - слишком просто: Строчка «Навыки: Swift, SwiftUI, Swift Concurrency, ChatGPT, CoreData, SwiftData» выглядит странно. ChatGPT в одном ряду с технологиями - это как указать Google в списке языков программирования. В лучшем случае такой пункт проигнорируют. В худшем - решат, что кандидат не умеет отделять инструменты от профессиональных компетенций. В вакансиях иногда прямо указывают желание видеть опыт работы с ИИ. Тогда такое упоминание может сработать как фильтр. Но это редкий случай. И даже тогда перечисление названий моделей не покажет вашего реального уровня. Результат - показатель опыта: Лучше выглядит опыт, описанный через результат. В разделе достижений можно написать: «Увеличил тестовое покрытие с 20% до 95% за два дня, используя Claude Code для генерации тестов». Это звучит убедительно. Во-первых, есть конкретные цифры. Во-вторых, понятен вклад кандидата. В-третьих, видно, что ИИ использовался осознанно, а не как замена головы. Еще один хороший пример - документация. Даже не самые мощные модели хорошо справляются с задачами по документированию кода. «С помощью ИИ устранил техдолг по документации на проекте» - это тоже результат. И тоже показывает, что кандидат умеет применять инструменты для решения реальных задач. Что писать не стоит: Формулировка «реализовал фичу за два часа с помощью Cursor» - это красный флаг. Она создает впечатление вайб-кодера, который коммитит не читая. Даже если это не так, такая строчка читается однозначно: человек не проверяет то, что генерирует ИИ, и не понимает, что попадает в код. Проблема еще и в том, что такие достижения создают нереалистичные ожидания у работодателя. Если кандидат написал, что сделал фичу за два часа, значит, лид может предположить, что и остальные задачи будут решаться так же быстро. А это прямой путь к неадекватным срокам и переработкам. 🔗 Читать подробнее 💡 Вывод: Если вы используете ИИ в работе - это нормально. Но в резюме важно показывать не список инструментов, а результаты. Конкретные цифры, описания задач, улучшения процессов. И главное - демонстрировать осознанное использование ИИ, а не слепое доверие к генерации. ИИ - это инструмент, а не навык. Покажите, что вы умеете им пользоваться, а не просто знаете, что он существует. И тогда даже самый скептический лид увидит в вас не вайб-кодера, а специалиста, который эффективно применяет современные технологии. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Почему знание технологии важнее, чем умение писать промпты. Многие сейчас рассуждают так: зачем учить фреймворки, если нейросеть сгенерирует любой код по промпту? Звучит убедительно, особенно на фоне успехов современных LLM. Можно действительно собрать рабочий интерфейс, почти не вникая в детали. Но вопрос в другом. Не в том, можно ли, а в том, сколько это будет стоить. По времени, деньгам на токены и нервам. Знание технологии меняет подход к работе с ИИ: Когда разработчик знаком с технологией, он лучше продумывает архитектуру и ключевые моменты заранее. ИИ становится мощным ускорителем: генерирует шаблонный код, дописывает рутину, экономит часы. Все это происходит быстро и предсказуемо. А если разработчик плавает в технологии, процесс выглядит иначе. Он тратит больше токенов, потому что приходится переделывать одно и то же. Итераций становится больше. Итоговый код часто получается неоптимальным или даже ошибочным. Просто потому, что трудно объяснить нейросети то, чего не понимаешь сам. ИИ пишет плохо? Возможно, проблема в контексте: Часто можно услышать, что нейросети генерируют плохой код. Но причина чаще не в модели, а в том, как с ней работают. Без указания версии библиотек, требований к архитектуре, ограничений и структуры проекта модель будет гадать. С ИИ нужно уметь работать. Есть множество техник, которые большинство пользователей игнорируют. Тех, кто жалуется на плохие результаты, обычно объединяет одно: они не дают модели достаточно контекста. А потом удивляются, почему результат их не устраивает. Вайбкодинг - это не замена пониманию: Можно нагенерировать работающее приложение, вообще не разбираясь в технологии. Но качество такого подхода падает по мере роста сложности. Для демо-проекта - возможно. Для реального продукта - нет. Вот несколько моментов, которые стоит учитывать: 🔹Устранение багов без знания технологии занимает намного больше времени. Нейросеть может сгенерировать кривой запрос к базе данных или неоптимальный алгоритм и вы просто не заметите этого, если не понимаете, как это должно работать. 🔹Производительность и безопасность - те области, где ИИ часто ошибается. Модель решает задачу «сделать работающим», а не «сделать эффективным и безопасным». Разница критическая. 🔹И наконец, инженерный комфорт. Многие разработчики признаются, что чувствуют дискомфорт, когда ИИ генерирует код, который они не понимают. Вместо слепого доверия они разбираются в сгенерированном коде, находят неоптимальные решения и улучшают их. Но для этого нужна база. 💡 Вывод: ИИ - это мощный инструмент, который ускоряет разработку. Но он не отменяет необходимости в фундаментальных знаниях. Можно навайбкодить демо-проект без понимания технологии. Но чтобы работать быстро, предсказуемо и качественно - база обязательна. Знание технологии меняет все: вы тратите меньше токенов, получаете более чистый код и чувствуете себя увереннее. ИИ не заменяет инженера. Он превращает хорошего инженера в быстрого и продуктивного специалиста. А плохого в того, кто быстро генерирует плохой код и вечно правит баги. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Важные вопросы о будущем разработчиков в эпоху ИИ. Эдди Османи, инженер из Google и автор книг по JavaScript, выпустил разбор того, что происходит с индустрией. ИИ-агенты уже пишут код, компании сокращают найм джунов, а 84% разработчиков используют ИИ ежедневно. Ситуация странная и неопределенная. Вот пять ключевых вопросов, которые определят, как будет выглядеть профессия через пару лет. Что будет с джунами? Гарвард опросил 62 миллиона инженеров и выяснил: через полтора года после внедрения ИИ в компании найм джунов падает на 9-10%. БигТех за последние три года нанял на 50% меньше выпускников. Один инженер съязвил: «Зачем нанимать джуна за 90 тысяч в год, если ИИ-агент стоит дешевле?». Но есть и обратный сценарий. ИИ может открыть спрос на разработчиков в других отраслях - сельском хозяйстве, медицине, производстве. BLS все еще прогнозирует рост софтверных вакансий на 15% до 2034 года. Плюс есть риск медленного разложения, который часто упускают: если не нанимать джунов сейчас, через 5-10 лет некем будет заменять сеньоров. Что делать джунам: прокачиваться в ИИ, показывать, что один человек с нейросетью делает работу за троих, собирать портфолио на GitHub, смотреть на смежные роли (QA, DevRel, аналитика). Не быть очередным выпускником, которому нужно все объяснять и учить. Какие навыки станут главными? 84% разработчиков уже используют ИИ регулярно. При виде бага или новой фичи первый инстинкт - написать промпт и склеить сгенерированные куски, а не писать код с нуля. Ключевой навык будущего - понимать, когда ИИ ошибается. Рутинные 80% задач уходят агентам. Человек фокусируется на архитектуре, безопасности, граничных случаях. Способность разбить сложную задачу на простые шаги становится важнее умения синтаксически правильно написать цикл. Как изменится роль разработчика? Инженер превращается из кодера в дирижера. Меньше написания кода, больше ревью и системного дизайна. Нужно оркестрировать ИИ-агентов, сервисы, пайплайны. Понимать, где можно отдать задачу нейросети, а где нужно писать самому. Это не про то, что разработчики станут не нужны. Это про то, что их работа станет другой. Узкая специализация - это риск? Анализ вакансий показывает: 45% уже требуют знания нескольких областей. Узкие специалисты под ударом. Если вы знаете только один фреймворк или одну технологию, ИИ может закрыть этот пробел быстрее, чем вы думаете. Выигрывают специалисты, которые глубоко знают свое дело, но при этом понимают, как устроены соседние области. У них есть глубокая экспертиза в чем-то одном, но при этом широкий кругозор - понимание смежных областей, инфраструктуры, продукта. Такие люди могут видеть картину целиком, а не только свой кусочек. 🔗 Читать подробнее 💡 Вывод: Следующие два года будут неопределенными, но есть несколько понятных направлений. Джунам придется доказывать свою ценность громче, чем раньше. Ставка на ИИ-навыки и широкий кругозор работает лучше, чем узкая специализация. Диплом перестает быть обязательным, портфолио выходит на первый план. А главное - разработчик из просто кодера превращается в того, кто понимает, когда довериться ИИ, а когда взять все в свои руки. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Async без await - плохая привычка, вызывающая проблемы. В коде часто можно встретить функцию, помеченную как async, хотя внутри нее нет ни одного await. Часто разработчик добавляет этот модификатор на всякий случай: вдруг потом понадобится асинхронность. Кажется, что это безобидное решение. Но на деле все меняется. И не в лучшую сторону. Что меняется, когда функция становится async: Как только перед функцией появляется async, она перестает возвращать значение напрямую. Вместо этого она возвращает специальный объект-обертку (Promise, Future, Task - в зависимости от языка). Даже если внутри нет ни одной асинхронной операции. Это сразу влияет на все места, где вызывается эта функция. Теперь ее нужно вызывать с ключевым словом await. А любой код, который использует await, сам становится асинхронным. И так по цепочке вверх. Асинхронность начинает расползаться по проекту, как снежный ком. Там, где изначально не было никакой асинхронной работы (ни сетевых запросов, ни чтения файлов, ни работы с базами данных). Зато появились лишние проблемы с вызовами. Почему это проблема: Главная проблема не в производительности. Современные языки хорошо оптимизируют асинхронные операции. Проблема в когнитивной нагрузке. Когда разработчик видит функцию с async, он ожидает, что внутри происходит что-то, что требует ожидания. Сеть, диск, внешний сервис. Это подсказка, которая помогает понять, как работает код. Если async стоит везде, где можно и где нельзя, эта подсказка перестает работать. Теряется разница между функцией, которая действительно ждет ответ от сервера, и функцией, которая просто возвращает уже готовую переменную. Код становится сложнее для чтения, отладки и поддержки. Оправдание - а вдруг понадобится: Часто async добавляют с мыслью: может быть, в будущем эта функция будет работать с сетью или базой данных. В некоторых случаях это оправдано - например, в публичных библиотеках, где изменение сигнатуры позже может сломать код пользователей. Но в прикладном коде это скорее вредит. Текущая версия функции не делает ничего асинхронного, а все ее вызывающие уже адаптированы под async. Когда реальная асинхронная операция действительно понадобится, добавить async будет делом одной минуты. А до тех пор код остается проще и понятнее. 🔗 Читать подробнее 💡 Вывод: Async без await - это не страховка на будущее. Это дополнительная сложность, которая распространяется по коду и делает его менее читаемым. Не стоит добавлять async, пока в этом нет реальной необходимости. Код должен быть честным. Если функция возвращает данные синхронно - пусть она остается синхронной. А async пусть появляется только тогда, когда внутри действительно есть что-то, что требует ожидания. Это сделает код чище, а разработчикам будет проще понимать, что на самом деле происходит. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👾 SpaceX покупает Cursor за $60 млрд. Маск делает серьезную ставку на ИИ-разработку. SpaceX договорилась о покупке Anysphere - создателя популярного ИИ-редактора кода Cursor. Сумма сделки - $60 млрд, полностью в акциях. Поглощение пройдет через дочернюю структуру X67 Inc., а Cursor станет полной дочкой SpaceX. Закрыть слияние планируют в третьем квартале 2026 года, при условии одобрении регулятора. Зачем SpaceX покупать Cursor: Cursor - один из самых популярных ИИ-редакторов кода. У него огромная база разработчиков и быстрорастущая выручка. По разным оценкам, годовой доход стартапа составляет от $2,6 млрд (Reuters) до $4 млрд (Forbes). Но главное - Cursor дает SpaceX готовый продукт в сегменте, где xAI пока уступает OpenAI и Anthropic. До этого рынок ИИ-разработки выглядел биполярно: либо Codex, либо Claude Code. Теперь появляется третий серьезный игрок с мощной ресурсной базой. Плюс у Cursor уже есть своя модель Composer, которая неплохо выглядит по бенчмаркам. А если туда интегрировать Grok и ресурсы xAI, может получиться очень интересный продукт. Маск же еще говорил о планах создать свой собственный GitHub для эры ИИ-агентов. И сейчас мы, вероятно, наблюдаем рождение новой экосистемы. Что это значит для разработчиков: Для тех, кто использует Cursor в повседневной работе, пока ничего не меняется. Редактор продолжит работать, обновления будут выходить, поддержка останется. По крайней мере, в ближайшей перспективе. Но дальше возможны сценарии. Если Маск интегрирует Cursor с Grok и xAI, редактор может получить уникальные фичи, которых нет у конкурентов. Например, более глубокую интеграцию с облачными вычислениями SpaceX или доступ к специализированным моделям. Cursor и так был одним из лучших ИИ-редакторов, а с ресурсами SpaceX может стать еще сильнее. С другой стороны, есть риск, что продукт станет менее открытым и более завязанным на экосистему Маска. Пока рано говорить, но история показывает, что крупные поглощения редко проходят бесследно для пользователей. Скорее всего, в ближайшие пару лет мы увидим, как Cursor превращается в нечто большее, чем просто редактор кода. И это может изменить расклад на рынке ИИ-инструментов для разработчиков. 🔗 Читать подробнее 💡 Вывод: Покупка Cursor - это не просто сделка. Это сигнал. Маск серьезно намерен конкурировать с OpenAI и Anthropic в сегменте ИИ-разработки. Cursor получает ресурсы SpaceX и доступ к xAI. А рынок получает третьего сильного игрока в сегменте ИИ-кодинга. Для разработчиков, которые используют Cursor, пока ничего не меняется. Редактор продолжит работать, обновления будут выходить. Но в долгосрочной перспективе возможны сценарии: либо Cursor станет еще мощнее благодаря интеграции с Grok и инфраструктурой SpaceX, либо превратится в более закрытый продукт, завязанный на экосистему Маска. В любом случае, ИИ-инструменты для разработчиков становятся одной из главных арен конкуренции крупнейших технологических компаний. И за этим стоит следить. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Умение адаптироваться - важный навык айтишника, который часто недооценивают. В ИТ недостаточно просто уметь писать код. Рынок меняется, технологии устаревают, приоритеты сдвигаются. Без умения быстро перестраиваться даже опытный специалист рискует остаться без работы. Технологии и рынок не стоят на месте: Инструменты, языки и подходы обновляются постоянно. Еще недавно все искали специалистов под один стек, сегодня - под другой, а завтра требования снова изменятся. То, что вы выучили два года назад, уже может считаться устаревшим. Чтобы оставаться востребованным, нужно уметь перестраиваться и не цепляться за привычный стек. Следить за тем, что появляется нового в индустрии, изучать свежие инструменты и технологии, а главное - понимать, что технологии и фреймворки это всего лишь инструменты для решения определенных проблем и задач, а не религия. Смена подхода - не трагедия, а естественный процесс. И тот, кто замыкается на одной технологии, быстро оказывается за бортом. Когда все идет не по плану: В разработке редко все идет по плану, особенно если план расписан на несколько лет вперед. Прод падает, заказчик передумал, бизнес меняет направление. Тот, кто не выдерживает изменений, паникует и мешает всей команде, вылетит в первую очередь. Нужно уметь быстро переключаться между задачами без потери контекста, не паниковать, когда ужесточают сроки или неожиданно меняют ТЗ и находить новые способы решения задачи, когда старые перестали работать. Рынок меняется каждый год: Еще недавно все искали специалистов под один стек, сегодня - под другой. Завтра требования снова изменятся. Тот, кто замыкается на одной технологии, быстро оказывается за бортом. Нужно понимать, что инструменты - это всего лишь инструменты, а не религия, и спокойно переучиваться, когда рынок этого требует. Когда задач больше, чем времени: Иногда объем работы зашкаливает, требования расплывчаты, а информации катастрофически не хватает. В такие моменты умение перестраиваться помогает не сломаться. Нужно уметь принимать решения в условиях неполной информации, не выгорать при авралах и переработках и сохранять эффективность даже в полном хаосе. 🔗 Читать подробнее 💡 Вывод: Умение адаптироваться - это не хаотичность и не отсутствие плана. Это способность сохранять эффективность, когда вокруг все меняется. Технологии устаревают, приоритеты сдвигаются, рынок перестраивается. Тот, кто умеет быстро перестраиваться, остается востребованным. А кто нет - быстро отстает и выгорает. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Почему компаниям не выгодно увольнять разработчиков из-за ИИ. В последнее время разработчики все чаще задаются вопросом: если нейросети уже пишут код, тестируют и даже деплоят, то как скоро нас всех заменят? Как скоро владельцы бизнеса побегут сокращать штат, оставляя несколько разработчиков с подпиской на ИИ? Давайте разберем, где разработчиков действительно могут сократить, а где нет. И главное - почему экономика сама не даст ИИ вытеснить нас из профессии. Где вас действительно могут сократить: Все зависит от того, в какой команде вы сидите. Если у вас 50 человек и три фронтендера дублируют друг друга, а два девопса делят одну нагрузку - да, там есть избыточность. ИИ поднимет производительность и кого-то могут сократить. Это неприятно, но это про большие команды с пересекающимися ролями. Но если вы - единственный бекендер в команде из трех человек, спите спокойно. Вас никем не заменить. Потому что никто, кроме вас, не полезет разбираться, почему зависла транзакция в базе, и не потратит полдня на эксперименты с постгресом. В маленьких командах избыточности нет. Каждый человек - на вес золота, и ИИ тут не помощник. Рутина не исчезнет, но вы перестанете выгорать: Многие разработчики боятся, что ИИ оставит их без задач. На самом деле произойдет обратное. В живом проекте с пользователями и инфраструктурой всегда есть рутина: там обсудить, здесь починить, тут разобраться. Один человек всегда занят скучными задачами большую часть времени. ИИ освободит вас от самой нудной части этой рутины. Вы перестанете тратить часы на однотипные запросы, написание простых функций или генерацию шаблонного-кода. Но убрать вас из команды и оставить одного с ИИ не получится - потому что некому будет фиксить срочные баги в три часа ночи. Некому будет разбираться в странном поведении базы данных. Кто возьмет на себя ответственность, если что-то сломалось в проде? ИИ не заменит дежурства и изучение проблем. Он просто сделает вашу работу менее выматывающей. Почему вас не уволят - экономика работает против сокращений: Допустим, у вас в команде все-таки произошло сокращение. Теперь трое с ИИ делают работу пятерых. Маржинальность компании выросла. Но это ненадолго. ИИ доступен всем - конкуренты тоже повысили производительность. Через полгода ваше преимущество исчезает и рынок выравнивается. Конкуренция начинает давить на цены или заставляет компанию больше тратить - на зарплаты, инфраструктуру, API-ключи. Чтобы снова вырваться вперед, компании нужно не экономить на команде, а масштабироваться - захватывать клиентов, выходить на новые рынки, делать больше конкурентов. А масштабирование требует людей. Много людей. Потому что больше клиентов = больше инцидентов. Больше инцидентов = больше дежурств. Больше дежурств = больше усталости. И ИИ в этом никак не поможет. И самое главное: ваша компания не единственная на рынке. Даже если она решит оптимизировать штат, конкуренты, которые масштабируются и нанимают, быстро перехватят инициативу. Спрос перетечет туда, где есть живые руки и головы. 🔗 Читать подробнее 💡 Вывод: Переживать, что ИИ оставит вас без работы, пока рано. Сокращения возможны только там, где была откровенная избыточность - несколько человек на одну зону ответственности. В здоровых командах каждый незаменим. Текучка и инциденты никуда не денутся, а капитализм заставляет компании масштабироваться, а не экономить на людях. Бояться нечего. А вот учиться новому - стоит. ИИ не враг разработчику. Он просто забирает себе скучную часть работы, оставляя вам интересную. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Почему разработчики ненавидят своих менеджеров. Всем привет! Сегодня хочу разобрать статью, в которой автор честно говорит про вечную боль отношений между разработчиками и менеджерами. И что особенно важно - ему довелось испытать на себе обе роли: больше десяти лет он был инженером, а потом перешел в менеджмент. Причины возникновения ненависти к менеджерам: Автор статьи рассказывает о пяти вещах, которые могут убить мотивацию разработчиков и привести к возникновению ненависти к менеджерам: Бесконечные созвоны и прерывания: Ты наконец в рабочем процессе, разбираешься с багом, который давно наблюдается в проде. Наушники на голове, ничего не отвлекает. И тут: «Привет, давай созвонимся на пару минут?». И все. Потом нужен минимум час, чтобы вспомнить, где ты был и о чем думал. Плохие менеджеры не понимают, что программирование требует глубокого фокуса. Они относятся к разработчикам как к работягам на конвейере - поставили на паузу, сняли с паузы, поехали дальше. Это же просто кнопка: Менеджеры, которые никогда не писали код, принимают технические решения. Обещают заказчику то, что невозможно реализовать. Назначают дедлайны без консультации с командой. А когда разработчик пытается объяснить, почему задача не на час, а на три дня - его называют душным и не командным игроком, который замедляет команду. Синдром невидимого инженера: Ты ночами и в выходные делаешь невозможное. Пишешь элегантное решение сложной проблемы. А на общем собрании менеджер рассказывает, «каких успехов я добился в этом квартале», хотя всю работу выполнил не он. Менеджер может и не хотеть украсть чужой успех - он просто привык выступать лицом проекта. Но разработчику, который реально сделал работу, от этого не легче. Воронка бесконечных встреч: Стендап на 45 минут. Созвон, чтобы запланировать другие созвоны. Ретроспектива, где ничего не меняется. Календарь превращается в кладбище продуктивности. Разработчики любят строить, а не сидеть на совещаниях. Каждая лишняя встреча крадет время у того, зачем они вообще пришли в профессию. Театр обратной связи: Годовое ревью от менеджера, которого ты почти не видел. Шаблонные фразы из HR-методичек. «Соответствует ожиданиям» - хотя ты в одиночку предотвратил три аварии. Повышение? «Может в конце года». А тот новый сотрудник с половиной твоего опыта, но вдвое большими коммуникативными навыками, только что получил повышение. Неудобная правда: Перейдя в менеджмент, автор обнаружил, что сам начал демонстрировать те же паттерны, на которые жаловался как разработчик. Управление - это одиночество. Ты принимаешь решения с неполной информацией, балансируешь между требованиями начальства и выгоревшей командой. Тебя оценивают по метрикам, которые ты не контролируешь напрямую. Большинство менеджеров не злодеи. Они так же фрустрированы, как и их команды. Их прерывают - они прерывают. Их давят принять любое решение - они принимают плохие. А привычку присваивать чужие успехи они подхватили потому, что в корпоративной среде без этого не выжить: если не покажешь, что именно ты приносишь результат, тебя заменят как бесполезного. 🔗 Читать подробнее 💡 Вывод: Разработчики ненавидят не менеджеров. Они ненавидят плохой менеджмент. При этом сам переход из инженера в управленца - это смена профессии, а не просто еще одна роль. И если менеджер, читая это, узнал себя в антипаттернах, пора задуматься. А если инженер узнал своего менеджера - может, стоит просто честно поговорить о том, что нужно обеим сторонам, чтобы работать эффективно. Лучшие команды - не те, где все друзья, а те, где понимают роль друг друга, уважают чужие сложности и вместе движутся к общей цели. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 ИИ-агент не сделает из вас разработчика, если у вас нет базовых знаний. Сейчас появилось много людей, которые раньше не могли написать даже простую программу, но с приходом ИИ-агентов вдруг почувствовали себя настоящими разработчиками. Они искренне верят, что за пару вечеров могут создать продукт, готовый к выходу на рынок. «Смотри, какую крутую штуку я за вечер сделал!» - делятся они своими успехами. Да, выглядит впечатляюще. Для домашнего использования или пет-проекта этого, возможно, даже достаточно. Но когда речь заходит о том, чтобы выкатить такое на сотни тысяч пользователей, становится понятно: это игрушки, а не продукты. Проблема не в том, что они делают лендинги или простые сайты. Они лезут в сложные системы, даже не осознавая, какой объем знаний и опыта нужен, чтобы довести технический продукт до ума. В чем здесь главная ловушка: ИИ-агенты - это мощный инструмент, но они не заменяют понимание того, как устроена разработка. Чтобы эффективно работать с ними, нужна сноровка. Нужно уметь не просто сформулировать запрос, а задать правильные правила, ограничения, архитектурные рамки. Иначе агент будет генерировать все, что ему вздумается, а не то, что действительно нужно. Без этого фундамента код превращается в кашу. Он может работать на маленьком объеме данных, но как только нагрузка вырастает, все начинает сыпаться. И человек, который «за вечер сделал приблуду», просто не понимает, почему это произошло. Потому что он не знает, как работают базы данных под нагрузкой, как кешировать ответы, как обрабатывать ошибки и как проектировать архитектуру, которая не развалится через месяц. Где место вайбкодингу: Для экспериментов, для обучения, для прототипов - это отлично. Быстро проверить идею, накидать интерфейс, посмотреть, как что работает. Дома, в ознакомительных целях - супер. Но лезть в боевые проекты без понимания технической базы - это все равно что пытаться управлять самолетом, прочитав инструкцию к игрушке. Результат таких попыток обычно один: проект с треском проваливается, код переписывают нормальные разработчики, а автор остается с убеждением, что все пропало и ИИ ничего не умеет. Хотя на самом деле проблема была не в ИИ, а в непонимании того, что именно нужно делать и как. 💡 Вывод: Вайбкодинг - это не замена инженерному мышлению, а его инструмент. Если у вас нет базы, агент не сделает вас разработчиком. Он сделает вас оператором, который генерирует код, не понимая его смысла. А в серьезных проектах это не прокатит. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Почему каждый разработчик должен успеть написать свой проект прямо сейчас. У уважающего себя разработчика должен быть хотя бы один пет-проект. Это не про галочку в резюме и не про демонстрацию того, какой я молодец. Это про возможность делать что-то без ТЗ, без дедлайнов, без согласований. Просто потому, что интересно. Раньше пет-проекты отнимали сотни часов. Сейчас, благодаря агентам, на пет-проекты можно тратить время параллельно с основной работой. Почему раньше пет-проекты делали не все: Причина не в лени. Причина в том, что у обычного разработчика после рабочего дня, семьи, быта и попыток выспаться не остается сил на еще одну кучу кода. Пет-проект превращался в обязаловку, которая висела грузом. В итоге большинство так и не доходили до релиза. Идеи были, энтузиазм угасал после первых трудностей. Что изменилось сейчас: ИИ-агенты и нейросети не пишут код за вас, но они берут на себя рутину. Генерацию шаблонов, настройку окружения, поиск типовых решений. То, на что раньше уходили вечера, теперь можно сделать за час. Пет-проект перестал быть подвигом. Он стал доступным удовольствием. Но есть нюанс - цены на агентов растут: Сейчас модели и подписки на них стоят относительно недорого. Можно пользоваться Claude Code, Cursor, ChatGPT с полным функционалом за разумные деньги. Но этот период не вечен. Компании, предоставляющие ИИ-инструменты, ужесточают условия для бизнес-клиентов, переводят их на оплату по факту. Индивидуальных пользователей пока не трогают, но тренд очевиден: дешевые токены заканчиваются. Рано или поздно подписки подорожают, либо функционал в дешевых тарифах урежут. Что будет, если подождать: Если отложить пет-проект на когда-нибудь потом, можно оказаться в ситуации, когда ИИ-инструменты, которые сильно упрощают разработку, станут заметно дороже. Придется либо платить больше, либо возвращаться к ручному написанию всего кода. Сейчас есть окно возможностей, когда нейросети уже достаточно умны, чтобы реально помогать, но еще не стали роскошью. 🔗 Читать подробнее 💡 Вывод: Пет-проекты перестали быть роскошью для избранных. Сейчас они доступны практически любому разработчику, у которого есть час-два в день и подписка на ИИ-инструменты. Но это окно может закрыться. Если вы давно хотели что-то сделать, но откладывали - сейчас самое подходящее время. Пока агенты еще не подорожали, а вы еще помните, какую идею хотели воплотить. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 Никакого кода до 10 утра: как одна команда перестроила разработку под эпоху агентов. Привет! Хочу обсудить статью о стартапе, который полностью пересмотрел свой подход к разработке после того, как Claude Code и Codex сломали их привычный ритм работы. Они собрали рабочую группу и переписали правила с нуля. Главное из них: никакого программирования до 10 утра. Восемь часов утра отводятся на обсуждение, согласование и совместное написание промптов. Только после этого агенты начинают работать. Суть нового подхода: Авторы статьи формулируют несколько ключевых принципов: 🔹Агенты - главные пользователи. Все системы, хранилища данных, соглашения об именовании должны быть спроектированы так, чтобы их основным потребителем был ИИ-агент. Люди взаимодействуют с системами через агентов, когда это возможно. 🔹Код - это контекст, а не библиотека. Агенты читают код, чтобы понять, что он делает, а затем генерируют свою версию. Не оптимизируйте код для переиспользования людьми. Оптимизируйте его для понимания агентом. Код сам по себе становится документацией. 🔹Данные - реальный интерфейс. Правильный интерфейс между компонентами - это хорошо структурированный артефакт данных, а не вызов функции. Чистые данные позволяют агентам строить системы без указаний, как это делать. 🔹Максимизируйте использование агентов. Если команда едет на работу, а ничего не работает - это пустая трата ресурсов. Агенты должны работать ночью, в дороге, на совещаниях, асинхронно. Самое дорогое в системе - это простаивающий вычислительный ресурс, который ждет человека. Формулирование задачи: 🔹Перед началом работы нужно сформулировать цель одним предложением, перечислить ограничения и определить критерии успеха. Если вы не можете уложить цель в одно предложение - вы недостаточно понимаете проблему. 🔹Не описывайте процесс, описывайте результат. ИИ сам определит процесс. Вы оцениваете результат по отношению к целевой функции. Это заменяет традиционные технические задания. 🔹Определяйте правила, а не структуру. Не переусложняйте схемы и форматы. Установите соглашения об именовании, требования к метаданным и правила версионирования. Пусть агенты сами разберутся с остальным. 🔹Проверяйте результат, а не код. Не читайте каждую строку, написанную агентом. Тестируйте код на соответствие цели. Если он проходит проверку - выпускайте. Если нет - пересматривайте цели и ограничения. Код-ревью в привычном виде становится излишним. Как организовать совместную работу: 🔹Никакого кода до 10 утра. Первый час-два каждого утра служит для обсуждения, согласования и совместного составления промптов. Как только команда определила, что строить и как настроить агентов, можно начинать кодинг. 🔹Оптимизируйте время, а не токены. Если в 10 раз больше токенов экономит день - тратьте токены. Узкое место - время принятия решений человеком, а не вычислительные затраты. 🔹Немедленно указывайте на антипаттерны. Если замечаете, что кто-то возвращается к старым привычкам (разрабатывает решения для людей, а не для агентов, накапливает мертвый код, пропускает спецификации) - отмечайте это. Старые привычки быстро накапливаются. 🔗 Читать подробнее Мое мнение: Мне кажется, эта стратегия работает не для всех. Она предполагает, что команда уже умеет хорошо формулировать задачи и понимает, чего хочет. А если нет? Тогда утро без кода превратится в утро без результата. Промпты будут красивыми, а код - бесполезным. И еще момент про «проверяй результат, а не код». Звучит круто, но на практике часто бывает, что код работает, но написан так, что через месяц в нем никто не разберется. А следующий агент, который будет его читать, просто сломается от неожиданностей. Так что ручное ревью, наверное, пока рано отменять. В целом подход интересный, но рискованный. Для стартапов, которые могут позволить себе переписывать код каждые три месяца, - отлично. Для проектов, которые живут годами, - нужно быть осторожнее. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO

👨‍💻 О сложности заработка на пет-проекте. Наткнулся на откровенную статью разработчика, который трижды пытался сделать прибыльное приложение. Результат: 2000 установок и 8 платных подписок по 6 долларов. Одна из них - его собственная. После полугода работы по ночам, в выходные и в отпуске. Это не первый блин комом. Первый проект умер на этапе обучения. Второй - после полугода разработки и потраченных полумиллиона рублей - оказался никому не нужен. Ноль пользователей. Третий, с умными установками «не делать маркетплейсы» и «привлекать пользователей с первых дней», дал 2000 установок и конверсию, о которой даже говорить стыдно. Главное открытие автора: 80% времени и сил уходит не на код. А на маркетинг. Реклама в сторах - выкинутые деньги. 5 тысяч рублей дают 30 установок. Из них 90% уходят сразу. Пара человек пользуются бесплатно. Никто не покупает. Платная реклама почти никогда не окупается. Единственное, что работает, - креативный подход и создание контента. Но на это уходит 80% усилий. Мечты о пассивном доходе разбиваются о реальность: разработка - это меньшая часть работы. Эмоциональные качели: Автор описывает состояние, которое знакомо каждому, кто пробовал: от вдохновения до «на что я трачу свою жизнь». После очередной подписки надежда возвращается. Потом снова отчаяние. И так по кругу. Добавляют масла инфоцыгане с курсами «Заработай 10к на приложении за 3 дня без навыков». Они тиражируют единичные успешные кейсы, выдавая их за систему. Про шансы, провалы и реальные бюджеты на маркетинг они молчат. Мое мнение: С приходом ИИ-агентов количество приложений в магазинах выросло в разы. Раньше конкуренция была огромной, теперь она запредельная. Да, хорошие и качественные приложения всегда будут востребованы. Но чтобы их раскрутить, нужны серьезные деньги на маркетинг. Пет-проект с минимальным бюджетом было сложно продвинуть и раньше. Сейчас - практически невозможно. ИИ упростил создание приложений, но не упростил их продвижение. Наоборот - усложнил, потому что предложение выросло, а внимание пользователей осталось прежним. 💡 Вывод: С точки зрения денег, делать свой продукт - плохая идея. Статистически выгоднее строить карьеру в найме. Но не все измеряется деньгами. Пет-проекты незаменимы для практики и обучения. Даже если проект не взлетит, навыки, которые вы прокачаете в процессе, останутся с вами навсегда. Подписаться на канал: ➡️ Кот Денисова Закрытый канал: 🚀 Мобильный трудоголик PRO