Спасибо, Юрий, что ответили. На самом деле вообще с ИИ можно работать по-разному и код писать разными методами. И если настроить, что код обслуживает сам же ИИ, то вообще проблемы не вижу. Можно дать ИИ большую задачу сразу. Можно дать один элемент. Можно давать ТЗ без промпта. Можно сначала сделать промпт, потом ТЗ. Причём методология может быть опять же разной. Можно задать задачу, совместно декомпозировать, ещё и ещё. Ведь когда ИИ понимает контекст, он и думает соответственно. Я вообще думаю, что дальше всё больше приложения будут делать не программисты. И да, возможно, ИИ не использует инструменты оптимизации, но это когда она пишет большую задачу сразу. И это не значит, что я не понимаю что такое оптимизация и не корректирую под это задачу.

Тут все немного сложнее, ии решает поставленную задачу, но если он предоставлен сам себе, то он и решит ее самым простым способом. Что бы такого не было и создают системы из сабагентов, строят графы документации и работают с множеством задач оптимизации. Простой пример: допустим у вас есть фронт и бек. Если вы используете просто 2 папки с кодом, то агент должен выполнить десятки поисковых запросов, что бы просто понять, что это такое. И это не бесплатное удовольствие. Это довольно интересная тема и я напишу статью на Хабр на основании вашего запроса. Присоединяйтесь

Юрий, спасибо. Но я как раз описывала работу, в которой ИИ не предоставлен самому себе: задачи декомпозированы, структура и связи документированы, результат проверяется. Код хранится на GitHub, над продуктом работают как минимум три постоянных агента, созданных под него.

В вашем примере речь об оптимизации поиска и восстановления контекста агентом. А выше мы обсуждали безопасность, поддерживаемость и производительность самого продукта. Это разные задачи.

По каким признакам вы определяете, что код сможет обслуживать только ИИ? Вы пока не спросили, как организованы проект и работа над ним. Поэтому пример с двумя папками мало говорит о моей ситуации.

Статью с интересом прочитаю. Но пока вы обсуждаете предполагаемый способ работы, а не тот, который я использую. Забавно: вы не первый, кто, не задав вопросов, уже уверен, что знает ответы)))

Спасибо, Анна, за поддержку! Тараканы, конечно, имеются 😉 Хотя сейчас я, наверное, немного в роли Моськи)))

И я не считаю себя особенно крутой. Многие работают с ИИ активнее, под другим углом — просто делают продукт и не оглядываются. А я озираюсь: мне кажется, что зашла на чужую территорию знаний. Людей учат думать по-другому. Они изучают программирование. У них особая логика мышления.

Но теория — одно, а практика — другое. Я честно признаю, что в этом вопросе «недоспециалист». Однако когда спрашиваю, какого именно знания мне не хватает для решения конкретной задачи, ответа не оказывается.

Хотя, наверное, я жду специалиста, который найдёт ошибки, незаметные мне потому, что я знаю, как системой правильно пользоваться. Который ответит не только на вопрос «Работает ли задуманный процесс?», но и на вопрос «Что произойдёт, если пользователь, сеть или внешний сервис поведут себя иначе?». Человека с опытом работы с инцидентами.

И по сути Всеволод был прав, но не сумел объяснить, какая именно помощь мне нужна.

И ещё раз спасибо, Анна, что дали возможность мне это объяснить.

А вы знаете, по моим наблюдениям, для успешной реализации задуманного, не обязательно быть "особенно крутой" Достаточно быть просто "крутой"🫢вообще слово ДОСТАТОЧНО сильно неодоцененно.

Я, кстати, многие вещи делаю сначала на коленке и иду в тест сразу. Только реальность покажет, ху из ху. Далее, в процессе пестую. Иногда важно запретить себе выдерживать огромные паузы между задумкой и реализацией, в противном случае пауза может затянуться до "хотел, но так и не сделал"

Точно! Вы напомнили мне историю про конкуренцию. Двое идут по саванне и видят, что на них несётся лев. Оба бросаются бежать. Один спрашивает другого: «Ты правда думаешь, что мы сможем обогнать льва?» А тот отвечает: «Нет. Мне достаточно обогнать тебя»)))

Вот и всё о слове «достаточно» 😄 Главное, правильно понять с кем соревноваться)))

Ой, я перфекционист: могу холить и лелеять идею, а потом сама же её закопать 😎 Мне сложно продавать то, во что я не верю, а тем более продукт, в безопасности которого сомневаюсь. И не думаю, что это плохо.

Но вы правы: не всё сразу. Важно действовать. Ведь невозможно заранее знать, когда возникнет инцидент и возникнет ли вообще. Иначе есть другой риск - застрять в состоянии «сбитого лётчика»)))

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

Реальность — наше всё. Хотя и тут неоднозначно: даже нужное люди могут не увидеть и не услышать. Нейронка мне тут объясняла 😁, что человек часто сдаётся слишком рано: нужно продолжать делать и постоянно работать над формой подачи информации.

И на волне нашего разговора я спросила себя: а как бы я объяснила, почему для декомпозиции сложной бизнес-задачи стоит пригласить именно меня, экономиста с большим опытом, а не другого аналитика?

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

И это сложно вербализировать, не то что всунуть куда-то в резюме. Между прочим, у большинства из нас там написаны одинаковые слова — и правда ни хрена не понятно, кто за ними стоит.

Ну вы описали процесс. А результат данного процесса какой? Что на выходе то?

С архитектурой согласна — поэтому и строила продукт поэтапно, ответственно документировала структуру, уровни и их связи, нагрузку планировала заранее. Но где именно пределы, покажет только пилот. А по каким признакам вы отличаете архитектуру, готовую к росту, от будущего «бабушкиного чулана»? Какие конкретные риски вы видите, кроме «там темно и страшно»?

Спасибо. Я тоже уже думаю, что ничего не мешает. Теперь нужно лишь поменять бизнес-модель, чтобы не спотыкаться о программистов.

А что вы имеете в виду под «рынок может мешать»? Продукт может оказаться не нужен заказчикам или рынок не готов принять продукт, созданный с помощью ИИ? Но ведь программисты тоже используют ИИ при разработке. Что именно, по-вашему, рынок должен принять или отвергнуть: сам продукт,  способ его создания или статус создателя?

сам продукт, нужен ли

Поняла. Разговор у нас немного о другом, но отвечу: у меня был заказчик, я исследовала рынок и саму проблему, изучила первичные и вторичные выгоды, конкурентов и другие способы решения задачи, оценила ёмкость рынка. На этой основе сформулировала УТП. А насколько хорошо продукт решает заявленную задачу на практике — как раз и хочу проверить в пилоте.

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

ChatGPT и поиск для меня — инструменты, как и для многих разработчиков. Найденное решение нужно понять, проверить и только потом применять. За работу продукта и свои решения отвечаю я. В коде указано моё имя как владельца продукта — я не прячусь за ИИ.

Моя шутка про «Окей, Google!» не означала, что при сбое я передам ему ответственность. Почему вы считаете, что я не смогу сама разобраться со сбоем в продукте, который сама создала?

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

Всеволод, я как раз не исхожу из того, что ИИ всё сделает безупречно. В моём продукте 15 уровней: только три из них генеративные, остальные работают по заданным правилам. Три уровня вспомогательные — их сбой не должен останавливать основной процесс. Ещё три предусмотрены для аварийных ситуаций. Один уровень пока не настроен, поскольку его работа зависит от условий, которые нужно согласовать с заказчиком.

Да, сбой возможен и в коде, и в операционной системе, и на аппаратной платформе. С этим я не спорю. Даже у крупных сервисов случаются ошибки: мне, например, выставляли счёт за неиспользованные услуги, а нужные письма до сих пор попадают в спам. Мы ещё даже пилот не провели. Почему от продукта, созданного с помощью ИИ, ждут гарантий, которых не дают продукты, написанные вручную?

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

Но мой MVP изначально строился вокруг персональных данных и безопасности. По устройству защиты продукт почти как цифровой рубль. Требования к российскому ПО выполнены. Нагрузка предусмотрена, а её реальные пределы покажет только пилот.

Чтобы собрать команду, нужны заказчик, результаты пилота и деньги на эту команду. Я провела несколько презентаций потенциальным заказчикам, поняла их боли, изучила конкурентов и знаю своё УТП.

Но дальше возникает странная ситуация: руководитель поручает своему программисту связаться со мной, а тот перестаёт брать трубку — просто «умирает». Мне ведь не нужен их программист в моём продукте: всё работает в отдельном облаке на выделенной виртуальной машине. Мне нужно согласовать условия пилота. Но без его участия решение, похоже, не проходит. Вот и вопрос в пространство: что может пугать программистов?)))

А вы пробовали спросить программиста не «что вас пугает?», а конкретно: какие технические риски он видит в продукте и что именно, по его мнению, мешает запуску пилота? И момент ! Если сотрудник руководителя которому я так понимаю он доверяет не выходит на связь, я бы позвонил и спросил а в чем причина? Возможно 🤔 есть обратная связь между ними но до Вас ее не довели.

Возможно, дело вообще не в страхе программиста. Работающий MVP и продукт, который безопасно выпускать на реальных персональных данных, — всё-таки разные уровни ответственности.

Если он может назвать конкретные проблемы — их можно проверить и устранить. Если конкретики нет, тогда уже интереснее вопрос, что на самом деле тормозит пилот. Есть ли еще варианты с помощью которых можно запустить пилот не ожидая именно этого программиста?

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

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

Можно, конечно, снова выйти на руководителя и «принудить к любви», но я вот пытаюсь разобраться со страхами. И своими, возможно, тоже))

О, вот это я люблю 😁 Особенно когда человек смотрит не только наружу — «что с ними не так», — но и внутрь себя: а что происходит со мной, где мои страхи, ожидания, ограничения.

Я как раз много работаю с такими историями у предпринимателей и руководителей. И часто самое интересное начинается именно в точке, где вроде бы есть продукт, логика, аргументы — а движение почему-то останавливается.

Причём иногда причина вообще не там, где её первоначально ищешь. Такое интересно разбирать 😇

Да ладно, доктор, со мной это тоже нечасто бывает))) Но чем больше область того, что знаешь, тем длиннее граница с тем, о чём даже не подозреваешь.

О этот наш мозг ))) все получится 💪 сам нахожу очень много комнат, о существовании которых не подозревал. О за доктора спасибо за жизнь может на интерна наработал)))

Сравнение с цифровым рублём, конечно, было гиперболой, но лишь отчасти: безопасность влияла на устройство продукта с самого начала. Я проектировала процесс так, чтобы минимизировать сбор и обработку персональных данных и обеспечить необходимые и достаточные меры защиты.

Поэтому исходно я посчитала шифрование Яндекс Облака достаточным для выбранной схемы. Если этого недостаточно, это предмет обсуждения с профессионалом и основание для доработки продукта. Конкретный недостаток может потребовать устранения до запуска, но сам по себе не доказывает, что продукт невозможно довести до безопасного использования.

Мне важно понять конкретно: какой риск остаётся, какие данные ему подвержены и какая дополнительная мера его закрывает. Такой предметный разбор мне действительно был бы полезен — именно применительно к моему продукту.

Спасибо за конкретные критерии. По читаемости и поддерживаемости: у меня описаны архитектура, этапы обработки, структура проекта, расположение компонентов и версии. Разрабатывала по шагам, проверяла поведение продукта, исправляла выявленные баги и техдолг.

По оптимальности: работала и над расходом токенов с учётом цены продукта, и над временем ответа. По масштабируемости: она предусмотрена в архитектуре, но реальные пределы нагрузки и требования к интеграции станут понятнее по итогам пилота.

Мне очень хочется показать весь код стороннему специалисту. Единственный эксперт, которому я доверяю, сказал, что и так уверен: у меня всё в порядке. Приятно, конечно, но это не ревью кода. А передавать разработку другому человеку без оформленных условий я не готова: пометка об авторстве в коде сама по себе её не защитит.

Главный вопрос остаётся: какой конкретный риск препятствует выпуску в прод? Я вижу недостатки и в продуктах, написанных программистами, но это не мешает выпускать их и зарабатывать на них. А при слове «вайбкодинг» многие закатывают глаза. Давайте разберём конкретные риски.

Риск такой - что Вы будете делать, если что-то пойдет не так? Снова вайбкодить? Вы уверены, что такой подход решит проблему?

А можно подумать, программист при инциденте ни разу не спрашивает ChatGPT: «Тут такая хрень, что делать?» ))) Я поступлю так же: разберусь, проверю решение и только потом применю. Если задача окажется за пределами моей компетенции — привлеку специалиста.

Но я сама собирала этот конструктор. Знаю, за что отвечает каждый элемент и как он должен работать. По-хорошему, инцидент должен попасть в дашборд технической диагностики, встроенный в продукт: сбой не придётся искать вслепую. Ну а если он туда не попал — «Окей, Google!» тоже никто не отменял.)))

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

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

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

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

Теперь о терапевте. Автоматизируя, например, создание медицинских карт, вы можете присваивать симптомам из клинических рекомендаций коды болезней. И вот программа автоматически присваивает код из справочника болезней и задаёт шаблон заполнения медкарты. Всё автоматизировано. Я прихожу на приём, врач смотрит на меня: кашель и насморк. Он вводит эти слова и вот вы уже своей программой поставили мне диагноз. А врач не знает куда нажать, чтобы изменить настройки. И вот мы с вами равны.

И, в итоге, мы всё столкнёмся с проблемами. Ну так проблемы – источник для дохода.

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

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

А значит, что если ИИ словит галюцинацию и допустит критическую ошибку в коде, которую Вы не сможете заметить не имея экспертизы в этой сфере рано или поздно приведёт к взлому вашей системы через уязвимость нулевого дня)

Повторюсь - ИИ это инструмент)

Как программист не станет с помощью ИИ врачом, так и врач не станет программистом с помощью того же ИИ) но почувствовать себя таковым конечно можно)

И если бы ИИ решал эти проблемы, то в бигтехе давно бы никого не осталось, кроме топ менеджмента) но там почему то работают разработчики с 6-7 значными зарплатами, наверное не спроста)

Круто вы загнули — до программистов-самородков, которые каждый раз изобретают уникальный код))) Но цифровой продукт обычно тоже собирается из уже отработанных решений. Мне пришлось самостоятельно придумать один инженерный слой, чтобы отказаться от зависимости от стороннего продукта с открытым кодом: при определённых условиях его использования могли возникнуть дополнительные лицензионные обязательства.

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

Вы не спросили, как я организовала работу над проектом, чтобы не терять контекст, и как проверяла ответы ИИ на ошибки и галлюцинации. Сразу поставили диагноз продукту, которого не видели. Я допускаю, что могу чего-то не знать или не учитывать. Почему вы не допускаете этого со своей стороны?

Умение работать с генеративными инструментами — отдельный навык. Профессия программиста сама по себе его не гарантирует, а отсутствие этой профессии его не исключает. Я не отрицаю ценность программиста. Но из этого не следует, что человек другой профессии с помощью ИИ не способен создать достойный продукт. Его качество нужно проверять, а не определять по статусу создателя.

Я этого не допускаю потому что уже больше года ежедневно работаю с ИИ он давно стал ежедневным инструментом) Я как раз могу оценить результат работы этого самого ИИ основываясь на опыте который мной получен ещё до появления ИИ и на профильные знаниях полученных из литературы, семинаров и так далее. А ещё я знаю как бы Вы хорошо не ставили задачу ИИ он галюцинирует, теряет контекст и забивает на правила описанные в проекте (мемы про "Да Вы действительно были правы, я ошибся / придумал" родились не на пустом месте)

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

Это же настолько очевидно, что я даже не знаю какие Вам ещё приводить примеры) чтобы проверить правильность чьей то работы, нужно самому обладать экспертизой в этой сфере)

Поэтому смысла Вам что то доказывать нет, время покажет.

Код не должен быть уникальным. Он должен быть хорошо продуманным. Как сказал Константин, ИИ думать не умеет, он только генерирует контент, качество которого оставляет желать лучшего и об этом все сейчас говорят.

Господи, Константин, как же вы уже более года работаете с ИИ, но по-прежнему складываете разные вещи в один мешок? Ограничения модели, чужие способы работы, ролики о взломах и качество моего продукта — не одно и то же.

Я не отрицала, что ИИ ошибается, теряет контекст и нарушает инструкции. Я спрашивала, какие конкретные проблемы нужно проверить в моём продукте. Вместо этого мы обсуждаем, почему человек без профессии программиста якобы не может справиться.

Разговор по существу так и не начался: ни код, ни организацию работы, ни результаты проверок мы не разбирали. Получилось «бабушка надвое сказала»: может работать, а может сломаться. С этим никто и не спорил.

Согласна: код должен быть продуманным. Но почему вы в своих рассуждениях предполагаете, что продумывать решение я поручила исключительно ИИ? Задачу, логику процесса, ограничения и критерии проверки задавала я. По сути, вы допускаете, что раз я не программист, то мыслить — в принципе не моё?!)))

«Об этом все говорят» — не критерий качества конкретного продукта. Давайте обсуждать, как проверить продуманность решения. Пока вы оцениваете его по инструменту создания, даже не выяснив, как им пользовались.

Дочь тоже рассказывала, как у них на работе не пользуются ИИ, потому что он галлюцинирует. У них дорогая корпоративная подписка с большим лимитом на глубокие исследования, а они не пользуются! И я стала выяснять, почему у меня не галлюцинирует. Ну, почти)))

Почему я своему должна доказывать, что правда это видела, и прикладывать фото, иначе он вымарает это из текста? Почему мы до тошноты перепроверяем источник, когда он не нашёл, а я точно читала? Оказалось, вопрос в привычном мне методе организации работы. Поэтому я доверяю ИИ — с проверками, уточнениями и правом усомниться в ответе.

Но все же лучше знают(((

Я же сказал время покажет все слабые стороны Вашего проекта созданного без экспертизы) не имею желания общаться с человеком, который без ИИ даже мысли свои выразить не может)

Всего хорошего)

Забавно😂 А теперь вы на что ориентировались? На длинные тире или на разбивку на абзацы - мысли?😂