Стол был конечно огонь. На каждой презентации показывал в своё время этот ролик. Сегодня сделать такой стол технологически стало сильно проще. Но любой технологии, чтобы пробиться, нужно показать какие уникальные возможности она открывает. Сейчас весь свет затмевает повальный хайп ИИ, без понимания, что LLM -- это лишь составная часть технологических решений, а не панацея.
Когда то давным давно инвестировал время и деньги в продажи metasonic bpms вместе с партнёром. Был это 2013 -2014 год. Нотация s-bpm была тогда очень визионерской. Однако bpmn с поддержкой OMG стал стандартом индустрии со всеми его достоинствами и недостатками. Camunda — это классика opensource адаптации в крупных компаниях, а Pega рулила в коммерческих продажах. Иногда прекрасная технология оказывается съеденной.
Ирония в том, что сейчас наступила эпоха агентного AI. Параллельные процессы, обменивающиеся сообщениями снова актуальны. Метасоник опередил немного время. Мир развивается по спирали. Возможно, что и для семантики наступает эпоха возрождения в этом году. Так что всему своё время.
Очень круто, что вы двигаетесь в похожем направлении. Будет здорово продолжить общение. У меня есть отличие в подходе, так как я не использую классическое RDF хранилище. Иммутабельный каузальный граф событий у меня ближе к event sourcing парадигме. Но у вас очень любопытная архитектура, которая требует отдельного изучения. shacl тоже используете или планируете в этом проекте?
В рамках формата комментария отвечу кратко, так как планировал серию статей, а эта была для затравки. Написал, чтобы объяснить с точки зрения бизнес ценности, зачем я рассказываю про технологии.
В классике бэк и фронт про разное, упрощенно за бэком логика и данные, а за фронтом отображение, между ними апи. У меня же на каждой ноде граф событий. Каждое событие это RDF, связанный причиной. На базе связи событий реализую эпизодическую, семантическую, процедурную и перспективную память для агентов. Работать с графом можно через декларативный язык, например, datalog для материализации объектов. Граф получается темпоральный (иммутабельные события). Но всё в деталях кроется. Синк на merkle-деревьях через строгий валидатор на 25 аксиомах. В рамках комментария точно не смогу объяснить, чтобы стало всё понятно.
Вот в точку 👍 Я вижу будущее в развитии распределённых финансовых услуг. Карты, счета, кредиты могут быть в разных банках, но управлять ими можно будет из одного приложения. Архитектура не классическая back и front, а ноды с одинаковым арх. решением. На каждой ноде темпоральный казуальный граф. Синхронизация через поток событий, без rest api. Если очень упростить, то аналогия с тем как работает git. По своей природе похоже на блокчейн только со скоростью обычной БД так как у меня граф. Сервера банков тогда будут отвечать за строгую валидацию, авторизацию и целостность событий.
Собственно именно такой разработкой я сейчас занят.
А у меня была однажды такая подстава, что я был уверен, что по карте рассрочки одного банка внёс правильный платёж, а оказалось что должен 3 рубля из-за расчета по новой покупке! Но при этом информация ушла в кредитную историю. Я просто отказался от такой карты, чтобы в будущем не ошибаться даже на копейку. Это пример того что банковские продукты могут быть сложны даже для того кто в этой теме разбирается. Для человека надо делать всё как можно проще и прозрачнее. Банки должны будут решить проблему доверия, чтобы бы ими пользовались не только по необходимости.
С уровнями проще понять, если прочитать книгу Кинга. Я не ставил целью прям детально раскрыть его концепцию, так как для меня важнее именно пятый уровень описать было. Он эти уровни придумал с точки зрения анализа поведения клиентов банка. Сначала люди шли в отделение (Банк 1) так как не было другой альтернативы, потом появились банкоматы и онлайн сайты (Банк 2). С появлением смартфонов клиенты перестали воспринимать банки как место (Банк 3). Затем банки оказались встроены в жизнь и уже не важно какой банк у конкретного человека, финансовые услуги вышли за пределы банков. Например, сегодня есть в России мирпей, сбп, продажа кредитов через партнеров, рассрочки, банкинг в маркетплейсах и т.д. (Банк 4). Но это я так понял.
Есть еще уровни по Николетти, но в России о них еще меньше знают, чем об уровнях Кинга. Николетти связал уровни банкинга не с поведением клиентов, а с разными промышленными революциями, что может быть более логично. Сейчас как раз 5 промышленная революция.
Но главное, что да, банки должны повернуться лицом к клиентам, не на словах, а в действиях. Если технологии не будут требовать бесконечных костов, а банковский рынок будет конкурентный, то в будущем получится создать совершенно другой финансовый мир.
Согласен, что сейчас тарифы маркетплейсов и банков высокие, и даже сверх высокие, если речь о маркетплейсах. Во многом это связано не столько с монополией, а со сложностью технологий, которые приняты в больших организациях и доступны только крупным компаниям. Я сейчас разрабатываю решение на базе других новых технологий, которые должны всё изменить. У меня есть первые обнадёживающие результаты. И это действительно должно быть более интересно обсуждать, чем стиль изложения. Если это вызовет интерес будет у аудитории, то продолжу рассказывать уже о технических деталях на Хабре. Всё зависит от вас друзья читатели.
Кстати на счет маркетплейсов... На базе технологии, о которой я пишу, можно сделать распределённый маркетплейс с комиссией близкой к нулю. Но эту тему я детально еще не прорабатывал, если будет запрос, то будет решение.
ответ на З.Ы. P.S. Сорян, я учился в советской школе и меня учитель учила ставить длинное тире "—" и двоеточия. Автохоткей в помощь. В word где пишу текст — это получается автоматом и кавычки тоже заменяются. До эпохи ГИИ тоже ставил длинное тире и уже не первый раз сталкиваюсь, что писать грамотно могут только боты по мнению многих, а вот человек вроде как уже не достоин грамотного русского языка. Но это не так. Ложная дихотомия. Надо писать грамотно и стараться при этом просто, понятно. Чтобы отличаться от ГИИ надо писать со смыслом, а не с ошибками.
Человек, который просыпается с мыслью где моя зарплата, действительно первым делом открывает банковское приложение. Но согласитесь, что он открывает его не потому, что хочет, а потому что вынужден. И это ровно моя мысль. Что банк должен быть таким, чтобы тебе не приходилось его открывать в тревоге. Идеальный банк будет тот, который сам пушнул бы тебе в 6:02 утра, что зарплата пришла, 15% отложил на накопительный, на кредитку закинул минимальный платёж, остаток — 47 320. Хорошего тебе дня друг. Вот это банкинг 5.0. А за никто — принимаю, загнул как литературный приём. Спасибо, что читаете внимательнее, чем я пишу.
Всё верно. Сейчас так. Но я не пишу про то, что сейчас. Есть примеры в мире, где уже активно используют ГИИ для кодинга в реальных проектах. Но это не тема данной статьи.
У меня прогноз на следующие 5 лет, который я делаю на основе статей по текущим трендам. Прогноз вероятностен и может быть даже футуристичен, может не сбыться. Однако так выглядят тренды.
Забавно, что вы сразу записали меня в “кого угодно, только не разработчика”. А я начинал программировать ещё школьником на Паскале на древнем УКНЦ МС-511 (кто помнит эти чудо-машины советской эпохи — привет из прошлого!). Работал программистом с 2000 года, со второго курса, и набил шишек в реальных проектах почти за 10 лет практики. Я могу ручками вести разработку через VIM, настроить ci/cd, использую docker, понимаю в архитектуре и т.д.
Сейчас я продолжаю кодить, но больше для себя в свободное время — это дает свободу выбирать интересные задачи, а не только то, что приносит деньги.
В статье (которую, похоже, вы не дочитали) я как раз и пишу про ДОПОЛНЕНИЕ возможностей разработчика с помощью ГИИ, а не про замену людей. Это принципиально разные вещи.
Самолёт летает лучше любого человека и даже любой птицы, но мы же не говорим, что “самолёты заменят людей”. Мы говорим, что самолёты расширили наши возможности передвижения.
Так и с ГИИ в разработке — это инструмент, который берёт на себя часть рутины и помогает быстрее решать знакомые задачи. Дальше в перспективе 5 лет будет интереснее — это главная мысль. А творческое мышление, понимание бизнес-контекста, архитектурные решения — это всё остаётся за человеком.
Зачем спорить с тем, чего я не писал? Например, в этой дискуссии с первого поста начинается разговор о “замене разработчиков” и другими словами излагается то же самое, что я написал, хотя в статье речь о совершенно другом - о дополнении и новых возможностях? Или Agile-coach — это точно никак не программист и не читая сразу минус в карму, не читая?
Кстати, а вы сами пробовали использовать ГИИ в своей работе, использовали Cursor с подпиской или дополнения к IDE? Было бы интересно узнать ваш опыт, без предвзятости.
Откуда у вас такие данные, что генеративные модели “уперлись и вышли на плато”, особенно в контексте генерации кода?
Анализ статей с показателями показывают совсем другую картину.
Вот конкретные цифры по бенчмарку HumanEval (% успешно решенных задач кодирования): от ~30% до более 90% за три года. Это не экспонента? На других бенчмарках тренд аналогичный. Можно посмотреть на ежемесячные обновления бенчмарков на HuggingFace Open LLM Leaderboard или McKinsey Technology Trends Outlook. Пока выхода на плато авторитетные источники не выдают.
Стратегические бизнес-решения — да, их должен принимать тот, кто видит большую картину и несет ответственность. ИИ тут пока даже рядом не стоял.
Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.
Рутинные ежедневные решения — вот здесь ГИИ уже может помочь. Но даже тут, контекст решает всё.
ГИИ хорошо помогает в узкоспециализированных задачах, если ему дать правильный контекст. Например, я пробовал его сам использовать для генерации unit-тестов для своих проектов — это снимает рутину, но ревью написанных тестов всё равно делаю я сам и может с 5 раза я получу то, что хотел.
Любые аналогии условны, как и аналогия с мультиком.
Можно увидеть три формата отношения к ГИИ среди участников
“Вау-подход”: “А нука ГИИ, напиши весь проект!” - получают кучу галлюцинаций, неработающего кода и разочаровываются.
“Нет-подход”: “Это всё бесполезно, видел я уже всё это в другом месте”- не получают никаких преимуществ
“Умный подход”: ГИИ используется для конкретных задач под контролем человека/команды, с направленными промтами, отсеиванием глюков (именно этот подход описан в статье)
Думаю, ключевое отличие от “двоих из ларца” в том, что хороший ИИ не просто тупо исполняет, а предлагает варианты, которые могут натолкнуть на новые идеи. Как джуниор, который иногда выдает неожиданно полезные мысли.
Нам нужно оставаться “умнее” в контексте задачи, технической архитектуры и бизнес-требований. Но это не значит, что мы должны знать все детали реализации.
Время рассудит. Прогноз всегда вероятностен. Человек не оракул и будущее не видит. Любой ответ ГИИ тоже вероятностную природу имеет. Каждый должен относится критически и к прогнозу и к ответам ГИИ. Это нормально.
В ИТ компаниях какой-то дикий перекос. Вроде создаём инструменты, чтобы людям стало легче, а потом заставляем людей работать как эти инструменты — без остановки. Я своим всегда говорю: технологии должны подстраиваться под людей, а не люди под технологии.
Наш мозг не предназначен для постоянного высокоскоростного переключения между задачами, которого требует организация работы сегодня в компаниях. Поэтому цель не делать 100 задач параллельно, а держать общий фокус команды на одной задаче. ГИИ может в этом помочь, устранив потери на рутину и ожидания. Но надо использовать ГИИ с умом, а "не пытаться микроскопом забить гвозди".
Кал Ньюпорт в книге “Digital Minimalism” писал: “Технологии должны служить нашим глубинным ценностям, а не превращать нас в рабов эффективности. Когда мы оптимизируем только скорость и объем, мы жертвуем глубиной и качеством — как работы, так и жизни”.
Технология должна не просто ускорять процессы, а освобождать людей от рутины для более глубокой, осмысленной работы. Поэтому нужно создавать технологии, которые увеличивают человеческие возможности, а не заменяют людей или заставляют их работать как машины.
Вы как думаете, возможен ли такой подход в реальной корпоративной среде? Или всё же культура “быстрее, больше, лучше, стресс, ещё больше и лучше и ещё быстрее” перевесит человеческие потребности? Дело же не в ГИИ, а в нас, людях. У ИИ нет целей, желаний и эмоций, нет ничего человеческого.
Я наблюдал за изменениями частоты релизов за 10 лет в разных компаниях. Если раньше только обсуждали, что надо чаще релизиться, то последние два года частота выпусков стала расти как факт. Экспоненциальная закономерность - это гипотеза, но пока она подтверждает моё личное наблюдение. Почти всё что связано с информацией и накоплением знаний имеет экспоненциальный тренд. Например, экспоненциален рост числа патентов, производительность процессоров, стоимость хранения 1 бита информации и т.д.
Согласен, что на текущем этапе преимущество только для джунов и может быть мидлов. Однако кроме непосредственно программирования есть ещё в разработке аналитика, документация, автотесты, ci/cd и т.д. - у ребят, кто этим занимается в разы больше рутины, чем у программистов-синьоров.
Я сам сейчас занимаюсь разработкой в IDE Cursor и решаю прикладные задачи: создать кастомизированный опросник через телеграм, или дашборд по метрикам, удобно написать сервис для ретро и т.д. Таким образом делаю всё то, на что не хватило бы времени без ГИИ, но упрощает и улучшает мою работу. Мой личный опыт связан с разработкой непосредственно и вышел в ИТ-менеджмент я когда то давно из разработки.
И надо понимать, что инструменты развиваются. Что будет полезным из ГИИ синьорам через 2-3 года мы увидим. Прогноз всегда вероятностен и точно не линеен.
Вы правы, если посмотреть так, то многое встает на свои места. Мы действительно проходим знакомый путь: новый инструмент → хайп → завышенные ожидания → разочарование → продуктивное использование. Прямо по классической кривой Гартнера. С практической точки зрения, полностью поддерживаю ваш здравый подход.
Помню на одном митапе в 2010 году говорили, как облачные технологии должны были “уничтожить” профессию системного администратора в компаниях. А по факту просто изменили требуемые навыки.
Есть небольшое отличие от других ПО конечно, современные ГИИ-инструменты иногда выдают такое, что даже их создатели удивляются :-)
Наблюдаю, что частота растёт. Всё верно. Но закономерность роста частоты релизов подобно закону Мура экспоненциальная, не линейная. В начале этот рост экспоненты не так заметен. Я написал в статье, что в перспективе 5 лет движение будет стремительным, несмотря на то, что скорость на старте пока не так сильно ощущаем. Противоречий нет.
Стол был конечно огонь. На каждой презентации показывал в своё время этот ролик. Сегодня сделать такой стол технологически стало сильно проще. Но любой технологии, чтобы пробиться, нужно показать какие уникальные возможности она открывает. Сейчас весь свет затмевает повальный хайп ИИ, без понимания, что LLM -- это лишь составная часть технологических решений, а не панацея.
Когда то давным давно инвестировал время и деньги в продажи metasonic bpms вместе с партнёром. Был это 2013 -2014 год. Нотация s-bpm была тогда очень визионерской. Однако bpmn с поддержкой OMG стал стандартом индустрии со всеми его достоинствами и недостатками. Camunda — это классика opensource адаптации в крупных компаниях, а Pega рулила в коммерческих продажах. Иногда прекрасная технология оказывается съеденной.
Ирония в том, что сейчас наступила эпоха агентного AI. Параллельные процессы, обменивающиеся сообщениями снова актуальны. Метасоник опередил немного время. Мир развивается по спирали.
Возможно, что и для семантики наступает эпоха возрождения в этом году. Так что всему своё время.
Очень круто, что вы двигаетесь в похожем направлении. Будет здорово продолжить общение. У меня есть отличие в подходе, так как я не использую классическое RDF хранилище. Иммутабельный каузальный граф событий у меня ближе к event sourcing парадигме. Но у вас очень любопытная архитектура, которая требует отдельного изучения. shacl тоже используете или планируете в этом проекте?
Статьи, например, A logic-based calculus of events, Executable Ontologies: Synthesizing Event Semantics with Dataflow Architecture, local first.
В рамках формата комментария отвечу кратко, так как планировал серию статей, а эта была для затравки. Написал, чтобы объяснить с точки зрения бизнес ценности, зачем я рассказываю про технологии.
В классике бэк и фронт про разное, упрощенно за бэком логика и данные, а за фронтом отображение, между ними апи. У меня же на каждой ноде граф событий. Каждое событие это RDF, связанный причиной. На базе связи событий реализую эпизодическую, семантическую, процедурную и перспективную память для агентов. Работать с графом можно через декларативный язык, например, datalog для материализации объектов. Граф получается темпоральный (иммутабельные события). Но всё в деталях кроется. Синк на merkle-деревьях через строгий валидатор на 25 аксиомах. В рамках комментария точно не смогу объяснить, чтобы стало всё понятно.
Вот в точку 👍 Я вижу будущее в развитии распределённых финансовых услуг. Карты, счета, кредиты могут быть в разных банках, но управлять ими можно будет из одного приложения. Архитектура не классическая back и front, а ноды с одинаковым арх. решением. На каждой ноде темпоральный казуальный граф. Синхронизация через поток событий, без rest api. Если очень упростить, то аналогия с тем как работает git. По своей природе похоже на блокчейн только со скоростью обычной БД так как у меня граф. Сервера банков тогда будут отвечать за строгую валидацию, авторизацию и целостность событий.
Собственно именно такой разработкой я сейчас занят.
А у меня была однажды такая подстава, что я был уверен, что по карте рассрочки одного банка внёс правильный платёж, а оказалось что должен 3 рубля из-за расчета по новой покупке! Но при этом информация ушла в кредитную историю. Я просто отказался от такой карты, чтобы в будущем не ошибаться даже на копейку. Это пример того что банковские продукты могут быть сложны даже для того кто в этой теме разбирается. Для человека надо делать всё как можно проще и прозрачнее. Банки должны будут решить проблему доверия, чтобы бы ими пользовались не только по необходимости.
С уровнями проще понять, если прочитать книгу Кинга. Я не ставил целью прям детально раскрыть его концепцию, так как для меня важнее именно пятый уровень описать было. Он эти уровни придумал с точки зрения анализа поведения клиентов банка. Сначала люди шли в отделение (Банк 1) так как не было другой альтернативы, потом появились банкоматы и онлайн сайты (Банк 2). С появлением смартфонов клиенты перестали воспринимать банки как место (Банк 3). Затем банки оказались встроены в жизнь и уже не важно какой банк у конкретного человека, финансовые услуги вышли за пределы банков. Например, сегодня есть в России мирпей, сбп, продажа кредитов через партнеров, рассрочки, банкинг в маркетплейсах и т.д. (Банк 4). Но это я так понял.
Есть еще уровни по Николетти, но в России о них еще меньше знают, чем об уровнях Кинга. Николетти связал уровни банкинга не с поведением клиентов, а с разными промышленными революциями, что может быть более логично. Сейчас как раз 5 промышленная революция.
Но главное, что да, банки должны повернуться лицом к клиентам, не на словах, а в действиях. Если технологии не будут требовать бесконечных костов, а банковский рынок будет конкурентный, то в будущем получится создать совершенно другой финансовый мир.
Согласен, что сейчас тарифы маркетплейсов и банков высокие, и даже сверх высокие, если речь о маркетплейсах. Во многом это связано не столько с монополией, а со сложностью технологий, которые приняты в больших организациях и доступны только крупным компаниям. Я сейчас разрабатываю решение на базе других новых технологий, которые должны всё изменить. У меня есть первые обнадёживающие результаты. И это действительно должно быть более интересно обсуждать, чем стиль изложения. Если это вызовет интерес будет у аудитории, то продолжу рассказывать уже о технических деталях на Хабре. Всё зависит от вас друзья читатели.
Кстати на счет маркетплейсов... На базе технологии, о которой я пишу, можно сделать распределённый маркетплейс с комиссией близкой к нулю. Но эту тему я детально еще не прорабатывал, если будет запрос, то будет решение.
ответ на З.Ы.
P.S. Сорян, я учился в советской школе и меня учитель учила ставить длинное тире "—" и двоеточия. Автохоткей в помощь. В word где пишу текст — это получается автоматом и кавычки тоже заменяются. До эпохи ГИИ тоже ставил длинное тире и уже не первый раз сталкиваюсь, что писать грамотно могут только боты по мнению многих, а вот человек вроде как уже не достоин грамотного русского языка. Но это не так. Ложная дихотомия. Надо писать грамотно и стараться при этом просто, понятно. Чтобы отличаться от ГИИ надо писать со смыслом, а не с ошибками.
Человек, который просыпается с мыслью где моя зарплата, действительно первым делом открывает банковское приложение. Но согласитесь, что он открывает его не потому, что хочет, а потому что вынужден. И это ровно моя мысль. Что банк должен быть таким, чтобы тебе не приходилось его открывать в тревоге. Идеальный банк будет тот, который сам пушнул бы тебе в 6:02 утра, что зарплата пришла, 15% отложил на накопительный, на кредитку закинул минимальный платёж, остаток — 47 320. Хорошего тебе дня друг. Вот это банкинг 5.0. А за никто — принимаю, загнул как литературный приём. Спасибо, что читаете внимательнее, чем я пишу.
Всё верно. Сейчас так. Но я не пишу про то, что сейчас. Есть примеры в мире, где уже активно используют ГИИ для кодинга в реальных проектах. Но это не тема данной статьи.
У меня прогноз на следующие 5 лет, который я делаю на основе статей по текущим трендам. Прогноз вероятностен и может быть даже футуристичен, может не сбыться. Однако так выглядят тренды.
Забавно, что вы сразу записали меня в “кого угодно, только не разработчика”. А я начинал программировать ещё школьником на Паскале на древнем УКНЦ МС-511 (кто помнит эти чудо-машины советской эпохи — привет из прошлого!). Работал программистом с 2000 года, со второго курса, и набил шишек в реальных проектах почти за 10 лет практики. Я могу ручками вести разработку через VIM, настроить ci/cd, использую docker, понимаю в архитектуре и т.д.
Сейчас я продолжаю кодить, но больше для себя в свободное время — это дает свободу выбирать интересные задачи, а не только то, что приносит деньги.
В статье (которую, похоже, вы не дочитали) я как раз и пишу про ДОПОЛНЕНИЕ возможностей разработчика с помощью ГИИ, а не про замену людей. Это принципиально разные вещи.
Самолёт летает лучше любого человека и даже любой птицы, но мы же не говорим, что “самолёты заменят людей”. Мы говорим, что самолёты расширили наши возможности передвижения.
Так и с ГИИ в разработке — это инструмент, который берёт на себя часть рутины и помогает быстрее решать знакомые задачи. Дальше в перспективе 5 лет будет интереснее — это главная мысль. А творческое мышление, понимание бизнес-контекста, архитектурные решения — это всё остаётся за человеком.
Зачем спорить с тем, чего я не писал? Например, в этой дискуссии с первого поста начинается разговор о “замене разработчиков” и другими словами излагается то же самое, что я написал, хотя в статье речь о совершенно другом - о дополнении и новых возможностях? Или Agile-coach — это точно никак не программист и не читая сразу минус в карму, не читая?
Кстати, а вы сами пробовали использовать ГИИ в своей работе, использовали Cursor с подпиской или дополнения к IDE? Было бы интересно узнать ваш опыт, без предвзятости.
Откуда у вас такие данные, что генеративные модели “уперлись и вышли на плато”, особенно в контексте генерации кода?
Анализ статей с показателями показывают совсем другую картину.
Вот конкретные цифры по бенчмарку HumanEval (% успешно решенных задач кодирования): от ~30% до более 90% за три года. Это не экспонента? На других бенчмарках тренд аналогичный.
Можно посмотреть на ежемесячные обновления бенчмарков на HuggingFace Open LLM Leaderboard или McKinsey Technology Trends Outlook. Пока выхода на плато авторитетные источники не выдают.
Стратегические бизнес-решения — да, их должен принимать тот, кто видит большую картину и несет ответственность. ИИ тут пока даже рядом не стоял.
Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.
Рутинные ежедневные решения — вот здесь ГИИ уже может помочь. Но даже тут, контекст решает всё.
ГИИ хорошо помогает в узкоспециализированных задачах, если ему дать правильный контекст. Например, я пробовал его сам использовать для генерации unit-тестов для своих проектов — это снимает рутину, но ревью написанных тестов всё равно делаю я сам и может с 5 раза я получу то, что хотел.
Любые аналогии условны, как и аналогия с мультиком.
Можно увидеть три формата отношения к ГИИ среди участников
“Вау-подход”: “А нука ГИИ, напиши весь проект!” - получают кучу галлюцинаций, неработающего кода и разочаровываются.
“Нет-подход”: “Это всё бесполезно, видел я уже всё это в другом месте”- не получают никаких преимуществ
“Умный подход”: ГИИ используется для конкретных задач под контролем человека/команды, с направленными промтами, отсеиванием глюков (именно этот подход описан в статье)
Думаю, ключевое отличие от “двоих из ларца” в том, что хороший ИИ не просто тупо исполняет, а предлагает варианты, которые могут натолкнуть на новые идеи. Как джуниор, который иногда выдает неожиданно полезные мысли.
Нам нужно оставаться “умнее” в контексте задачи, технической архитектуры и бизнес-требований. Но это не значит, что мы должны знать все детали реализации.
Время рассудит. Прогноз всегда вероятностен. Человек не оракул и будущее не видит. Любой ответ ГИИ тоже вероятностную природу имеет. Каждый должен относится критически и к прогнозу и к ответам ГИИ. Это нормально.
Любая экспонента упирается в сингулярность, за которой следует смена закономерностей.
В ИТ компаниях какой-то дикий перекос. Вроде создаём инструменты, чтобы людям стало легче, а потом заставляем людей работать как эти инструменты — без остановки. Я своим всегда говорю: технологии должны подстраиваться под людей, а не люди под технологии.
Наш мозг не предназначен для постоянного высокоскоростного переключения между задачами, которого требует организация работы сегодня в компаниях. Поэтому цель не делать 100 задач параллельно, а держать общий фокус команды на одной задаче. ГИИ может в этом помочь, устранив потери на рутину и ожидания. Но надо использовать ГИИ с умом, а "не пытаться микроскопом забить гвозди".
Кал Ньюпорт в книге “Digital Minimalism” писал: “Технологии должны служить нашим глубинным ценностям, а не превращать нас в рабов эффективности. Когда мы оптимизируем только скорость и объем, мы жертвуем глубиной и качеством — как работы, так и жизни”.
Технология должна не просто ускорять процессы, а освобождать людей от рутины для более глубокой, осмысленной работы. Поэтому нужно создавать технологии, которые увеличивают человеческие возможности, а не заменяют людей или заставляют их работать как машины.
Вы как думаете, возможен ли такой подход в реальной корпоративной среде? Или всё же культура “быстрее, больше, лучше, стресс, ещё больше и лучше и ещё быстрее” перевесит человеческие потребности? Дело же не в ГИИ, а в нас, людях. У ИИ нет целей, желаний и эмоций, нет ничего человеческого.
Я наблюдал за изменениями частоты релизов за 10 лет в разных компаниях. Если раньше только обсуждали, что надо чаще релизиться, то последние два года частота выпусков стала расти как факт. Экспоненциальная закономерность - это гипотеза, но пока она подтверждает моё личное наблюдение. Почти всё что связано с информацией и накоплением знаний имеет экспоненциальный тренд. Например, экспоненциален рост числа патентов, производительность процессоров, стоимость хранения 1 бита информации и т.д.
Согласен, что на текущем этапе преимущество только для джунов и может быть мидлов. Однако кроме непосредственно программирования есть ещё в разработке аналитика, документация, автотесты, ci/cd и т.д. - у ребят, кто этим занимается в разы больше рутины, чем у программистов-синьоров.
Я сам сейчас занимаюсь разработкой в IDE Cursor и решаю прикладные задачи: создать кастомизированный опросник через телеграм, или дашборд по метрикам, удобно написать сервис для ретро и т.д. Таким образом делаю всё то, на что не хватило бы времени без ГИИ, но упрощает и улучшает мою работу. Мой личный опыт связан с разработкой непосредственно и вышел в ИТ-менеджмент я когда то давно из разработки.
И надо понимать, что инструменты развиваются. Что будет полезным из ГИИ синьорам через 2-3 года мы увидим. Прогноз всегда вероятностен и точно не линеен.
Вы правы, если посмотреть так, то многое встает на свои места. Мы действительно проходим знакомый путь: новый инструмент → хайп → завышенные ожидания → разочарование → продуктивное использование. Прямо по классической кривой Гартнера. С практической точки зрения, полностью поддерживаю ваш здравый подход.
Помню на одном митапе в 2010 году говорили, как облачные технологии должны были “уничтожить” профессию системного администратора в компаниях. А по факту просто изменили требуемые навыки.
Есть небольшое отличие от других ПО конечно, современные ГИИ-инструменты иногда выдают такое, что даже их создатели удивляются :-)
Вы сами используете ГИИ-инструменты в работе?
Наблюдаю, что частота растёт. Всё верно. Но закономерность роста частоты релизов подобно закону Мура экспоненциальная, не линейная. В начале этот рост экспоненты не так заметен. Я написал в статье, что в перспективе 5 лет движение будет стремительным, несмотря на то, что скорость на старте пока не так сильно ощущаем. Противоречий нет.