КайфКодинг

Когда тестируешь open source модель на русском языке

You Suck at "Vibe Coding" Because You Suck at Coding
Senior SWE here. I maintain systems doing millions monthly. I use Claude Code 90% of the time.

While you're complaining your for-loops are going nuts, I'm shipping 10x faster with better tests. The problem isn't vibe coding. The problem is you.

1. Your Prompts Are Garbage

"Fix my auth bug" isn't a prompt. It's a prayer. Tell the AI WHERE the problem is. Show the error. Explain what should happen. If you can't explain the problem clearly, that's on you.

2. Stop Using Autoaccept

Anyone using autoaccept deserves their bugs. READ EVERY LINE. Always. It's a suggestion, not gospel.

3. Less Code = Better Code

Saw Paul Graham praising some founder for generating 10k lines daily with AI. Good luck maintaining that mess. Good engineering means minimal changes. If your AI rewrites half your codebase for one feature, you're doing it wrong.

4. Fix Your Folder Structure

Your repo is a mess. That's why AI gets confused. Make it simple: feats/[feature-name]/[files]. If a human can't scan it quickly, neither can AI.

5. It's a Tool, Not Magic

"Vibe coding is bad" is like saying "knives are dangerous." Yeah, if you're an idiot with them. Learn to use the tool properly.

6. Use Voice for Prompts

Pro tip most of you miss: dictate your prompts. You give 3x more context speaking vs typing. I use writevoice.io (I built it). WillowVoice and Flow work too. When you speak, you naturally explain edge cases and assumptions you'd skip when typing.

7. Stop Mixing Features in One Chat

Long conversations about 3 different features confuse the AI. Change chats between features. If you tell AI "I ate strawberries and now I'm late for school, what's my salary?" it'll think you're a farmer. Context switching breaks AI just like it breaks humans. There's research on this.

8. Document Changes, But Keep It Short

Keep a log file. Write one-sentence updates after each feature/big change. That's it. These breadcrumbs save hours of explaining context later.

Stop blaming the tool. Start learning how to use it.

Как я выгляжу для своей команды разработки

У нас в InfluAI мощный анонс🔥

https://influai.world/v2/onboarding

Теперь вы можете взять свою фотку, ссылку на профиль и за один клик получить копию популярного тренда, но с вашим лицом и под тему вашего профиля♥️

Мою фотку на входе и результат на выходе можно прикрепила выше🔥

Никаких длинных онбордингов.

Жду ваших видосов. Первые бесплатно

Лайк, репост, обняли

Какие молодцы!

Как решать сложные проблемы не на вайбе

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

Но есть типы функционала, которые нам приходится реализовывать, и который при этом сетки часто пишут неверно с первого раза. Это деплой, многопоточность, мета-промптинг, нюансы авторизации, код из новых библиотек и т.д.

Мы не можем просто их "не решать", так как заменить их нечем, а что-то делать нужно.

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

1) Описываем баг. Либо сами (подробно), либо кормим Gemini 2.5 pro в AI студии логи работы вашего кода и просим сказать, что там не так. Она съедает до 1 млн контекста — идеально для анализа логов (я работаю в основном по логам, т.к. много бэкенда, фронтам нужно иначе).
2) Несем результат в Шотган и выбираем промпт "Find bug" — получаем потенциальный стектрейс проблемы.
2.1) Если она понятна и проста, то далее тащим результат тоже в шотган и применяем dev промпт. Затем полученный дифф интегрируем хоть руками хоть курсором.
2.2) Если непонятна, то отдельным промптом просим Find bug агента дать вам список файлов, которые имеют отношение к проблеме, это пригодится нам далее.

3) Что если проблема не пофиксилась с первого/второго раза. Короче говоря, творческая в плохом смысле.

Тогда нас будет выручать GPT-5

Его особенность в том, что ему нужно очень сурово препарировать контекст.

Итак, открываете ChatGPT 5-thinking модель и даете следующий промпт:

Я делаю таску [такую-то]. В процессе работы я наткнулся на баг. Он заключается в [копируем сюда вывод Gemini по логам]. 

Расскажи мне причины бага, и почему он возник. 

Прикладываю контекст

Архитектура
====
 {описание архитектуры которое я надеюсь вы делаете для своих тасок, шотган -> Architecture}. 
===

Необходимые файлы /собираем индексилкой, или просто шотганом, ШотганПро умеет это делать автоматически). Важно — не весь проект/ 
===
[список файлов и их кода]
===

Мнение тестировщика, но я не уверен что оно корректное/замечание про неуверенность важно, т.к. иначе модель зацепится за эти выводы, а т.к. баг не пофиксился легко, то очень часто они неверные/
====
[складываем отчет от Gemini]
====

GPT-5 выплюнет в вас достаточно сложными рассуждениями и кусками кода, которые вы плохо поймете. Но это не беда, потому что:

4) Тащим теперь это в шотган к dev агенту или в курсор. Тупо копируем и говорим

Я делаю таску [такую-то]. В процессе работы я наткнулся на баг. Он заключается в [копируем сюда вывод Gemini по логам] /короче то же что и GPT-5/

Вот предложение архитектора
====
[Пространный бред от GPT-5]
====

Верифицируй и реши задачу

И вот это уже с большой вероятностью сработает

А далее можно продолжать фигачить ваш курсорный или CC-шный вайб в промышленных объемах =)

В целом, секрет заключается в тщательном отборе контекста для моделей, с соблюдением двух принципиальных моментов
— Помнить, что модели не знают ничего за пределами их контекста
— Не подходить к ним с человеческими мерками. Модели уже умнее людей в ряде задач, и то что для вас "какой-то бред", для них валидный инпут, который не нуждается в пояснениях. Нужно уметь этот момент почувствовать.

Это мой способ. Пишите, если у вас есть свой, будет интересно почитать комментарии.

Andrew Ng об AI и разработке

Как я упомянул во вчерашнем посте, Andrew Ng вчера поделился своими мыслями про то, как AI меняет разработку —> ключевые тезисы:
1) в AI Fund они заметили, что сильным предиктором успеха инновационного проекта является скорость, с которой команда двигается (execution speed)

2) Именно эту ценность дает AI в разработке новых продуктов: если его достаточно тяжело использовать в существующих продкшн проектах и выигрыш c натяжкой может дать 30-50% в сокращении скорости разработки, то для разработки прототипов ускорение в 10 раз. Именно для этого и надо использовать AI

3) Код больше не является таким ценным артефактом разработки, как был раньше. Более того, возможно даже и архитектура таковой не является. Его словами:

"Even choosing the architecture for an application is closer to a 2-way than a 1-way door"

с намеком на критерий сложности решений Безоса

4) Какими навыками должен обладать AI Engineer, по его мнению? 3 блока:
- навыки написания кода с помощью AI (ai assisted coding)
- понимание ключевых блоков AI разработки: промпты, RAG, агенты, эвалы, MCP, voice. Мне было важно узнать, что темы курса AI Product Engineer хорошо соотносятся с этим
- понимание full stack, архитектуры, базовых навыков продакт-менеджмента и дизайна

Эндрю подчеркнул, что они работают со многими компаниями из Fortune 500 и не хватает именно таких спецов. И как ему обидно, что выпускники Computer Science зачастую не знакомы с этими блоками выше.

5) И ключевая мысль: что раньше узкое место в разработке продуктов было именно написание кода, сейчас же оно смещается в product management: сбор фидбека и взаимодействие с пользователями/клиентами. Я, разумеется, спросил его про virtual user boards и сможет ли AI расшить и это узкое место —> он согласился, что много интересного ресерча делается в этом направлении, но отметил, что для b2b продуктов зачастую данные об их пользователях отсутствуют в интернет, поэтому LLM не очень хорошо могут "воспроизводить" такие персоны. Тем не менее, это безусловно перспективная тема и он следит за тем, что происходит тут.

В целом, я не устану повторять, что то, что Andrew говорил лет 6-7 назад становится мейнстримом через 3-4 года - например, про AI как электричество (см. посты 1, 2, 3 от 2017-2019), поэтому я очень рекомендую прислушаться к этим мыслям, даже если они пока кажутся "шарлатанскими". И посмотрите обязательно это видео 8-летней давности

В аттаче слайды с моего пересказа этого выступления на сессии AI Product Engineer сегодня.

Настроил разработку с помощью агентов

Каждый из них имеет задание инструкции, tools.

Каждый пишет отчет. Его отчет проверяется.

Иногда конечно бывает - fix it.


Но все равно - уже вышел на другой уровень

Завайкодил сегодня.

Превращаем любой магазин в тикток