В то время как вся индустрия ПО вкладывается в ИИ, открыто заявлять "я категорически не буду программировать с помощью ИИ" — это почти как сознательно сужать свои карьерные возможности.
Но Джейк Уортон все равно так сделал.
Этого гуру open-source в области Android и Kotlin, которого китайские разработчики называют "Джей-богом", при поиске новой работы составил список из девяти критериев для будущего работодателя. Первым пунктом стало: не идти в ИИ-компании, не участвовать в продуктах, ядром которых является ИИ, и не соглашаться на принудительное использование ИИ инженерами. По его оценке, это требование сразу исключает около 80% потенциальных работодателей.
У Уортона был выбор. Он утверждает, что базовая годовая зарплата старшего инженера по Kotlin в США обычно начинается от 200 тысяч долларов, плюс возможны опционы на акции в размере около 100 тысяч долларов в год с четырехлетним вестингом. Войдя в горячие отрасли, такие как ИИ, доходы могут быть выше, но и риски больше. В молодости он был готов делать ставку на опционы; сейчас же он больше ценит стабильный денежный доход и свободу выбора работодателя.
Такое отношение также объясняет причины его ухода из крупных компаний. Уортон признает, что команда Android в Google была выдающейся, но ему не нравится, как Google через продукты и сервисы запирает пользователей в своей экосистеме. По мере роста компании бюрократия увеличивается, итерации продуктов замедляются, а руководство сильнее стремится найти новых пользователей и доход. В сравнении с этим он предпочитает оставаться в небольших командах с четкими целями.
Отношение Уортона к хайповым трендам Кремниевой долины почти резкое. Он считает, что криптовалюты "фактически превратились в финансовую пирамиду", не создав особой реальной ценности; а большие языковые модели сопровождаются не только спорами об авторских правах и лицензиях open-source, но и противоестественным образом проникают в разработку ПО: раньше новые языки, новые IDE и инструменты обычно продвигались инженерами снизу вверх, а теперь это менеджмент, минуя инженерные суждения, требует, чтобы все обязательно использовали ИИ.
Он до сих пор не использовал ИИ-агентов для написания кода. По его мнению, ИИ может помочь инженерам с рутинной работой, но самое безответственное использование — это заставлять ИИ генерировать код, выходящий за пределы компетенций пользователя. Если без большой языковой модели не выполнить задачу, то разработчик часто не сможет по-настоящему понять, проверить и поддерживать результат. Как только возникает зависимость, инженер отдает не только часть работы, но и свои способности и переговорную силу, в конечном итоге превращаясь в легко заменяемую шестеренку.
Уортон не считает, что ИИ исчезнет, и не беспокоится, что программисты скоро останутся без работы. "ИИ уже стал пугающе мощным", но это не значит, что он может стабильно и безошибочно взять на себя весь процесс разработки ПО. Для него ИИ может быть максимум инструментом в ящике с инструментами, но не может стать фундаментом инженерных способностей.
От отказа от ИИ и сомнений в криптовалютах до обсуждения того, сохраняет ли Kotlin преимущества и почему он предпочитает Rust — вот полные ответы Джейка Уортона в недавнем двухчасовом интервью.
1 Kotlin похож на "то, чем Java хотела бы стать через десять лет"
Ведущий: В то время Java уже была самым популярным языком программирования в мире, Android тоже построен на Java, зачем тогда понадобился Kotlin?
Джейк Уортон: Когда появился Kotlin, развитие языка Java находилось в относительно застойной фазе. Oracle постепенно принимал Java, цикл релизов все еще составлял два года. Для команды Android возможности использования языковых возможностей во многом ограничивались самой Java.
В то же время языки программирования вне экосистемы Java быстро развивались, появлялось много новых функций, которые хотели разработчики. Сообщество тоже начало пробовать другие варианты: кто-то использовал Scala, кто-то Groovy. Все ждали более современный язык, и Kotlin появился как раз в этот момент.
JetBrains сама является компанией-разработчиком инструментов, поэтому смогла одновременно с выходом нового языка предоставить IDE и сопутствующую инфраструктуру. Это сделало Kotlin более приемлемым для разработчиков, чем языки, которым нужно строить инструментарий с нуля.
Что еще важнее, использование Kotlin не означает отказ от существующего Java-кода и библиотек. Разработчики могут продолжать использовать существующую Java-экосистему, постепенно вводить Kotlin в существующих проектах и медленно выполнять миграцию. Эта способность к постепенной совместимости — важная причина широкого распространения Kotlin.
Ведущий: Позже ты стал первым инженером в команде Kotlin в Google, как появилась эта возможность?
Джейк Уортон: До прихода в Google я проработал в Square около пяти-шести лет. Примерно за три года до этого мы начали внедрять Kotlin внутри компании.
Чтобы получить одобрение руководства, я написал документ, объясняющий, почему мы должны использовать Kotlin. Поскольку аргументы в нем были применимы не только к Square, я позже опубликовал этот документ. Он в определенной степени способствовал росту интереса к Kotlin в сообществе Android, и я все глубже вовлекался в работу с Kotlin, постоянно продвигая этот язык среди разработчиков.
По мере роста внимания сообщества, некоторые люди внутри Google также постепенно осознали, что Kotlin может сильно помочь в разработке под Android. Тогда некоторые знакомые мне сотрудники Google начали намекать, что Google может официально поддержать Kotlin, и спрашивали, не хочу ли я поучаствовать.
Для меня не могло быть большего признания, чем присоединиться к компании, отвечающей за весь инструментарий Android, и продвигать Kotlin до статуса официального языка первого класса для Android. От такой возможности практически невозможно отказаться.
Ведущий: Было ли сопротивление внедрению Kotlin в команде Android Google в то время?
Джейк Уортон: Скорее не сопротивление, а осторожность. К тому моменту Android уже около десяти-двенадцати лет строился вокруг Java, Java пронизывала весь стек технологий, и команда была с ней очень знакома. В сравнении с этим Kotlin был относительно молодым, недостаточно проверенным языком, стабильным всего год-два.
Поэтому внедрение Kotlin действительно несло риски, и внутри команды были опасения. Google не полностью избегает рисков, но должен был убедиться, что все аспекты продуманы.
Внедрение Kotlin происходило очень осторожно, это не было мгновенным жестким переходом. Команда Android изначально создавала отдельные библиотеки для Kotlin, а не сразу переписывала существующие Java-библиотеки на Kotlin. Командам разработчиков тоже не нужно было одномоментно переделывать всю кодовую базу, можно было внедрять постепенно.
С другой стороны, это доказывает уважение Kotlin к Java-традициям. Он позволяет разработчикам медленно мигрировать, не ломая существующую систему.
Ведущий: Является ли Kotlin языком только для разработки под Android?
Джейк Уортон: Первые несколько лет, из-за большой поддержки Kotlin в сообществе Android, у сложилось ошибочное впечатление, что это язык, созданный специально для Android. Тогда даже появлялись статьи, утверждающие, что Kotlin создан Google для Android, что явно неверно.
Позже Kotlin стал проникать в большее количество областей. Бэкенд-сервисы, которые раньше могли бы строить на Java, теперь все чаще используют Kotlin. Многие возможности, предоставляемые такими компаниями, как Spring, тоже начали отдавать приоритет Kotlin.
JetBrains также продолжает продвигать Kotlin Multiplatform, поэтому теперь Kotlin можно встретить и в iOS, и в десктопных приложениях. Например, Toolbox App для управления и установки IDE от JetBrains — это десктопное приложение, построенное на Kotlin.
Android стал скорее катализатором для проникновения Kotlin в другие экосистемы. Возьмем Square: изначально нам разрешили использовать Kotlin только в проектах под Android. Но Java-инженеры с бэкенда, видя энтузиазм мобильных команд по поводу Kotlin, тоже захотели его использовать. Позже Kotlin постепенно утвердили для использования в бэкенд-сервисах.
Ведущий: Если бы тебе нужно было за минуту порекомендовать Kotlin Java-разработчику, что бы ты сказал?
Джейк Уортон: Kotlin очень похож на "то, чем Java хотела бы стать через десять лет".
Java должна максимально избегать ломать существующий код, поэтому эволюция языка относительно медленная. Многие современные языковые возможности, которые могут попасть в Java в будущем, уже доступны в Kotlin.
Использование Kotlin также не требует, чтобы проект работал на последней версии JVM. В реальности еще много кодовых баз остаются на Java 8 или Java 11, и Kotlin тоже совместим с этими средами. Разработчики могут использовать более современные языковые возможности на более старых JVM.
Ведущий: Какие крупные компании сейчас используют Kotlin в production?
Джейк Уортон: Meta, Google и Amazon используют Kotlin. Изначально применение было в основном на мобильной стороне, но теперь бэкенд-сервисы тоже все чаще используют Kotlin.
Эти компании также вкладываются в соответствующие инструменты. Например, на той неделе, когда мы записывали этот выпуск, Meta передала свой инструмент форматирования Kotlin в Kotlin Foundation, и в будущем он может стать официальным инструментом форматирования Kotlin.
У этих компаний одни из самых больших кодовых баз в мире. Тот факт, что они могут постепенно внедрять Kotlin поверх существующих языков и систем и готовы к долгосрочным инвестициям, сам по себе является подтверждением этого языка.
2 Отталкивающее в Google — запирание пользователей в своей экосистеме
Ведущий: Google для многих инженеров — идеальный работодатель, почему ты ушел оттуда всего через два года и девять месяцев работы?
Джейк Уортон: До прихода в Google я работал в Cash App. Мы продвигали внедрение Kotlin и написали на Kotlin несколько open-source библиотек. Позже Google решил сделать Kotlin официальным языком для Android, и такая возможность была слишком заманчивой.
Однако, присоединяясь, я сказал коллегам, что, вероятно, покину офис через два года. Мой план был помочь Kotlin стать языком первого класса для Android, максимально продвинуть его успех, чтобы в будущем я мог спокойно полагаться на этот язык, а затем вернуться к фронту и с помощью этих инструментов реально создавать продукты.
Мне нравится разрабатывать инструменты и библиотеки, но я не хочу заниматься только инструментами вечно. Я также хочу быть пользователем этих инструментов и реально пожинать плоды своих первоначальных вложений.
Когда истекли два года, я уже собирался уйти, но Google как раз одобрил еще один проект, который мне очень хотелось сделать, поэтому я остался еще на девять месяцев. В итоге я решил, что достиг своей первоначальной цели, и вернулся к разработке продуктов.
Ведущий: Что тебе не нравилось в Google?
Джейк Уортон: Google — очень крупная компания. Команда Android относительно независима, коллеги, с которыми я там работал, были выдающимися, и я до сих пор скучаю по той работе.
Но у меня есть претензии к некоторым действиям Google как компании, например, к тому, как она через продукты и сервисы запирает пользователей в своей экосистеме. Однако эти взгляды в основном касаются способов работы Google как компании, а не команды Android.
Ведущий: Когда ты уходил из Cash App в 2025 году, технологическая отрасль переживала массовые увольнения. Насколько сложно было тогда искать работу?
Джейк Уортон: Искать работу было непросто, но возможности на рынке все же были. У меня были конкретные требования к следующей работе, поэтому я выбирал осторожно.
Мне повезло — я уходил по собственному плану, у меня не было давления срочно найти работу. Но нынешний рынок труда действительно уже не такой, как пять лет назад. Тогда Android-разработчика могли легко нанять и предложить очень высокую зарплату.
Сейчас поиск работы требует больше усилий, занимает больше времени, и нужно уметь доказывать свою уникальную ценность. Я очень понимаю давление, с которым сталкиваются инженеры, вынужденные искать работу. Однако я не думаю, что рынок полностью рухнул. Вакансии по-прежнему есть, просто найти их стало сложнее.
Ведущий: Какова примерно сейчас зарплата старшего инженера по Kotlin в США?
Джейк Уортон: Обычно я вижу базовую зарплату от 200 тысяч долларов, плюс могут быть опционы на акции, например, около 100 тысяч долларов в год с четырехлетним вестингом.
Конечно, есть много позиций и ниже этого уровня. Сейчас компании более осторожно подходят к расходам и не платят повсеместно крайне высокие зарплаты, как раньше.
Если хочется большего дохода, возможно, нужно идти в самые хайповые, потенциально высокодоходные технологические области. Такие компании могут предлагать больше денег и акций, но и риски выше: опционы могут обесцениться или вырасти в десять раз.
В конечном счете, это зависит от жизненного этапа человека и его готовности к риску. В молодости я был готов идти на такой риск; сейчас же я больше склоняюсь к стабильному, предсказуемому денежному доходу.
Ведущий: В 2026 году владение Kotlin еще дает программным инженерам карьерное преимущество?
Джейк Уортон: Не уверен, что сейчас это можно считать преимуществом. В каком-то смысле это даже демонстрирует успех Kotlin: он стал стандартным требованием, а не редким, труднодоступным навыком.
В основном это связано с тем, что Google утвердил Kotlin в качестве официального языка первого класса для Android. Сейчас, входя в область разработки под Android, обычно сразу учат Kotlin, и работодатели по умолчанию считают, что соискатель им владеет. То же самое с Jetpack Compose: около четырех лет назад это мог быть относительно редкий навык, а сейчас он постепенно становится стандартным требованием.
Если разработчик знает не просто обычный Kotlin, а относительно продвинутые возможности, такие как Kotlin Multiplatform, то это все еще может составить дифференцирующее преимущество, выделив вас среди других Kotlin-разработчиков. Но просто "знать Kotlin" уже вряд ли станет явным карьерным плюсом, настолько он распространен.
3 Почему отказываться от программирования с помощью ИИ?
Ведущий: Ища следующую работу, ты публично перечислил девять требований к будущему работодателю, и первым пунктом было "не идти в ИИ-компании, не делать продукты на основе ИИ и не соглашаться на принудительное использование ИИ для разработки". Почему это так важно для тебя?
Джейк Уортон: Он стоит на первом месте не просто так. Возможно, это самый важный для меня критерий при поиске работы.
Мы находимся в периоде быстрых изменений: меняется не только способ разработки ПО, но и многие компании насильно впихивают ИИ — точнее, большие языковые модели — туда, где он, возможно, и не нужен.
Я не считаю, что общее качество ПО за последние годы выросло, и не думаю, что такие инструменты в долгосрочной перспективе улучшат качество ПО. Но некоторые топ-менеджеры видят другую картину: они думают, что ИИ может заставить инженеров работать быстрее и выдавать код более высокого качества. Мое мнение прямо противоположно.
Кроме того, у меня большие претензии к этическим проблемам, стоящим за этими инструментами. На мой взгляд, они построены на массовом использовании защищенного авторским правом контента. Обучение моделей игнорирует авторские права художников и лицензии open-source кода. Возможность доступа к контенту в сети не означает, что у тебя есть право его перекомбинировать, переписывать или даже дословно выводить.
Поэтому я не хочу быть связанным с этим. Просто сейчас полностью избежать ИИ становится все труднее, поэтому я поставил это требование на первое место. Оно также сразу исключает около 80% компаний, в которые я мог бы пойти.
Ведущий: Кроме авторских прав и качества ПО, ты выступаешь еще и против способа, которым компании принуждают инженеров использовать ИИ?
Джейк Уортон: Да. Традиционно инструменты разработки обычно продвигались инженерами снизу вверх.
Возможно, инженеру понравился новый язык, например, Kotlin; или новая IDE, например, IntelliJ IDEA; или новая система сборки. Инженер на практике видит ее ценность, энтузиазм постепенно передается другим, а затем все вместе убеждают руководство утвердить ее использование.
Но продвижение ИИ-инструментов, кажется, идет в совершенно противоположном направлении. Почему CEO компании должен указывать инженерам, какими инструментами пользоваться в повседневной работе?
Руководство компании обычно не требует напрямую использовать статически типизированный язык, не решает, как именно нужно использовать систему типов для выражения бизнес-требований или обрабатывать null-значения. Это изначально инженерные решения. Инженеры понимают бизнес-требования и выбирают инструменты, которые эффективно выполнят работу.
Если бы Джек Дорси тогда потребовал, чтобы я обязательно использовал Eclipse, я, вероятно, тоже уволился бы. Проблема не только в ИИ, а в том, что менеджмент компании перешагивает через инженерные суждения, заставляя разработчиков использовать определенный инструмент.
Ведущий: Почему настойчивое продвижение ИИ руководством ассоциируется у тебя с увольнениями в технологической отрасли?
Джейк Уортон: Если просто требовать использовать какой-то инструмент, это, возможно, отдельный вопрос для обсуждения. Но когда принудительное использование ИИ происходит одновременно с волнами увольнений, вся картина выглядит не так оптимистично.
Я могу сделать личный выбор и не использовать эти инструменты. Я также считаю, что многие компании, полностью вкладывающиеся в ИИ, гонятся за рынком, деньгами и пользователями. Входить в эту область на пике хайпа с коммерческой точки зрения понятно: куда идут деньги и пользователи, туда идут компании.
Но мне повезло. После многих лет работы у меня сейчас есть возможность выбирать работодателя в соответствии со своими ценностями, не у всех есть такая возможность. Отказ от ИИ лишил меня массы потенциальных возможностей, но это пока самый важный для меня критерий, поэтому я готов с этим смириться.
Ведущий: Твой второй критерий — не идти в криптовалютные компании. Ты против криптографии или криптовалют?
Джейк Уортон: Криптография — ценная технология, но я не поддерживаю криптовалюты. До больших языковых моделей криптовалюты были одним из самых популярных направлений в технологической отрасли, и Square с Cash App тогда тоже активно в них вкладывались.
На мой взгляд, криптовалюты в основном превратились в финансовую пирамиду, не создав особой реальной ценности. Это, кажется, противоречит моей ценности "владения" — конечно, я поддерживаю, чтобы люди действительно владели своими активами и не контролировались другими институтами, но проблема криптовалют в конкретной реализации.
В итоге получилась хищническая система. Реально зарабатывают те, кто использует других участников для получения прибыли, или компании, которые строят на этом бизнес и постоянно извлекают ценность из клиентов. Это та отрасль, в которой я не хочу участвовать.
Ведущий: Ты хочешь, чтобы будущий работодатель и использовал open-source ПО, и открывал свои проекты. Почему?
Джейк Уортон: В процессе становления разработчиком я почти всегда имел дело с open-source. Изучая новые технологии, исследуя, как другие пишут ПО, я в первую очередь смотрю на open-source проекты. Поэтому для меня, когда я пробую или создаю что-то новое, выбор по умолчанию — сделать это открытым.
Позже я присоединился к Square, и нам удалось открыть исходный код множества наших технических наработок. Почти каждая компания строится на основе работы других. Если бизнес готов открывать свои наработки или вносить вклад в другие open-source проекты, это и есть отдача, передача полученной помощи следующим поколениям.
Компании не нужно с нуля строить Linux, Android, SQLite или JVM, потому что предыдущие поколения уже проделали эту работу. Точно так же проект, который ты открываешь сегодня, может стать основой для следующей компании или следующего поколения разработчиков.
Ведущий: Еще одно твое требование — компания должна быть "небольшой и сфокусированной". Почему ты считаешь, что сделать одну вещь хорошо важнее, чем пытаться обслуживать всех?
Джейк Уортон: Один из лучших периодов в моей карьере — ранние дни в Square, участие в создании Cash App. Тогда компания была еще небольшой, все знали друг друга, и можно было быстро исполнять общее видение. Команда даже с некоторой наивностью верила, что может сделать много всего.
Когда я присоединился к Square, в компании было около 200 человек; когда я уходил из Cash App, их стало примерно 12 тысяч.
Google был еще на порядок больше. По мере роста компании бюрократия увеличивается, итерации продуктов замедляются, а руководство все сильнее стремится найти направления, которые привлекут новых пользователей и доход.
В сравнении с этим небольшой команде легче сохранять чистоту цели: найти четкую проблему и решить ее хорошо.
Ведущий: Кроме падения эффективности в крупных компаниях, какое влияние они оказывают на самого инженера?
Джейк Уортон: Чем крупнее компания, тем уже становятся обязанности инженера. Я слышал об инженере в Twitter, который долгое время отвечал практически за крошечную часть интерфейса личных сообщений. Когда работа человека настолько фрагментирована, ему сложно испытать другие аспекты разработки продукта.
Мне нравится участвовать в разного рода задачах, постоянно переключаться между проблемами внутри одного продукта. Небольшие команды дают инженеру больше такого пространства, а также больше возможностей для обучения.
Когда команда небольшая, нет отдельной команды из 50 человек, которая решала бы за тебя определенный класс проблем. Ты не можешь просто бросить задачу в другой отдел и ждать два месяца результата, ты должен выйти из зоны комфорта, самому учиться и решать проблемы. Для меня такая широта и возможности роста очень важны.
Ведущий: После трех месяцев поиска в феврале 2026 года ты присоединился к Skylight. Чем эта компания тебя убедила?
Джейк Уортон: Skylight соответствует многим упомянутым ценностям, и что важнее, я сам являюсь ее целевым пользователем.
Она делает аппаратные продукты для семей, а у меня есть семья и реальные потребности в их использовании. Я давно хотел больше работать с аппаратной разработкой, и эта работа как раз дает такую возможность. Она связана с Android, но включает много вещей, которые я раньше глубоко не делал, например, AOSP и работу с реальным железом.
Приложения Skylight не распространяются через магазин Google Play, поэтому у нас больше контроля над системой, не нужно иметь дело со многими проблемами экосистемы Google Play. Для меня это тоже привлекательная новая область.
Кроме того, компания уже привлекла финансирование и имеет реальные доходы. Я знаю автора Nova Launcher Кевина Барри, он присоединился к Skylight примерно на полгода раньше меня. Его выбор тоже укрепил мою уверенность в компании.
Skylight была одной из первых компаний, с которыми я связался в процессе поиска, и позже она стала эталоном для сравнения с другими возможностями. На рынке были и другие хорошие компании, но ни одна не удовлетворяла моим требованиям так полно, как она.
Ведущий: Skylight тоже использует большие языковые модели, не противоречит ли это твоему принципу "не идти в ИИ-компании"?
Джейк Уортон: Я не считаю, что пошел на существенный компромисс.
Skylight раньше мало занималась open-source, но компания готова пробовать и принимает то, что я продолжаю поддерживать существующие open-source проекты, некоторые из которых используются в самом продукте.
Она действительно использует большие языковые модели, но весь продукт не построен вокруг ИИ. Функции ИИ опциональны, пользователь может вообще их не использовать; компания также не переделала весь продукт в чат-бота ради следования тренду.
Я считаю, что компания использует ИИ относительно сдержанно и в подходящих местах. Это не то же самое, что присоединиться к компании, где ИИ — ядро, и которая требует от всех инженеров полагаться на ИИ в разработке.
4 Когда не-технари пишут код с помощью ИИ, это прогресс или риск?
Ведущий: Coinbase сократила 14% сотрудников и заявила, что "не-технические команды теперь тоже могут выпускать production-код". Как ты относишься к такой трансформации?
Джейк Уортон: Я не против снижения порога входа в разработку ПО. Более прямое участие не-инженеров в создании продуктов само по себе может быть хорошей вещью.
Один отличный дизайнер, с которым я работал, за выходные выучил основы разработки под Android, а затем реализовал очень сложную анимацию и сразу отправил PR в репозиторий. Такой вклад, преодолевающий границы должностей, очень ценен. Если ИИ поможет большему количеству людей участвовать в разработке таким образом, я полностью поддерживаю.
Но есть ответственный и безответственный способы его использования. Помощь не-техническим специалистам выражать идеи, делать их вклад более конкретным — относительно ответственный способ; увольнять массу инженеров и потом всю эту работу перекладывать на большие языковые модели — совсем другое дело.
Ведущий: Некоторые компании хотят, чтобы меньшее количество инженеров вместе с ИИ выполняли прежний объем работы. Считаешь ли ты, что такая модель устойчива?
Джейк Уортон: Насколько я знаю, после моего ухода из Cash App они уволили 70% инженеров. Похоже, замысел компании был с одной стороны сделать организацию более стройной, а с другой — с помощью больших языковых моделей заставить одного инженера выполнять работу четверых, или даже позволить продуктовым специалистам через чат-систему напрямую генерировать PR, без полного понимания кода.
Я считаю, что такой подход может работать очень короткое время, но в долгосрочной перспективе приведет к падению качества ПО. Не могу сказать, столкнется ли бизнес сначала с проблемами качества или с резким ростом стоимости ИИ, но думаю, случится и то, и другое.
Сейчас индустрия больших языковых моделей во многом еще субсидируется капиталом. Типичный путь: сначала привлечь пользователей низкими ценами, захватить рынок, заставить компании зависеть, а затем перейти на взимание платы по реальной стоимости. Тогда стоимость ИИ для некоторых компаний может вырасти на порядок или даже два.
Если стоимость использования больших языковых моделей в итоге превысит зарплаты инженеров, которых они хотели заменить, экономическая целесообразность "замены инженеров на ИИ" тоже пропадет. Масштабные увольнения сейчас и построение возможностей на внешних моделях кажутся мне близорукостью.
Ведущий: Ты пробовал писать код с помощью ИИ-агентов?
Джейк Уортон: Никогда.
Я сознательно занял довольно крайнюю позицию, чтобы люди задумались о проблемах, стоящих за этими инструментами. В технологической отрасли раньше редко создавали профсоюзы, потому что зарплаты были высокие, условия хорошие, и инженеры не чувствовали необходимости бороться за дополнительные коллективные права. Но сейчас финансирование сокращается, происходят массовые увольнения, и многих сотрудников компания бросает без подготовки.
В США сотрудника могут уволить, даже не уведомив заранее — он просто обнаружит, что корпоративный аккаунт отключен, почта не обновляется. Чем больше инженер зависит от ИИ-систем, тем больше он отдает своих способностей и переговорной силы, превращаясь в более дешевую и легко заменяемую шестеренку.
Ведущий: Считаешь ли ты, что использование ИИ для программирования в любом случае ошибочно?
Джейк Уортон: Думаю, нужно смотреть на это с двух сторон: этическая проблема и ответственное использование.
Относительно ответственный способ — использовать ИИ как помощника, усиливающего уже имеющиеся у инженера способности, позволяя инженеру быстрее выражать и реализовывать то, что он уже понимает.
Безответственный способ — заставлять ИИ писать код, выходящий за пределы личных компетенций человека. Если без большой языковой модели ты не можешь выполнить эту работу, значит, ты не сможешь по-настоящему понять и поддерживать сгенерированный результат, и станешь сильно зависим от инструмента.
Предположим, цена модели вырастет в 20 раз, и компания сможет купить только около 4% от прежнего количества токенов, потеряешь ли ты внезапно способность выполнять свою ежедневную работу? Вернешься к прежнему способу разработки или будешь использовать ИИ только для скучных, повторяющихся задач? Это то, о чем инженерам нужно подумать заранее.
Я не думаю, что ИИ полностью исчезнет, но он должен быть лишь инструментом в ящике с инструментами, а не фундаментом всех инженерных способностей человека.
Ведущий: Если через полгода ИИ будет писать код лучше тебя, что ты будешь делать?
Джейк Уортон: Возможно, я буду работать во все более мелких компаниях, соглашаться на все более низкий доход, стараясь при этом сохранить свое удовольствие от работы.
Я уже не в начале карьеры и не стремлюсь срочно расти по должности. Прошлые профессиональные выборы дали мне некоторую подушку, позволяющую занимать такую жесткую позицию. Мне повезло, потому что у многих инженеров нет такого пространства для выбора.
Однако мне трудно поверить, что ИИ действительно лишит программистов работы. Большие языковые модели построены на коллективных достижениях, созданных людьми в прошлом, а индустрии ПО по-прежнему нужны люди, которые будут независимо создавать новое.
Я помню исследование, где обсуждалось, что когда модель постоянно дообучается на данных, сгенерированных ей же, может произойти "коллапс модели". Но я не смог точно вспомнить исследовательскую организацию и конкретные выводы. По крайней мере, на мой взгляд, если люди перестанут создавать новый качественный контент, модели будет трудно бесконечно улучшаться, используя лишь собственный вывод.
Вывод больших языковых моделей в конечном счете статистический, поэтому он всегда может содержать ошибки. Так же, как код, скопированный с Stack Overflow, может содержать баги, и даже некоторые ответы с большим количеством голосов имеют очень скрытые проблемы, код, сгенерированный ИИ, все равно нуждается в понимании, проверке и отладке.
Поэтому я не слишком беспокоюсь, что в будущем для программистов вообще не останется места. ИИ уже стал пугающе мощным, но это не значит, что он сможет стабильно и безошибочно выполнять всю работу по разработке ПО.
5 Золотой век Kotlin закончился?
Ведущий: Одним из больших преимуществ Kotlin изначально было сокращение шаблонного кода Java, а ИИ как раз хорошо генерирует такой код. Было ли основное преимущество Kotlin перед Java нивелировано ИИ?
Джейк Уортон: Архитектор языка Java Брайан Гоетц неоднократно подчеркивал: код читают примерно в десять раз чаще, чем пишут. Написание кода само по себе никогда не было самой сложной частью разработки ПО.
По-настоящему сложная работа происходит до и после написания кода. До — нужно продумать, как решить проблему, как разделить границы системы, как описать сложный бизнес кодом; после — нужно долгосрочно поддерживать. В ПО появляются баги, меняются требования, меняются общество, политика и сам бизнес, код должен постоянно адаптироваться.
Kotlin вначале действительно делал упор на "меньше кода": не нужно писать поля, геттеры и сеттеры вручную, можно использовать свойства, trailing lambda и более лаконичные DSL. Эти особенности легко демонстрировать, и они могут привлечь разработчиков к Kotlin, но это лишь входные ворота в язык, а не вся его ценность.
Выживет ли язык и его библиотеки в долгосрочной перспективе, зависит от того, помогает ли он эволюции кодовой базы. Для этого нужны хорошие инструменты, строгая система типов и полноценная экосистема. ИИ может помочь разработчикам с рутинными задачами, например, разом изменить тысячи мест вызова, но он не устранил ценность Kotlin в поддержке кода, типобезопасности и инструментарии.
Ведущий: Java уже добавила современные возможности, такие как Record, sealed классы, разрыв с Kotlin сокращается. Закончился ли золотой век Kotlin?
Джейк Уортон: Java не остановилась и не сдалась. Она сократила цикл релизов до шести месяцев, через экспериментальные механизмы позволяет сообществу заранее тестировать новые функции и провела много работы над низкоуровневой инфраструктурой, чтобы язык мог легче эволюционировать.
Фактически, некоторые новые возможности Java в последние годы могут быть спроектированы более полно, чем соответствующие решения в Kotlin. Kotlin должен быть совместим с существующим Java-кодом и компилироваться в байт-код, исполняемый JVM. Когда Kotlin только набирал популярность, ему приходилось быть совместимым со старыми версиями Java байт-кода, поэтому многие новые возможности могли строиться только поверх существующих механизмов.
У Java таких ограничений нет. Она может добавлять языковые возможности, такие как Record, одновременно вводя новый байт-код и даже меняя виртуальную машину, позволяя языку, байт-коду и рантайму эволюционировать вместе. Поэтому Java Record может иметь более единообразную низкоуровневую реализацию; Kotlin Data Class в основном генерирует обычные Java-классы, стандартные методы и немного метаданных.
Если Kotlin хочет оставаться конкурентоспособным в долгосрочной перспективе, он должен следить за новыми возможностями платформы Java и находить способы по-настоящему использовать эти низкоуровневые особенности.
Ведущий: Раз Java быстро догоняет, какие сегодня у Kotlin есть преимущества, которые трудно заменить?
Джейк Уортон: Один аспект, в котором Java вряд ли догонит Kotlin, — это обработка null-безопасности (nullable types).
Так называемая "ошибка на миллиард долларов" — не в том, что в программах не должно быть null-значений. ПО всегда должно уметь выражать состояние "какое-то значение отсутствует". Настоящая проблема в том, что Java не описывает это достаточно в системе типов, позволяя разработчику игнорировать возможность null-значения до момента выполнения, когда возникает NullPointerException.
Kotlin поднял null-безопасность на уровень системы типов. Если значение может отсутствовать, разработчик должен явно добавить знак вопроса к типу и явно обработать это при использовании. Такое, казалось бы, простое изменение практически устранило целый класс ошибок. Это до сих пор очень сильная сторона дизайна Kotlin.
Ведущий: Kotlin доминирует в разработке под Android, Swift — под iOS. Какие явные преимущества есть у Swift?
Джейк Уортон: Мне очень нравится Swift. По сравнению с Kotlin, у Swift при проектировании был относительно чистый лист. Ему тоже нужно было быть совместимым с Objective-C, но не нужно было, как Kotlin, всегда ограничиваться существующим представлением байт-кода JVM, поэтому дизайн языка и способ компиляции могли эволюционировать более согласованно.
Первое явное преимущество — обработка ошибок. Swift делает ошибки полноценной концепцией языка: функция, которая может выбросить ошибку, явно помечается, и вызывающая сторона должна обработать эту возможность. Это немного похоже на то, как Kotlin заставляет разработчиков обрабатывать nullable-значения.
Kotlin же построен на механизме исключений JVM. Java различает checked и unchecked исключения, а Kotlin решил рассматривать все исключения как unchecked. В результате при вызове функции ты не можешь четко увидеть из типа и сигнатуры функции, какими способами она может завершиться неудачей. Это закладывает "мины" в кодовой базе.
Другое преимущество — представление в памяти. Swift ориентирован на нативный код и может предоставлять действительно компактные структуры данных, лучше используя кэш процессора. Kotlin в основном построен на объектной модели JVM, многие данные в виде классов и полей разбросаны по heap-памяти, требуя частого разыменования указателей. В сценариях, где важна низкоуровневая производительность и layout памяти, у Swift преимущество.
Ведущий: А наоборот, в чем Kotlin явно превосходит Swift?
Джейк Уортон: Если сравнивать только дизайн языков, я даже считаю, что Swift лучше спроектированный язык. Kotlin трудно найти много языковых особенностей, по которым он бы полностью превосходил Swift.
Большее преимущество Kotlin — вне языка: его экосистема библиотек, open-source сообщество, инструменты разработки от IntelliJ IDEA и система сборки более зрелые. Особенно при рефакторинге крупных кодовых баз опыт работы с Kotlin намного лучше.
Как бы прекрасно ни был спроектирован язык, без IDE, библиотек, статического анализа и production-инструментов его сложно широко внедрить. Kotlin и Swift — отличные языки, но эта целостная экосистема вокруг Kotlin значительно повышает реальный опыт разработки. Это тоже важная причина, по которой я до сих пор выбираю Kotlin.
Ведущий: Если сравнивать моделирование ошибок и неудач в разных языках, какой тебе нравится больше всего?
Джейк Уортон: Мне нравится Rust. Многие решения в Rust очень соответствуют моему образу мышления: владение ресурсами и отношения заимствования должны быть в системе типов; ответственность за закрытие файлового дескриптора тоже должна быть четко выражена.
Такое признание пришло после многих лет страданий в разработке. Пройдя через утечки памяти, утечки файловых дескрипторов, NullPointerException и внезапные непредвиденные исключения в функциях, естественно задумываешься, есть ли лучший способ решения. Rust напрямую включает в язык и систему типов многие проблемы, которыми раньше легко было пренебречь.
Кривая обучения Rust действительно крутая, нужно преодолеть порог, чтобы постепенно сформировать интуицию. Я сам не достиг высокого уровня мастерства. Возможно, это не самый простой в использовании язык, но в описании владения, ответственности за ресурсы и моделей неудач, я считаю, Rust делает это лучше всего.
Ведущий: При написании программ для микроконтроллеров и embedded систем какой язык ты бы использовал?
Джейк Уортон: Если это мой личный pet-проект, сейчас я бы выбрал Rust. Технологический стек для продуктов компании нужно выбирать с учетом команды и бизнеса, это не то же самое, что личные экспериментальные проекты.
Embedded-экосистема Rust интересна. Многие библиотеки мапят аппаратные возможности на модель асинхронного программирования Rust. Например, можно напрямую ожидать событие нажатия кнопки, не прописывая логику опроса или настраивая сложные механизмы прерываний и пробуждения — такое поведение выражается одной строкой кода.
В моей повседневной работе не так много возможностей использовать Rust, а его философия дизайна очень привлекательна. Выбор Rust позволяет и сделать hardware-проект, и дает мне повод продолжать учиться и испытывать этот язык.
6 Когда ИИ может генерировать код на лету, нужны ли еще open-source библиотеки?
Ведущий: Когда ты пишешь на Kotlin, работает ли у тебя в голове маленький borrow checker от Rust?
Джейк Уортон: У меня есть список "проектов-мечт", если бы однажды мне еще платили зарплату, но не нужно было выполнять конкретную работу, и один из них — попробовать внедрить семантику владения в Kotlin.
На KotlinConf этого года уже были представлены очень ранние наработки исследователей, обсуждающие, как добавить семантику владения в Kotlin, это пока даже нельзя назвать формальным предложением по развитию языка (KEEP). Но когда понимаешь владение и время жизни в Rust, видишь, сколько проблем изначально мог бы обрабатывать язык.
Возьмем Java: если тебе передают List, обычно нужно сделать защитную копию, потому что ты не знаешь, не изменит ли его потом передающая сторона. Kotlin через разделение на read-only List и mutable List частично смягчает проблему, но еще не решает вопрос владения по-настоящему.
Если бы в языке была четкая семантика владения, то передав тебе List, другая сторона не могла бы его произвольно менять; или же позволяла бы тебе временно заимствовать, явно указывая, что исходный владелец сохраняет право на изменение. Это напрямую устранило бы целый класс ошибок, вызванных общим изменяемым состоянием.
Ведущий: Какого масштаба сегодня open-source экосистема Kotlin?
Джейк Уортон: Одно большое преимущество Kotlin — его способность взаимно использовать open-source экосистему Java. Поэтому сложно полностью разделить open-source экосистемы Java и Kotlin.
Когда мы переписывали Okio и OkHttp с Java на Kotlin, это вызвало недовольство некоторых Java-разработчиков. В процессе переписывания мы строго сохраняли бинарную совместимость. Даже если пользователь получил новую версию библиотеки через транзитивные зависимости, его старый код должен был продолжать компилироваться, линковаться и запускаться, просто в проекте появлялась зависимость от стандартной библиотеки Kotlin.
Open-source атмосфера Kotlin в первую очередь исходит от самого языка. Kotlin полностью open-source, процесс его эволюции прозрачен, разработчики могут видеть, как меняется каждая возможность. После прихода Kotlin в Android, в сообществе быстро появилось множество open-source библиотек; когда Kotlin Multiplatform стал более зрелым, возникло много проектов, удовлетворяющих базовые потребности кроссплатформенной разработки.
Это связано и со способом управления языком со стороны JetBrains, и с культурой, сложившейся в раннем сообществе. Самые ранние участники языка устанавливают неявные нормы поведения. Если сообщество с самого начала привыкло открывать код, делиться инструментами, эта культура продолжается.
Open-source экосистема Kotlin, возможно, не самая большая по масштабу, но, несомненно, одна из крупных языковых экосистем.
Ведущий: Не ставит ли использование open-source зависимостей проект под чужой контроль? Ради безопасности, не стоит ли форкнуть код и прекратить обновления?
Джейк Уортон: У этого есть две явные стороны. Строительство на основе чужой работы экономит массу времени, но проект также связывается с направлением развития библиотеки. Если мейнтейнер принимает решение, с которым ты не согласен, пользователь может почувствовать себя преданным; если проект меняет лицензию, бизнес может внезапно обнаружить, что за то, что раньше использовалось бесплатно, теперь нужно платить.
Но коренная проблема в том, что многие неправильно понимают значение "использования open-source ПО". Приняв open-source библиотеку, ты должен нести за нее определенную ответственность, рассматривая ее как часть своей собственной кодовой базы. В конечном итоге этот код вместе с твоим собственным доставляется пользователю, а пользователю все равно, какая часть от кого.
Компании часто требуют от инженеров получать дополнительное разрешение, чтобы в рабочее время вносить вклад в open-source проекты. Я считаю такой подход необоснованным. Если бы этой open-source библиотеки не было, инженеру пришлось бы самому писать и поддерживать аналогичный функционал; раз она стала частью продукта, то исправление проблем, внесение функций и отслеживание направления проекта по логике должны быть частью обычной работы.
Если бизнес постоянно участвует в поддержке, он может заранее видеть изменения в проекте, раньше корректировать курс при расхождении направлений и даже совместно с мейнтейнерами находить решения, устраивающие обе стороны, вместо того чтобы сваливать всю вину на open-source сообщество, когда обновление провалится.
Ведущий: Если большие языковые модели могут генерировать тот базовый, повторяющийся код, нужны ли разработчикам еще open-source библиотеки?
Джейк Уортон: Такое утверждение недооценивает долгосрочную ценность общих библиотек.
Смысл open-source библиотек не только в том, чтобы сгенерировать для тебя кусок работающего кода здесь и сейчас, а в том, чтобы многие проекты совместно получали пользу от постоянной поддержки. Возможно, кто-то сегодня исправит краевой баг, с которым ты пока не столкнешься; через два года твой бизнес изменится, и ты мог бы наткнуться на эту проблему, но поскольку ты используешь ту же open-source библиотеку, она уже исправлена.
Или, может, кто-то повысит производительность библиотеки на 15%, и все пользователи получат это улучшение. Open-source распространяет один вклад на множество разных кодовых баз, вместо того чтобы каждая компания отдельно поддерживала свою сгенерированную ИИ, изолированную реализацию.
Поэтому способность ИИ генерировать код не означает, что общие зависимости теряют ценность. Бизнес должен пользоваться эффективностью, которую дает open-source, и одновременно относиться к зависимостям как к своему собственному коду, уделяя им внимание и поддерживая их.
Ведущий: Open-source сложно напрямую вписать в финансовую отчетность, зачем тогда бизнесу вкладывать человеческие ресурсы?
Джейк Уортон: Превращение внутреннего проекта в действительно пригодный для использования open-source проект требует дополнительной работы. Нужно дополнять документацию и тесты, настраивать инфраструктуру публикации, постоянно обрабатывать внешние вклады и issues. Эти затраты не огромны, но и не нулевые.
Соответственно, компания может получить вклад от сообщества, баги и функции проекта будут улучшаться совместными усилиями большего числа людей. Open-source также демонстрирует инженерную культуру компании. Разработчики, видя открытый код, могут оценить технический уровень команды, что может помочь компании привлекать таланты. В прошлом такие компании, как Google и Meta, получали множество заявок на работу через свои open-source проекты.
Для самого инженера демонстрация результатов тоже приносит больше удовлетворения, чем устное описание. Не нужно рассказывать "я сделал крутой проект", можно просто дать ему адрес на GitHub, позволить использовать, модифицировать и даже создавать на его основе новое.
Однако компании не должны заставлять команды открывать код ради создания имиджа. Какие проекты подходят для открытия, инженеры обычно чувствуют естественным образом. Намеренная публикация проектов без реальной ценности, и сообщество почувствует неискренность.
Open-source тоже несет бремя: мейнтейнеры сталкиваются с недружелюбными issues, запросами, отклоняющимися от направления проекта, языковыми барьерами и массой low-quality PR, сгенерированных ИИ. Поэтому open-source подходит не всем инженерам и не должен быть обязательным требованием.
7 Будущее Kotlin
Ведущий: Создатель Kotlin Андрей Бреслав ушел из JetBrains в 2020 году. Может ли язык продолжать эволюционировать без основателя?
Джейк Уортон: Успешный язык должен уметь существовать без основателя. Человек, вложивший десять лет в успех проекта, конечно, имеет право уйти и попробовать что-то другое.
Kotlin успешно пережил эту передачу, и процесс практически не стал кризисом. Это как раз доказывает, что вокруг него уже построена относительно здоровая организационная структура.
Сейчас большинство успешных крупных языков программирования больше не определяются одним "доброжелательным диктатором", а управляются общей организационной структурой и, в идеале, продвигаются совместно с сообществом. Только так можно уменьшить зависимость от одного человека и обеспечить долгосрочную стабильность языка.
Ведущий: Кто определяет развитие Kotlin в 2026 году?
Джейк Уортон: Идеальный ответ — трое: JetBrains, Google и сообщество разработчиков.
Одна из целей создания Kotlin Foundation — сделать так, чтобы язык больше не полностью принадлежал JetBrains, избежать ситуации, когда любая одна компания может единолично его контролировать. Google уже проходил через опыт принятия технологии, контролируемой другой компанией, с последующими длительными судебными разбирательствами, поэтому, официально принимая Kotlin, он не мог согласиться на полный контроль над языком со стороны другой компании.
Сообщество, хотя и не "входит" в фонд таким же прямым способом, по численности намного превосходит языковые команды JetBrains и Google. Если управленческие механизмы работают нормально, фонд и обе компании должны постоянно прислушиваться к мнению сообщества, а затем из множества отзывов выделять направления, способные продвинуть развитие языка.
Ссылка на оригинальное видео:https://www.youtube.com/watch?app=desktop&v=9WjPdgOK-68
Статья из WeChat Official Account "InfoQ" (ID: infoqchina), автор: Дун Мэй
