О чём я
размышляю

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

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

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

Часто опасаются, что ИИ делает людей глупее, потому что берёт значительную часть работы на себя. Я смотрю на это иначе.

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

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

Сегодня этот стандарт меняется. Акцент смещается с количества потраченных часов на качество решения и точность результата.

Вопрос больше не звучит так: «Сколько времени это заняло?»

Теперь он звучит так: «Верное ли решение вы приняли и достигли ли верного результата?»

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

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

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

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

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

Это жадный алгоритм. Он прекрасно работает — ровно до того момента, когда перестаёт.

Я запустил его на 8 запросах и 25 специалистах. Он закрыл семь, а восьмой клиент остался вообще без людей. Когда я посмотрел цифры, оказалось, что по дороге он сэкономил 47. Каждое его решение было самым дешёвым из возможных в тот момент, и результат всё равно оказался неприемлемым. Ни один менеджер не станет объяснять клиенту, что тот не получил никого, потому что компания экономила 47.

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

У задачи, которая у меня на самом деле была, есть имя: задача о назначениях. Есть люди, есть работы, у каждой пары своя стоимость, и нужен самый дешёвый набор назначений в целом. Не самый дешёвый первый выбор. Самая дешёвая сумма.

Венгерский алгоритм решает её точно, за O(n³). Вместо того чтобы идти по запросам по одному, он строит матрицу «каждый специалист против каждого открытого места» и находит лучшее назначение сразу по всем.

На тех же 8 запросах он закрыл все восемь. На больших прогонах он тоже закрыл всё — и при этом вышел дешевле жадного: 904 против 917 в одном случае и 2071 против 2097 в другом. Вот это меня удивило. Я был уверен, что за корректность придётся доплатить. Оказалось, что жадный ничего и не экономил, как только людей становилось достаточно.

Он медленнее — примерно в восемь раз. На 150 специалистах это 160 миллисекунд. Работа, которую он заменяет, занимает у человека три дня.

Об одном я позаботился отдельно. Я не придумывал этот алгоритм, я реализовал его по описанию — значит, просто поверить ему я не имею права. Я написал второй матчер, который перебирает все возможные комбинации. Он безнадёжно медленный, но ошибиться незаметно он не может. Дальше я сгенерировал 200 случайных сценариев и проверил, что быстрая версия совпадает с медленной в точности. Если они когда-нибудь разойдутся, сборка упадёт.

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

Жадный писался быстрее и объясняется проще. Он же был тихо неправ ровно в той ситуации, которая стоит настоящих денег, — и сам бы мне об этом никогда не сказал.

Меня зацепило то, что один разработчик сказал про Git и файлы .env, — особенно мысль о том, что мы иногда держимся за определённые практики разработки не потому, что они лучшие, а просто потому, что к ним привыкли.

Я согласен с этой мыслью, но здесь важно кое-что уточнить.

Проблема не в том, что Git «не разрешает» коммитить .env. Технически — разрешает. Мы обычно этого не делаем потому, что в .env могут лежать чувствительные данные: ключи API, пароли, доступы к базе данных.

Поэтому правильный вопрос для меня не «почему мы не кладём .env в Git?», а другой: мы поступаем так, потому что это действительно верно, или просто потому, что всегда так делали?

Решение — вовсе не обязательно закоммитить настоящий .env.

Можно закоммитить .env.example со всеми переменными, которые нужны проекту, но без реальных значений, а сами секреты хранить в менеджере секретов или в централизованной системе управления секретами.

И это, мне кажется, самое важное во всём обсуждении.

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

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