Не совсем понятно, чем это отличается от подключения MCP/LSP сервера используемого языка. Он ведь точно так же выставляет наружу граф ASP и греп становится не нужен. Не поясните разницу/преимущества?
У меня нет никакого эйджизма. У самого есть парень, который за пару лет буквально вырос от стажёра до синьора – сам ему синьорские лычки и навешивал, вполне заслуженно. Но это скорее исключение – очень талантливый, и по сути в программировании чуть ли не с пелёнок: отучился на очень хороших многолетних курсах, в конце концов даже сам уже на них же преподавал.
А вот у HR не то, чтобы эйджизм, а определённые (да, далеко не всегда правильные) критерии отбора есть. Представить себе, что они дружно накинулись на относительно неопытного кандидата, когда программисты со стажем 10++ лет месяцами стоят в очереди, мне довольно сложно. Вот мой молодой талант ко мне не так просто попал, например: папа его у меня же работал, предложил попробовать – поначалу за совершенно символическую з/п. А там уж пошло. Если бы он пробивался стандартным путём, через сито HR – ох, сомневаюсь, что это было бы так просто.
решил, что найду работу за 2-3 недели. Три года опыта, фуллстек, React + Node, пара нормальных проектов в портфолио
Честно говоря, звучит излишне самоуверенно. Три года – это опытный джун, таких сейчас массово на ИИ меняют. Вообще то, что человека с подобным бэкграундом за месяц собеседовали аж 15 раз, а несколько собесов закончились достойными офферами, из которых он мог ещё и выбирать, по нынешним временам звучит... необычно.
Как описать нейронке необходимость использовать React Router если ты вообще не знаешь о его существовании в силу отсутсвия опыта?
Довольно просто. Прежде чем давать задания джунам, человек, который разбирается в архитектуре проекта, создаёт в его корне AGENT.md, в котором прописаны требования к реализации, использованию библиотек и прочие важные архитектурные требования. В идеале вообще работа с ИИ начинается с создания инфраструктуры требований: правил, хуков, скиллов. А если ещё и задание джуну дать в виде такого же .md, который он может скормить ИИ – так и вообще замечательно. Если он возьмёт на себя труд его прочитать, то через какое-то время поймёт, как ставить ИИ задачу, и сможет это делать сам.
львиную долю занимают Messages - 400k токенов. Контекст безусловно важен, но если заставить llm сначала составить небольшой файлик в котором суммировать то, что должно быть сделано, то его можно и обрезать до 7-8 последних сообщений.
Понятия не имею, что он считает за сообщения в этой статистике. Я же описывал свой процесс: там именно что чата минимум. Весь обмен как раз через файлы: я пишу задание, он мне предлагает спецификацию (сначала уточняет то, что сформулировано недостаточно конкретно, а иногда и свои идеи предлагает – тут чат есть, но в основном в форме моих ответов на его вопросы, чаще всего просто выбор из предложенных вариантов); по согласованной спецификации он пишет план реализации (это тоже документ), я просматриваю, при необходимости корректирую. И уже когда все эти этапы пройдены и задокументированы – пишется собственно код. Собственно, это более или менее стандартная цепочка /superpowers – мне подходит, чаще всего ей и пользуюсь. И конечно, да: каждое сколько-нибудь значимое изменение делается в отдельной ветке гит.
Пусть модель на первом шаге разобьет ваше задание на шаги (если вы сами его не разбили) а потом брэйнстормит каждый шаг: предлагает идеи собирает информацию по каждой идее, анализирует, делает выводы, критикует, корректирует, опять ищет инфорацию и т.д. и так идея за идеей.
Так оно и происходит. Вот прямо пока мы тут всё это обсуждали, например. Задача была в принципе несложная: добавить экран к мобильному приложению.
Сначала дизайн. Сам я дизайнер никакой – если бы речь шла о корпоративном проекте, разумеется, этим бы занимался профессионал. А поскольку проект мой личный, мы прошли 13 итераций пока получилось то, что меня устроило. Получилось неплохо, кстати – и подозреваю, "токены" профессионального дизайнера мне обошлись бы сильно дороже.
Далее, технические требования. Разумеется, мне нужно, чтобы все решения, принятые в процессе обсуждения дизайна/UX учитывались – соответственно, та же сессия, тот же контекст. Плюс туда же добавляется новое: страница не очень сложная, но она взаимодействует с тремя модулями того же приложения, обрабатывая потоки данных от них. Ну и страницу сеттингов пришлось изменить – добавить туда параметры для новой, да на домашнюю добавить кнопку доступа. Соответственно, контекст расширяется.
Согласовали требования, дальше план реализации. Он его разбил на 11 этапов (Вы так хотели?) – разумеется, опять в том же контексте.
Ну и наконец, собственно реализация – опять же, контекст сохраняем. Он запускает несколько параллельных агентов на каждую задачу, через часик какой выкатывает готовый код.
Дальше дебаг. Дизайн превью – это хорошо, но перенести его в реальный код не всегда просто. У меня чуток графики, которую нужно из .svg перенести в Painter. Использовать статический ассет нельзя – графика динамическая. С первого раза у него не получилось – наверное, примерно с десятого. Но таки получилось – в результате я примерно за рабочий день добавил неплохую фичу, от начала до конца. А вот в плане контекста получилось так:
Можно было затратить меньше? Наверное, можно запускать /clear после каждого этапа – но тогда гораздо больше шансов, что в какой-то момент он потеряет контекст и уйдёт не туда. На токенах тоже можно сэкономить: например, план реализации – это фактически готовый код, можно даже не отдавать ему, а просто самому пройти по шагам плана, создавая файлы и копируя в них код. Но мне лень – зачем, если он это сделает в разы быстрее?
То же самое с выбором между локальным сетапом и подпиской. Локальный может быть дешевле (в частности, если пригодное железо уже есть), но значительно медленнее и не в состоянии держать большой контекст. Для меня сейчас выбор очевиден – стоимость сервиса приемлемая, особенно если рассмотреть как альтернативу реализацию человеком. Вот эта вышеописанная страница – примерно день работы дизайнера и (оптимистично) 3-4 дня хорошего программиста. Умножим на стоимость человеко-часа и видим, что оно того стоило.
Не мой случай. За исключением каких-то мелочей, я всегда формулирую задание в виде .md и уже его отдаю в работу. Так задание получается значительно точнее, после того, как сам его несколько раз просмотришь, почти никогда не остаётся неясностей или упущенных деталей. Так что чат по большей части сводится к `/brainstorm @very-complex-task.md`.
Любую достаточно сложную задачу можно разбить на несколько более простых подзадач. Т.е. ваш проект скорее всего можно разбить, ну допустим на 5 подзадач
Я умею в декомпозицию, поверьте на слово. Но когда имеешь дело с несколькими потоками параметризованных событий, то чтобы понять, к какому результату они приведут, держать в голове (контексте) приходится их все.
Это также как: "Зачем вам иметь локальный компьютер и возможность устанавливать то, что вы хотите, когда мы лучше знаем что вам нужно, пользуйтесь нашими мэйнфреймами!"
Так и используем – всё возвращается на круги своя. Я когда модели тренирую, покупаю у них машинное время. Гораздо выгоднее – мне не так часто нужно, стоит это грубо $1/час, а купить какую-нибудь H200 – уже $60,000.
Контекстное окно 32К - было приведено как пример.
Возможно, просто тут порядок цифр буквально из разных вселенных. Мне действительно нужно контекстное окно в сотни тысяч – и не сказал бы, что мои задачи так уж уникальны, любой достаточно сложный проект потребует примерно того же. Можно ли это получить в домашних условиях, и какой при этом будет производительность – я не знаю. Скорее нет, чем да.
Тут явное противоречие: подписки становятся дорогими из-за высокой стоимости железа – так давайте каждый будет покупать это железо сам. При том, что оно явно будет использоваться менее эффективно – только в рабочие часы, тогда как у них оно крутится (и зарабатывает деньги) круглые сутки.
Контекстное окно в 32К – вообще смешно. У меня полмиллиона токенов на задачу – обыденность. Да, я использую пайплайны, параллельных агентов и прочие методы повышения эффективности. Всё равно 32К – это ни о чём, уровень hello world.
Интересно, вроде бы этим набором кодеков пользуюсь долго, никогда подобного не замечал
Я обработкой видео закончил активно заниматься лет 15 назад, и уже тогда у этого набора кодеков была скверная репутация. За прокси не скажу, но если у кого-то возникали проблемы с рендером, одна из самых первых рекомендаций была снести их нахрен.
промпт это не ТЗ, это начало разговора. сначала "сделай форму", смотрю что вышло, потом уточняю
Честно говоря, я вообще практически перестал пользоваться промптами с описанием задач. Только если что-то совсем уж мелкое, типа: у тебя кнопка съехала в сторону, верни на место. Во всех остальных случаях промпт – это просто ссылка на .md с описанием задачи:
Если новая фича, то подробное описание, часто со ссылками на предыдущие документы;
Если результат тестового прогона, то тест кейс, ожидаемый и фактический результаты, если есть – то логи ошибок.
Таким образом каждый шаг получается документированным и ничего в дальнейшем не "забывается".
Если изменение хоть сколько-нибудь значительное, то обязательно включаю многоэтапный процесс: брэйншторм -> спецификация -> план реализации. После чего тоже остаются документы, и почему сделано так, а не иначе, вопросов потом не вызывает.
С общим посылом статьи: точные инструкции + постоянный контроль – согласен полностью:
LLM не делает junior’а senior’ом. Он просто позволяет тому, кто уже умеет, делать быстрее.
Да, как-то так. Это инструмент для тех, кто уже обладает серьёзными навыками проектирования. Для джуна, подозреваю, он будет скорее вреден, чем полезен.
Но есть нюансы. В частности:
и в ноль не помнит, что вы обсуждали в предыдущей сессии
Это не так. Он сохраняет историю работы с проектом в `~/.claude/projects/<project path>` и прекрасно помнит, что было не то, что в прошлой сессии – а вообще всё. Иногда удивляюсь даже, насколько уместно он напоминает о предыдущих решениях.
В моем проекте 814 unit-тестов, каждый написан до соответствующего кода.
Вот тут его приходится даже притормаживать – иначе он запускает тесты ещё не созданных модулей и радостно рапортует: О! Упало, так и должно быть! Что, разумеется, ничего не говорит о качестве кода – чисто перевод токенов. Я это явно запрещаю – причём иногда он об этом запрете "забывает", приходится напоминать.
Разумеется. А зачем? Я же честно попытался выяснить, каким может быть его применение (см. вопрос про воркфлоу) ‒ сам не вижу, так зачем мне время тратить? Вы позиционируете в качестве преимущества своего приложения возможность многодорожечного редактирования. А я не понимаю, зачем оно нужно в мобильном редакторе ‒ ну не будет же кто-то всерьёз сводить на телефоне материал с нескольких камер. Не, так Вы этого слона не продадите.
Вот я и пытаюсь понять, какой тип работы может такого потребовать. Собрать видео с телефонов всех участников события и тут же смонтировать? Весьма сомнительно, девайсы разные, навыки съёмки тем более, таймкода нет – только синхронизировать упаришься. Про перенос материала с про камер на телефон уже писал. Не вижу, для чего такое может понадобиться.
Обе темы знакомые – и видеомонтаж, и флаттер. Каждую в отдельности люблю – а вот как их поженить, не понимаю. Видеоредактор – это же не просто нарезка. Даже многодорожечная. Это и работа с цветом – от банального баланса белого до полноценного грейдинга в разных цветовых пространствах. Это работа с различными входными форматами и рендер в различных стандартах, с разными разрешениями и т.п. Это высококачественные титры – что добавляет элементы композитинга. Эффекты ладно – в профессиональной работе они особо не нужны, хотя любители хотят. Но вот резкость, размытие, маски, трассировка объектов – тоже неотъемлемая часть любого сколько-нибудь приличного видеоредактора. Где всё это и где флаттер?
Ну и самое главное – воркфлоу. Как это всё выглядит? Видео с профессиональных камер загружается на телефон и там обрабатывается? Звучит, ээээ... необычно. А если съёмка на телефон, то напуркуа многодорожечность? И вообще о каком профессиональном использовании тогда речь? Автор таки позиционирует себя, как видеомонтажёра.
Как развлечение – понимаю. Как коммерческий (или хотя бы просто востребованный) продукт – нет.
Да, извините 🙂
Понятно, спасибо. Надо будет попробовать.
Не совсем понятно, чем это отличается от подключения MCP/LSP сервера используемого языка. Он ведь точно так же выставляет наружу граф ASP и греп становится не нужен. Не поясните разницу/преимущества?
Собственно, всю статью можно было бы сократить до одной фразы:
У меня нет никакого эйджизма. У самого есть парень, который за пару лет буквально вырос от стажёра до синьора – сам ему синьорские лычки и навешивал, вполне заслуженно. Но это скорее исключение – очень талантливый, и по сути в программировании чуть ли не с пелёнок: отучился на очень хороших многолетних курсах, в конце концов даже сам уже на них же преподавал.
А вот у HR не то, чтобы эйджизм, а определённые (да, далеко не всегда правильные) критерии отбора есть. Представить себе, что они дружно накинулись на относительно неопытного кандидата, когда программисты со стажем 10++ лет месяцами стоят в очереди, мне довольно сложно. Вот мой молодой талант ко мне не так просто попал, например: папа его у меня же работал, предложил попробовать – поначалу за совершенно символическую з/п. А там уж пошло. Если бы он пробивался стандартным путём, через сито HR – ох, сомневаюсь, что это было бы так просто.
Честно говоря, звучит излишне самоуверенно. Три года – это опытный джун, таких сейчас массово на ИИ меняют. Вообще то, что человека с подобным бэкграундом за месяц собеседовали аж 15 раз, а несколько собесов закончились достойными офферами, из которых он мог ещё и выбирать, по нынешним временам звучит... необычно.
А чем это отличается от старого доброго
/goal?Довольно просто. Прежде чем давать задания джунам, человек, который разбирается в архитектуре проекта, создаёт в его корне AGENT.md, в котором прописаны требования к реализации, использованию библиотек и прочие важные архитектурные требования. В идеале вообще работа с ИИ начинается с создания инфраструктуры требований: правил, хуков, скиллов. А если ещё и задание джуну дать в виде такого же .md, который он может скормить ИИ – так и вообще замечательно. Если он возьмёт на себя труд его прочитать, то через какое-то время поймёт, как ставить ИИ задачу, и сможет это делать сам.
Понятия не имею, что он считает за сообщения в этой статистике. Я же описывал свой процесс: там именно что чата минимум. Весь обмен как раз через файлы: я пишу задание, он мне предлагает спецификацию (сначала уточняет то, что сформулировано недостаточно конкретно, а иногда и свои идеи предлагает – тут чат есть, но в основном в форме моих ответов на его вопросы, чаще всего просто выбор из предложенных вариантов); по согласованной спецификации он пишет план реализации (это тоже документ), я просматриваю, при необходимости корректирую. И уже когда все эти этапы пройдены и задокументированы – пишется собственно код. Собственно, это более или менее стандартная цепочка
/superpowers– мне подходит, чаще всего ей и пользуюсь. И конечно, да: каждое сколько-нибудь значимое изменение делается в отдельной ветке гит.Так оно и происходит. Вот прямо пока мы тут всё это обсуждали, например. Задача была в принципе несложная: добавить экран к мобильному приложению.
Сначала дизайн. Сам я дизайнер никакой – если бы речь шла о корпоративном проекте, разумеется, этим бы занимался профессионал. А поскольку проект мой личный, мы прошли 13 итераций пока получилось то, что меня устроило. Получилось неплохо, кстати – и подозреваю, "токены" профессионального дизайнера мне обошлись бы сильно дороже.
Далее, технические требования. Разумеется, мне нужно, чтобы все решения, принятые в процессе обсуждения дизайна/UX учитывались – соответственно, та же сессия, тот же контекст. Плюс туда же добавляется новое: страница не очень сложная, но она взаимодействует с тремя модулями того же приложения, обрабатывая потоки данных от них. Ну и страницу сеттингов пришлось изменить – добавить туда параметры для новой, да на домашнюю добавить кнопку доступа. Соответственно, контекст расширяется.
Согласовали требования, дальше план реализации. Он его разбил на 11 этапов (Вы так хотели?) – разумеется, опять в том же контексте.
Ну и наконец, собственно реализация – опять же, контекст сохраняем. Он запускает несколько параллельных агентов на каждую задачу, через часик какой выкатывает готовый код.
Дальше дебаг. Дизайн превью – это хорошо, но перенести его в реальный код не всегда просто. У меня чуток графики, которую нужно из .svg перенести в Painter. Использовать статический ассет нельзя – графика динамическая. С первого раза у него не получилось – наверное, примерно с десятого. Но таки получилось – в результате я примерно за рабочий день добавил неплохую фичу, от начала до конца. А вот в плане контекста получилось так:
Можно было затратить меньше? Наверное, можно запускать
/clearпосле каждого этапа – но тогда гораздо больше шансов, что в какой-то момент он потеряет контекст и уйдёт не туда. На токенах тоже можно сэкономить: например, план реализации – это фактически готовый код, можно даже не отдавать ему, а просто самому пройти по шагам плана, создавая файлы и копируя в них код. Но мне лень – зачем, если он это сделает в разы быстрее?То же самое с выбором между локальным сетапом и подпиской. Локальный может быть дешевле (в частности, если пригодное железо уже есть), но значительно медленнее и не в состоянии держать большой контекст. Для меня сейчас выбор очевиден – стоимость сервиса приемлемая, особенно если рассмотреть как альтернативу реализацию человеком. Вот эта вышеописанная страница – примерно день работы дизайнера и (оптимистично) 3-4 дня хорошего программиста. Умножим на стоимость человеко-часа и видим, что оно того стоило.
Не мой случай. За исключением каких-то мелочей, я всегда формулирую задание в виде .md и уже его отдаю в работу. Так задание получается значительно точнее, после того, как сам его несколько раз просмотришь, почти никогда не остаётся неясностей или упущенных деталей. Так что чат по большей части сводится к `/brainstorm @very-complex-task.md`.
Я умею в декомпозицию, поверьте на слово. Но когда имеешь дело с несколькими потоками параметризованных событий, то чтобы понять, к какому результату они приведут, держать в голове (контексте) приходится их все.
Так и используем – всё возвращается на круги своя. Я когда модели тренирую, покупаю у них машинное время. Гораздо выгоднее – мне не так часто нужно, стоит это грубо $1/час, а купить какую-нибудь H200 – уже $60,000.
Возможно, просто тут порядок цифр буквально из разных вселенных. Мне действительно нужно контекстное окно в сотни тысяч – и не сказал бы, что мои задачи так уж уникальны, любой достаточно сложный проект потребует примерно того же. Можно ли это получить в домашних условиях, и какой при этом будет производительность – я не знаю. Скорее нет, чем да.
Тут явное противоречие: подписки становятся дорогими из-за высокой стоимости железа – так давайте каждый будет покупать это железо сам. При том, что оно явно будет использоваться менее эффективно – только в рабочие часы, тогда как у них оно крутится (и зарабатывает деньги) круглые сутки.
Контекстное окно в 32К – вообще смешно. У меня полмиллиона токенов на задачу – обыденность. Да, я использую пайплайны, параллельных агентов и прочие методы повышения эффективности. Всё равно 32К – это ни о чём, уровень hello world.
Я обработкой видео закончил активно заниматься лет 15 назад, и уже тогда у этого набора кодеков была скверная репутация. За прокси не скажу, но если у кого-то возникали проблемы с рендером, одна из самых первых рекомендаций была снести их нахрен.
Честно говоря, я вообще практически перестал пользоваться промптами с описанием задач. Только если что-то совсем уж мелкое, типа: у тебя кнопка съехала в сторону, верни на место. Во всех остальных случаях промпт – это просто ссылка на .md с описанием задачи:
Если новая фича, то подробное описание, часто со ссылками на предыдущие документы;
Если результат тестового прогона, то тест кейс, ожидаемый и фактический результаты, если есть – то логи ошибок.
Таким образом каждый шаг получается документированным и ничего в дальнейшем не "забывается".
Если изменение хоть сколько-нибудь значительное, то обязательно включаю многоэтапный процесс: брэйншторм -> спецификация -> план реализации. После чего тоже остаются документы, и почему сделано так, а не иначе, вопросов потом не вызывает.
С общим посылом статьи: точные инструкции + постоянный контроль – согласен полностью:
Да, как-то так. Это инструмент для тех, кто уже обладает серьёзными навыками проектирования. Для джуна, подозреваю, он будет скорее вреден, чем полезен.
Но есть нюансы. В частности:
Это не так. Он сохраняет историю работы с проектом в `~/.claude/projects/<project path>` и прекрасно помнит, что было не то, что в прошлой сессии – а вообще всё. Иногда удивляюсь даже, насколько уместно он напоминает о предыдущих решениях.
Вот тут его приходится даже притормаживать – иначе он запускает тесты ещё не созданных модулей и радостно рапортует: О! Упало, так и должно быть! Что, разумеется, ничего не говорит о качестве кода – чисто перевод токенов. Я это явно запрещаю – причём иногда он об этом запрете "забывает", приходится напоминать.
Разумеется. А зачем? Я же честно попытался выяснить, каким может быть его применение (см. вопрос про воркфлоу) ‒ сам не вижу, так зачем мне время тратить? Вы позиционируете в качестве преимущества своего приложения возможность многодорожечного редактирования. А я не понимаю, зачем оно нужно в мобильном редакторе ‒ ну не будет же кто-то всерьёз сводить на телефоне материал с нескольких камер. Не, так Вы этого слона не продадите.
Ну извините 🤷♂️ Не знал, что принимаются только восторженные отзывы.
Вот я и пытаюсь понять, какой тип работы может такого потребовать. Собрать видео с телефонов всех участников события и тут же смонтировать? Весьма сомнительно, девайсы разные, навыки съёмки тем более, таймкода нет – только синхронизировать упаришься. Про перенос материала с про камер на телефон уже писал. Не вижу, для чего такое может понадобиться.
Обе темы знакомые – и видеомонтаж, и флаттер. Каждую в отдельности люблю – а вот как их поженить, не понимаю. Видеоредактор – это же не просто нарезка. Даже многодорожечная. Это и работа с цветом – от банального баланса белого до полноценного грейдинга в разных цветовых пространствах. Это работа с различными входными форматами и рендер в различных стандартах, с разными разрешениями и т.п. Это высококачественные титры – что добавляет элементы композитинга. Эффекты ладно – в профессиональной работе они особо не нужны, хотя любители хотят. Но вот резкость, размытие, маски, трассировка объектов – тоже неотъемлемая часть любого сколько-нибудь приличного видеоредактора. Где всё это и где флаттер?
Ну и самое главное – воркфлоу. Как это всё выглядит? Видео с профессиональных камер загружается на телефон и там обрабатывается? Звучит, ээээ... необычно. А если съёмка на телефон, то напуркуа многодорожечность? И вообще о каком профессиональном использовании тогда речь? Автор таки позиционирует себя, как видеомонтажёра.
Как развлечение – понимаю. Как коммерческий (или хотя бы просто востребованный) продукт – нет.