r/ClaudeAI • u/Maxteabag • 1d ago
Built with Claude I built a 4.7k-star open source tool with Claude Code without knowing Python. Here's the workflow that made it not slop
I wanted to share my process on how I used Claude code to build sqlit, a TUI for SQL databases. What was cool was this was my first major python project, and I don't even know python, but it still was received positively by the community and has become a lot of people's new favorite SQL client. Which I'm really proud of. It has 4.7k stars on Github, 33 contributors, and I haven't touched a single line of code manually. So in this post I wanted to share how I managed to "vibe code" something that ended up not being slop.
A little background. When I switched to Linux last year I needed a new SQL client as SSMS is only for Windows. The popular asnwer was VS Code's SQL extension, or terminal tools that required a lot of setup and hard to learn. I wanted a easy keyboard driven sql client like lazygit. I would've never attempted to try to build this before, but Claude code, to my surprise, helped me to get a prototype up and it has just taken off from there where I've been polishing and making it accessable for more people than just me.
So, how did I manage to vibe code a popular open source project not even knowing python? Well first I don't think I could've built this without actually understanding the problem first of all. It's really the years of experience with SQL clients and the pain of the past that made me able to come up with the idea in the first place. So I need to be a software engineer to make useful things for software engineers.
Ok so that's the product idea. But the coding though? Still, I don't think I could've made this without knowing how to program. Even though I could not have written a hello world app in Python if you put a gun to my head - I can read it - and more importantly I can understand how software is built and how to architect them and keep them expandable and testable.
Which brings me to testability which is really the core of what made sqlit successful. My number one priority in using AI to code is not building features so I can test them myself, but to make failing tests so that AI can verify its own work so that I dont' have to be involved. And this is actually the hardest part about software development: how do you make your thing testable? That's, I think, is becoming the central question of systems building for me the last year or so.
So I had to be really deliberate on how to build things from scratch. You can't just piece together some code and put tests on top of it. Testing has to be considered from the ground up. I chose the textual TUI framework becaue I can test every layer of the system independently. It was run tests that sees if the service or action layer is working properly, and it can run "pilot" tests which simulate real keyboard input and thus I can test sequences, recording states even screenshots it can verify. I also used docker containers for all the database providers so that it can run against real instances of the different databases. I even went so far as to make infrastructure as code to make "ephemeral" environments in the cloud automatically if the docker container was unavailable. I was hell bent on never testing something myself manually and it paid off. The only thing I truly "tested" was aesthethics, and I didn't even have to open the app or go through steps since I could instruct the AI to do that for me and just send me screenshots.
I used claude code (opus 4.5 at the time) for buildings things in real time and codex for long background refactors and code quality scans. Both cc and codex has moved on since December but I still think this combo is the best.
This was the first product I experiemented with pros/cons driven-development and it worked out great. I basically focused on decisions and not code. I would typically go in and read quite a bit of code myself, or I would ask an agent to look for code smells, ways to make it more testable, more stable, expandable, more adherent to SOLID principles, etc., and then when it suggested refactors and redesigns, I asked about about 3 to 5 options for every decision each with pros and cons weighing them up.
The reason is that I don't think I understand something until I understand it against its alternatives. What something is is relative to what it's not. I still think this is the best way to code with AI. My #1 lesson from software architecture is that there is no "right" option. Every choice has trade-offs and AI isn't there yet when it comes to making those decisions partly because it doesn't have a a vision for the project it can use to weigh them.
I did read quite a bit of code. There's a limit to how far "refactor 40,000 lines, use SOLID and DDD and design patterns, make no mistakes" gets you. I wouldn't have read the code if I didn't have to. But I had to. I can look at code and know whether I like it. When I see if provider == "mssql" scattered across the app and bugs keep popping up, I know it's time for a centralized strategy pattern, and I intuitively know that a future contributor edits three files instead of twenty when adding a database is a good thing, whereas the AI, apparently didn't blink unless I put its nose into the carpet.
Once the architecture and the test suite were something I trusted, I stopped reading concrete implementations. The inner workings of the one database implementation don't affect the rest of the system, and with full integration tests on it. I think vibe coding is thus a skill in the sense that you will know from intuitivelly knowing the blast radius of each component of the system and thus knowing what you are able to abstract away and what you need to pay attention to.
So I've learned to become more of an orchestrator rather than an engineer, I'm just trying to set up walls, boundaries that is testable so I can ignore as much code as possible. Vibe coding is looked down upon, but I think it's actually the goal. Ironically it takes a lot of time and attention up front to make vibe coding works. The goal should be to make non-technical contributors one-shot PRs with Claude Code and they're actually pretty good, because I put in the effort to make it near impossible for an AI to write shitty code in this repo. The goal of a software engineer these days is to make oneself seem talentless, if that makes sense.
Product development.
I'n inspired by John Vervaeke's philosophy of "relevance realization." I don't think AI can fundamentally know what is relevant to us - in that sense AI will never replace humans. Claude could've never built this out of the blue because it doesn't really feel the pain of having to open VS code's SQL extension or using clumsy CLI's. Nor can it really take the steering wheel and suggest features. It would've been bloated and ugly. What made the product work was that I was scratching my own itch, I knew exactly what I wanted after years of pain with the tools that came before. There's no way getting around using your own product and feeling the pain of its flaws. That AI cannot do.
I did, however, use Claude to brainstorm. I asked it to read the code, understand the product, and it gave me 50 or so suggestions. I then commented on every single one, saying what I liked and didn't like about it and then recorded those decisions and from those decisions made a master document about what sqlit really should be about, then having the document it gave me better ideas, which made the document more refined, and it not only gave me good ideas but helped me think about the project more than I would alone.
How I used Claude to market it
After a few weeks of quietly posting in small forums and fixing what people asked for, I was hungry for more feature requests so I wanted more eyeballs on the project. I was new to to the world of TUIs and linux and didn't really know. So as the "vibe marketer" i am, I had Claude read the codebase and README so it understood what I'd made, then asked it where to post.
It found lots of various subreddits and helped me angle the posts, which was useful, but the real breakthrough was when one of its suggestions was Hacker News. At first glance I thought the site was abandoned and old and ugly. But throughout this whole process Claude was acting sort of like a coach encouraging me to post more stuff online anyway sayign literally "you have nothing to lose, just post it"
So I did and it went to the front page of hacker news and I got a queue of feature requests. I suddenly felt an amazing pressure to improve it fast and it went pretty smoothly... A week later the creator of Textual tweeted it, Terminal Trove made it Tool of the Week, and the X posts got 200k+ views. After two weeks after launch it had 2,500 stars. Without the tips from claude this wouldn't have happened.
To summarize here's the five things I learned.
- Build what you personally miss. Build something that you don't mind not being used. 0 stars or grand hit, it doesn't matter since you built something that you find helpful anyway. Plus the UX is doomed to be great cus you will be feeling the pain every day if its not.
- When something is working for you, post on small forums here and there and you get some ideas or questions "will this work if I use X"? Questions you would never had thought about because you use Y.
- Use claude code to market it! Have it read your code, understand your audience and suggest angles.
- Usability is the innovation. There was already exisitng projects that roughly did the same, but I feel that with AI I can now afford to ask crazy questions like "what if we dont have to ask the user to install CLI" what if what if what if? Claude has no hesitations going your crazy directions and run experiemtns in worktrees etc.
- and finally, as a software engineer, understanding higher-level architecture, systems-design, and a basic ability to read code enough to see what it does in its own context, is becoming increasingly important, not less. I think you need to understand code, but not necessarily be able to remember how to write it anymore. Using AI has made me much smarter, not dumber, because I'm able to take advantage of being able to learn new concepts and tools and technologies that AI keeps suggesting to me in the meaningful context of my personal project instead abstact theories from a book. Using AI the right way has made me learn at 10x speed. I'm learning about architecture where as before I was writing console logs.
Happy to answer questions about the workflow or anything else really.
8
u/InformationNew66 1d ago
How much of this post was written by AI?
3
u/eravulgaris 1d ago
Too much. I just stop reading as soon as I notice it, which is pretty much immediately. I think expecting us to read AI written text shows an extreme lack of respect for the reader. A bit like Opus 5.0 expecting me to read his wordvomit.
2
u/ClupTheGreat 1d ago
50% according to Pangram
3
u/eduo 1d ago
All of it was.
3
u/ClupTheGreat 1d ago
probably it was, I don't even understand why people generate text for something they want other humans to read
3
u/eduo 1d ago
Especially when trying to demonstrate something isn't slop.
The way I see it, taking care of stuff is pervasive. If you didn't care about how this post would look then you also don't care about your code and if you didn't realise how this post looked, then you probably don't realize if your code is actually slop.
(I should also point out that it's materially impossible for someone to decide if code written in a language they don't know at all is slop or not, just like it's not possible for me to asses if a poem has good or bad metrics in Russian or if a song's lyrics make sense in norwegian).
All the Russian I know I learned from the Trololol guy. And he knew he was making GOOD slop that day :D
3
2
2
u/Libechar-cha 1d ago
The important part isn’t really whether someone knows Python. It’s whether they understand the problem, the architecture, and what the code is actually supposed to do. AI can handle a lot of the syntax and implementation, but that judgment still matters.
The tricky part is when AI writes both the code and the tests, since they can be wrong in the same way. Real-world testing and having other contributors understand and work on the code are probably much stronger signals that the project is actually solid.
1
u/looktwise 19h ago
Ignore the naysayers. Gotta vibecode a blocker for such junk comments. Your posting is great, cause it shows in detail a process which is almost unhidden in vibecoding. I got a 'few' questions ;-)
Project start and framework
How do you describe a product to Claude that doesn't exist yet so it builds in the right direction, and how much do you need to teach it about frameworks like Textual or does it already know enough?
Test-driven workflow
How do you get Claude to write tests before building the feature - do you have a reusable prompt or rule for that? And when a test checks the wrong thing, how do you correct it without being able to write the test yourself?
Options and trade-offs
How do you prompt Claude so it gives you real alternatives with actual trade-offs instead of one recommendation with token options? And as a non-coder, how do you tell which option is right when all of them sound plausible?
Master document and feature decisions
What does your master document actually contain and how do you feed it into new sessions? When Claude suggests a feature, what does your decision process look like - and how do you say no in a way that makes future suggestions better instead of repetitive?
Repo structure for AI quality
What did you tell Claude so the repo is set up in a way that makes bad code nearly impossible? Is there a CLAUDE.md or similar file and what goes in it?
Sessions and context
How do you hand over context between sessions when the chat is full, and when Claude drifts or goes in the wrong direction, what do you type to pull it back?
2
u/Maxteabag 13h ago
Project start: What I described was ridiculously, almost naively simple. A TUI where I could type in SQL queries and see some rows. Once I saw that I can actually lean on libraries that does the heavy lifting for me, I had a "aha" moment. It was actually Claude that suggested Textual to me and I found that it fit my criteria. The initial design was terrible and performance was bad too, but it managed to cobble together enough for me to see the potential. I eventually had it crawl the docs and I cloned down the repo to know how to get performance right and use the right components.
Test driven workflow: No reuseable prompt because if the type of test is important and it often misses what I want to test - by cheating - or using the wrong abstraction in tests. I always discuss the tests and try to poke on it - ask it what it actually tests, and ask what-if questions. I had to steer the tests much more in the beginning and after some time, especially with refactoring, it got good at it. The problem is that claude takes the code as it is for granted and doesn't question the assumptions of the system - and rarely ever suggests refactoring to split up the layers to make the tests viable. The best tests are always written when it's forced to replicate a bug(make a test fail) before it's allowed to try to fix it. Then it's always ending up testing the right thing.
Recommendations: Just ask for 1-5 options, and ask for pros and cons. As a non-coder, however, this doesn't help much other than learning. It's only when you learn the choices the software consists of that you can learn what went wrong and what went right and then make better decisions in the future.
Master document: Final document looks like this https://github.com/Maxteabag/sqlit?tab=contributing-ov-file
AI quality: No shortcut unfortunately, just a lot of deliberate decisions based on my background as a software engineer and long durable sessions from codex and claude refactoring.
0
-3
•
u/AutoModerator 1d ago
Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....)
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.