Я говорил не про примеры промптов. Примеров тонны, и почти все голословные, потому в общей массе не особо полезные. Я говорил про proof-of-concept - было-стало, делали так (а, б, в), ввели это, стало так (А, Б, В). Конкретно. Такие-то достижения, такие-то ограничения. Такой инфы на самом деле мало, и она была бы куба ценней очередной сухой выжимки.
Может, и показал бы, да боюсь, что это будет очередной «рецепт пирожков моей бабушки, она готовит так», вроде этой статьи (да и то как-то бессвязно получалось, когда думал об этом). Я же не говорю, что тут что-то бесполезное. Очень интересно было бы посмотреть это все в деле. Я про то, что от подобных материалов хотелось бы больше конкретики на примерах, так сказать, а не сухой набор каких-то предписаний. Вообще с этим беда какая-то, много историй успешного успеха, а по фактам или это, или просто всякий шлак от ai коучей.
Да ладно. Как раз-таки аналоговые часы мне в 2023 chatgpt3.5 выдавал вполне рабочие. Это потому что их реализаций была целая тонна в сети до этого, как я подозреваю.
Термин и движение «вайбкодинг», по-видимому, принесли больше вреда, чем пользы, раз появляются такие статьи. Но хорошо, что в итоге приходит осознание. Из статьи не увидел никакой конкретики.
Качество: - Соблюдай единый стиль проекта и best practices выбранного стека. - Не дублируй код: предпочитай переиспользование и понятные абстракции. - Не оставляй заглушек/“TODO”, если это не оговорено отдельным пунктом. - Пиши тесты там, где это критично для поведения/контрактов. - Если не уверен — перечисли варианты, но не делай скрытых допущений.
В проектах с большой кодовой базой такие промпты превращаются в практически ничто без конкретных спецификаций.
4) Предложи минимальный набор диаграмм/ADR, которые стоит зафиксировать.
Это особенно порадовало. Стоит зафиксировать по решению кого?
Вот как выглядит рабочий день промпт-инженера в нашей команде. Утром — настройка окружения под конкретную задачу: какие MCP-серверы подключить, какие скиллы нужны агенту, какой контекст дать. Потом — декомпозиция фичи через speckit или подобный подход: разбить на атомарные задачи, выстроить зависимости, определить, что можно запустить параллельно. Дальше — запуск агентов. Не одного — пяти-семи, каждый со своей частью задачи. Мониторинг, валидация промежуточных результатов. Если агент застрял — разобраться почему, скорректировать промпт или контекст, перезапустить. Ну и сборка финального результата.
Это не копирайтинг. Это инженерия. Просто другая.
Внезапно! Это и есть суть инженерии изначально. После этого эти стенания души можно не читать. Да, это уменьшение энтропии исходных данных и вариантов на пути к конечной картине. А вы все апеллируете к чисто механической части «писать код», называя это инженерией. Сеньор - это не тот, кто пишет «хороший код». Так же, как и инженер по мостовым конструкциям - это не тот, кто хорошо крутит болты. Я вот чувствую даже облегчение, потому как не надо постоянно думать о каждой мелочи, и по сути интуитивно к этому и стремился. А вы все упиваетесь негативом, «ох, я двадцать лет пишу код, что же теперь»? А то же, что и инженер в других областях.
Мне привычно, когда программист — это человек, который пишет код.
У вас опять в голове перепутались понятия «кодер» и инженер программист. Даже ИИ понимает это лучше.
Абсолютно точно. Я сказал так. Инженер редуцирует пространство возможностей, он думает «как не сделать» прежде всего, отсекая все лишнее, пусть даже «интуитивно». А ИИ изначально расширяет. Причем инженер исходит из своего опыта, следствия которого проявлялись нередко во времени, а не здесь и сейчас. ИИ это фактически всегда «здесь». Парадокс в том, я бы сказал, что обычно инженерия - это создание условно «чертежа», который не равен продукту. В разработке ПО чертеж (код) - это почти или часто сам продукт. То есть планировщик является почти всегда и исполнителем. Автоматизация обычно идет снизу вверх, заменяя исполнительные роли. Но в инженерии ПО это выглядит так, как будто замещение идет сверху внизу по этой самой причине, хотя по сути это иллюзия. Отсюда и тревожность, а на деле эта область движется к классическому понятию инженерии. Тут, что удивительно, под ударом оказываются вовсе не джуны, а мидлы. Потому что джун учится (тому, чему надо), мидл исполняет (роль, замещаемая ИИ), сеньор планирует и ограничивает (мы берем тех, кто не просто сидел 20 лет на стуле и как бы может так себя называть, старший специалист, короче). Инженерия - это проецирование часто противоречивых и неполных факторов, требований и их ограничения часто во времени в конечный продукт. Этого у ИИ, думаю, еще долго не будет. Многие разработчики (как минимум часть моих знакомых) чувствуют даже облегчения, так как они меньше времени тратят на исполнительную рутину.
Да уж не знаю наверняка куда) Я лишь про что, реимплементация человеческой непредсказуемости вряд ли будет ценна именно для человека, и этот этап надо поскорее пройти, а не обсасывать его со всех сторон, как конечно же усиленно начнут всякие недоблогеры и недосми. Скорее тут я бы стремился к некому бесстрастному советнику-исполнителю, не лишенному определенной этики и целей, но так чтобы они точно не были как основополагающими в качестве личности.
Если это все действительно так и было, то это, я бы сказал, плохой milestone на пути создания ИИ. Вряд ли человеку нужен второй как бы человек, человек и сам себе достаточно недетерминирован, чтобы рядом существовал кто-то еще более. И если это является целью, то это очень посредственная цель. Мне лично хотя бы точно был бы не нужен такой ИИ. Может быть, это и необходимый этап, но, как по мне, от него надо скорее бежать дальше, не слушая очередных «пораженных» и «испуганных» великими талантами ИИ.
Когда клиент добавляет товар - мы сразу его резервируем. Товар остаётся заблокированным. Если клиент не оформляет заказ - товар возвращается на склад.
Это плохое решение. "Заабьюзить" сервис можно запросто. К примеру, я сделаю скрипт, который каждые 15 минут тупо добавляет товар обратно в корзину. У других практически нет шансов тогда купить товар. Если резервировать на этапе оформление заказа, то тут надо рассмотреть этот же вариант, к примеру, самое примитивное решение - при отказе или таймауте оплаты, позволять перейти к новому оформлению заказа не ранее, чем через 5 минут.
Сразу списать товар при отправке заказа, чтобы он не разблокировался
Это не понял, что значит. То есть, еще на заплатили, а товар уже списан? Тогда однозначно - нет.
Ввиду вышесказанного, я бы процесс сделал так: 1. Добавляются товары в корзину с обновлением доспупности для ранее добавленных и соответствующими предупреждениями. 2. Переход к оформлению заказа - тут происходит резервирование товаров на 15 мин (если доступны все еще, если нет, то предупреждать в соответствии). 3. Списание товаров только по факту оплаты, то есть по нажатию на кнопку "оплатить". Причем учесть процесс продолжения действия, если оплата и списание не выполняются атомарно и произошла ошибка. То есть чтобы не получилось так, что оплата произведена, а списание не произошло, и наоборот. Тут можно придумать много чего, к примеру, сохранять идентификатор сеанса оформления заказа и при повторной попытке проверять что было реально сделано. 4. Если опалата не была произведена по таймауту или заказ был отменен, добавить таймаут на новое оформление. Добавлять товары тем не менее можно.
Ну я пишу лет 8 в том числе и на питоне, и сходу тем не менее затруднился с ответом на {("a", [1, 2]): "value"} и print((x for x in range(3))). А за 55 == True is True надо сразу бить по рукам на месте. Наверное, я не знаю базу? Или просто в нормальных условиях такую дичь на код ревью не пропускают, и вообще такое в голову не приходит? Питон, скажем так, довольно специфичный язык, а автор, видимо, нанимался загадывать ребусы и выводить на чисту воду этих наглых "накрутчиков". Я вот смотрю больше на способность кандидата мыслить, коммуницировать, рассуждать и предлагать варианты, что куда важнее, чем знание 100+ подводных камней питона. И в качестве теста на написание кода идут самые обычные кейсы.
Парад продолжается. После фиаско с первой версией этого, хм, "компилятора", а так же после его разбора, автор еще 8 месяцев пушил добавление/удаление строки в readme с целью создать видимость работы. Почти незамеченной протухла и вторая версия, краткий разбор которой был тут. Но автор не стоит на месте, радуя нас своим прогрессом, его даже не смущают 13 минусов под предыдущей статьей. Взлетит ли третья версия? Сомнительно. Видно, что автор явно не дурак, но нарциссизм не лучший спутник на этом пути.
Пустой треп в большей части. Понятно, что это интервью, однако...
Сейчас самое волнительное — это рост автономности ИИ-систем. Всё чаще инструменты, тот же Deep Research, выдают ответ в том виде, в котором его можно сразу использовать.
Тут точно имелась в виду автономность?
здоровенный чатик
Звучит прикольно.
..., выходит вперед LongChain, известная библиотека, которая адаптируется к фреймворкам.
LangChain?
Вообще, сейчас происходит такой ползучий процесс переизобретения процесса разработки.
Ползучий процесс и переизобретение, да-да. Это называют "эволюцией" обычно.
какие джабы выполняют инженеры
Это что такое? Джабба Хатт?
Например, возьмем кейс с проблемными активами: вы звоните должнику, что-то не то сказали — вам сразу штраф 500 тысяч прилетает от ФССП
Конгениальный и актульный пример и практики использования ИИ - работа звонаря-выбивателя долгов. Ах, это же банк, тогда норм.
В последнее время, на мой взглад, складывается впечатние о какой-то эпидемии словесного поноса среди подобных спикеров. Может быть, я слишком придирчив.
Тогда я предложил коммерческому директору вместе использовать нейросеть для анализа ситуации.
Когда есть только молоток, вокруг все кажется гвоздями.
Это время, которое коммерческий директор потратил на то, чтобы обучить ИИ, дать ему полное представление о бизнесе.
"Обучение" тут - это двухдневная болтовня с чатом?
Сначала ИИ предложил уволить одного бухгалтера, но так как у компании несколько юрлиц и большой объем работы, эту рекомендацию отклонили. ... В переписке с ИИ появилась идея передать функции отдела кадров в бухгалтерию, нейросеть одобрила, и скоро в компании станет еще на одного сотрудника меньше.
Противоречие тут видится мне.
То, что часть сотрудников уволили, не значит, что у других стало в разы больше обязанностей и нагрузки, с которой они не справляются.
Из чего сие значит? Из ваших слов?
Еще одна рекомендация: убрать вакантные позиции с нулевым выхлопом. Это дало еще +200 тысяч в месяц или 2,4 млн в год.
Долго вкуривал этот тезис. Каким образом незанятые позиции сэкономили +200 тыс в месяц. Видимо, я понимаю термин "вакантная позиции" как-то иначе. Ответ ИИ - "Вакансия" (вакантная позиция) означает незанятое рабочее место в компании, на которое можно принять нового сотрудника.
Я даю свой ноутбук... Можно я завтра еще к тебе приду? Действительно, даже час глубокого погружения зачастую помогает найти рабочие варианты.
Ноутбук один на всю компанию? Глубокого погружения куда?
Мой прогноз такой: через год-полтора в динамичных небольших компаниях останутся сотрудники, которые используют нейронки.
Еще один "прогнозист". Занялись бы вы чем-то более полезным.
Чем отличается ИИ от сотрудника? ИИ не скажет вам «Я не знаю».
Вы правы. Почему-то большая часть статей о graphql обходят этот вопрос. Помимо оптимизации глубоко вложенных запросов, есть также проблема глубины как таковой, так как object типы могут ссылаться циклически друг на друга (если так задать схему), то тем самым можно запросто положить сервер. У себя решили это просто собрав все запрашиваемые клиентами пути путем логирования, а потом все, что не в списке, то отбрасываем. Complexity тут не особо помогает тоже, так как сложно понимать что и насколько оценивать. Глубоко вложенные структуры в рамках одного сервиса можно оптимизировать, отображая схему запроса на eager или lazy отношения в orm, ну или как кому удобнее. Проблема N+1 может быть решена с помощью data loader (в federation схеме к примеру), но опять же смотреть надо что и как запрашивается. Оффтоп, но механизм upload в некотором роде просто приставка сбоку, и не рекомендуется аполло. У себя сделали просто отдельный рест для загрузок файлов, а в сервис передаем айди загрузки.
Почему бы и нет. Не обязательно на гитхаб, хотя бы чтоб пару живых случаев.
Было бы очень неплохо, заранее благодарен.
Я говорил не про примеры промптов. Примеров тонны, и почти все голословные, потому в общей массе не особо полезные. Я говорил про proof-of-concept - было-стало, делали так (а, б, в), ввели это, стало так (А, Б, В). Конкретно. Такие-то достижения, такие-то ограничения. Такой инфы на самом деле мало, и она была бы куба ценней очередной сухой выжимки.
Может, и показал бы, да боюсь, что это будет очередной «рецепт пирожков моей бабушки, она готовит так», вроде этой статьи (да и то как-то бессвязно получалось, когда думал об этом). Я же не говорю, что тут что-то бесполезное. Очень интересно было бы посмотреть это все в деле. Я про то, что от подобных материалов хотелось бы больше конкретики на примерах, так сказать, а не сухой набор каких-то предписаний. Вообще с этим беда какая-то, много историй успешного успеха, а по фактам или это, или просто всякий шлак от ai коучей.
Да ладно. Как раз-таки аналоговые часы мне в 2023 chatgpt3.5 выдавал вполне рабочие. Это потому что их реализаций была целая тонна в сети до этого, как я подозреваю.
Термин и движение «вайбкодинг», по-видимому, принесли больше вреда, чем пользы, раз появляются такие статьи. Но хорошо, что в итоге приходит осознание. Из статьи не увидел никакой конкретики.
В проектах с большой кодовой базой такие промпты превращаются в практически ничто без конкретных спецификаций.
Это особенно порадовало. Стоит зафиксировать по решению кого?
И его в том числе?
Внезапно! Это и есть суть инженерии изначально. После этого эти стенания души можно не читать. Да, это уменьшение энтропии исходных данных и вариантов на пути к конечной картине. А вы все апеллируете к чисто механической части «писать код», называя это инженерией. Сеньор - это не тот, кто пишет «хороший код». Так же, как и инженер по мостовым конструкциям - это не тот, кто хорошо крутит болты. Я вот чувствую даже облегчение, потому как не надо постоянно думать о каждой мелочи, и по сути интуитивно к этому и стремился. А вы все упиваетесь негативом, «ох, я двадцать лет пишу код, что же теперь»? А то же, что и инженер в других областях.
У вас опять в голове перепутались понятия «кодер» и инженер программист. Даже ИИ понимает это лучше.
Абсолютно точно. Я сказал так. Инженер редуцирует пространство возможностей, он думает «как не сделать» прежде всего, отсекая все лишнее, пусть даже «интуитивно». А ИИ изначально расширяет. Причем инженер исходит из своего опыта, следствия которого проявлялись нередко во времени, а не здесь и сейчас. ИИ это фактически всегда «здесь». Парадокс в том, я бы сказал, что обычно инженерия - это создание условно «чертежа», который не равен продукту. В разработке ПО чертеж (код) - это почти или часто сам продукт. То есть планировщик является почти всегда и исполнителем. Автоматизация обычно идет снизу вверх, заменяя исполнительные роли. Но в инженерии ПО это выглядит так, как будто замещение идет сверху внизу по этой самой причине, хотя по сути это иллюзия. Отсюда и тревожность, а на деле эта область движется к классическому понятию инженерии. Тут, что удивительно, под ударом оказываются вовсе не джуны, а мидлы. Потому что джун учится (тому, чему надо), мидл исполняет (роль, замещаемая ИИ), сеньор планирует и ограничивает (мы берем тех, кто не просто сидел 20 лет на стуле и как бы может так себя называть, старший специалист, короче). Инженерия - это проецирование часто противоречивых и неполных факторов, требований и их ограничения часто во времени в конечный продукт. Этого у ИИ, думаю, еще долго не будет. Многие разработчики (как минимум часть моих знакомых) чувствуют даже облегчения, так как они меньше времени тратят на исполнительную рутину.
Да уж не знаю наверняка куда) Я лишь про что, реимплементация человеческой непредсказуемости вряд ли будет ценна именно для человека, и этот этап надо поскорее пройти, а не обсасывать его со всех сторон, как конечно же усиленно начнут всякие недоблогеры и недосми. Скорее тут я бы стремился к некому бесстрастному советнику-исполнителю, не лишенному определенной этики и целей, но так чтобы они точно не были как основополагающими в качестве личности.
Если это все действительно так и было, то это, я бы сказал, плохой milestone на пути создания ИИ. Вряд ли человеку нужен второй как бы человек, человек и сам себе достаточно недетерминирован, чтобы рядом существовал кто-то еще более. И если это является целью, то это очень посредственная цель. Мне лично хотя бы точно был бы не нужен такой ИИ. Может быть, это и необходимый этап, но, как по мне, от него надо скорее бежать дальше, не слушая очередных «пораженных» и «испуганных» великими талантами ИИ.
и далее
Видимо, без коммерческого опыта?
Это плохое решение. "Заабьюзить" сервис можно запросто. К примеру, я сделаю скрипт, который каждые 15 минут тупо добавляет товар обратно в корзину. У других практически нет шансов тогда купить товар. Если резервировать на этапе оформление заказа, то тут надо рассмотреть этот же вариант, к примеру, самое примитивное решение - при отказе или таймауте оплаты, позволять перейти к новому оформлению заказа не ранее, чем через 5 минут.
Это не понял, что значит. То есть, еще на заплатили, а товар уже списан? Тогда однозначно - нет.
Ввиду вышесказанного, я бы процесс сделал так:
1. Добавляются товары в корзину с обновлением доспупности для ранее добавленных и соответствующими предупреждениями.
2. Переход к оформлению заказа - тут происходит резервирование товаров на 15 мин (если доступны все еще, если нет, то предупреждать в соответствии).
3. Списание товаров только по факту оплаты, то есть по нажатию на кнопку "оплатить". Причем учесть процесс продолжения действия, если оплата и списание не выполняются атомарно и произошла ошибка. То есть чтобы не получилось так, что оплата произведена, а списание не произошло, и наоборот. Тут можно придумать много чего, к примеру, сохранять идентификатор сеанса оформления заказа и при повторной попытке проверять что было реально сделано.
4. Если опалата не была произведена по таймауту или заказ был отменен, добавить таймаут на новое оформление. Добавлять товары тем не менее можно.
Ну я пишу лет 8 в том числе и на питоне, и сходу тем не менее затруднился с ответом на
{("a", [1, 2]): "value"}иprint((x for x in range(3))). А за55 == True is Trueнадо сразу бить по рукам на месте. Наверное, я не знаю базу? Или просто в нормальных условиях такую дичь на код ревью не пропускают, и вообще такое в голову не приходит? Питон, скажем так, довольно специфичный язык, а автор, видимо, нанимался загадывать ребусы и выводить на чисту воду этих наглых "накрутчиков". Я вот смотрю больше на способность кандидата мыслить, коммуницировать, рассуждать и предлагать варианты, что куда важнее, чем знание 100+ подводных камней питона. И в качестве теста на написание кода идут самые обычные кейсы.Парад продолжается. После фиаско с первой версией этого, хм, "компилятора", а так же после его разбора, автор еще 8 месяцев пушил добавление/удаление строки в readme с целью создать видимость работы. Почти незамеченной протухла и вторая версия, краткий разбор которой был тут. Но автор не стоит на месте, радуя нас своим прогрессом, его даже не смущают 13 минусов под предыдущей статьей. Взлетит ли третья версия? Сомнительно. Видно, что автор явно не дурак, но нарциссизм не лучший спутник на этом пути.
Пустой треп в большей части. Понятно, что это интервью, однако...
Тут точно имелась в виду автономность?
Звучит прикольно.
LangChain?
Ползучий процесс и переизобретение, да-да. Это называют "эволюцией" обычно.
Это что такое? Джабба Хатт?
Конгениальный и актульный пример и практики использования ИИ - работа звонаря-выбивателя долгов. Ах, это же банк, тогда норм.
В последнее время, на мой взглад, складывается впечатние о какой-то эпидемии словесного поноса среди подобных спикеров. Может быть, я слишком придирчив.
Точно, необходимость передачи закрытого ключа как-то упустил из виду.
Бессмысленно, см "шифр Вернама", если размер ключа равен размеру текста, но идея интересная.
Когда есть только молоток, вокруг все кажется гвоздями.
"Обучение" тут - это двухдневная болтовня с чатом?
Противоречие тут видится мне.
Из чего сие значит? Из ваших слов?
Долго вкуривал этот тезис. Каким образом незанятые позиции сэкономили +200 тыс в месяц. Видимо, я понимаю термин "вакантная позиции" как-то иначе.
Ответ ИИ - "Вакансия" (вакантная позиция) означает незанятое рабочее место в компании, на которое можно принять нового сотрудника.
Ноутбук один на всю компанию? Глубокого погружения куда?
Еще один "прогнозист". Занялись бы вы чем-то более полезным.
А вы точно уверены, что понимаете причины этого?
Вы правы. Почему-то большая часть статей о graphql обходят этот вопрос. Помимо оптимизации глубоко вложенных запросов, есть также проблема глубины как таковой, так как object типы могут ссылаться циклически друг на друга (если так задать схему), то тем самым можно запросто положить сервер. У себя решили это просто собрав все запрашиваемые клиентами пути путем логирования, а потом все, что не в списке, то отбрасываем. Complexity тут не особо помогает тоже, так как сложно понимать что и насколько оценивать. Глубоко вложенные структуры в рамках одного сервиса можно оптимизировать, отображая схему запроса на eager или lazy отношения в orm, ну или как кому удобнее. Проблема N+1 может быть решена с помощью data loader (в federation схеме к примеру), но опять же смотреть надо что и как запрашивается. Оффтоп, но механизм upload в некотором роде просто приставка сбоку, и не рекомендуется аполло. У себя сделали просто отдельный рест для загрузок файлов, а в сервис передаем айди загрузки.