Hello everyone!
In February this year, I discovered vibe coding.
Up until then:
- I couldn't write a single line of code.
- Even opening Terminal felt intimidating.
- Words like Docker, databases, or deployment seemed like something I'd never understand.
Six months later, I'm building software I never thought I'd be able to create and getting incredible satisfaction from the results:
- Applications across different languages and architectures;
- Projects with hundreds of thousands of lines of code;
- Tools that solve real problems I face every day.
I'm not here to tell you how to create a profitable app from a single prompt for an AI agent.
I'm here to share my journey, what I've learned so far, and everything I discover along the way.
It is important to remember: an AI agent is a very powerful weapon for coding, but if you don't watch where you are shooting this weapon and don't check the results of your shooting, your work is no different from a monkey handling an assault rifle
For example, when bringing the documentation up to date with an AI agent, if you approve everything without looking, there are two possible outcomes:
1. If you insist on a strict review - the agent will cut almost everything down to the bone, including a lot of important information.
2. If you set the task softly - the agent will not only leave a lot of junk, but will very likely add even more unnecessary content.
In both cases, the goal of the task for the agent will be fulfilled, which it will happily report to you.
For example, when bringing the documentation up to date with an AI agent, if you approve everything without looking, there are two possible outcomes:
1. If you insist on a strict review - the agent will cut almost everything down to the bone, including a lot of important information.
2. If you set the task softly - the agent will not only leave a lot of junk, but will very likely add even more unnecessary content.
In both cases, the goal of the task for the agent will be fulfilled, which it will happily report to you.
Make the agent give you information in small steps, in simple human language, in the following format:
What is it about, where is it being moved to, and why is it being deleted. Take action only after agreement and confirmation.
This format is important not only to avoid losing important records from the documentation, but also to remember about things that were postponed or forgotten.
Don't forget: the agent doesn't care about the quality and hygiene of your project - it simply follows instructions, goals, and quality criteria.
Which, by the way, it will happily bypass if they are stated abstractly.
AI agent is:
- either a workhorse that plows the field for a bountiful harvest.
- or an untamed stallion that will trample the entire field of crops.
Everyone trains the stallion in their own way, and those who manage to tame its temperament gain a loyal friend.
The evolution of a vibe coder lol
Day 1
“Wow... it really makes things when I just tell it to?”
Day 3
“Add login too.”
Week 1
“Handle the DB yourself too.”
Week 2
“Take care of deployment too.”
Month 1
“Why did you build it like this?
For now, don’t touch anything.”
Month 2
“Wait.
Before making changes, explain the cause first.”
Month 3
“No, don’t write code.
Answer my question first.”
And the final evolution
AI: “Would you like me to make the changes?”
Me: “No. Seriously, don’t do anything until I tell you to.”
At first, I coded everything myself because I didn’t trust AI.
These days, I’m stopping it because I’m worried it’ll work too hard lol
Make the agent give you information in small steps, in simple human language, in the following format:
What is it about, where is it being moved to, and why is it being deleted. Take action only after agreement and confirmation.
This format is important not only to avoid losing important records from the documentation, but also to remember about things that were postponed or forgotten.
Don't forget: the agent doesn't care about the quality and hygiene of your project - it simply follows instructions, goals, and quality criteria.
Which, by the way, it will happily bypass if they are stated abstractly.
I recommend doing documentation checks in separate sessions, requiring the AI agent to go through each group of documents, with the following requirements:
1. Check for accuracy:
The documentation matches the code.
2. Check for clutter:
Remove information that is not important to the current state of the project.
For example: outdated measurements, rejected decisions, implementation process, irrelevant leftovers, and other noise.
3. Check for duplication:
Check the documentation for repeated duplication across multiple documents.
Determine a single owner; delete the duplicates everywhere else.
Examples of an owner: current project state documentation, ADRs, comments, lessons, planned slices, tests, or any other forms of documentation you maintain.
I recommend doing documentation checks in separate sessions, requiring the AI agent to go through each group of documents, with the following requirements:
1. Check for accuracy:
The documentation matches the code.
2. Check for clutter:
Remove information that is not important to the current state of the project.
For example: outdated measurements, rejected decisions, implementation process, irrelevant leftovers, and other noise.
3. Check for duplication:
Check the documentation for repeated duplication across multiple documents.
Determine a single owner; delete the duplicates everywhere else.
Examples of an owner: current project state documentation, ADRs, comments, lessons, planned slices, tests, or any other forms of documentation you maintain.
And if you remind it to update the documentation too often, or incorrectly, for example: “Update the documentation.”
The problem will become much worse.
To the agent, this is a signal not to make your documentation better and more up to date, but a command to add things just for the sake of adding them - the agent will write even when nothing needs to be written, and write things that don't need to be written.
And if you remind it to update the documentation too often, or incorrectly, for example: “Update the documentation.”
The problem will become much worse.
To the agent, this is a signal not to make your documentation better and more up to date, but a command to add things just for the sake of adding them - the agent will write even when nothing needs to be written, and write things that don't need to be written.
If you use AI to maintain documentation in your projects, make sure to check it for accuracy and clutter at least once a month during active development.
Even if you remind the agent to update the documentation before every push - believe me, the problem will still be there.
If you use AI to maintain documentation in your projects, make sure to check it for accuracy and clutter at least once a month during active development.
Even if you remind the agent to update the documentation before every push - believe me, the problem will still be there.
How to enable this setting:
Make sure your version is 2.1.237 or later.
1. Through the terminal:
/config → Output style → Concise
The setting will apply only to the current project.
2. Through the settings.json file:
Add the following lines to your settings file:
{
"outputStyle": "Concise"
}
~/.claude/settings.json - applies to all your projects
.claude/settings.json - applies only to the current project (the settings file is committed and will be included in the repository)
.claude/settings.local.json - applies only to the current project (the settings file is not committed and is not included in the repository)
Changes take effect in a new session.
If you still haven't managed to solve Claude's verbosity problem, I have good news.
In the new version of Claude Code 2.1.237, the problem was solved at the system prompt level by adding a settings option: Concise.
This option does not affect the model, reasoning level, toolset, or anything else.
It only affects the response text, not how the work is performed.
The style applies only to the main dialogue and sub-agents launched with the session context. It does not apply to sub-agents launched with a clean context.
If your agent instructions contain things like:
"List all errors and warnings explicitly"
"Explain Changes: High-level summary at each step"
Or anything similar, be sure to check that the new response style mode does not cut them off.
If you still haven't managed to solve Claude's verbosity problem, I have good news.
In the new version of Claude Code 2.1.237, the problem was solved at the system prompt level by adding a settings option: Concise.
This option does not affect the model, reasoning level, toolset, or anything else.
It only affects the response text, not how the work is performed.
The style applies only to the main dialogue and sub-agents launched with the session context. It does not apply to sub-agents launched with a clean context.
If your agent instructions contain things like:
"List all errors and warnings explicitly"
"Explain Changes: High-level summary at each step"
Or anything similar, be sure to check that the new response style mode does not cut them off.
2. Responses are now longer by default.
Anthropic recommends adjusting this with model instructions.
If your Claude.md is very long, they recommend adding a brief reminder about response length near the end of the document, since the model may ignore the middle of a large prompt.
My recommendation: before changing anything, check whether your response length has actually changed. I already had instructions to keep responses concise, and they were enough to avoid any issues with response length after switching to Opus 5.
So, this is what I’m getting at 😀
A lot of time passed, and my bro Opus 5 and I were having fun as always (but that’s not certain) developing:
- Opus 5: Bro, I noticed a bug in the neighboring code while working - you have a dead zone on the table row when resizing. I didn’t fix it because of the rules, if you want, I can look into it?
- Me: I describe to him the exact same situation and the pain we went through fixing this bug.
- Opus 5: Bro, don’t worry, it’s nothing, an hour of work, I’ll do everything!
- Me (anticipating suffering): add a separate slice for the work in a new session, carefully study the lessons (we wrote several lessons there so that this fucking text would never crawl out of the cell again for the rest of its fucking life, that fucking bastard, goddamn it), carefully study the code, make sure the text incontinence bug in the cell won’t reproduce, double-check everything before writing the code.
- Opus5: (in a new session, 15 minutes later): Bro, check it, everything’s hOcKey!
Just casually fixed something that was still unattainable a few months ago.
This is one of the few examples that every vibe coder encounters over time. And examples like these are much more telling than any benchmark.
Luckily, the improvement in AI model capabilities is something we can see with the naked eye 😀
Here’s one of my personal examples:
In one of my projects, I’m implementing a table from scratch in pure Swift.
By the way, designing a table from scratch is one of the rare moments where I ran into problems while vibe coding and was stuck in place for more than a week.
Usually, everything happens quickly. Once, and that’s it. But don’t think I work that fast in bed as well 😀
Working with Opus 4.6, I ran into a serious problem - for a long time, I couldn’t get the text to sit still inside a table cell.
And after days of suffering, we finally solved this problem. But we fixed it through another bug:
The new bug was that manually resizing the height of a table row created a dead zone above and below the cell, leaving the cell size unchanged. And every attempt to fix this bug resulted in the text incontinence bug coming back.
At the same time, changing the row height caused by text wrapping worked well.
Considering how much time and effort had been invested (more than a week) I decided to simply disable manual row resizing. The feature wasn’t particularly popular.
With a sigh of relief, I continued developing the app.
Luckily, the improvement in AI model capabilities is something we can see with the naked eye 😀
Here’s one of my personal examples:
In one of my projects, I’m implementing a table from scratch in pure Swift.
By the way, designing a table from scratch is one of the rare moments where I ran into problems while vibe coding and was stuck in place for more than a week.
Usually, everything happens quickly. Once, and that’s it. But don’t think I work that fast in bed as well 😀
Working with Opus 4.6, I ran into a serious problem - for a long time, I couldn’t get the text to sit still inside a table cell.
And after days of suffering, we finally solved this problem. But we fixed it through another bug:
The new bug was that manually resizing the height of a table row created a dead zone above and below the cell, leaving the cell size unchanged. And every attempt to fix this bug resulted in the text incontinence bug coming back.
At the same time, changing the row height caused by text wrapping worked well.
Considering how much time and effort had been invested (more than a week) I decided to simply disable manual row resizing. The feature wasn’t particularly popular.
With a sigh of relief, I continued developing the app.
AI models are improving at an incredible pace. But:
Looking at benchmarks, we see numbers that are just slightly higher, while in practice a model can actually behave even worse.
On top of that, many benchmarks show progress in areas where we don’t use the model at all.
And who actually understands, on a deep level, how these benchmarks differ from each other?
The AI era didn’t give birth to vibe coders so they could figure out things they aren’t interested in - the result is what matters!
AI models are improving at an incredible pace. But:
Looking at benchmarks, we see numbers that are just slightly higher, while in practice a model can actually behave even worse.
On top of that, many benchmarks show progress in areas where we don’t use the model at all.
And who actually understands, on a deep level, how these benchmarks differ from each other?
The AI era didn’t give birth to vibe coders so they could figure out things they aren’t interested in - the result is what matters!
@Jadu100x Unfortunately, that’s much closer to the truth than what we’re being sold.
Despite all the possibilities vibe coding gives us, creating a good product still requires a lot of hard work and time. Especially when you’re a solo developer.
You can personally see what can be achieved with vibe coding with enough persistence and patience, while your game can actually make you money and receive positive reviews:
https://t.co/zPXhqBJQx3
But don’t believe the grifters on Twitter who show you how they created an AAA game with a single prompt, right after every new model is released.
Let them tell that to the developers of GTA VI, with its multi-billion-dollar budget.
Want to see a real example of someone creating a game solo without knowing how to code?
A quote from the game's creator: “A year of work, a year of sleepless nights, an exhausted body...”
By the time of release, 1,000 hours of actual work had gone into the product.
The game was released on Steam two weeks ago, and here’s the result:
$10,000+ in the first week of sales and mostly positive reviews on Steam.
This is a very good result for a vibe coder. But this definitely wasn’t a one prompt - it was hard, daily work.
Want to see a real example of someone creating a game solo without knowing how to code?
A quote from the game's creator: “A year of work, a year of sleepless nights, an exhausted body...”
By the time of release, 1,000 hours of actual work had gone into the product.
The game was released on Steam two weeks ago, and here’s the result:
$10,000+ in the first week of sales and mostly positive reviews on Steam.
This is a very good result for a vibe coder. But this definitely wasn’t a one prompt - it was hard, daily work.
Today, it's genuinely possible to build highly sophisticated apps with vibe coding - even apps as sophisticated as Netflix.
And it's possible even with older models, like Opus 4.6.
But to do that, you need to understand a huge number of things.
From architecture and the right infrastructure to marketing, evaluating whether users actually need your app, and whether it can compete with established companies. Not to mention building a vibe coding workflow that consistently helps you produce high-quality code.
Vibe coding has done something remarkable: today, building complex apps is accessible to everyone.
But it's definitely not a single prompt followed by a working product with people lining up to use it.
If you want to build a high-quality product instead of a Frankenstein that falls apart during use, it still takes a tremendous amount of time and effort - even with vibe coding.
8/🧵:
During the period I tracked, there were 148 to 286 such pumps per day.
After some time, they all go to zero.
The wallets are funded through chains of one-time wallets and are no longer used after the pump-and-dump scheme.
I traced some of the wallets. Their original funding comes from a Binance 2 wallet.
All I can hope is that this is done only to inflate activity and volume, and that there are no victims.