IT Insights

Реклама WinRAR

Как стать 10x-разработчиком с помощью проговаривания мыслей

Андрей Карпати недавно написал в X о своём новом любимом способе работы с LLM — «хорошей длинной сессии бесцельного проговаривания мыслей», как он сам это назвал.

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

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

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

У вас осталось всего несколько недель на вайб-кодинг

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

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

Большинство из нас уже потратили время, силы и деньги на создание вещей, которые никому не нужны. Скоро месяц вайб-кодинга будет обходиться в 2000–4000 долларов.

На этом вайб-кодинг и закончится.

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

Один файл CLAUDE.md стал вирусным - причина до смешного проста

Я чуть было не пролистал это сообщение. Пост в LinkedIn о Markdown-файле, ставшем вирусным на GitHub. Звучало как хайп. Типа, когда кто-то делает скриншот количества звезд и выдает это за революцию.

Затем я проверил репозиторий. 91 000 звезд. Никаких зависимостей. Никакоих этапов сборки. Никакой модели. Просто один файл под названием CLAUDE.md с четырьмя правилами поведения внутри. И эти правила не являются чем-то новым. Вот что меня обеспокоило. Это то, что каждый senior инженер рассказал бы младшему в первый день работы. И все же этот файл сейчас является самым популярным репозиторием на GitHub, и кривая растет. Я немного подумал и вот, что происходит на самом деле.

Как ошибка двухлетней давности привела к тому, что мое Flutter-приложение получило счет за ИИ на €3167

В апреле 2026 года моё Flutter-приложение было представлено на презентации Google Cloud Next’26 для разработчиков в Лас-Вегасе. Три недели спустя я обнаружил, что тот же проект заблокирован за злоупотребление, а за ночь с меня списали 3167 евро за использование Gemini Developer API.

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

Это история о том, как моя конфигурация Firebase привела к утечке данных.

Как DoorDash создал систему проверки кода на основе ИИ, к мнению которой инженеры действительно прислушиваются

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

Мы хотели сделать что-то другое. Последние несколько месяцев мы постепенно разворачивали агента для code review внутри инженерной организации DoorDash. Ключевой проблемой в итоге оказалось внимание: помочь агенту сфокусироваться на тех частях изменений, которые действительно заслуживают пересмотра, и молчать, когда ему нечего полезного добавить.

Планка, которую мы для себя установили, была не в духе «находить проблемы». Критические вопросы были такими:

• Действительно ли инженеры меняют свой код, когда агент оставляет комментарий?
• Сохраняет ли он достаточный уровень доверия, чтобы команды продолжали держать его включённым?

Вот к чему мы пришли.

Почему вашим следующим приложением, вероятно, не будут пользоваться

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

Это тот же сдвиг, который уже заметен на примере Google и Stack Overflow. Если уловить паттерн, то идею headless-приложений представить намного проще.

Конвейер подготовки джунов сломан, и ни у кого нет плана по его исправлению

Средний срок работы разработчика в крупной tech-компании — 2–3 года. Среднее время, чтобы вырастить junior-а в надёжного самостоятельного middle-инженера — 2–4 года. Среднее время от middle до senior — ещё 3–5 лет. Эти цифры могут гулять, но порядок величин стабилен: чтобы вырастить senior-инженера из нового выпускника, нужно примерно 5–9 лет.

Если индустрия заметно сокращает junior-найм на протяжении трёх лет подряд — 2024, 2025 и 2026 годов, а именно это сейчас и происходит, — эффект проявится не сразу. Он проявится в 2029–2033 годах, когда истончится конвейер middle-инженеров, и в 2032–2036 годах, когда истончится конвейер senior-инженеров.

К тому моменту компании, которые сегодня режут junior-найм, будут конкурировать за ещё меньший пул опытных инженеров и жаловаться на «дефицит талантов». CEO будут винить кого угодно, кроме самих себя, за проблему, которую сами и создали тремя годами квартальной оптимизации.

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

Прямо сейчас ответ такой: нет. Ни у кого нет плана.

Промпт-контракты — от гадания к выпуску кода

Фреймворк промпт-контрактов не о том, чтобы писать больше кода. Он о том, чтобы думать 60 секунд, чтобы Claude Code не приходилось гадать 60 минут.

Я перешёл от азартных игр к поставке продуктов. Ваш ход.

Сейчас писать код дешево

Самая большая проблема при внедрении методов агентной инженерии — это смириться с последствиями того факта, что написание кода теперь обходится дёшево.

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

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

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

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

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

Никакого программирования до 10 утра

Инженерное дело сегодня — это уже не просто написание кода. Вот стратегия одного стартапа по созданию проектов в эпоху ИИ-агентов.

🤖 Происходит что-то серьезное

Новая алармистская статья про угрозу ИИ. Мэтт Шумер (предприниматель и инвестор в сфере ИИ) ответственно заявляет, что скоро ничего не будет - никакой работы, один сплошной ИИ. Сначала он заменил программистов, а сейчас идет и за всеми остальными:

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

Усталость от ИИ — это реальность, и никто об этом не говорит

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

Я хочу поговорить об этом честно. Не в версии «ИИ — это потрясающе, и вот мой рабочий процесс». А в реальной версии. В той, где вы смотрите на свой экран в 11 вечера, окруженные сгенерированным ИИ кодом, который вам еще нужно проверить, и задаетесь вопросом, почему инструмент, который должен был сэкономить вам время, отнял у вас весь день.

Модульность как архитектурный выбор

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

Навыки, которые вы теряете, пока ИИ берет на себя рутинные задачи

Концертный пианист не забывает, как играть. Он забывает, как играть хорошо. И он не замечает этого, пока это не становится важным.

Вы не потеряете работу из-за ИИ.

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

Вопрос не в том, использовать ли ИИ. Вы будете его использовать.

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

Почему Senior инженеры допускают провал неудачных проектов

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

X открывает исходный код своего алгоритма рекомендаций

В 2023 году Twitter впервые частично открыл исходный код своего алгоритма. В те дни миллиардер Илон Маск, владелец Tesla, только недавно приобрел платформу и заявил, что его миссия — реструктурировать социальную сеть, сделав её более прозрачной.

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

Теперь X делает вторую попытку и снова открывает исходный код своего алгоритма, выполнив обещание, данное Маском на прошлой неделе. «Мы сделаем новый алгоритм , включая весь код, используемый для определения того, какие органические и рекламные публикации рекомендуются пользователям, открытым в течение 7 дней», — сказал он. Маск также пообещал обеспечивать прозрачность работы алгоритма каждые четыре недели в обозримом будущем.

Разработка [iOS] приложений с помощью ИИ в 2026 году

Томас Рикуар из Medium написал огромную статью о своем подходе к iOS-разработке с помощью ИИ, используемых инструментах и идеях о том, как будет развиваться программирование в будущем:

Программирование мертво, и оно не вернётся. Оно медленно, но верно угасает.

Следующие два года в области разработки программного обеспечения

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

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

Что произойдет дальше действительно неопределенно. В статье приведены пять важнейших вопросов, которые могут определить развитие программной инженерии в 2026 году, с двумя контрастными сценариями для каждого. Это не совсем прогнозы, а скорее инструменты для подготовки. Цель — четкая дорожная карта для решения будущих задач, основанная на текущих данных и смягченная здоровым скептицизмом, которым славится это сообщество.

По возможности, поддержите мой перевод на Хабре.

Как работают ИИ-агенты и кому они на самом деле нужны

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

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

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