Кот Денисова

👨‍💻 Почему разработчики стали маркетологами.

Есть метрика time to market - количество времени, которое нужно, чтобы вывести продукт на рынок и начать на нем зарабатывать. С появлением ИИ эта метрика сильно сократилась. Если раньше на разработку уходили месяцы, то сейчас за пару дней можно выкатить прототип или даже первую рабочую версию. Это меняет рынок и ценность работы.


Что изменилось:

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

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

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


С чем сталкиваются разработчики:

Оказывается, если ты хочешь зарабатывать на этом рынке, нужно уметь не только писать код и создавать приложение. Нужно уметь показать его миру.

Нужно привлекать трафик. Объяснять ценность. Упаковывать идею. Понимать, кому ты это продаешь, зачем человеку это нужно и почему он должен обратить внимание именно на твой продукт.

Можно сделать хорошее приложение. Но если о нем никто не узнает, это останется пет-проектом с идеальной архитектурой.


Как распределяются усилия:

Чтобы заработать первые деньги, усилия часто должны распределяться совсем не так, как программисты привыкли думать. Не 80% в продукт и 20% в маркетинг, а скорее наоборот: 20% в первую рабочую версию продукта и 80% в то, чтобы понять рынок, привлечь внимание, донести ценность и получить первых пользователей.

Это звучит непривычно. Но именно так работает экономика внимания. Продуктов много. Внимания мало. Выигрывает не тот, кто лучше написал код, а тот, кто лучше объяснил, зачем это нужно.


ИИ помогает не только с кодом:

Хорошая новость в том, что нейросети помогают не только писать код. Они помогают исследовать рынок, формулировать офферы, писать тексты, собирать лендинги, делать контент, тестировать гипотезы, анализировать аудиторию и быстрее понимать, что вообще имеет смысл создавать.

Это снижает барьер для тех, кто раньше не занимался маркетингом. Не нужно нанимать отдельного специалиста, чтобы проверить гипотезу. Можно сделать это самому с помощью тех же инструментов, которые помогают писать код.


🔗 Читать подробнее


💡 Вывод:

Создание продукта стало доступным. Это значит, что конкуренция выросла. Выигрывает не тот, кто умеет создавать, а тот, кто умеет доносить ценность.

Разработчикам стоит пересмотреть распределение усилий. Не 80% в код, а 20%. Остальное - в маркетинг, исследование рынка, упаковку и привлечение пользователей.


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Скорость разработки перестала быть дефицитом. Дефицитом стали доходные идеи.

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


Что изменилось:

С появлением ИИ бизнес получил возможность собирать MVP, фичи и рефакторинги за недели, а не за кварталы. И оказалось, что большинство этих MVP никому не нужны. Это вызвало вопрос: действительно ли бутылочное горлышко было в разработке?

Если мы генерим MVP быстро, но они не находят спроса, проблема в них, а не в скорости разработки. Раньше узким местом была очередь в разработку. Сейчас приложение может быть готово в понедельник и выясняется, что платить некому.


От одиночки к команде и обратно:

Разработка начиналась с одиночек. Один человек мог собрать продукт и вывести его на рынок. Потом требования выросли, и один человек перестал конкурировать с командами.

Команды дали синергию. Когда продукт стал крупнее, появились направления: несколько команд под одним руководителем, цепочка координации, разделение на части. Руководитель направления в этой схеме - не «писать код лучше всех», а держать разных людей на одном результате.

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


Сигнал с рынка:

Генеральный директор Y Combinator Гарри Тан на конференции SXSW в марте 2026 года описывал свой день так: «Я могу работать полный день, проводя восемь-девять часов встреч, и написать 10 тысяч строк кода в трех разных проектах прямо сейчас».

По его словам, внутри YC примерно половина стартапов производит 10–20 тысяч строк кода в день. С доступным интеллектом ускоритель меньше смотрит на диплом и опыт работы в крупных компаниях, а больше - на вкус, самостоятельность и продуктовое чутье.


Медленная разработка скрывала мертвые идеи:

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

Теперь темп другой. Раньше: «Проверим эту гипотезу в следующем квартале, когда освободятся ресурсы». Сейчас: «ИИ собрал приложение за выходные. Завтра понедельник. Где первые 100 оплативших пользователей?»

Сегодня продуктовая команда часто не успевает генерировать и проверять денежные смыслы с той скоростью, с которой модели генерируют код. Пока мы не можем проверить все идеи - мы верим, что где-то есть та, что принесет деньги. Когда мы можем проверить все - мы видим, что денежных просто нет.


🔗 Читать подробнее


💡 Вывод:

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

Конечно, всегда можно вспомнить фразу Чарльза Дьюэлла в 1899 году: «Все, что может быть изобретено, уже изобретено». Значит, всегда есть надежда, что будут открываться новые возможности. Но кажется, ИТ-компании и инвесторы поняли: это теперь дело отважных одиночек и пионеров, а не общепринятая практика каждой компании.

Скорость разработки перестала быть дефицитом. Дефицитом стали доходные идеи. И пока этот дефицит не будет закрыт, сокращения будут продолжаться.


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Команды Git, которые полезно знать.

Когда вы уже хорошо знакомы с командами add, commit, pull и push, наступает момент, когда нужно больше. Не просто сохранять изменения, а управлять историей. И здесь Git предлагает команды, которые могут быть как полезными, так и опасными.


Rebase:

Rebase нужен, когда вы работаете над своей веткой, а в основной ветке (например main) за это время появились новые коммиты и вы хотите, чтобы ваша ветка строилась поверх этих новых изменений из основной ветки.

После git rebase main коммиты D и E превращаются в D' и E' с другими хэшами. Пока ветка только ваша, все безопасно. Если на ней уже работают другие - у них все разъедется.

Это главное правило: rebase можно делать на своих ветках, но не на общих. Если вы переписали историю, а коллеги уже забрали ваши коммиты, у них все сломается.

После rebase обычный push не пройдет - вы получите rejected (non-fast-forward). Есть два способа это исправить:

🔹Первый: git push --force. Он перезапишет удаленную ветку вашей версией. Если кто-то успел запушить свои изменения, они будут потеряны.

🔹Второй: git push --force-with-lease. Он безопаснее: пуш пройдет, только если удаленная ветка не менялась с последнего fetch. Иначе Git откажет, и чужая работа уцелеет.


Amend - исправление последнего коммита:

Amend нужен, чтобы изменить последний коммит. Это удобно, когда вы забыли добавить файл, допустили опечатку в сообщении или хотите объединить изменения с предыдущим коммитом.

Например вы закоммитили изменения, а потом вспомнили, что забыли файл:

git add forgotten-file.ts
git commit --amend --no-edit

Флаг --no-edit означает, что сообщение коммита останется прежним. Если нужно изменить и его, уберите этот флаг - Git откроет редактор.

Важно понимать: amend не редактирует существующий коммит. Он создает новый с тем же содержимым, но другим хэшем. Если ветка уже на удаленном сервере, обычный push не пройдет - вы получите rejected (non-fast-forward).

В этом случае есть два варианта:

🔹Первый: git push --force. Он перезапишет удаленную ветку вашей версией. Если кто-то успел запушить свои изменения, они будут потеряны.

🔹Второй: git push --force-with-lease. Он безопаснее: пуш пройдет, только если удаленная ветка не менялась с последнего fetch. Иначе Git откажет, и чужая работа уцелеет.


Reset - откат назад:

Reset нужен, чтобы откатиться назад по истории коммитов. Но важно знать, что происходит с изменениями:

🔹git reset --soft HEAD~1: откатывает коммит, но оставляет изменения в индексе. Можно сразу закоммитить заново.

🔹git reset --mixed HEAD~1: откатывает коммит, но оставляет изменения в рабочей папке без индексации. Нужно снова делать add.

🔹git reset --hard HEAD~1: стирает изменения и из индекса, и из рабочей папки. Использовать с осторожностью, потому что данные исчезают.


Reflog - восстановление потерянных коммитов:

Reflog нужен, чтобы найти коммиты, которые исчезли из видимой истории. git log показывает коммиты, доступные в той части истории, которую вы просматриваете в данный момент.

Если вы откатите ветку назад, некоторые коммиты могут исчезнуть из вывода git log. Однако это не обязательно означает, что Git тут же их удалил. Git также ведет локальный журнал перемещений ссылок (например HEAD), поэтому исчезнувший коммит может быть в reflog.  Вы можете просмотреть его с помощью:

git reflog

Вы можете увидеть что-то подобное:

e35fa12 HEAD@{0}: reset: moving to HEAD~2
821cd77 HEAD@{1}: commit: Add authentication
f992ab1 HEAD@{2}: commit: Add login page

Вот ваш недостающий коммит. Теперь вы можете переместить ветку обратно к этому коммиту:

git reset --hard 821cd77

🔗 Читать подробнее


💡 Вывод:

Git - это инструмент, который дает много возможностей. Но с возможностями приходит ответственность. Rebase, amend, reset и force - мощные команды, которые могут изменить историю. Использовать их нужно с умом.

Если ветка только ваша - можно делать что угодно. Если на ней работают другие - лучше использовать revert и force-with-lease. А если что-то потеряли - reflog поможет.


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Гонка за самую мощную ИИ-модель подходит к концу?

Последние несколько лет за развитием генеративного ИИ было удобно следить как за спортивной таблицей. OpenAI выпускала GPT-4, Google отвечала Gemini, Anthropic показывала новую Claude, затем начинался следующий круг. Каждая компания приносила набор бенчмарков и объясняла, где ее модель теперь первая.

В 2026 году эта логика начала ломаться. Не потому, что модели перестали становиться мощнее. Наоборот, 1 сентября Anthropic выпустила Claude Fable 5.1 - новую топовую модель для программирования и сложной интеллектуальной работы. Проблема в другом: возможность построить более сильную модель больше не означает, что большинство клиентов захотят использовать ее для большинства задач.


Что показывают цифры:

Financial Times обратила внимание на показательный пример. Fable 5 вышла 9 июня 2026 года как одна из самых мощных моделей Anthropic. Спустя примерно два месяца на нее приходилось около 11% расходов на продукты Anthropic среди корпоративных клиентов.

Это не 11% всей выручки Anthropic, а показатель внутри конкретной выборки корпоративных расходов. Кроме того, доступ к модели был отключен 12 июня из-за американских экспортных ограничений, а глобальный релиз восстановили 1 июля. Цифра не идеальна. Но сама тенденция интереснее конкретных 11%. Компании все чаще выбирают более дешевые модели, если дополнительное качество frontier-модели не влияет на результат.


Что изменилось к 2026 году:

Разница между классами моделей стала огромной. Claude Sonnet 5 стоит $2 за миллион входных и $10 за миллион выходных токенов. Fable 5.1 - $10 и $50 соответственно.

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

В релизе Fable 5.1 Anthropic рассказывает не только о новых результатах на тестах, но и о снижении стоимости cache reads на 75%. То есть даже релиз самой мощной модели теперь приходится объяснять через экономику ее эксплуатации.


На смену лидербордам приходит оркестрация:

Perplexity делает ставку на multi-model orchestration. Разные модели используются внутри одной системы и получают те части работы, для которых подходят лучше. В 2026 году Perplexity развивает Model Council - один запрос может параллельно отправляться нескольким моделям, после чего отдельный слой сравнивает ответы и формирует итоговый результат.

Для прода именно оркестрация становится важнее, чем выбор модели. Нужно решить, какие запросы требуют дорогого inference, когда включать reasoning, сколько контекста передавать, где использовать кеш, когда переключаться на другого провайдера.

Хорошая оркестрация может влиять на стоимость и качество продукта сильнее, чем очередная замена одной frontier-модели на другую.


Так гонка закончилась или нет:

На исследовательском уровне нет. OpenAI, Google, Anthropic, xAI, DeepSeek продолжат выпускать более сильные модели. Frontier по-прежнему важен: именно там появляются возможности, которые позднее становятся дешевле и переходят в массовые модели.

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


🔗 Читать подробнее


💡 Вывод:

К 2026 году рынок раздробился. Есть быстрые модели, reasoning-модели, системы с огромным контекстом, open-weight решения, специализированные модели и архитектуры, которые автоматически переключаются между несколькими вариантами.

Позиция в одном лидерборде все хуже описывает реальную ценность модели. Для прода гораздо важнее соотношение качества, стоимости и задержки.

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


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Почему ПМ игнорирует мнение разработчика и спрашивает других?

Знакомая ситуация. Вы работаете над задачей, разобрались в контексте, изучили все нюансы. Приходит ПМ, задает вопросы, вы подробно объясняете свое видение. А потом оказывается, что решение принято на основе мнения других разработчиков, которые в контекст вообще не погружены.

Это одна из самых раздражающих ситуаций в разработке. И она возникает не от злого умысла, а от того, как устроены процессы в команде.


В чем суть проблемы:

Разработчик, который работает над задачей, видит ее целиком. Он знает нюансы, проблемы, ограничения, потенциальные риски. Его мнение основано на реальном опыте работы с кодом и контекстом.

Когда ПМ спрашивает других разработчиков, не погруженных в задачу, он получает мнения, основанные на догадках или поверхностном анализе. Это не делает их плохими разработчиками, они просто не видят всей картины.


Когда подключается лид команды или всего проекта:

Бывает еще хуже. ПМ идет не к разработчикам, а к лиду команды или всего проекта. Тоже не погруженным в детали конкретной задачи, но имеющим авторитет. И решение принимается на основе их мнения.

Лид команды или всего проекта часто дают ответ в духе «ну, наверное, так можно сделать». Они не видели код, не знают всех ограничений, но их слово оказывается решающим. Потому что у них есть статус.

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


Почему ПМ так поступает:

Причин несколько. И почти все они плохие.

🔹Первая: недоверие. ПМ может не доверять вам. Не потому, что вы плохой специалист, а потому, что не сложилось доверия, или он не понимает, насколько глубоко вы погружены в задачу. Возможно, вы уже допускали ошибки в прошлом. Или просто стиль общения не совпадает.

🔹Вторая: желание ускорить процесс. ПМ считает, что не хочет тратить время на обсуждение с вами, а хочет быстро получить ответ от того, кто, по его мнению, скажет быстрее. Но это иллюзия. Быстрое решение без контекста почти всегда хуже, чем правильное решение с небольшим обсуждением.

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

🔹Четвертая: обычная некомпетентность. ПМ не понимает, почему погруженный в задачу разработчик важен. Он не отличает мнение от экспертизы.


🔗 Читать подробнее


💡 Вывод:

Когда ПМ игнорирует мнение разработчика, погруженного в задачу и обращается к лиду или другим разработчикам, не владеющим контекстом, страдает не только сам разработчик. Страдает качество решений и вся команда. Доверие падает, вовлеченность снижается, а процессы становятся менее эффективными.

Важно, чтобы ПМ понимал: эксперт, работающий над задачей, видит ее иначе, чем кто-то со стороны. И его мнение должно иметь больший вес. А разработчикам стоит не молчать, а аргументированно отстаивать свою позицию. Потому что, если не доносить свою экспертизу, ее никто не увидит.


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Навыки прохождения собеседований стали важнее реального опыта.

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


Что спрашивают на собеседованиях:

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

В крупных компаниях используется стандартный набор технологий и инструментов. Но спрашивают часто о том, что в этих компаниях не используется. Ведь проще найти готовые задачи в интернете, чем составить свои, связанные с реальным проектом.


Раньше было иначе:

Общие вопросы были всегда. Но раньше собеседования больше проверяли реальный опыт и понимание. Сейчас система превратилась в отдельный навык. Прохождение собеседований стало самоцелью.

Вопросы не всегда адекватны. Некоторые компании спрашивают то, что устарело. Другие - что используется раз в год. Третьи - что вообще не имеет отношения к проекту. И это не помогает найти хороших разработчиков.


Собеседования стали отдельной индустрией:

Сейчас даже появились отдельные курсы, менторы и школы по подготовке к собеседованиям. Люди платят деньги за то, чтобы научиться проходить интервью. Не за то, чтобы научиться работать. А за то, чтобы отвечать на вопросы, которые в реальной работе не возникают.

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

Но это не делает таких людей хорошими сотрудниками. Они становятся опытными в прохождении собеседований. Разница огромная. И компании, которые нанимают таких людей, часто получают не то, что ожидали.


Конкуренция - не оправдание:

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

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

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


Почему так происходит:

Рекрутерам и собеседующим разработчикам проще использовать готовые задачи и вопросы. Это экономит время. Не нужно разбираться в проекте, не нужно формулировать задачи под реальный стек.

Но это снижает качество найма. Собеседования оценивают не способность работать, а способность готовиться к собеседованиям. Это разные навыки.


🔗 Читать подробнее


💡 Вывод:

Собеседования в ИТ превратились в отдельный навык, который мало связан с реальной работой. Задачи из интернета не проверяют опыт. Они проверяют способность заучивать решения.

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

Появление целых курсов и менторов по подготовке к собеседованиям только подтверждает, что процесс найма сломался. Вместо того чтобы оценивать реальные навыки, компании проверяют способность готовиться к интервью. И пока компании не пересмотрят свои подходы, эта индустрия будет только расти.


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Почему слабые руководители боятся сильных сотрудников.

В каждой компании есть сотрудники, которые задают неудобные вопросы. Они не принимают ответы «мы так решили» или «так принято». Они спрашивают: «почему?», «что это даст?», «как мы проверяем качество?». Для слабого руководителя такие люди - кошмар. Они подрывают авторитет, требуют ответов, которых у него нет. Признать свою неправоту для него драма. Поэтому он будет пытаться от них избавиться.

Но сильные руководители таких людей ищут целенаправленно.


Кто такие сильные сотрудники:

Сильные сотрудники - это не те, кто просто хорошо пишет код. Это те, кто небезразличен к проблемам вокруг. Они видят, что можно улучшить. Они приходят не с вопросами, а с решениями. Или хотя бы с пониманием проблемы.

Им не нужно четкое ТЗ. Им нужно понимать, для чего это делается. Как только они понимают проблему, они способны решить все сами.

Управлять ими нужно иначе. Если пытаться нарезать задачи и объяснять, как именно все должно работать - они уйдут или перестанут стараться. Им нужны рамки и свобода внутри них.


Как отличить сильного от токсичного:

Главная сложность: сильный и токсичный сотрудник иногда выглядят одинаково. Оба задают неудобные вопросы. Оба спорят. Оба не принимают «потому что я так сказал».

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

Это ключевое отличие, которое важно замечать.


Почему слабые руководители проигрывают:

Слабый руководитель нанимает удобных. Тех, кто не спорит, не задает вопросов, делает что скажут. Это проще, безопаснее и не требует усилий.

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

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


🔗 Читать подробнее


💡 Вывод:

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

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

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


Подписаться на канал:
➡️ Кот Денисова

👨‍💻 Менеджер - это еще не бизнес. Кто на самом деле принимает решения?

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

Но это ошибка. В большинстве случаев те, кто ставит задачи и меняет требования, к бизнесу имеют косвенное отношение. Они наемные сотрудники, у которых свои 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