The 2025 Developer Survey.

Давайте начнем трудовую недельку с небольшого на 49000 с плюсом респондентов исследования от StackOverflow — The 2025 Developer Survey. Все в ресерче пропитанно AI и LLM.

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

Еще отмечу, что в 2025 году доля положительных отзывов об инструментах на основе AI снизилась по сравнению с 2023 и 2024 годами, когда она составляла более 70%. В этом году этот показатель составил всего 60%. Но среди профессионалов доля положительных отзывов выше (61%), чем среди тех, кто только учится разработке (53%).

Закон Гудхарта как неизбежность экономики управляемой тревоги

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

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

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

Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT.

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

Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT.

Опуская детали и разные разности, финально хочется зафиксировать важный момент: если у тебя уже случился такой кейс, ну научись работать в новых условиях, скоро таких будет каждый второй, и работать таки придется. То есть как правильно ставить им задачи? Как правильно выставлять условия? Какие у тебя реальные есть требования к коду и можешь ли ты их формально подготовить для LLM?

Ну и сами дальше можете придумать. Для примера можно оттолкнуться от Summary of 'Clean code' by Robert C. Martin, там коменты тоже хорошие. +)