Не то чтобы быстро, но время летит, иногда кто-нибудь да напомнит. Интересно, что за каждой цифрой какие-то воспоминания, не просто какой-то континуум. Какие-то первые проекты, сайты на заказ, работа, новые проекты, "опен-сорс", ну а потом зациклилось.

Помню еще до гитхаба у многих на сайтах были ссылки на sourceforge 👨‍🦳

https://github.com/boryashkin

Переписал robots.txt с помощью AI и вылетел из поиска 😌

Пока подозреваю
Disallow: /_next/

Плохая идея была - мешать SEO вместе с кучей других технических задач.

Сейчас AI в документации - общепринятая норма. Но первый раз я увидел такое больше года назад на нишевом проекте - https://www.traccar.org/
Еще тогда стало понятно, насколько это удобно. Сейчас у всех топовых вендоров AI интегрирован везде и без него можно было бы терять дополнительные часы на разбирательства (например, в AWS, где все гранулировано и разбито на такие мелочи, что просто в панели управления заблудиться можно).

Время в UI
Когда клиентское приложение отображает дату и время события без указания таймзоны, я отношусь к данным скептически.
2025-02-06 18:10:00
Это время по моему часовому поясу или UTC, а может локальное время события, а таймзона просто отброшена?

Чего только я не видел на практике, от этого и сомнения.

Я тут подумал: со всеми этими AI свистелками, программист со стороны теперь больше похож на типичного хакера из фильмов — напечатал что-то, а на экране все мелькает, тексты крутятся, анимации и кнопки вылазят.

Мой блог на сайте отставал от телеграма только лишь из-за неудобств: там надо писать tsx и пушить в репу, потом ждать регенерации и деплоя. Посмотрим что сделает агент.

Эффективная работа с AI
Я в этом деле, как и многие, только разгоняюсь, но по выходным работаю над парой пет-проектов и вот мой текущий рецепт продуктивных инструкций для агентов (они имели смысл и без агентов, но люди могли жить без четких процессов):
— Весь код должен отталкиваться от схем и быть сгенерирован (не важно, схема-first или схемагенерация): делаешь бэк, клиент генерится. Делаешь микросервис, прото клиент генерится, гейтвей его использует.
— Не использовать энвы в коде, использовать типизированные конфиги, которые наполняются из энвов (типа viper для го, zod для TS)
— Использовать линтер после изменений (иначе будет гадать и по сто раз пытаться запускать сервисы и падать)
— Все делать только через docker / docker compose, без локальных утилит (это мое личное предпочтение)

— Externalized thinking - есть папка (в gitignore или нет - не важно) tasks, в ней make-something, внутри md файл типа PLAN, где описана цель, а агент должен держать актуальный план, описания, идеи в этой папке. Это позволяет переиспользовать наработки, переключая модели, ide и тп

Не знаю, насколько это хорошо или не хорошо, но вроде работает.

Всего несколько лет назад некоторые банкиры хвастались, что благодаря приложениям, люди проводят финансовые транзакции стоя в метро, теперь разрабы дают задачи агентам в тех же ситуациях.
Осталось добить инфру еще немного и для многих задач будет хватать телефона от идеи до деплоя.

*но некоторые старые задачи все так же мучительно долгие по инерции

В связи с этими агентами и желанием скинуть на них побольше работы и в параллель, давно назревают идеи и решения, вспомнить тот же n8n, как одну из попыток.

Я, как и многие, использовал md-файлы для сохранения поддержания актуального плана, контекста и описания, чтобы можно было в любой момент бросить и вернуться с новой моделью.

Но md-файлы это не совсем то, так и просится решение в виде тасок. И вот автор этой либы пришел к тому же выводу:
https://github.com/steveyegge/beads

Пытаюсь использовать, пока с переменным успехом. Opus 4.6 справляется, дешевые модели пытаются, но получается плохо: новые задачи не множатся, старые не закрываются, все делается отталкиваясь от твоего промпта или описания начальной задачи.

Было так, на новом сайте поймал новый прикол ☹️