📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Как изменилась жизнь разработчиков с приходом ИИ

Лёша Корепанов13:40

Transcription

Есть популярное мнение, что искусственный интеллект - это пузырь, и его польза сильно переоценена. Я не совсем с этим согласен, поэтому решил рассказать, как конкретно поменялась моя работа, работа разработчика с появлением искусственного интеллекта.

Привет, с вами Лиш Крипанов. Я разрабатываю софт около 25 лет, последние 3 года. Плотно использую и инструменты. Сейчас пишу в основном на Typeesриpt. Участвую в разработке платформы для управления базами данных в облаке. Погнали по порядку.

5 лет назад работа разработчика состоялась из того, что одной рукой мы гуглили, а другой писали код. Сейчас вместо Google я иду в чат GPT. Простой пример. Пару дней назад мне нужно было сделать черепик без комита. Я не помню команду. Раньше я пошёл в Google, он дал бы мне несколько ссылок. Мне пришлось бы кликнуть на ссылку, открыть страницу. Сейчас я иду в чат GPT и просто копирую готовый ответ.

Или вот Continuous Integration выдал ошибку. По-хорошему надо покопаться в логах, разобраться. Часто эта ошибка уникальная, Гуглом не найдёшь. А если скопировать кусок логов в чат GPT, если повезёт, он скажет, как исправить. Но в худшем случае он подскажет несколько вариантов, как это дебажить.

Или ещё пример. Я постоянно путаюсь в закладках браузера. У нас много рабочих ресурсов и у RIL я на изус не помню. Понятно, что в браузерах есть поиск по закладкам, но мне было лене искать, как это настроить. Я просто попросил в чат DPT написать экстеншн с иконкой на панели. Тыкаешь в иконку, вываливается список всех закладок. Сразу можно найти, что надо. Это заняло минут пять. Скопировать файлы, сохранить на диск, запушить на GitHub. Иконку я тоже отдельным запросом сгенерировал. Получилось не идеально, но сойдёт. И раньше бы я за такую утилитку не взялся. Час работы рай 30 секунд экономии в день, оно того не стоит. А сейчас за 5 минут можно набросать всё, что угодно. И с философской точки зрения программирования - это про автоматизацию повторяющихся скучных вещей. И я рад, что EИ позволяет делать эту автоматизацию быстрее.

Следующий пункт - это написание тестов. Все нормальные разработчики всегда писали тесты, потому что жизнь без тестов тяжёлая. Лично для меня написание тестов всегда занималось столько же мыслительной энергией, сколько сам код. Что изменилось с искусственным интеллектом? Пару лет назад чат GPT начал писать тесты не хуже нас. Правда, сначала ему нужно было указать фреймворк, показать пример теста. Это называется oneшотot промптинг. А зато сейчас агенты сами находят примеры и пишут тесты так же, как и остальные тесты, уже написанные в проекте. Не всегда идеально, конечно, иногда пишут слишком много лишнего, иногда не покрывают нужные кейсы, но всегда это можно использовать как первую итерацию. Любой код, сгенерированный EИ, нужно прочитать внимательно и вдумчиво. Желательно два раза, а потом удалить половину, особенно это касается тестов. Тем не менее, они очень сильно облегчают работу. Мыслительную энергию, которую я раньше тратил на тесты, больше тратить не надо. Ну, по крайней мере, не в том же количестве, как раньше.

Или вот ещё раньше всё было просто. Берёшь задачу из трекера, думаешь над архитектурой, пишешь код, тестируешь. Сейчас, буквально в последние полгода, появились относительно надёжные агенты для программистов. Ты берёшь задачу, думаешь над архитектурой, но печатаешь не код, а печатаешь агенту, как ты хочешь, чтобы выглядело это с точки зрения архитектуры. А иногда даже не с точки зрения архитектуры, а с точки зрения пользователя. И он сам догадывается про архитектуру. Печатаешь, запускаешь и идёшь пить чай минут на 5, 15, иногда на полчаса в зависимости от сложности. Через 15 минут он выдаёт код, который надо внимательно посмотреть, исправить, провести ещё несколько итераций. Но идея в том, что первую итерацию ты получаешь, а не пишешь руками. Это не избавляет от необходимости думать над архитектурой, но как минимум скорее разработку и даёт больше энергии подумать над чем-то важным, а не над тем, как назвать там переменную или функцию.

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

Ещё один простой пример. Все разработчики об этом знают, но я всё же скажу. Я вот, например, использую GitHub Piles Visual Studio Code. Когда печатаешь код, появляется вот дополнение. Он догадывается, что ты хочешь написать. Это была самая первая фичат. Сейчас их, естественно, гораздо больше. И раньше приходилось печатать весь код руками. А в дополнении было, но относительно простое. Сейчас в очень большом проценте случаев он просто догадывается, какой код дальше надо дописать. И даже если он напишет неправильно, легче изменить это, чем писать с нуля. В общем, это сокращает количество нажатия на кнопки. Хотя скорость печати никогда не была тормозящим фактором, обычно скорость мышления тормозит, но тем не менее жизнь это тоже облегчает.

О'кей. Раз уж начали говорить о мелких вещах, описание комитов. Как было раньше, сделал изменения, нужно закомитить в гит, сидишь, придумываешь комментарий. Мы все знаем, почему хорошие комментарии важны. Потому что потом сам будешь читать и разбираться. Это не критично каждый день, но когда через год нужно поднять историю и найти, где что-то определённое было сделано, вот тогда поймёшь, зачем нужны правильные описания. Поэтому программисты обычно думают, что поменяли, и стараются аккуратно это описать. А теперь GitHubile сам пишет, что поменялось. Обычно пишет внятно и коротко. Правда, когда комит не сфокусирован на одном изменении, а каждый комит должен быть сфокусирован, он может расписать всё это очень подробно и длинно. И это, конечно, не означает, что нужно просто нажать пуш. Твоя задача - прочитать и аккуратно исправить, чтобы было понятно. Не всегда он следует формату, как вы делаете это в вашей организации, например. Ну, блин, насколько это облегчает жизнь. Не надо напрягать мозг, шерстить по файлам, вспоминать, где что поменял. Он раз и сам говорит. Остаётся только немножко подправить.

То же самое с пореквест. Когда создаёшь пиар, чтобы другие посмотрели твои изменения, надо аккуратно расписать, что поменялось. Именно надо это сделать с точки зрения кода, а не просто скопировать текст задачи из тикета. А ты уже не помнишь все эти мелочи. Где-то что-то поменял, где-то небольшой баг исправил, какую-то мелочь подправил. Но это тоже надо указать, чтобы человек, который смотрит на код, понимал, на что обращать внимание. Ну и теперь сари тоже можно сделать с помощью EИ. Например, в GitHub можно добавить CPй в качестве ревьюера, и он напишет такой вот summary. Ну и плюс к этому почти каждый день приходится ревьюить чужой код. Смотришь на изменения, не до конца понятно, зачем это, что это. Хорошо, когда есть подробное описание пиар, но, как показывает практика, такое бывает не всегда. Тогда ты можешь сам сделать div по полреквесту. Кл на GitHub добавляешь токаdди div, открываешь divфайл, копируешь и вставляешь чат GPT и спрашиваешь: "Давай подробно расскажи, что поменялось". Потом идёшь по коду уже вспоминаниям, смотришь: "Ага, это то, что чат GPT сказал, и думаешь, имеет ли это смысл, ты бы сам также написал или нет". В общем, в этом случае ревью код гораздо проще, потому что ты уже имеешь представление о том, что за изменения, что поменялось. Легче увязать то, что видишь, с тем, что человек пытался сделать. Это довольно сильно облегчает ревью. Ну и плюс к этому и сейчас сам может поревьють твой код и сказать, какие косяки видит. Процентов 20-30 случаев он даёт прямо хорошие подсказки. И это я про GitHubil. Иногда, конечно, глючит, но я думаю, что это временно разработчики всё докрутят. Я думаю, что в какой-то момент купайлот или там другие инструменты будут ревьть код не хуже живого человека. Те же самые глупые опечатки он может найти, там устаревший комментарий, который не соответствует логике кода. Линтер, например, с проверкой орфографии такое никогда не найдёт. Раньше это люди находили. Или там, например, на английском я какое-то слово постоянно пишу неправильно. Ну, астнт, например, я никогда с первого раза не могу определить там е или а в середине писать. И у меня такое было. написал везде неправильно отправил на пиар, ребята исправили. В общем, немножко стыдно. У других ребят тоже, допустим, английский не родной, а почему-то тебя исправляют. А сейчас Копалот посмотрел, нашёл ошибки, исправил на правильную букву. Меньше приходится краснеть перед ребятами за свои тройки по английскому языку в школе.

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

Дальше по поводу английского. Раньше пишешь что-то, даже письмо, например, какое-то, смотришь слово в словаре, думаешь: "А вообще, как оно используется?" Идёшь гуглишь, попадаешь на лингвистический сайт, где носители объясняют, когда это слово использовать. А теперь понятно, запомню. Исправляешь, используешь правильно. Сейчас не надо гуглить. Идёшь в чат GPT, исправь, чтобы было написано красиво. Он исправляет. Если исправлять слишком заумно, то я правлю опять, чтобы было проще. Умные слова, сложные выражения, они могут быть и правильные, но, допустим, я так не говорю, потому что не носитель. В общем, это тоже время сокращает.

Дальше по поводу архитектуры. Раньше ведь как было? Пишешь задачу, думаешь: "Блин, вот что-то мне не нравится архитектурное решение. Надо с кем-то посоветоваться". Раньше это был там архитектор или просто другой разработчик: "Ребята за чаем на обеде. Я вот так вот собираюсь делать". Нет, давай по-другому. Можешь лучше вот так вот. Ну, в общем, клёво было. Можно было посоветоваться по архитектуре. Сейчас я работаю из дома. Вот мой офис. Созваниваемся, конечно, но меньше, чем в офисе. И у этого есть плюсы и минусы. Я, например, обожаю работать из дома. И теперь не обязательно отвлекать других ребят от работы. Посоветоваться по архитектуре. Можно с чат GPT или там с каким-нибудь агентом. Если там какой-нибудь chт GPT понятия не имеет про твою кодовую базу, то вот агент может прошерстить по всем файлам и понять и посоветовать что-то конкретное. Простой пример. Месяц назад я прикручивал Obserсербиility платформу L Fuse. Там есть понятие сессии, а в нашем продукте такого понятия нету. И я спрашиваю у агентов GitHub Cilot: "Посмотри по коду, что у нас может читаться сессией." Он несколько вариантов подкинул. Я подумал, выбрал тот, у которого минусов меньше. В общем, это тоже удобно.

Следующий момент. Я много работаю с базами данных. Часто, чтобы с ними что-то сделать, нужны тестовые данные, иногда какие-то специфические. Раньше их приходилось придумывать из головы, писать из SQL, который их вставляет. Это там занимало, конечно, минут 10-15, особенно если данных было много. Ну, плюс подумать нужно было. А тут спрашиваешь чат GPT или, кстати, я разрабатываю как раз такую фичу в нашей платформе, специальный инструмент, который человеческом языке понимает запрос и делает SQL, создаёт таблицу, вставляет данные. В общем, это экономит те же самые 5 или 10 минут. Смотришь на данные, красивые, то, что надо. экономия времени и экономии мозговых ресурсов.

Давайте ещё про митинги. Раньше я старался ходить на все, куда приглашали, ведь там может быть что-то полезное. И да, было и полезное, и важное, но если были какие-то другие дела, то я прогуливал и тогда пропускал важное. Сейчас на работе у нас есть инструменты, которые делают транскрипции митингов. Очень неплохо рассказывают, кто и что говорил. И пробежаться глазами по такой транскрипции иногда бывает быстрее, чем 30 минут сидеть в наушниках. Я не говорю, что все должны читать транскрипции вместо посещения митингов, но если почему-то пропустил, то читаешь то, что пропустил. Это тоже делать жизнь разработчика немножко легче.

Далее, по поводу мессенджеров и переписки. У меня миллион каналов слаг. Не то чтобы все важные, но некоторые вещи надо знать, что происходит в других частях компании, например. Ну, часто просто нет физически времени читать все обсуждения. И Слак совсем недавно прикрутил инструмент, который пересказывает краткосодержимое того, что в канале Слака обсуждали. И если есть такое самр, я хотя бы примерно пойму, что происходит. Если что-то заинтересовало, можно подробнее почитать. С имейлами то же самое. Приходит рассылка, если не особо важно, можно саре посмотреть вместо каждого письма. Удобно.

Но самая офигенная штука в нашей компании - это внутри корпоративный EИ, который ищет по корпоративному Слак, Wiки, документации, в общем-то, много источников. Для чего я это использую? Например, у нас есть большой документ, который описывает, что делать, когда ты он call. Я давным-давно прочитал его от корки до корки. В этом случае делать то, в этом это. Это было года два назад. Естественно, я половину уже не помню. А онкол приходится быть раз в пару месяцев. Что я делаю сейчас? Предположим, я онкол, произошла какая-то ситуация, я не помню, что делать. Я иду в этот агент, спрашиваю, что делать в этом случае. Он прямо со ссылкой на документ говорит: "Делать то-то, то-то". Идёшь в документ, проверяешь, да, так и написано, и делаешь. И это не только про онкол. Я практически каждый день этим пользуюсь. Да, у нас все в компании пользуются. И насколько это наша жизнь улучшего, мне кажется, очень сильно.

Теперь про отчёты для менеджеров. Думаю, во многих компаниях так есть. У нас каждую неделю, например, нужно написать отчёт на пару абзацев, что ты сделал. Менеджер свойт это в свой отчёт. Это слайд высшему руководству, чтобы было представление, что компания сделала за неделю. Раньше нужно было поднимать все свои поуреквесты, красиво формулировать по-человечески, чтобы было понятно нормальным людям, которые работают в компании, а не только тебе. Формулируешь, описываешь, время занимает, мозг напрягать приходится. Сейчас ребята разработали утилитку, которая использует языковую модель. Она автоматически смотрит на твои пиары и составляет список. До языковых моделей такие утилитки тоже были, которые на GitHub за неделю поднимают. Ничего сложного. Зато с языковыми моделями это можно красиво переформулировать, описать, может даже посмотреть в ходе какие-то подробности. Это, в общем, тоже наша жизнь облегчает.

Ещё вспомню, есть суперудобная фича. Я не очень часто пользуюсь, но это просто бомба. Тебе нужно, допустим, найти, где обрабатываются банковские транзакции, где сумма ноль. Как это искать по коду? Никак. Zero будешь искать или transaction - это ключевые слова миллион раз выскочат. С агентами в последнее время можно в GetHub Cilet, например, просто словами описать то, что тебе надо, и это он сделает. Это называется семантический поиск. Поиск по смыслу. У меня такой был несколько раз. Например, один раз я собирался написать функцию, которая определённые вещи из URL вытаскивала, а потом решил поискать. Оказалось, что эта функция уже есть, покрыта тестами, ничего писать не надо. И раньше бы я сам написал, ребята, возможно, бы на пиар заметили, а может быть и нет. И был бы у нас в проекте повторяющийся код.

В общем, что я хочу сказать в этом видео наша работа сильно поменялась и поменяется ещё сильнее. Как поменяется, никто не знает, но у меня есть несколько мыслей. Возможно, я запишу про это отдельное видео. Поэтому подпишитесь на канал, если хотите про это послушать. И спасибо, что досмотрели видео до конца. С вами был Лёша Крепанов. Пока-пока.