Теперь хочу написать почему Python это ХУДШИЙ выбор для вайбкодинга
ОН ОЧЕНЬ СЛОЖНЫЙ
Нет, ну это серьёзно

В нём из коробки встроена динамическая типизация (И это не только Any тип)
Ну там просто всё построено на Dict
Ещё есть уйму других конструкций которые можно юзать для динамической типизации: cast(), hasattr, astibute
Это ужасно и это даже статическими анализаторами сложно закрыть

Но ок синтаксические конструкции
На питоне 99% дата сета написано с помощью динамической типизации
Он просто всегда будет пытаться генерировать динамически типизированный код
Это постоянные ошибки, которые приводят к циклической зависимости (Постоянно удаляет динамическую типизацию и добавляет)
Ещё на питоне ОЧЕНЬ большое количество библиотек с динамической типизацией

Так же линтер не очень хороший у питона
Сложно питон прувать

Ну и отображение ошибок у питона тоже не очень
Вот пример качественных ошибок: https://news.1rj.ru/str/ProverCoderAI/9 (Это Rust cтиль ошибок. Кстати прикольно его ещё реализовали в языке Gleam)
Это стиль ошибок, когда ошибка говорит как себя исправить

Всё это приводит к долгой обратной связи и БОЛЬШОЙ ЧЕЛОВЕЧЕСКОЙ РАБОТЕ

Чуть позже напишу мысли про Rust, Gleam и функциональные языки программирования (Почему за ними будущее для вайбкодинга)
Так же возможно затрону TypeScript и C#

До этого я упоминал "jscpd" для поиска дублей внутри кодовой базы

Тула прикольная, ищет базовые дубли кода

Но какую частую проблему совершает ИИ или люди?
У нас есть кучу подключённых библиотек, но мы всё равно часто дублируем функции и пишем их с нуля (Т.к иногда даже не знаем что такое уже есть)
Хочу сделать тулинг для поиска дублей в коде исходя из библиотек
Что если мы дублируем логику то получаем ошибку и заставляем использовать библиотечные функции

Пока у меня нет чёткого плана как я хочу это сделать, но есть идеи:
С помощью векторов искать схожесть по коду и проверять input и output параметры
Типо если сигнатура функции совпадает на 100% и векторный поиск показывает близкий вектор скорее всего это дубль (Но это ещё надо поресёрчить)

Так же поискать полностью 1 в 1 написанные дубли

В комментарии к этому посту буду кидать видео/статьи связанные с дублями кода

Я думаю, что для вайб кодеров точно так же могут быть грейды:
Train, Junior, Middle, Senior

Train/Junior это такая база 99% типов, кто трогает ИИ для кодинга
Они ничего особо не знают, просто умеют тыкать промты

И думаю надо различать Train от Junior тем что Джуниор это умеет делать качественнее
Возможно Джуниор чуть чуть понимает программирование или чуть лучше шарит в управление программистами

Но вот если мы хотим стать профессиональным вайбкодером надо начать изучать CS
Тут начинается понимание компиляторов, статический/динамический анализ кода
Лучшие практики архитектуры кода
Настройка CI/CD (всякие девопс навыки)

Почему так?
Чем это отличается от обычных программистов?
Тем что ты не пишешь код
Ты занимаешься только валидацией согласно идеи и настаиваешь конфиги (да даж конфиги может ИИ настраивать, но тебе важно что бы эти конфиги ты понимал. И все было согласно нужной тебе архитектуре)

Middle вайбкодеру я бы приписал понимать: настройка анализаторов, CI/CD
Чуть чуть понимание в архитектуру проекта

А вот Senior это тот чел, который шарит за компиляторы
Статический/динамический анализ кода
Может решить любую проблему с которой столкнется ИИ (реализовать под это тулинг)

Так же жду ваших мыслей в комментарии

До этого упоминал про проблемы Lovable

Теперь хочу написать про прикольную вещь, которую они реализовали для фронтенда ( lovable-tagger )

В чём его суть?
Это vite плагин который добавляет во фронтенд мета информацию об вашем React коде

Сразу видно в сбилженом HTML коде к какой части React кода он относится

<a data-lov-id="src/pages/IndexPage/IndexPage.tsx:36:10" data-lov-name="Link" data-component-path="src/pages/IndexPage/IndexPage.tsx" data-component-line="36" data-component-file="IndexPage.tsx" data-component-name="Link" data-component-content="%7B%7D" class="link" href="#/theme-params"><div class="tgui-b5d680db78c4cc2e tgui-b8dfba0b5c3d054c" data-lov-id="src/pages/IndexPage/IndexPage.tsx:37:12" data-lov-name="Cell" data-component-

Подключается он в vite.config.ts

import { componentTagger } from "lovable-tagger";

export default defineConfig(({ mode }) => {
  const plugins = [
mode === 'development' && componentTagger()
  ].filter(Boolean) as PluginOption[];
}

Оказывается такое представление не является информативным

Я уже давно заметил, что LLMка по своему желанию обрезает мусорный результат оставляя только ошибку (приложил пример на изображении)

Сейчас я думаю как лучше сделать отображение "мета" информации для ошибок, что бы они имели максимальную полезность

Скоро напишу об этом пост тоже

Если у кого-то есть свои идеи как по их мнению должна выглядеть такая система пишите в комментарии

Нашёл интересную тулу TypeStat
На изображении приложил то что она делает

Если кратко то проходит по коду и там где тип "any" то он просто его убирает пытаясь описать тип исходя из дерева кода

-  createdAt: string;
+  createdAt: string | string | number | Date | string | number | Date;

-function KnowledgeCard({ item, query }: { item: SearchKnowledge; query: string }) {
+function KnowledgeCard({ item, query }: { item: SearchKnowledge | string; query: string key?: string;
+}) 

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

Особенно что бы фиксить многие баги от LLM

Типо можно применять что бы тула сперва сгенерировала типы, а потом LLMку улучшить читаемость кода
И она уберёт эти большие типы перечисленные через "|"

Единственный минус: долго работает (пару минут) из-за этого на каждом изменении кода не прогонишь её

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

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

Использую я библиотеку 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://news.1rj.ru/str/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://news.1rj.ru/str/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 для удобной работы, напишу об этом в другом посте (это про выстраивания удобной архитектурны проекта)

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