я описал только то что применяю на практике каждый день, и что заметил из случаях взаимодействия с другими людьми с агентами. В случае с лексикой это особенно важно, потому что в случае работы с такими приложениями как chatgpt/codex app, или Claude app, или кастомными реализациями памяти, в память агента сохраняются воспоминания (memories), что в дальнейшем, даже при учете компрессии памяти, может оказывать влияние на решения (т.е. predictions) llm которые использует агент.
важный момент на который обратил бы внимание - что я описываю то, что важно взаимодействовать с агентами как людьми - это не значит хвалить модель через каждый шаг, точно так же как и при работе с людьми есть определенная деловая этика, на мой взгляд ровно точно также стоит общаться с агентами (в каких-то местах с упрощениями, в каких-то местах с преобразованиями). На мой взгляд важно ловить баланс между бессмысленными словами- бюрократией и не этичными словами
Да, соглашусь с Вами, терминов много, и много что узнается по практике + у каждого человека свой опыт:)
про PDCA/ PDSA (цикл Шухарта-Деминга) - изучал ещё в универе, а потом применял на практике, так как он на мой взгляд применим к любой индустрии (применял работая в закупках / и участвовал в переносе производства в РФ), и так как сейчас работаю в разработке, особенно при работе с агентами - очень помогает. Что интересно - зачастую в разных индустриях адаптация одних и тех же терминов происходит в разном порядке, и под разными названиями. Могу ошибаться, но этот цикл берет источником 1920 год - https://en.wikipedia.org/wiki/PDCA
с SOP - впервые столкнулся когда работал в организации перевозок из Китая, Европы в РФ - они прописывались довольно строго и с тех пор, мне понравился такой подход, не везде применим, но когда есть необходимости зафиксировать/ задокументировать процесс - нашел его полезным.
LLM (как и интернет и библиотеки) просто позволяет быстрее обучаться, узнавать быстрее то, что раньше было бы сложно найти - почти вся статья написана вручную, но писал на английском изначально, перевод делал с помощью LLM и потом пруфридил вручную.
Как пример - недавно находил лекцию (на YouTube, https://youtu.be/OoJsPvmFixU?si=HTnEumIH7Lrn4MKv&t=2549) в которой увидел документ про apollo https://ntrs.nasa.gov/search?q=what made apollo a success и так как документ в общем доступе, его можно исследовать и затем применять похожие выводы в других индустриях, в том числе разработке - и тут (чтобы разобраться) помогает в том числе LLM:) - совмещение LLM / AI агентов + поиск + видео делает информацию доступнее
и из видео-документа там понравилась такая фраза:
Too small a step would have involved the risk that is always inherent in manned flight, without any significant gain — without any real progress toward the lunar land-ing.Too large a step, on the other hand, might have stretched the system beyond the capability and to the point where risks would have become excessive because the new requirements in flight operations were more than people could learn and practice and perfect in available time.
что я бы интерпретировал так: Слишком маленький шаг привел бы к риску, который всегда присущ [пилотируемым полетам - интерпретация - ручному труду], без какого-либо значительного выигрыша - без какого-либо реального прогресса на пути к [посадке на Луну - интерпретация - достижению цели].
Слишком большой шаг, с другой стороны, мог бы вывести систему за пределы возможностей и привести к тому, что риски стали бы чрезмерными, поскольку новые требования к [полетным - интерпретация - рабочим] операциям оказались бы выше, чем [люди] могли бы выучить, отработать и довести до совершенства за имеющееся время.
Что в каком-то смысле очень похоже на использование AI /LLM в наши дни:)
Грамотное использование ai инструментов требует не только навыков разработки, но и понимания архитектуры, взаимодействия с агентами (делегирование задач), умение накапливать знания и опыт с каждым обращением и каждой генерацией.
На все это нужно время, эксперменты и планирование.
Поэтому в конечном итоге любой результат надо смотреть в динамике времени, на протяжении нескольких месяцев (потому что технологии еще новые, и стабильных инструментов, которые как vscode или excel существуют годами ещё только разрабатываются, пока почти нет).
Срез же дает максимально скептическую картинку. Возможно сейчас самые лучшие вайбкодеры и ml ресерчеры / разработчики это junior+ - middle уровень с точки зрения применения ai тулов / агентов. Можно представить что те люди, которые только начинают работать с ai - равносильны по знаниям тем, кто пробует впервые в жизни написать saas не зная что такое сервер, клиент и браузер.
Поэтому на мой взгляд тут просто нужно время на обучение и совершенствование.
На мой взгляд самое опасное со стороны компаний, это то, что ожидания по скорости и качеству работы возрастают в большее количество раз.
Например: Раньше можно было сказать 1 экран ~ 1-3 дня (зависит от бизнес целей экрана и логики, но усредненно), с ai в целом можно сделать целиком прототип за 1-3 дня.
И самая большая здесь печалька - раз ты можешь делать х10 работы, то теперь:
Раз ты умеешь делать х10, значит все задачи должны ускориться в х10
Доход не только останется прежним, но и упадет.
Оплачиваешь AI тулы за свой счет
Ресерчишь AI тулы в свободное время (потому что бизнесу мгновенной ценности от ресерча нет, ресерч может закончиться успешно или совсем не успешно)
Но здесь есть нюанс, для работы с ai требуется в несколько раз больше скилов:
Нужно ревьюить гиганское кол-во кода (code review)
Нужно работать с накоплением промптов, паттернов (pattern review)
Нужно обучаться новому стеку, новым подходам разработки, ресерчить что больше подходит с разработкой ai
Чаще пилить микротулы
Организовывать работу которая будет качественнее (tdd, ddd, промпты валидаторы), чтобы в следующей итерации было на что опираться и с точки зрения автоматизаций, но и с точки зрения промптов
Плюс прототип != прод. Если нужно докатывать до прода, то не исключено что нужно будет сделать несколько итераций, где-то допиливать руками, или в некоторых случаях вообще соьрать 1-5 прототипов, потетстить идеи, а потом пересобрать еще раз.
Плюс нужно дополнительно выстраивать общение с другими разработчиками, дизайнерами чтобы они понимали ограничения, на что стоит обращать внимание в прототипе, на что - нет. Как именно транслировать дизайн в код, анимации и т.д.
Прежде всего решал проблему не для заказчиков, а для самого себя, так как этот пост не про успешный успех, а про то, как решил свою личную проблему при разработке с использованием AI.
ЦА тут такой же любой разработчик который только начинает работать с любыми AI тулами - Cursor, Cline, Claude, Windsurf etc..
Скорее всего вопрос “это же не я пишу а машина" возникнет не у всех людей, но надеюсь, что у тех которых возникнет - мой пост как-нибудь поможет.
Поэтому речь не совсем про "раньше было бездуховное А, а стало высокоморальное Б”, а про обычную day-to-day работу непосредственно с кодом и продуктом.
Да, в конце поставил ссылку на канал, так как для меня в данный момент телеграм - это хранилище информации которым хотел поделиться в рамках опыта который описал в посте
да, lodash 🔥 изначально хотел написать побольше статью, чтобы была совсем language agnostic, чтобы показать примеры и из js, rust, go, но со временем пока не вышло:)
очень рекомендую при разработке в вебе для всех сервисов которые имеют доступ к web api, или импортируют web библиотеки писать моки библиотек, и основную часть разработки вести как desktop приложение - это сильно убыстряет разработку, потому что desktop поддерживает hot reload, а веб к сожалению нет, и вроде бы это и не планируется.
В таком случае разработку даже можно поделить на несколько частей чтобы ускорить и распараллелить 1 - разработка верстки / дизайна / логики экранов (через desktop) 2 - разработка веб фич как отдельных api - библиотек со своими моками или другими платформенными фичами (отдельно как wrapper API) 3 - тестирование / допилка в вебе готового приложения (desktop) и web api
спасибо за вопрос.
я описал только то что применяю на практике каждый день, и что заметил из случаях взаимодействия с другими людьми с агентами. В случае с лексикой это особенно важно, потому что в случае работы с такими приложениями как chatgpt/codex app, или Claude app, или кастомными реализациями памяти, в память агента сохраняются воспоминания (memories), что в дальнейшем, даже при учете компрессии памяти, может оказывать влияние на решения (т.е. predictions) llm которые использует агент.
важный момент на который обратил бы внимание - что я описываю то, что важно взаимодействовать с агентами как людьми - это не значит хвалить модель через каждый шаг, точно так же как и при работе с людьми есть определенная деловая этика, на мой взгляд ровно точно также стоит общаться с агентами (в каких-то местах с упрощениями, в каких-то местах с преобразованиями). На мой взгляд важно ловить баланс между бессмысленными словами- бюрократией и не этичными словами
Да, соглашусь с Вами, терминов много, и много что узнается по практике + у каждого человека свой опыт:)
про PDCA/ PDSA (цикл Шухарта-Деминга) - изучал ещё в универе, а потом применял на практике, так как он на мой взгляд применим к любой индустрии (применял работая в закупках / и участвовал в переносе производства в РФ), и так как сейчас работаю в разработке, особенно при работе с агентами - очень помогает.
Что интересно - зачастую в разных индустриях адаптация одних и тех же терминов происходит в разном порядке, и под разными названиями. Могу ошибаться, но этот цикл берет источником 1920 год - https://en.wikipedia.org/wiki/PDCA
с SOP - впервые столкнулся когда работал в организации перевозок из Китая, Европы в РФ - они прописывались довольно строго и с тех пор, мне понравился такой подход, не везде применим, но когда есть необходимости зафиксировать/ задокументировать процесс - нашел его полезным.
LLM (как и интернет и библиотеки) просто позволяет быстрее обучаться, узнавать быстрее то, что раньше было бы сложно найти - почти вся статья написана вручную, но писал на английском изначально, перевод делал с помощью LLM и потом пруфридил вручную.
Как пример - недавно находил лекцию (на YouTube, https://youtu.be/OoJsPvmFixU?si=HTnEumIH7Lrn4MKv&t=2549) в которой увидел документ про apollo https://ntrs.nasa.gov/search?q=what made apollo a success и так как документ в общем доступе, его можно исследовать и затем применять похожие выводы в других индустриях, в том числе разработке - и тут (чтобы разобраться) помогает в том числе LLM:) - совмещение LLM / AI агентов + поиск + видео делает информацию доступнее
и из видео-документа там понравилась такая фраза:
что я бы интерпретировал так:
Слишком маленький шаг привел бы к риску, который всегда присущ [пилотируемым полетам - интерпретация - ручному труду], без какого-либо значительного выигрыша - без какого-либо реального прогресса на пути к [посадке на Луну - интерпретация - достижению цели].
Слишком большой шаг, с другой стороны, мог бы вывести систему за пределы возможностей и привести к тому, что риски стали бы чрезмерными, поскольку новые требования к [полетным - интерпретация - рабочим] операциям оказались бы выше, чем [люди] могли бы выучить, отработать и довести до совершенства за имеющееся время.
Что в каком-то смысле очень похоже на использование AI /LLM в наши дни:)
Грамотное использование ai инструментов требует не только навыков разработки, но и понимания архитектуры, взаимодействия с агентами (делегирование задач), умение накапливать знания и опыт с каждым обращением и каждой генерацией.
На все это нужно время, эксперменты и планирование.
Поэтому в конечном итоге любой результат надо смотреть в динамике времени, на протяжении нескольких месяцев (потому что технологии еще новые, и стабильных инструментов, которые как vscode или excel существуют годами ещё только разрабатываются, пока почти нет).
Срез же дает максимально скептическую картинку. Возможно сейчас самые лучшие вайбкодеры и ml ресерчеры / разработчики это junior+ - middle уровень с точки зрения применения ai тулов / агентов. Можно представить что те люди, которые только начинают работать с ai - равносильны по знаниям тем, кто пробует впервые в жизни написать saas не зная что такое сервер, клиент и браузер.
Поэтому на мой взгляд тут просто нужно время на обучение и совершенствование.
На мой взгляд самое опасное со стороны компаний, это то, что ожидания по скорости и качеству работы возрастают в большее количество раз.
Например:
Раньше можно было сказать 1 экран ~ 1-3 дня (зависит от бизнес целей экрана и логики, но усредненно), с ai в целом можно сделать целиком прототип за 1-3 дня.
И самая большая здесь печалька - раз ты можешь делать х10 работы, то теперь:
Раз ты умеешь делать х10, значит все задачи должны ускориться в х10
Доход не только останется прежним, но и упадет.
Оплачиваешь AI тулы за свой счет
Ресерчишь AI тулы в свободное время (потому что бизнесу мгновенной ценности от ресерча нет, ресерч может закончиться успешно или совсем не успешно)
Но здесь есть нюанс, для работы с ai требуется в несколько раз больше скилов:
Нужно ревьюить гиганское кол-во кода (code review)
Нужно работать с накоплением промптов, паттернов (pattern review)
Нужно обучаться новому стеку, новым подходам разработки, ресерчить что больше подходит с разработкой ai
Чаще пилить микротулы
Организовывать работу которая будет качественнее (tdd, ddd, промпты валидаторы), чтобы в следующей итерации было на что опираться и с точки зрения автоматизаций, но и с точки зрения промптов
Плюс прототип != прод. Если нужно докатывать до прода, то не исключено что нужно будет сделать несколько итераций, где-то допиливать руками, или в некоторых случаях вообще соьрать 1-5 прототипов, потетстить идеи, а потом пересобрать еще раз.
Плюс нужно дополнительно выстраивать общение с другими разработчиками, дизайнерами чтобы они понимали ограничения, на что стоит обращать внимание в прототипе, на что - нет. Как именно транслировать дизайн в код, анимации и т.д.
спасибо за комментарий!
Примеры есть и у меня и у других людей, подумаю как оформить в статью)
Спасибо большое!
Спасибо за вопрос!
Моя причина простая - давно работаю с fvm , и для меня - it just works.
Puro довольно новая и интересная штука, слежу за ней давно, но руки потестить на продовых проектов пока не дошли.
Есть возможность поделиться хорошими примерами по работе с puro?:)
Прежде всего решал проблему не для заказчиков, а для самого себя, так как этот пост не про успешный успех, а про то, как решил свою личную проблему при разработке с использованием AI.
ЦА тут такой же любой разработчик который только начинает работать с любыми AI тулами - Cursor, Cline, Claude, Windsurf etc..
Скорее всего вопрос “это же не я пишу а машина" возникнет не у всех людей, но надеюсь, что у тех которых возникнет - мой пост как-нибудь поможет.
Поэтому речь не совсем про "раньше было бездуховное А, а стало высокоморальное Б”, а про обычную day-to-day работу непосредственно с кодом и продуктом.
Надеюсь что ответил на вопрос.
Спасибо за комментарий.
Да, в конце поставил ссылку на канал, так как для меня в данный момент телеграм - это хранилище информации которым хотел поделиться в рамках опыта который описал в посте
да, lodash 🔥 изначально хотел написать побольше статью, чтобы была совсем language agnostic, чтобы показать примеры и из js, rust, go, но со временем пока не вышло:)
статья классная 🔥 спасибо!
очень рекомендую при разработке в вебе для всех сервисов которые имеют доступ к web api, или импортируют web библиотеки писать моки библиотек, и основную часть разработки вести как desktop приложение - это сильно убыстряет разработку, потому что desktop поддерживает hot reload, а веб к сожалению нет, и вроде бы это и не планируется.
В таком случае разработку даже можно поделить на несколько частей чтобы ускорить и распараллелить
1 - разработка верстки / дизайна / логики экранов (через desktop)
2 - разработка веб фич как отдельных api - библиотек со своими моками или другими платформенными фичами (отдельно как wrapper API)
3 - тестирование / допилка в вебе готового приложения (desktop) и web api