Max Ischenko

Додав собі в блог можливість писати long-form content тож треба спробувати щось написати. Наприклад про LLM. :)

Disclaimer: я не пишу production-ready код, цей блог не рахується.

Отже чим я користуюсь зараз:

1. ChatGPT: трекінг калорій, транскріпти для подкасту, рісерч на різні теми.
2. Claude (web): код для блога.

Власне все.

Картинки/відео мені не цікаво, command-line та agentic інструменти типу Claude Code – пробував, але щось поки не зайшло. Теж саме про Cursor/Windsurf. Можливо повернусь за місяць-два бо там чи не кожен тиждень нові релізи.

Чому веб-інтерфейс?

Бо це мені дає відчуття контролю, це раз. По-друге це вписується в мій workflow, до якого я звик коли був розробником. Я хочу бачити що саме пише мені Claude, перш ніж я зроблю commit або запушу нову версію.

Типовий workflow роботи над фічею виглядає так:

1. Промпт для Claude (“I want to add long-form posts to my blog…”).
2. Ревʼю його implementation plan (про це нижче).
3. Чекаю поки знегеруються артефакти та/або code changes.
4. Vim, git diff, test/edit/change, more git diff, commit, deploy.

Робочі спостереження:

1. Claude дуже любить генерувати код на будь який промпт і витрачає на це токени, хоча часто його рішення йдуть зовсім “не туди”. Тому мій Project instructions включає в себе explicit інструкцію показати implementation plan перш ніж щось робити.
2. GitHub інтеграція це тема. “Look at the code” і все. Мене правда напрягає що я вже на “55% project knowledge size” used і це маленький pet project. Але є надія, що це вирішиться швидше ніж я дійду до ліміту. Якщо ні-буду нарізати на модулі.
3. Claude жахливий архітектор. По дефолту він може генерувати модулі, які будуть між собою на 80% дублювати код або використати схожі але трошки інші naming convention і ще мільйон інших помилок джуна, який прочитав вчора книжку про Design Patterns, а сьогодні хоче їх всі реалізувати.
4. У 90% якщо Claude поліз у дебрі намагатися його “повернути” то марна справа. Простіше почати новий чат.
5. Що працює краще: дійти до “чекпойнт” де можна зупинитися. В ідеалі це працюючий код, але це може бути тільки фронт (без бекенду) або тільки архітектура або тільки база даних або тільки command-line interface, etc.
6. Спрощувати задачу і потім спрощувати ще раз. Як ніколи потрібно вміння дробити одну задачу на компоненти (бек/фронт) або на ітерації, eg v1 проста compose форма v2 drafts v3 markdown і тд.
7. Що працює неочікувано класно: idea exploration. Пробуєш пʼять різних ідей (промптів) для абсолютно різних задач і в залежності від його “розуміннія” та ідей вибираєш одну-дві для роботи яка виглядає найбільш перспективно.

Думаю на сьогодні все, якщо згадаю ще щось–допишу.

P.S.: Діліться своїми промптами :)

А я залишу свій project instruction (lightly edited).

before writing any code create an implemenation plan and show it for me to review/approve/ask questions or change tactics.

look at the codebase.

Don’t write features I didn’t ask for- ask first. Same with introducing new concepts/libraries or major frameworks or refactorings. Run it by me to confirm. 

I prefer to keep my loc down as much as possible and dont write more than i have to- so there is less code to maintain and less context for LLMs to read.

Keep things simple.