Обновить
0
-4

IT специалист — на все руки мастер

Отправить сообщение

Спасибо, интересная статья.

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

Несколько лет назад AI уже можно было более-менее использовать как помощника, автозаполнение, написание небольших простых функций и т.п.

Сейчас - создание небольших "пет" проектов: то что раньше можно было пилить пару недель, сейчас вполне себе вайбкодиться за пару-тройку часов. При этом практически полностью не разбираясь в технологии. Так я сам недавно накидал себе приложение под андроид, хотя ничего подобного ранее не делал и оно работает, это все что мне надо. Я вижу как менеджеры создают небольшие проекты с UI-интерфейсом, которые так же решают их задачи. Просто вайбкодя, не зная и не понимая ничего в программировании.

А в будущем - разработка сложных проектов от начала и до конца по предоставленной спецификации, в том числе с уточнение требований у заказчика, доработкой, использование разнообразных инструментов, добавление новых фичей и т.п. Есть ли физический закон, который не позволяет такого?

У меня в команде мы сейчас придерживаемся подхода описанного в статье, т.к. это гарантирует результат. Но баланс уже начинается достаточно сильно смещаться в сторону AI, для небольших простых патчей, чего-то однотипного, ответа на вопросы, исследования как что-то устроено сейчас в коде и т.п.

Однозначно, что профессионал с молотком это гораздо круче, чем домохозяйка, но с другой стороны, если нам всего навсего надо повесить картину на гвозь, то почему бы и нет?

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

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

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

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

Прогресс не отвратим, новые инструменты надо принять и использовать, а еще лучше быть драйвером их внедрения, только в этом случае можно как-то контролировать процесс. Самое лучшее, что я вижу сейчас и что работает в нашей команде - это разговаривать и делиться на тему AI, кто что использует, как, какие подходы работают, что лучше/хуже, как выстроить процесс, что бы все было быстро и без снижения качества, запуск агентов в параллель, прикручивание доп. проверок к ревью/теста и т.п., к каким тулам можно дать доступ, к каким нет, выработка общего стиля и подхода, что приемлемо и что нет. Регулярные собрания на эту тему и тогда все оказываются примерно на одном уровне, а не так что кто-то продолжает писать все сам, а кто-то за 5 мин. с клодом бам-бам и в прод.

AI - это именно инструмент и то как он будет испльзоваться - целиком на совести исполнителя.

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

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

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

Я целенаправленно в течении нескольких месяцев сравнивал точность и качество ответов по-кодовой базе полученными самостоятельно и от клода. И если раньше, скажем год назад, ответы от AI нельзя было надежно использовать, то сейчас ситуация обратная - правильность ответов в районе 95% процентов по моей статистике.

Но остается риск деградации самой кодовой базы - это правда. Падение производительности, бесполезный или не эффективный код и т.п. Можно взглянуть на картинки в моей статье, вначале и в конце - они сгенерированы в рамках одной сессии и видно, как качество начинает постепенно деградировать.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Фулстек разработчик, Веб-разработчик
Ведущий