arrow

назад

ask

Вопрос

Я не программист. С ИИ сделала работающий продукт. «Красного» кода никогда не было, найденные баги и техдолг устранила. Что мешает выпустить его в прод?

repost

77

input message

напишите коммент


17 комментов

Что?

0

ответить

Проблема в таком подходе в том, что Вы снимаете с себя ответственность за поддержку своей программы и перекладываете ее на ChatGPT и OK Google. По-моему, это несерьезно. Так дела не делаются.

0

ответить

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

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

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

0

ответить

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

0

ответить

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

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

0

ответить

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

1

ответить

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

0

ответить

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

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

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

0

ответить

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

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

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

0

ответить

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

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

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

0

ответить

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

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

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

0

ответить

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

0

ответить

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

0

ответить

Покажите этот код профессиональному программисту и спросите его мнение, что он думает о нем. Важны следующие моменты: 1. Читаемость 2. Поддерживаемость 3. Оптимальность 4. Масштабируемость

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

1

ответить

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

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

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

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

0

ответить

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

0

ответить

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

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

0

ответить

еще контент автора

пост закреплён — пока закрепить можно только один пост

trash bin
перейти к нему не получится