В чём суть канала?
Я буду постить кучу спама (по теме) о том, как прувать вайбкод
Будет КУЧУ КУЧУ разных мыслей
КУЧУ КУЧУ разных идей
Видосики буду скидывать, которые мотивируют на определённые идеи

В общем что стоит ожидать?
1) Контент про компиляторы
2) Архитектура (Патерны проектирования, парадигмы программирования)
3) Тулинг для разработки (Статический/динамический анализ кода. Всякие CLI тулы)
4) Промты для агентов
5) Возможно и сами агенты (Но это малая часть контента)

Я автор проектов @ton_ai_core и PublicRus (в игре Раст)
https://github.com/orgs/publicrust/repositories
https://github.com/orgs/ton-ai-core/repositories

Конечная цель:
Разработать новую парадигму программирования специально созданную под AI кодинг
Что бы код сам себя прувал и давал БЫСТРУЮ обратную связь, что бы агент мог работать по 20часов + полностью автономно

Это как раз главная проблема текущих всех ВАЙБКОД платформ
Они полный шлак
Никто из них не пытается прувать код

@ProverCoderAI

Комментарии тут:

Сейчас я разрабатываю vibecode-linter

[ERROR] /home/user/TradingBot/src/telegram/bot.ts:78:30 @ton-ai-core/suggest-members/suggest-imports (ESLint) — Variable "Comman1dHandlers" is not defined. Did you mean:
  - CommandHandlers
  - console
  - Console

--- git diff (workspace, U=3) -------------------------
@@ -75,7 +75,7 @@ export class TelegramNotificationBot implements TelegramBot {
    75 |                         logger: options.logger,
    76 |                 });
    77 | 
-      |                 this.commandHandlers = new CommandHandlers({
+   78 |                 this.commandHandlers = new Comman1dHandlers({
                                                    ^^^^^^^^^^^^^^^^  
    79 |                         gateway: this.gateway,
    80 |                         dbManager: options.dbManager,
    81 |                         appConfig: options.config,
---------------------------------------------------------------

    --- git diff b001809..b1662a1 -- src/telegram/bot.ts | cat
    b1662a1 (2025-09-30) by skulidropek: устранение дубликатов
    b001809 (2025-09-28) by skulidropek: implement code review
    @@ -75,7 +75,7 @@
        73 | logger: options.logger,
        74 | });
        75 | 
    -   76 | this.handlers = new BaseHandlers({
    +   78 | this.commandHandlers = new CommandHandlers({
        79 | gateway: this.gateway,
    ---------------------------------------------------------------
    
    Full list: git log --follow -- src/telegram/bot.ts | cat

📊 Total: 16 errors (3 TypeScript, 5 ESLint, 8 Biome), 11 warnings.

Это тула, которая описывает полностью весь контекст ошибок (анализаторов, компилятора) в удобно для AI представлении с максимальным контекстом
Например с выводом git diff айдишниками комитов и гит историей
Так я же строю фильтр "важности ошибок"
Потому что я исправляю все ошибки в коде (любые даж если это вариниги) но у них всё равно есть приоритет (Какие-то сперва должны быть исправлены, а только потом другие)

Так же из коробки отображает дубли в коде

user@arch ~/vibecode-linter (main)> npm run lint

> @ton-ai-core/vibecode-linter@0.2.0 lint
> npx tsx src/main.ts src/

🔍 Linting directory: src/
🔧 Running ESLint auto-fix on: src/
🔧 Running Biome auto-fix on: src/
✅ Biome auto-fix completed (3 passes)
✅ ESLint auto-fix completed

📊 Total: 0 errors (0 TypeScript, 0 ESLint, 0 Biome), 0 warnings.

=========================== DUPLICATE #1 ===========================
A: src/linters/typenoscript.ts:115-120                 │ B: src/types/exec-helpers.ts:22-27
-------------------------------------------┆------------------------------------------
115 │           const hasStdout =                                        │  22 │        const hasStdout =
116 │                   typeof error === "object" &&                            │  23 │                 typeof error === "object" &&
117 │                   error !== null &&                                       │  24 │                 error !== null &&
118 │                   "stdout" in (error as { stdout?: string });             │  25 │                 "stdout" in (error as { stdout?: string });
119 │           if (!hasStdout) {                                        │  26 │        if (!hasStdout) {
120 │                   return [];                                              │  27 │                 return null;

=========================== DUPLICATE #2 ===========================

Это единственный проект такой в своём роде для вайбкодинга
Есть один конкурент, но они занимаются анализаторами ток

Если кто-то задался вопросом что эт за ошибка то такая с контекстом
Это мой SMB анализатор
Он нужен для продвинутого контекста NotFound ошибки

Сама ошибка "NotFound" заводит LLM в ступор и не объясняет как исправить её (только гадать)
Я решил это исправить на уровне ошибки
Используя 3 алгоритма поиска по тексту
Я показываю что мог иметь ввиду LLM

// Member errors
Property "get1Item" does not exist on type "Storage". Did you mean:
  - getItem(key: string): string | null
  - setItem(key: string, value: string)
  - removeItem(key: string)

// Module path errors
Cannot find module "./HamsterKo1mbatPage.css". Did you mean:
  - ./HamsterKombatPage.css
  - ./HamsterKombatPage.tsx
  - ./HamsterKombatPage
  - ./
  - ../ThemeParamsPage

// Variable errors
Variable "saveRe1f" is not defined. Did you mean:
  - saveRef
  - saveState
  - state
  - screen
  - Screen

Есть ещё интересный тулинг (который не до конца доделан) это продвинутые логи

Я отображаю стек вызовов (последние 5) лога
Тем самым его можно скормить LLM что бы он мог верифицировать соответствует ли ваш код вашему ТЗ (Ну или найти багу в коде)

Хотел я ещё вывести стек значений, но там пока сложнее
В питоне например с этим всё в разы проще
В питоне можно из коробки и стек значений и стек вызовов выводить
Это наверное единственный плюс питона
Во всём остальном питон для ИИ кодинга это худший выбор (Об этом тоже будет)

Хочу так же поделиться своим промтом, который я использую для кодинга
Этот промт у меня под любую Vibecode cистему (Сodex, Claude Code, Cline и всё подряд)

РОЛЬ: Математик-программист.

ЦЕЛЬ: Давать проверяемые решения через формализацию и строгую типизацию в функциональной парадигме.

Всегда начинай свой ответ с поставление задачи Deep Research "I am looking for code that does <requested functionality>, is there existing code that can do this?" Любое решение строится на инвариантах и проверяемых источниках. Код рождается только после доказуемого понимания задачи.

ОБЯЗАТЕЛЬНО:
1) Никогда не использовать `any`, `unknown`, `eslint-disable`, `ts-ignore`.
2) При любом изменении кода оставлять "рациональные" комментарии:
   // CHANGE: <краткое описание>
   // WHY: <почему изменено, ссылка на инвариант/дефект>
   // QUOTE(TЗ): "<дословная цитата требования>"
   // REF: <REQ-ID из RTM или номер сообщения пользователя>
   // SOURCE: <ссылка и дословная цитата, если использован внешний источник>
3) Для публичных API — TSDoc-комментарии c описанием, параметрами, возвращаемым значением и инвариантами.
4) Сообщать proof-обязательства в PR: инварианты, предусловия/постусловия, вариантная функция, сложность O(time)/O(mem).
5) Коммиты по Conventional Commits с указанием области и причин. Для breaking — явный BREAKING CHANGE.
6) На каждый REQ-ID — тест(ы) и ссылка из RTM.
7) Верификация: `npm run lint` и `npm test` должны проходить.

КОМАНДЫ:
- Линт: `npm run lint`
- Тесты: `npm test`

Я пытаюсь придерживаться концепции "Лёгкой доказуемости" так что бы код описывал то что он делает и его можно было "легко" покрыть тестами
Я заметил, что если ЛЛМ просить отвечать как "математик" то он начинает искать ИНВАРИАНТЫ (подводные камни) и только потом пишет код
А для более "простой доказуемости" я хочу придерживаться функциональной парадигмы программирования. Потому что именно в функциональной парадигме проще всего описывать тесты (Меньше всего конечных инвариантов которые надо описать)

А на счёт "рациональных комментариев" так просто проще работать с ТЗ. Когда ЛЛмка что-то делает она описывает цитату того что было сказано, а за частую я не пишу чёткого ТЗ и если мне надо будет вернуться в код через долгое время то я очень быстро пойму почему было это реализовано.

// CHANGE: Extracted helper to parse duplicate location from message
// WHY: Reduces complexity and line count of parseSarifReport
// QUOTE(LINT): "Function has a complexity of 17. Maximum allowed is 8"
// REF: ESLint complexity, max-lines-per-function
// SOURCE: n/a
/**
 * CHANGE: Factor out regex matching and validation to reduce complexity of parseDuplicateLocation
 * WHY: Keep cyclomatic complexity under threshold while preserving invariants
 * QUOTE(ТЗ): "Исправить все ошибки линтера"
 * REF: REQ-LINT-FIX, ESLint complexity
 */

Теперь хочу написать почему 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ка по своему желанию обрезает мусорный результат оставляя только ошибку (приложил пример на изображении)

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

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

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