Разработка — всё? Действительно ли нас всех заменят роботы
Привет! Меня зовут Александр Пряхин. Я руковожу разработкой в юните Авито Работа.
В среде IT практически все слышали о No Code, Low Code, нейросетях. И, разумеется, о том, что скоро инженеры станут не нужны.
Я и сам активно пользуюсь всем вышеперечисленным, но решил поразмышлять, а так ли бесперспективно будущее для инженеров из крови и плоти. Заодно поделюсь немного и тем, как инженер может применять No Code и нейросети в работе и жизни.
Возможности No Code
Уже сейчас многие вещи можно сделать вообще без привлечения инженеров разного ненулевого уровня квалификации, а только с помощью инструментов No Code. Кажется, что ещё немного, и всю работу за нас будут выполнять роботы.
No Code — это, как правило, браузерные программы, в которых можно собрать приложение без единой строчки кода. В них есть визуальный интерфейс с набором готовых блоков, их можно перетаскивать мышкой, располагать в нужном порядке, настраивать логику их взаимодействия.
С помощью No Code можно создавать практически любые системы: веб-приложения, интеграции с разными сервисами, мобильные приложения, базы данных. Например, с помощью Shopify собрать интернет-магазин, а в FlutterFlow — игру на смартфон.
Например, для себя я открыл инструмент Zapier. Это No Code решение для автоматизации различных интеграций. Его удобно применять и в работе, и в обычной жизни.
Zapier позволяет интегрировать больше 5000 сервисов с помощью простых скриптов — запов. С его помощью можно настроить загрузку данных из одной системы по триггерному событию, рассылку уведомлений, запуск приложений. Например, в считанные секунды собрать скрипт (он тут называется zap), который отправляет уведомление на почту, если, скажем, Илон Маск постит что-то у себя в Твиттере.
Как создается zap
Наряду с Zapier есть очень похожие аналоги — это IFTTT, Connect, Albato и многие другие. Всех их объединяет схожий принцип работы, который заключается в конструировании интеграции данных мышкой. Каждая такая система, интегрируясь у себя под капотом с источниками и потребителями данных, уже знает, каким пакетом информации сможет распоряжаться пользователь, и по каким событиям сможет передавать её дальше по цепочке.
Еще одним примером применения таких систем является автоматизация рутинных события. Скажем, если у Вас в команде есть регулярные события вроде спринт-ревью. К каждому ревью Вам нужно подготовить короткую презентацию по одинаковому шаблону. Конечно, можно изучить API того же Google Drive, получить ключ разработчика, развернуть код в Google App. С другой стороны, достаточно будет набросать простенький «зап»: подключить календарь Google, указать адрес шаблона в drive, скопировать его с нужным именем и прикрутить рассылку в нужный мессенджер. В самом запе прописать инструкцию: каждые две недели создавать шаблон презентации и отправлять на почту.
Основной экран создания zap-а
Логика предельно простая. Инициатором будет Google Календарь. Мы создаём некое событие раз в спринт, по которому в Google Drive будет выполняться действие. Дальше описываем, что конкретно будет происходить. В нашем случае — по старту события будет вызываться копирование файла. Остаётся лишь авторизоваться в Google Calendar и Google Drive. Простейший zap готов. Добавляем нужные действия по вкусу.
И хотя для опытного разработчика оба сценария по сложности вряд ли будут сильно отличаться, решение на базе No Code позволяет бизнес-пользователям подразделениям компании, далеким от разработки, получить продукт для тестирования гипотезы или сокращения затрат на рутину без больших вложений денег и времени. Чтобы использовать их, не нужно нанимать команду разработчиков или разбираться в программировании. Да и самим разработчикам может не хватать времени или будет лень собирать стенд и на нем писать что-то, когда можно получить рабочий скрипт в несколько кликов мышкой.
Предположим, несколько друзей запускают стартап на основе того, что нравится и интересно им сами. По-хорошему, им нужно сначала проверить, будет ли это востребовано, захотят ли люди покупать и использовать их приложение или сервис. А с помощью No Code они могут собрать концепт, протестировать его и решить, вкладываться ли в дальнейшую разработку.
В большом бизнесе No Code используют немного иначе. Например, покупают лицензию на Tilda, чтобы быстро собирать простые промо-лендинги. При этом не нужно привлекать программистов, время которых стоит дороже. Разумеется, как и у любого решения, у такого подхода есть свои риски, о которых поговорим дальше.
Для более сложных систем в корпорациях чаще используют Low Code решения. Такие системы ускоряют разработку, потому что помогают экономить время на рутине. Его можно тратить на более сложную логику. Для работы с Low Code нужны знания по программированию, но кода в них минимум.
Наравне с No Code есть Low Code системы. Они отличаются тем, что все же могут потребовать некий уровень программирования внутри себя. В своей практике я работал с такими Low Code решениеями как Talend и Informatice. Это решения для организации ETL (Extract, Transfrom and Load) процессов. Подобные системы используют, когда нужно собрать из разных источников, обработать и загрузить в новое хранилище большой объём данных. И они позволяют в графическом интерфейсе собрать схему такого ETL-процесса: из каких источников берутся данные, как они трансформируются и куда перемещаются. Сами процессы ETL чаще всего встречаются в больших системах DWH (Data Warehouse), которые являются фундаментом для аналитических витрин.
ETL на базе Informatica
Риски, которые несёт использование No Code
Конечно, волшебных решений не бывает. Пользователи No Code платформ платят за время и удобство тем, что берут на себя определенные риски.
Вероятность получить vendor lock. Когда мы создаем что-нибудь на Zapier или Tilda, мы размещаем свою интеллектуальную собственность и логику на внешнем ресурсе. Если платформа закрывается или становится недоступной по любой причине, решение блокируется вместе с ней. Вытащить его сложно, а часто невозможно. Даже если будет возможность программно достать содержимое сайта или скрипт, всё равно придётся писать код вокруг No Code. А это повторные инвестиции времени и денег в то, что уже было сделано и пропало.
Возможные утечки данных. Часто у маленьких компаний-разработчиков No Code нет возможности вкладывать много ресурсов в безопасность. Поэтому у них, да и не только, иногда случаются утечки данных или возникают проблемы с конфиденциальностью. Например, не так давно у того же Zapier было получено подозрение на утечку данных.
Можно использовать решения только от крупных компаний, которые действительно инвестируют деньги и время своей команды в инфобезопасность. Но и у них бывают проблемы, например из-за человеческого фактора, когда сотрудник такой компании может удалить данные клиентов или отрубить продакшн.
Ограниченные возможности. No Code решения создают для массового использования, поэтому на них сложно реализовать высоконагруженную систему или систему со сложной логикой. Бюджетный автомобиль не выдержит ралли. Точно так же приложение на базе No Code не сможет работать с десятками и сотнями тысяч запросов в секунду.
Технический долг. No Сode — быстрое решение, но с техническими проблемами. Недостаточно просто добавить фичу, нужно ещё и обеспечить стабильность. А проблемы могут возникнуть разные: например, падение скорости загрузки контента или внезапная рассылка системой уведомлений спама клиентам. Лёгкость добавления функциональности может привести к раздуванию и замедлению приложения ещё и из-за этого. Поэтому важно понимать, что при использовании No Code возникает технический долг, который рано или поздно придётся устранять.
Если обкатанный MVP на No Code даёт хороший результат, то нужно начинать эволюционно работать над более серьёзной реализацией продукта. Тогда к моменту, когда ваше приложение или сервис перестанет справляться с нагрузкой из-за ограничений платформы, у вас будет возможность быстро перенести трафик.
Прошлое и будущее No Code
На самом деле No Code появился не сейчас, первые решения в отдельных сферах использовали уже давно.
Например, уже в 1997 году мой папа, который проектирует системы безопасности на АЭС, при помощи Low Code системы симуляции Relap уже создавал модели реакторов. Такие модели тестировали в условиях аварии или отказа одного из компонентов. Конечно, с современными системами No Code/Low Code это сложно сравнить, но все же это одна из тех систем, которая стояла у истоков современных подходов.
А в 2005 году многие пользователи интернета создавали сайты в конструкторах UCoz и narod.yandex.ru. Кто помнит? Привет олдам! Сайт собирали из блоков, без какого-либо кода.
Сейчас популярность No Code растет, решений становится больше, люди активнее их используют в жизни и в работе. Думаю, причина в том, что есть необходимость быстро реагировать на все события. Многие команды работают через A/B-тесты, запуск MVP, проверку гипотез. Их нужно раскатывать быстро, чтобы успеть раньше конкурентов, показывая при этом экономическую эффективность.
No Code строится на выявлении и автоматизации паттернов. Условное стандартное мобильное приложение часто состоит из набора примерно одинаковых блоков, которые можно заранее запрограммировать и скрыть от пользователя. И чем дальше, тем больше таких паттернов будет появляться и автоматизироваться, поэтому будут появляться новые No Code решения.
Значит ли это, что программисты скоро станут не нужны? Нет. Сами No Code решения тоже кто-то должен разрабатывать, поддерживать и развивать. Возможно, менее востребованными станут начинающие инженеры или инженеры с низкой квалификацией. Бизнес-заказчику легче и дешевле выбрать No Code решение, чем обучать джуниоров.
Думаю, что это приведет к перетоку новичков между инженерными областями. Если в какой-то области задачи будут решать с помощью автоматизации, то порог входа начнет расти. Потому что зачем нанимать человека там, где можно не нанимать? Джунам надо будет дольше готовиться для старта, либо стремиться в области, где No Code еще не развит. Например, в Machine Learning (ML) — разработку и обучение нейросетей. Зайти в неё сложнее, но зато есть место для развития и роста. К ним как раз и перейдём.
Как работают нейросети (и наш мозг)
Как думаете, какую картинку из трёх нарисовал человек?
На самом деле, все три картинки сгенерировала по описанию нейросеть Midjourney. Запросы: иллюстрация к песне «Вдова и Горбун» группы «Король и Шут», «Картина маслом» и «BMW 2er stanced».
Нейросеть — это не программа, которая выполняет императивно заданные инструкции разработчика. Грубо говоря, она имитирует работу человеческого мозга. Когда мы взаимодействуем с чем-либо, органы чувств передают сигналы об этом в мозг. За это отвечают нейроны — нервные клетки, которые связываются друг с другом, создают сеть и формируют память. Они позволяют нам узнавать, что именно мы видим, слышим, читаем.
Похожим образом работает и классифицирующая нейросеть. Для очень быстрого понимания можно сказать, что в ней есть три слоя: входной — для получения данных, скрытый слой — для обработки или вычислений, и выходной — для выгрузки результата. Нейросеть определяет условия на основе входных данных и принимает решения или генерирует контент в зависимости от них.
Например, мы хотим предугадать покупателя, исходя из данных. Предположим, что у нас есть крутая система компьютерного зрения (кстати, уже ни разу не фантастика). Когда человек входит в магазин, система сканирует его, ищет в базах данных информацию: как его зовут, где он живет, какой у него средний чек в магазинах.
На внешний слой нейросети мы подаём данные от системы компьютерного зрения и других баз данных. Допустим, он вышел из BMW, у него нет обручального кольца и по карте лояльности магазина мы узнали среднее значения по чеку. На основе этих данных нейросеть должна принять решение: этот человек — наш потенциальный покупатель, или просто посмотрит и уйдёт?
На скрытом слое у всех известных нейросети параметров есть определённый вес. Чем он больше, тем параметр важнее в принятии конкретного решения.
Допустим, у нас есть два параметра с дробными значениями от 0 до 1.
Чем больше значение а, тем больше вероятность, что это покупатель, и наоборот. Например, если нейросеть получает результат а=0,7 и b=0,2, то скорее всего, это покупатель.
Откуда сеть всё это узнает? В принципе, написать самую простую нейросеть легко — достаточно знать программирование на уровне массивов и циклов. Но сеть, которую только что написали, ещё ничего не знает, поэтому ее нужно обучить.
Как обучают нейросети
Каждый раз, когда мы узнаем что-то новое, в мозгу строятся нейронные связи. Например, если впервые показать ребёнку кубик, он не будет знать, что это такое. Взрослый должен назвать предмет, дать его потрогать. Затем показать и назвать куб другого цвета, размера, из другого материала.
Когда ребёнок увидит третий кубик, он сможет сам сделать вывод, как называется этот предмет. Но если дать ему, например, тетраэдр, у которого тоже есть углы, грани и стороны, ребенок предположит, что и это может быть кубик.
Процесс обучения нейросети называется Machine Learning и требует почти такого же терпения, как обучение ребенка. Разработчик загружает в нейросеть набор похожих данных и ожидаемый результат их обработки. Грубо говоря, показывает много кубиков и объясняет нейросети их отличительные черты. Постепенно нейросети учатся узнавать разные объекты и различать их.
Чтобы нейросеть умела предугадывать покупателей, ей нужно правильно определить веса различных параметров. Для этого разработчик загружает массив данных и сообщает нейросети: вот это — профиль человека, мы ожидаем, что он будет покупателем.
Чтобы нейросеть научилась определять вес параметров верно, её нужно обучать на очень большом объеме данных. Их должно быть как минимум на порядок больше, чем нейронов на скрытом слое.
Собрать такой массив данных непросто, для этого компании используют разные способы. Например, в Google для этого используют капчи. Каждый раз, когда вы выбираете мотоциклы, горы или пешеходные переходы, вы участвуете в обучении нейросети.
В Авито нейросети обучаются на исторических данных о действиях пользователей. У нас есть несколько моделей, которые работают по разным поведенческим паттернам, анализируют интересы человека и формируют ленту рекомендованных объявлений.
Как только нейросеть прошла обучение, она знает распределение весов и может работать.
Как разработчики могут использовать нейросети
Нейросети можно применять не только для создания картинок. С разными задачами помогут разные типы нейросетей:
Классифицирующие — распознавание и классификация лиц, эмоций и объектов, а также выбор конкретного объекта из набора. Например, чтобы найти на фото кота среди других объектов.
Регрессионные — определение числовых значений, таких как возраст, стоимость имущества, прогнозирование курса акций в моменте.
Прогнозирующие — создание долгосрочных прогнозов на основе изменяющихся данных, например, цен, физических явлений и объёма потребления.
Кластеризационные — изучение и сортировка больших объемов данных без заранее известного числа классов. Эти сети помогут классифицирующим сетям научиться распознавать котов на фото.
Генеративные — знакомые многим ChatGPT, Midjourney и другие. Они призваны создавать контент по описанию.
Подробнее про типы нейросетей и их работу читайте в статье Нейронные сети для начинающих. Решение задачи классификации Ирисов Фишера →
ChatGPT умеет генерировать код по текстовому запросу. Я могу попросить её написать Telegram-бота на языке Go, который будет сравнивать курсы валют для двух пользователей.
Процесс запроса
Вот такой код нам сгенерировала ChatGPT
package main
import (
"fmt"
"log"
"strings"
"github.com/opencurrency/opencurrency"
"gopkg.in/telegram-bot-api.v4"
)
const (
botToken = "YOUR_BOT_TOKEN"
)
func main() {
bot, err := tgbotapi.NewBotAPI(botToken)
if err != nil {
log.Panic(err)
}
bot.Debug = true
log.Printf("Authorized on account %s", bot.Self.UserName)
u := tgbotapi.NewUpdate(0)
u.Timeout = 60
updates, err := bot.GetUpdatesChan(u)
for update := range updates {
if update.Message == nil {
continue
}
msg := update.Message
log.Printf("[%s] %s", msg.From.UserName, msg.Text)
if !strings.HasPrefix(msg.Text, "/convert") {
continue
}
parts := strings.Split(msg.Text, " ")
if len(parts) != 3 {
reply := tgbotapi.NewMessage(msg.Chat.ID, "Invalid format. Use /convert [amount] [from_currency] [to_currency]")
bot.Send(reply)
continue
}
amount := parts[1]
from := parts[2]
to := parts[3]
client := opencurrency.NewClient()
rate, err := client.Latest(from, to)
if err != nil {
reply := tgbotapi.NewMessage(msg.Chat.ID, fmt.Sprintf("Error getting exchange rate: %s", err))
bot.Send(reply)
continue
}
convertedAmount := rate * amount
reply := tgbotapi.NewMessage(msg.Chat.ID, fmt.Sprintf("%f %s is equal to %f %s", amount, from, convertedAmount, to))
bot.Send(reply)
}
}Нейросеть, конечно, пока не умеет оптимизировать код, да и выдает периодически не самые хорошие конструкции, но при этом вам не нужно с нуля писать весь каркас. ChatGPT найдет и подключит все зависимости и нужные API. Вам останется только подредактировать почти готового бота и скомпилировать код.
Конечно, нельзя попросить нейросеть написать целое многослойное приложение, но отдельные куски кода под отдельные задачи она уже может писать. Это как будто джуниор, который пишет за тебя код по конкретной инструкции. Причем делает это очень быстро. На мой взгляд, для разработчика это крутая возможность избавиться от рутины. Тем более, что уже есть встраиваемые решения, такие как Copilot от GitHub или Bard от Google.
Надеюсь, что текст ниже не будут читать наши HR, но ещё я могу отдать нейросети ссылку на свой профиль в соцсети и попросить написать сопроводительное письмо.
Пример сопроводительного письма
Заменят ли программистов No Code и нейросети
Подведу итог своим размышлениям.
Пора ли инженерам искать другую работу? Конечно же нет. Чтобы нейросети или No Code приносили пользу, нужно понимать, что ты хочешь получить на выходе. К тому же, результат требует проверки, доработки и уточнения. Для всего этого нужны инженеры, которые, например, будут понимать, что хорошего и плохого есть в коде, который написала нейросеть.
Нейросети пока могут создавать только отдельные кусочки больших программ и приложений. А их ещё нужно правильно собрать в единое целое.
То же самое касается No Code решений. Они позволяют быстро создавать простые программы, но не помогут построить высоконагруженную платформу. Построить и развить что-то уникальное с их помощью тоже вряд ли удастся.
Нужно понимать, что в настоящий момент нейросети и No Code — это еще одна часть инструментария инженера. С их помощью разработчики могут углубляться в более мощные абстракции, а не тратить время на рутину. Они едва ли заменят программистов, по крайней мере, в ближайшем будущем.
И наконец, кто-то же должен программировать и поддерживать сами No Code решения и нейросети. А для этого ещё долгое время будут нужны опытные инженеры.
Поэтому закончить эту статью я хотел бы, напомнив всем, что компьютер Великий Думатель, спустя 7,5 миллионов лет работы, сообщил всем ответ на Главный Вопрос о Жизни, Вселенной и Всяком Таком, так и не обозначив вопроса :)
Предыдущая статья: «Путь инженера: как эффективно пройти его от джуна до сеньора»
