Смогли бы. Но тут кривая входа совсем другая. Какой-нибудь бухгалтер в первый день на первой работе запускает Excel и пишет там =A1+B1 - и это уже полезно в рамках его простой и маленькой задачи. Через неделю условие. Потом vlookup. Потом сводную. И так очень-очень плавно выходит на вот эти чудеса - не покидая окна с зелёной рамкой и серой сеткой.
А программирование ему придётся именно осваивать. Дополнительно, с нуля, ломая привычки (точнее, создавая новые). Это отдельная работа.
Притом Hello, World! в отличие от его самого первого =A1+B1 никому особо не нужен, а до получения такого кода, который можно будет использовать в уже сложившейся инфраструктуре, ему учиться и учиться.
Собирает компания-разработчик, точнее, её продуктовая команда.
А требует рынок. Не отдельный гражданин, а некое их множество, готовое заплатить деньги за реализацию этого требования. Собственно, факт оплаты - лучшее доказательство, что требование таки имеется, пусть и не сформулировано.
Требования собираются всегда. Не всегда в лоб "а что вы хотите?" - просто потому, что это самый ненадёжный сбор требований.
Анализируются сценарии, анализируются конкретные задачи, которые пользователи решают в этих сценариях, анализируется костыльность этих решений. Если она высокая - то тут есть место для продукта.
Взять тот же айфон. К 2006-2007 году уже стало ясно, что люди активно используют телефоны для браузинга - статистика Opera Mini это ясно показывала. Но Opera Mini - объективно-то костыль тот ещё. В итоге когда Джобс вышел на сцену, у него за спиной красовались 3 слова: iPod, Phone и Internet.
Да нету ни у кого в голове UML диаграммы или сводной таблицы Excel вот так, сразу. Она в какой-то момент может возникнуть, но уже после того, как человек мысль в голове покрутит - на вербальном уровне.
И весь посыл в том, что это самое кручение необязательно изолировать в своей голове. Можно "подумать об коллегу". Можно - "об LLM".
Попробуйте пропроцессить этот чувственный опыт. Не просто на уровне "светофор зелёный - иду", а сделать какие-то многоступенчатые сложные выводы из наблюдений (принципиально нетекстовых даже). На каком-то этапе в слова или соскользьнёте, просто картинами, звуками, запахами думать не получится. Или в инфографику - но она как раз в слова хорошо конвертируется.
А что до предыдущего опыта - он никогда не бывает совсем нулевой. ТЗ формата "такое же, но красненькое" вы можете сформулировать и понять даже если до сих пор чувственно воспринимали такое только синим.
Тот, кто поставил подпись под актом ввода в эксплуатацию.
А уж как он будет балансировать свои риски - это второй вопрос. И он опять же решается уже сейчас: начальник, ставящий подпись, может вообще понятия не иметь, кто и как кодил и тестировал решение. Единственная точка контакта у него - приёмо-сдаточные испытания. И ничего, как-то справляются.
А в белковых образ желаемого в какой форме хранится? Фактор слов для нас тоже очень важен, особенно при создании нового, когда сослаться на предыдущий опыт не получится.
А это уже в какой-то мере есть. Я вот в Курсоре небольшой проект пилю, там есть БД. Соответственно, для каждого изменения БД мне нейросетка генерила SQL файл миграции.
Плюс у меня есть "большой" SQL файл, который должен создавать БД с нуля (на всякий случай) - и после каждого изменения структуры я делал отдельный запрос на обновление этого большого файла, чтобы он оставался актуальным.
Где-то после пятого такого изменения с отдельным запросом нейросетка мне сама предложила и файл миграции, и обновление файла для создания с нуля. Т.е. где-то вот этот паттерн сохранился - то ли в скрытом мастер-промте, то ли пробежавшись по папке с SQL-ями нейросеть отсекла, что обновления большого файла подозрительно совпадают с появлением атомарных миграций. ХЗ.
Дальше я догадался это дело явно в rules.md прописать)
нужно уже обладать экспертностью в двух сферах: о том, как разговаривать с машиной, и о сфере, для которой вы хотите получить нужный софт
Опять же, ничего нового) Сейчас ровно так же продакт менеджер, скажем, должен обладать экспертностью как в продукте (сфере, домене, как угодно), так и в менеджменте, или софт-скиллах - что в целом можно обобщить до "как разговаривать с людьми".
Я просто раз за разом вижу ошибку - люди пытаются воспринимать промты как ещё один язык программирования. В итоге идёт борьба за написание некоего самого правильного промта, который даст на выходе готовый результат.
По факту же это примеривание привычной парадигмы на чуждый инструмент. Гораздо эффективнее процесс строить примерно вот по такой схеме:
"У меня есть команда (с обязанностями и паттернами поведения, описанными в agents.md) - моя задача вложить в их кремниевые головы образ желаемого и критерии его готовности (definition of done). А для этого у меня есть возможность провести серию диалогов со всеми вместе или с каждым по отдельности, дать им документацию плюс возможность обмениваться уже своими наработками через общие файлы"
Это чисто софт-скилловая работа. Она не дублирует один-к-одному ту, что применяется к людям, доучиваться в любом случае надо. Но и работе с людьми мы, как индустрия, когда-то учились.
Как элементы они никуда не денутся, особенно с низких орбит - оттуда всё рано или поздно обратно попадает. Разумеется, не в готовом для переработки виде, но потомки через тыщи лет найдут их в коре или в океане)
Смогли бы. Но тут кривая входа совсем другая. Какой-нибудь бухгалтер в первый день на первой работе запускает Excel и пишет там =A1+B1 - и это уже полезно в рамках его простой и маленькой задачи. Через неделю условие. Потом vlookup. Потом сводную. И так очень-очень плавно выходит на вот эти чудеса - не покидая окна с зелёной рамкой и серой сеткой.
А программирование ему придётся именно осваивать. Дополнительно, с нуля, ломая привычки (точнее, создавая новые). Это отдельная работа.
Притом Hello, World! в отличие от его самого первого =A1+B1 никому особо не нужен, а до получения такого кода, который можно будет использовать в уже сложившейся инфраструктуре, ему учиться и учиться.
Собирает компания-разработчик, точнее, её продуктовая команда.
А требует рынок. Не отдельный гражданин, а некое их множество, готовое заплатить деньги за реализацию этого требования. Собственно, факт оплаты - лучшее доказательство, что требование таки имеется, пусть и не сформулировано.
А ребёнка берут на должность инженера после 11+5 лет опыта чтения учебников, вот парадокс!
Будем продолжать котятам дверцы приделывать?
Требования собираются всегда. Не всегда в лоб "а что вы хотите?" - просто потому, что это самый ненадёжный сбор требований.
Анализируются сценарии, анализируются конкретные задачи, которые пользователи решают в этих сценариях, анализируется костыльность этих решений. Если она высокая - то тут есть место для продукта.
Взять тот же айфон. К 2006-2007 году уже стало ясно, что люди активно используют телефоны для браузинга - статистика Opera Mini это ясно показывала. Но Opera Mini - объективно-то костыль тот ещё. В итоге когда Джобс вышел на сцену, у него за спиной красовались 3 слова: iPod, Phone и Internet.
подозреваю опечатку в "ЯП")
Это вопрос не кода, а процесса - тестирования, выкатки, откатов, бэкапов.
У меня максимально любительский проект, я пока эти миграции глазами могу вычитать)
Но спасибо за наводку в любом случае.
Да нету ни у кого в голове UML диаграммы или сводной таблицы Excel вот так, сразу. Она в какой-то момент может возникнуть, но уже после того, как человек мысль в голове покрутит - на вербальном уровне.
И весь посыл в том, что это самое кручение необязательно изолировать в своей голове. Можно "подумать об коллегу". Можно - "об LLM".
THIS
Попробуйте пропроцессить этот чувственный опыт. Не просто на уровне "светофор зелёный - иду", а сделать какие-то многоступенчатые сложные выводы из наблюдений (принципиально нетекстовых даже). На каком-то этапе в слова или соскользьнёте, просто картинами, звуками, запахами думать не получится. Или в инфографику - но она как раз в слова хорошо конвертируется.
А что до предыдущего опыта - он никогда не бывает совсем нулевой. ТЗ формата "такое же, но красненькое" вы можете сформулировать и понять даже если до сих пор чувственно воспринимали такое только синим.
С человеками это примерно так и работает. Только вот "пролистывание перед глазами" растягивается на 11+5+N лет, а у железки - сильно быстрее.
Я вот не уверен, что эти сбои - побочный эффект от борьбы с Телеграмом или чем-то ещё
Тот, кто поставил подпись под актом ввода в эксплуатацию.
А уж как он будет балансировать свои риски - это второй вопрос. И он опять же решается уже сейчас: начальник, ставящий подпись, может вообще понятия не иметь, кто и как кодил и тестировал решение. Единственная точка контакта у него - приёмо-сдаточные испытания. И ничего, как-то справляются.
А в белковых образ желаемого в какой форме хранится? Фактор слов для нас тоже очень важен, особенно при создании нового, когда сослаться на предыдущий опыт не получится.
Не совсем. Токен != символ, в английском целые слова могут быть отдельными токенами.
А это уже в какой-то мере есть. Я вот в Курсоре небольшой проект пилю, там есть БД. Соответственно, для каждого изменения БД мне нейросетка генерила SQL файл миграции.
Плюс у меня есть "большой" SQL файл, который должен создавать БД с нуля (на всякий случай) - и после каждого изменения структуры я делал отдельный запрос на обновление этого большого файла, чтобы он оставался актуальным.
Где-то после пятого такого изменения с отдельным запросом нейросетка мне сама предложила и файл миграции, и обновление файла для создания с нуля. Т.е. где-то вот этот паттерн сохранился - то ли в скрытом мастер-промте, то ли пробежавшись по папке с SQL-ями нейросеть отсекла, что обновления большого файла подозрительно совпадают с появлением атомарных миграций. ХЗ.
Дальше я догадался это дело явно в rules.md прописать)
Этот вопрос немножко ключевой - человеческая жизнь конечна. Да и просто жить в режиме откладывания - очень такое себе развлечение.
Опять же, чисто менеджерская задача. Начать "что-то большое" с запроса к нейросети же на декомпозицию)
Опять же, ничего нового) Сейчас ровно так же продакт менеджер, скажем, должен обладать экспертностью как в продукте (сфере, домене, как угодно), так и в менеджменте, или софт-скиллах - что в целом можно обобщить до "как разговаривать с людьми".
Я просто раз за разом вижу ошибку - люди пытаются воспринимать промты как ещё один язык программирования. В итоге идёт борьба за написание некоего самого правильного промта, который даст на выходе готовый результат.
По факту же это примеривание привычной парадигмы на чуждый инструмент. Гораздо эффективнее процесс строить примерно вот по такой схеме:
"У меня есть команда (с обязанностями и паттернами поведения, описанными в agents.md) - моя задача вложить в их кремниевые головы образ желаемого и критерии его готовности (definition of done). А для этого у меня есть возможность провести серию диалогов со всеми вместе или с каждым по отдельности, дать им документацию плюс возможность обмениваться уже своими наработками через общие файлы"
Это чисто софт-скилловая работа. Она не дублирует один-к-одному ту, что применяется к людям, доучиваться в любом случае надо. Но и работе с людьми мы, как индустрия, когда-то учились.
Как элементы они никуда не денутся, особенно с низких орбит - оттуда всё рано или поздно обратно попадает. Разумеется, не в готовом для переработки виде, но потомки через тыщи лет найдут их в коре или в океане)