do...while...ai
мы просим модель принять решение, но она же не про это, LLM вообще про вероятностную генерацию следующего токена. И какой там токен будет следующим, зависит просто от цепочки предыдущих
Как-то так. Помогает аккуратней относиться к ожиданиям от моделей.
Временно описался от Claude Max Plan ($200), в причинах указал игнорирование CLAUDE.md на длинных сессиях. На самом деле, опыт уже получен, и я однозначно переподпишусь, когда потребность возникнет снова.
Сделаны классные продукты и утилиты, некоторыми из которых я занимаюсь каждый день. Масса планов — всё на месте. Получен шикарнейший опыт и скилл. Я горячо рекомендую на 2-3 месяца каждому продакту, менеджеру или предпринимателю (именно так) погрузиться в вайб-кодинг, снять страхи, очарования, потрогать новую реальность и понять, как она работает.
Это существенно повлияет на бизнес-флоу, на сам взгляд на найм, критерии, подготовит к будущему, которое на самом деле уже настоящее.
Сделаны классные продукты и утилиты, некоторыми из которых я занимаюсь каждый день. Масса планов — всё на месте. Получен шикарнейший опыт и скилл. Я горячо рекомендую на 2-3 месяца каждому продакту, менеджеру или предпринимателю (именно так) погрузиться в вайб-кодинг, снять страхи, очарования, потрогать новую реальность и понять, как она работает.
Это существенно повлияет на бизнес-флоу, на сам взгляд на найм, критерии, подготовит к будущему, которое на самом деле уже настоящее.
👍3
Forwarded from do...while...ai (Gregory is typing...)
Не успел к пятнице, исправляюсь в понедельник.
👍1
Гугл иногда не очень хорош в маркетинге, вполне экологичном.
Например, при ИИ-ответе, который меня вполне устраивает, я часто всё равно хочу продолжить диалог. И буду, скорее, благодарен, если меня шустренько перебросит в Gemini для этого. Дальше там уже диалог, лимиты, продажи, и т.п.
Простая кнопка «Продолжить диалог» 🤷♂️
Например, при ИИ-ответе, который меня вполне устраивает, я часто всё равно хочу продолжить диалог. И буду, скорее, благодарен, если меня шустренько перебросит в Gemini для этого. Дальше там уже диалог, лимиты, продажи, и т.п.
Простая кнопка «Продолжить диалог» 🤷♂️
Вот это тоже пролетело ниже радаров осознанности и адекватности Альфы. Такой баннер, с которым ты неизбежно соприкасаешься (буквально — пальцем, чтобы закрыть) на входе в приложении банка.
Как это воспринимается.
Когда живёшь в пузыре: просто напоминание о таком бытовом событии, как звонок мошенников.
Когда находишься чуть вне пузыря: мощный панч «здесь небезопасно» прямо со входа. Альфа = постоянная угроза?
Такая вот болезненная заботушка. Через принесение части репутации в жертву, когда острой необходимости в этом нет.
Как это воспринимается.
Когда живёшь в пузыре: просто напоминание о таком бытовом событии, как звонок мошенников.
Когда находишься чуть вне пузыря: мощный панч «здесь небезопасно» прямо со входа. Альфа = постоянная угроза?
Такая вот болезненная заботушка. Через принесение части репутации в жертву, когда острой необходимости в этом нет.
— It's complicated!
— Then uncomplicate it!
Для вайб-кодинга тоже подходит, для эмоциональных сессий.
Неожиданно эффективное решение в плане ADHD подошло мне как влитое, уже несколько раз. Может и вам зайдёт 🤷🏻♂️
Метаться между неопределенным количеством одновременных дел — это боль и непредсказуемость, страх неизвестности, можно легко загнаться в цикле, и т.п.
А вот если решить самому с собой, что берёшь в текущий цикл только, скажем, два или три несложных дела, и переключаешься только между ними — вот в этом случае уже включается суперсила, когда все они выполняются эффективно.
Типа, know your limits, если упростить. Где ключевое слово — знать. А не лимиты.
Метаться между неопределенным количеством одновременных дел — это боль и непредсказуемость, страх неизвестности, можно легко загнаться в цикле, и т.п.
А вот если решить самому с собой, что берёшь в текущий цикл только, скажем, два или три несложных дела, и переключаешься только между ними — вот в этом случае уже включается суперсила, когда все они выполняются эффективно.
Типа, know your limits, если упростить. Где ключевое слово — знать. А не лимиты.
👍4
Вообще, я пришёл написать восторженный пост про Kanbanchi.com — типа, лучшая доска по всем статьям. И интерфейс, и общий опыт. Но решил посмотреть на тарифы...
Классно, конечно, давать триал к Enterprise-версии. И не прикопаться, демка всего функционала. Но блин. Когда даже уведомления, подзадачи и архивирование доступны лишь в третьем по счёту тарифе из четырёх — возникает прям такое себе впечатление.
Не, всё равно классно и того стоит, пожалуй. Просто в баланс между ожиданием и реальностью вкрадывается небольшая толикавымогательства маркетинга 🥺
Классно, конечно, давать триал к Enterprise-версии. И не прикопаться, демка всего функционала. Но блин. Когда даже уведомления, подзадачи и архивирование доступны лишь в третьем по счёту тарифе из четырёх — возникает прям такое себе впечатление.
Не, всё равно классно и того стоит, пожалуй. Просто в баланс между ожиданием и реальностью вкрадывается небольшая толика
👍1
Forwarded from do...while...ai (Gregory is typing...)
Рефакторинг вайбкодинга
Все последние проекты, которые я разрабатывал (процентов на 80 вайбкодил), всегда проходят через две фазы: разработки и рефакторинга, и циклически повторяют их.
Разработка — это активный вайбкодинг, задача которого реализовать некую законченную бизнес-функцию, не сильно упарываясь с качеством кода. Не важно, какая модель или какой агент используется, они всегда вместе с полезным кодом добавляют кучу избыточного. Я не могу сказать, что этот новый код всегда мусорный, или лишний. Код часто бывает локально полезный, но если смотреть на уровне всего проекта — реализация часто неэффективная. Поэтому после каждого этапа разработки я делаю принудительный этап рефакторинга, чтобы привести код в порядок и не превратить проект в "спагетти".
Почему не делать это сразу в момент ревью результатов? Это замедляет реализацию бизнес-функций. Но откровенный булщит, конечно, исправляю сразу.
Как человек ленивый, первое, что я попробовал — это делать автоматический рефакторинг. Написал огромную инструкцию о том, как делать рефакторинг поэтапно (для python backend, деплоя, фронта на reactjs, ..), как запускать тулзы типа vulture, flake8, ESlint, Skylos, и т.п. для диагностики и валидации результатов, задал пороговые значения и параметры рефакторинга, позапускал с разными агентами (я попеременно использую Cursor, Claude Code и Codex). И то, что получалось в итоге — было фиаско.
Увы, пока ни агенты, ни модели, не работают на должном уровне, чтобы автономно по инструкциям сделать грамотный и эффективный рефакторинг. Поэтому данный этап я всё ещё делаю ручками. Открываю файлы, которые недавно менялись, начинаю ревьюить, замечать какие-то кривости реализации (например, сегодня у меня в трех местах в ansible playbook'ах была однотипная проверка на ОС на целевом хосте). Как только обнаруживаются проблемы реализации — я даю команду курсору или Codex исправить её: описываю, что и где я нашёл, почему я считаю это неэффективным, как я предлагаю реализовать, настаиваю на том, чтобы не было breaking changes и сохранилась вся текущая функциональности, и прошу также прошерстить остальной код на предмет аналогичных проблем. Если просить модель саму решить, как лучше отрефакторить, часто получается не лучше, чем было. Поэтому здесь нужно это брать в свои руки.
Я выработал свой критерий успешности рефакторинга: размер кода должен уменьшиться при сохранении функциональности и 100% pass rate для тестов.
Если я вижу, что переделка кода удалила 400 строк и добавила 390 — это какая-то фигня. Отменяю и делаю новую итерацию.
Типичные проблемы, которые я замечаю при вайб-кодинге, и для чего я делаю принудительный рефакторинг:
- дубли кода (иногда явно задублированный код в разных файлах)
- "мёртвый" код (модель переписывает что-то, забывая удалить старый, и оно там остаётся на века, засоряя проект)
- ненужный избыточный код, сохранённый для обратной совместимости (которая не нужна). Это прямо бич всех агентов: они стараются быть аккуратными и лишний раз реализуют избыточный код для сохранения обратной совместимости, которая не нужна.
- избыточные комментарии и код для дебага (когда агент что-то дебажит, он добавляет кучу ненужного для прода кода, и потом его не удаляет)
- .md файлы с документированием изменений (удаляю их сразу после завершения сессии). Пробовал делать рулзы не создавать эти .md, если я явно не прошу, но Cursor забивает на часть моих рулзов.
- лоскутное одеяло из стилей кодирования (где-то файлы читаются через file read(), где-то через pathlib read_text())
- константы и импорты объявляются локально внутри try / catch блоков или функций.
Важное наблюдение: поскольку природа LLM — completion inference, модель учитывает и "продолжает" стиль существующего кода. Если сделать заготовку проекта, написанную "с нуля" хорошо и аккуратно, есть шанс, что модель продолжит дальше вайбкодить также хорошо, как по трафарету (до определенного момента, конечно). Поэтому аккуратность кода нужно поддерживать регулярно, и, увы, вручную. Именно это я и пытаюсь делать регулярными рефакторингами проектов.
Все последние проекты, которые я разрабатывал (процентов на 80 вайбкодил), всегда проходят через две фазы: разработки и рефакторинга, и циклически повторяют их.
Разработка — это активный вайбкодинг, задача которого реализовать некую законченную бизнес-функцию, не сильно упарываясь с качеством кода. Не важно, какая модель или какой агент используется, они всегда вместе с полезным кодом добавляют кучу избыточного. Я не могу сказать, что этот новый код всегда мусорный, или лишний. Код часто бывает локально полезный, но если смотреть на уровне всего проекта — реализация часто неэффективная. Поэтому после каждого этапа разработки я делаю принудительный этап рефакторинга, чтобы привести код в порядок и не превратить проект в "спагетти".
Почему не делать это сразу в момент ревью результатов? Это замедляет реализацию бизнес-функций. Но откровенный булщит, конечно, исправляю сразу.
Как человек ленивый, первое, что я попробовал — это делать автоматический рефакторинг. Написал огромную инструкцию о том, как делать рефакторинг поэтапно (для python backend, деплоя, фронта на reactjs, ..), как запускать тулзы типа vulture, flake8, ESlint, Skylos, и т.п. для диагностики и валидации результатов, задал пороговые значения и параметры рефакторинга, позапускал с разными агентами (я попеременно использую Cursor, Claude Code и Codex). И то, что получалось в итоге — было фиаско.
Увы, пока ни агенты, ни модели, не работают на должном уровне, чтобы автономно по инструкциям сделать грамотный и эффективный рефакторинг. Поэтому данный этап я всё ещё делаю ручками. Открываю файлы, которые недавно менялись, начинаю ревьюить, замечать какие-то кривости реализации (например, сегодня у меня в трех местах в ansible playbook'ах была однотипная проверка на ОС на целевом хосте). Как только обнаруживаются проблемы реализации — я даю команду курсору или Codex исправить её: описываю, что и где я нашёл, почему я считаю это неэффективным, как я предлагаю реализовать, настаиваю на том, чтобы не было breaking changes и сохранилась вся текущая функциональности, и прошу также прошерстить остальной код на предмет аналогичных проблем. Если просить модель саму решить, как лучше отрефакторить, часто получается не лучше, чем было. Поэтому здесь нужно это брать в свои руки.
Я выработал свой критерий успешности рефакторинга: размер кода должен уменьшиться при сохранении функциональности и 100% pass rate для тестов.
Если я вижу, что переделка кода удалила 400 строк и добавила 390 — это какая-то фигня. Отменяю и делаю новую итерацию.
Типичные проблемы, которые я замечаю при вайб-кодинге, и для чего я делаю принудительный рефакторинг:
- дубли кода (иногда явно задублированный код в разных файлах)
- "мёртвый" код (модель переписывает что-то, забывая удалить старый, и оно там остаётся на века, засоряя проект)
- ненужный избыточный код, сохранённый для обратной совместимости (которая не нужна). Это прямо бич всех агентов: они стараются быть аккуратными и лишний раз реализуют избыточный код для сохранения обратной совместимости, которая не нужна.
- избыточные комментарии и код для дебага (когда агент что-то дебажит, он добавляет кучу ненужного для прода кода, и потом его не удаляет)
- .md файлы с документированием изменений (удаляю их сразу после завершения сессии). Пробовал делать рулзы не создавать эти .md, если я явно не прошу, но Cursor забивает на часть моих рулзов.
- лоскутное одеяло из стилей кодирования (где-то файлы читаются через file read(), где-то через pathlib read_text())
- константы и импорты объявляются локально внутри try / catch блоков или функций.
Важное наблюдение: поскольку природа LLM — completion inference, модель учитывает и "продолжает" стиль существующего кода. Если сделать заготовку проекта, написанную "с нуля" хорошо и аккуратно, есть шанс, что модель продолжит дальше вайбкодить также хорошо, как по трафарету (до определенного момента, конечно). Поэтому аккуратность кода нужно поддерживать регулярно, и, увы, вручную. Именно это я и пытаюсь делать регулярными рефакторингами проектов.