Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
ProverCoderAI
Kanalga Telegram’da o‘tish
Ko'proq ko'rsatish
Mamlakat belgilanmaganToif belgilanmagan
416
Obunachilar
+524 soatlar
+137 kunlar
+10930 kunlar
Postlar arxiv
+1
Давал LLMке таску "Мол удали кое что"
И моё ТЗ оказывается было написано изначально не очень верно
Тем самым он удалил то чего я не хотел (А я заметил это только через пару часов. Когда уже закрыл все старые чаты)
А я уже даже об этом не помнил
В итоге спрашиваю у него куда это пропало
И он мне даёт цитату из моего ТЗ где я попросил удалить секцию "настройки" (промт тут)
Тем самым я имею полный контекст о проблеме
Почему она произошла
Из-за чего
Я считаю, что таких пометок в кодовой базе должно быть больше
Возможно даже стоит указывать дополнительную мета информацию автоматически:
Текущий хеш коммита при изменении
Ссылку на полный диалог обсуждения проблемы
Ссылку на Issues и описание Issues
Ссылку на Pull Request
Тогда LLMка будет понимать от и до как работает ваш проект
Почему было то или иное изменение
Вам так же сложнее будет запутатья
Прикол
Тут человек рассказывает буквально всё то про что я топлю
Говорит, что язык "verse" будет мультипарадигменный с упором на функциональщину
То что если компилятор говорит что код работает значит он и правду должен работать
Упоминал он так же AI и говорил, что AI пишет примерно рабочий код, который запускается, но имеет баги, а вот если бы компилятор сказал что код не работает то ИИ его бы исправило
Они делают язык для Unreal Engine
https://www.youtube.com/watch?v=WmSNTIqGuTM
На счёт архитектуры, которой я пока пытаюсь придерживаться:
Пишу я более функциональной парадигме
Почему решил выбрать такую?
Из-за преимуществ простоты тестирования кода: Иммутабельность, персистентность, ссылочная прозрачность, функциональная чистота
Всё это позволяет создать меньше итоговых инвариантов, которые в будущем надо будет протестировать
Использую я библиотеку 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://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://t.me/ProverCoderAI/2)
Нашёл интересную тулу 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ку улучшить читаемость кода
И она уберёт эти большие типы перечисленные через "|"
Единственный минус: долго работает (пару минут) из-за этого на каждом изменении кода не прогонишь её
Оказывается такое представление не является информативным
Я уже давно заметил, что LLMка по своему желанию обрезает мусорный результат оставляя только ошибку (приложил пример на изображении)
Сейчас я думаю как лучше сделать отображение "мета" информации для ошибок, что бы они имели максимальную полезность
Скоро напишу об этом пост тоже
Если у кого-то есть свои идеи как по их мнению должна выглядеть такая система пишите в комментарии
До этого упоминал про проблемы 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-import { componentTagger } from "lovable-tagger";
export default defineConfig(({ mode }) => {
const plugins = [
mode === 'development' && componentTagger()
].filter(Boolean) as PluginOption[];
}Я думаю, что для вайб кодеров точно так же могут быть грейды:
Train, Junior, Middle, Senior
Train/Junior это такая база 99% типов, кто трогает ИИ для кодинга
Они ничего особо не знают, просто умеют тыкать промты
И думаю надо различать Train от Junior тем что Джуниор это умеет делать качественнее
Возможно Джуниор чуть чуть понимает программирование или чуть лучше шарит в управление программистами
Но вот если мы хотим стать профессиональным вайбкодером надо начать изучать CS
Тут начинается понимание компиляторов, статический/динамический анализ кода
Лучшие практики архитектуры кода
Настройка CI/CD (всякие девопс навыки)
Почему так?
Чем это отличается от обычных программистов?
Тем что ты не пишешь код
Ты занимаешься только валидацией согласно идеи и настаиваешь конфиги (да даж конфиги может ИИ настраивать, но тебе важно что бы эти конфиги ты понимал. И все было согласно нужной тебе архитектуре)
Middle вайбкодеру я бы приписал понимать: настройка анализаторов, CI/CD
Чуть чуть понимание в архитектуру проекта
А вот Senior это тот чел, который шарит за компиляторы
Статический/динамический анализ кода
Может решить любую проблему с которой столкнется ИИ (реализовать под это тулинг)
Так же жду ваших мыслей в комментарии
До этого я упоминал "jscpd" для поиска дублей внутри кодовой базы
Тула прикольная, ищет базовые дубли кода
Но какую частую проблему совершает ИИ или люди?
У нас есть кучу подключённых библиотек, но мы всё равно часто дублируем функции и пишем их с нуля (Т.к иногда даже не знаем что такое уже есть)
Хочу сделать тулинг для поиска дублей в коде исходя из библиотек
Что если мы дублируем логику то получаем ошибку и заставляем использовать библиотечные функции
Пока у меня нет чёткого плана как я хочу это сделать, но есть идеи:
С помощью векторов искать схожесть по коду и проверять input и output параметры
Типо если сигнатура функции совпадает на 100% и векторный поиск показывает близкий вектор скорее всего это дубль (Но это ещё надо поресёрчить)
Так же поискать полностью 1 в 1 написанные дубли
В комментарии к этому посту буду кидать видео/статьи связанные с дублями кода
Теперь хочу написать почему Python это ХУДШИЙ выбор для вайбкодинга
ОН ОЧЕНЬ СЛОЖНЫЙ
Нет, ну это серьёзно
В нём из коробки встроена динамическая типизация (И это не только Any тип)
Ну там просто всё построено на Dict
Ещё есть уйму других конструкций которые можно юзать для динамической типизации: cast(), hasattr, astibute
Это ужасно и это даже статическими анализаторами сложно закрыть
Но ок синтаксические конструкции
На питоне 99% дата сета написано с помощью динамической типизации
Он просто всегда будет пытаться генерировать динамически типизированный код
Это постоянные ошибки, которые приводят к циклической зависимости (Постоянно удаляет динамическую типизацию и добавляет)
Ещё на питоне ОЧЕНЬ большое количество библиотек с динамической типизацией
Так же линтер не очень хороший у питона
Сложно питон прувать
Ну и отображение ошибок у питона тоже не очень
Вот пример качественных ошибок: https://t.me/ProverCoderAI/9 (Это Rust cтиль ошибок. Кстати прикольно его ещё реализовали в языке Gleam)
Это стиль ошибок, когда ошибка говорит как себя исправить
Всё это приводит к долгой обратной связи и БОЛЬШОЙ ЧЕЛОВЕЧЕСКОЙ РАБОТЕ
Чуть позже напишу мысли про Rust, Gleam и функциональные языки программирования (Почему за ними будущее для вайбкодинга)
Так же возможно затрону TypeScript и C#
Хочу так же поделиться своим промтом, который я использую для кодинга
Этот промт у меня под любую 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 */
Есть ещё интересный тулинг (который не до конца доделан) это продвинутые логи
Я отображаю стек вызовов (последние 5) лога
Тем самым его можно скормить LLM что бы он мог верифицировать соответствует ли ваш код вашему ТЗ (Ну или найти багу в коде)
Хотел я ещё вывести стек значений, но там пока сложнее
В питоне например с этим всё в разы проще
В питоне можно из коробки и стек значений и стек вызовов выводить
Это наверное единственный плюс питона
Во всём остальном питон для ИИ кодинга это худший выбор (Об этом тоже будет)
Если кто-то задался вопросом что эт за ошибка то такая с контекстом
Это мой 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
Сейчас я разрабатываю 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/typescript.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 ===========================
Это единственный проект такой в своём роде для вайбкодинга
Есть один конкурент, но они занимаются анализаторами ток
+1
Вот самый базовый пример
Попросил Lovable cделать мне тапалку
И разумеется, что ж мы получим в коде?
Они специально отключают везде какую либо проверку на "any"
"noImplicitAny": false,А "any" создаёт билиберду в коде Никто из них не пытается использовать хоть какие-то линтеры А Lovable каждый день генерирует людям кучу проектов И создаёт впечатление того, что вайбкодинг это через 10 лет, а не настоящее Позор таким платформам Много раз пытался связаться с их разработчиками и предлагал помощь, что бы улучшить их продукт ВЕРДИКТ: В большинстве случаев, когда вайбкод не работает это проблема не в LLM а в халатности разработчиков, которые не хотят прувать код
В чём суть канала?
Я буду постить кучу спама (по теме) о том, как прувать вайбкод
Будет КУЧУ КУЧУ разных мыслей
КУЧУ КУЧУ разных идей
Видосики буду скидывать, которые мотивируют на определённые идеи
В общем что стоит ожидать?
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
