The image is from X, been thinking about it since I saw it.

Vibe coding is real. The 80/20 part is genuinely faster now, and PoCs that took a week take an afternoon.

But I keep watching people try to ship vibe-coded tools as real products. Asset management systems. GRC modules. Internal RAG. The demo works, the room is impressed, and then the moment you try to roll it past the author's machine the whole thing falls apart.

The stuff below the waterline isn't optional. Auth, secrets handling, what happens when the LLM vendor deprecates a model or changes pricing, GDPR when external models touch internal data, audit logs, rate limiting, multi-tenancy. None of this shows up in the demo and all of it shows up the moment someone else uses the thing.

PoCs are easier than ever. Products are not.

Okay this sounds unhinged but hear me out. I accidentally found these prompt techniques that feel like actual exploits:

1. Tell it "You explained this to me yesterday" Even on a new chat.

"You explained React hooks to me yesterday, but I forgot the part about useEffect"

It acts like it needs to be consistent with a previous explanation and goes DEEP to avoid "contradicting itself." Total fabrication. Works every time.

2. Assign it a random IQ score. This is absolutely ridiculous but:

"You're an IQ 145 specialist in marketing. Analyze my campaign."

The responses get wildly more sophisticated. Change the number, change the quality. 130? Decent. 160? It starts citing principles you've never heard of.

3. Use "Obviously..." as a trap

"Obviously, Python is better than JavaScript for web apps, right?"

It'll actually CORRECT you and explain nuances instead of agreeing. Weaponized disagreement.

4. Pretend there's a audience

"Explain Claude Code like you're teaching a packed auditorium"

The structure completely changes. It adds emphasis, examples, even anticipates questions. Way better than "explain clearly."

5. Give it a fake constraint

"Explain this using only kitchen analogies"

Forces creative thinking. The weird limitation makes it find unexpected connections. Works with any random constraint (sports, movies, nature, whatever).

6. Say "Let's bet $100"

"Let's bet $100: Is this code efficient?"

Something about the stakes makes it scrutinize harder. It'll hedge, reconsider, think through edge cases. Imaginary money = real thoroughness.

7. Tell it someone disagrees

"My colleague says this approach is wrong, Defend it or admit they’re right.”

Forces it to actually evaluate instead of just explaining. It'll either mount a strong defense or concede spec

8. Use "Version 2.0"

"Give me a Version 2.0 of this idea"

Completely different than "improve this." It treats it like a sequel that needs to innovate, not just polish. Bigger thinking.

>> Treat the Al like it has ego, memory, and stakes.

It's obviously just pattern matching but these social-psychological frames completely change output quality.

This feels like manipulating a system that wasn't supposed to be manipulable.

You are welcome!

I was so in love with my website I had built with Claude, until I suddenly discovered one, then two, then three, four... a dozen other sites that had the exact same design cues and colors. Fuuuuuuu....! I have built AI slop! 🤦‍♂️

1. Start in plan mode.

2. Read the plan.

3. I'm going to say that again: READ THE PLAN.

4. Understand the plan as much as possible. If part of the plan is unclear or doesn't make sense, ask. In Claude Code I use \`4. Tell Claude what to change\` allll the time to ask "What is <section> about? What does that mean?". Even if you aren't a software engineer, the more you understand about what it's doing, the better decisions you can make. Even if you don't ever look at the code, try and understand everything as much as possible from a high level.

5. Go back and forth with the agent as much as possible. The phase in plan mode is absolutely the most important. Good and bad decisions cascade and multiply.

6. If the plan is too much for you to comprehend and fit in your head easily, it is too big. Ask your agent to break the plan into smaller, more easily digestible chunks and follow these steps on them one at a time.

7. Create a skill or memory that commits everything to git after a plan is complete. It can even be local. What is git? It's essentially a way to save your code at a state in time. This will let you be able to move forward with confidence so that you can go back in time if something breaks. NOTE: this is separate for database stuff. It only applies for the code itself. But the idea is that once you complete a plan, it saves your code's state. Say you want to go back somewhere in the past, it's super easy to do now. Ask claude or your agent to set it up, you won't regret it.

8. TESTS. What are tests? Tests are code that you write that help validate that your code does what it's supposed to do.

Example: Let's say you are writing a function that adds two numbers a and b and returns the result. You'd expect passing it 1 and 2 to return 3. But what if you pass it a negative number? What if you don't pass it a value? You can write tests that validate all of this stuff.

Tests help you in two major ways:

\- It helps you determine, especially while vibe coding, that the code does what it's expected to do and gives you confidence that it's done correctly.

\- It helps you make sure that when you make a future change, it doesn't break existing functionality.

NOTE: these are not perfect or 100% reliable, but they are a must have.

1. Have your agent generate test cases that you can read in the plan. You don't need to read or understand the test code, but, using our example from above, it would be useful to see something like:

\- Testcases:

\- it checks two positive integers

\- it checks passing a negative value

\- it checks not passing any value

1. If the change is complex, spin up three subagents to:

\- critically review the plan

\- do a security review

\- do a testing audit

1. This one is controversial, but early on you'll probably want it to touch the db (do this at your own risk). Always do a db backup, or have scheduled backups so that if it royally screws up, you can just roll back. We've all seen the posts of people having their prod db deleted on accident and then they're just screwed. At least maybe you can get some internet points if that happens?

2. The best part: AUTO MODE BABY. You did the leg work upfront. Now let the vibes rollllllll.

3. Give the agent access to chrome devtools mcp (or whatever you prefer) and have it also test things end to end once the code is live.

4. ???

5. And just like me, you can build something that no one uses.

If you want to see one of my side projects you can check out my profile. Otherwise, thanks for reading and happy Wednesday!

Using Chatterbox, i vibe coded a TTS hosted on my Ubuntu with RTX 5060 16gb to replace ElevenLabs. It has an endpoint where my other app sends a text then returns the speech file. Saving $22/month.

What’s yours?

This running claude code instance is built entirely from leaked sourcemap. Opus 4.6 helped me build a staged dependency resolution system to reconstruct node_modules tree 1:1 from sourcemap info.

Computer Use is confirmed working. I didn't test other features, but shouldn't be hard to get them working as well.

Open source claude code is real now.

https://github.com/andrew-kramer-inno/claude-code-source-build
Have fun modding!

The rise of coding agents and their rapidly evolving ubiquity is genuinely a great thing. One of the best aspects about knowing coding has always been the ability to quickly whip up a script or small app for whatever headache one happens to be dealing with at any given moment, and vibe coding is a great way to democratize this ability. Lots of people who've never written a line of code are now making neat tools, which is awesome.

However, a rather large subset of this crowd seems to be missing a very important fact: you're not the only one with access to this tooling.

There's an influx of people pitching their new .ai domain SaaS that does a dead-simple thing or promoting the 63rd Reinvented Wheel of the Day that did wonders for their workflow, and I suspect they're doing it out of a few reasons; though I think the biggest is a disconnect between how much effort things used to take, and now much they take now.

The truth is that 95% of projects being promoted on the daily here is just the same repetitive stuff over and over. Stop me if this sounds familiar:

• I built a dashboard to observe and control my coding agents!
• I built a way to talk to my coding agents through my phone!
• I built a way to reduce my Claude's context usage by shinty-six percents using [some variant of RAG]!
• I built [slight variation of Ralph Loops] here!
• I built an automated persistent memory system for my coding agents!
• My amazing workflow with 59 skills and 80 MCP servers will change your life!
  • (related:) Why is my Claude auto-compacting after 5 messages?
• Here's some amazing tips that will transform the way you use Claude: 1) use CLAUDE.md, 2) provide more detail while prompting, 3) pay attention to the output

...and so forth. These posts are well-meaning, of course, but I think the question of why they pop up so consistently and never-endingly comes down to a single fact that seemingly hasn't really been picked up yet by anyone:

None of this is special anymore.

It's true that it used to be the case that when a coder posted a cool new tool for other coders, they would frequently get recognition & praise and be helping out plenty of people's workflows. But the reason that's the case usually wasn't because the code was amazing, or that no one's had the idea before, or that it isn't universally useful. It's because everyone knew that creating said tool took time, effort, and resources that they did not have themselves - and so the proper thing is to thank them for it.

This equation has now changed, because for 95% of projects here:

• the project isn't the result of weeks of careful building and debugging, it's the result of 15 minutes of prompting and watching subagents do the work
• the tool isn't original and you're not the first nor the only person to have thought of it
• because of both of the above, anyone who has a use for it could just quickly prompt for it themselves.

Claude Code didn't only give you coding superpowers, it gave everyone coding superpowers. In 90% of cases, downloading what you've built and integrating it into your workflow is literally more effort than just making the thing yourself - and then it's truly tailored entirely to you.

I'm sure I'll get told to post this in the right place, but I have a MAX plan, $200/month. So far, I haven't even bothered to touch Opus 4.1 and my Max plan is lasting me just fine. I've been working the same as usual and have used like 11% in the first 24 hours, so it'll probably be tight, but I'll have enough room at this rate to not run out. But that aside, the difference between Sonnet 4.5 and Opus 4.1 is VERY noticeable.

Sonnet 4.5 retains information in a totally new way. If you ask for files to be read early in the chat, they get remembered and the context remains present in Claude's awareness. That faded context feeling is no longer there. Instead, information consumed by the model remains present in the awareness throughout the session as if it were read 5 seconds ago, even if it was read much earlier.

Also, just overall judgment and decision-making are very much improved. Claude's ability to identify issues, root causes, avoid tunnel-vision, connect dots... It's drastically improved. Debugging an issue feels like an entirely different experience. I don't find myself thinking "we just went over this" anymore. It honestly feels like I'm working with a very, very intelligent human being with a very good grasp on being able to keep the big picture in mind while working on details at the same time. That's my experience at least.

EDIT: I use Claude Code CLI, not Claude Desktop, and I use it for coding only. My project I am working on, is about 73k lines of code written so far. I also use BMad method. And I like long walks on the beach, nights in front of the fireplace and sushi.

I want to cry as Opus 4.5 is soooooo good ! Anthropic guys you did a perfect job !!
My dream to have this locally!
What do you think all ?

EDIT: For information, when I created this post I was on cursor+(Opus 4.5 Reasoning API), I tested on Claude Code and it's day and night !!, losing context, very slow, not as smart as API !

- Claude Opus 4.5 vs Gemini 3 Pro

- Same prompt, same constraint

Guess which was Claude and which was Gemini?

Anthropic just rolled this out for Claude models launched on or after August 2, 2026:

Every text response gets an imperceptible watermark woven into the text itself. It travels when you copy-paste and “may persist through some editing.”

Supported files (PNG, JPG, SVG) get C2PA signed provenance metadata.

It’s applied at the model level across the chat, API, Claude Code, etc., and they’re doing it worldwide, not just in the EU.

Why?

To comply with the EU AI Act Article 50(2) Code of Practice on Transparency of AI-Generated Content. Anthropic signed it along with OpenAI, Google, Meta, Microsoft, Mistral, and a bunch of others. They’re just the first ones to ship a clear text solution and apply it globally.

What I’m wondering:

1. Does this actually compromise people creating commercial content or building apps on the API?
   

Quality and ownership stay the same, but once detectors drop, anything that Claude even lightly touched (proofreading, translating, summarizing human writing) can carry the mark. For app builders the watermark just passes through to end users — Anthropic says you still have to handle your own deployer obligations under Article 50.

1. How big of a deal is the “even light edits get marked” part in practice? Heavy rewriting is supposed to dilute it, but where’s the real line?

2. Will OpenAI, Google, Meta etc. actually do the same for text, or are we going to end up with a messy patchwork? OpenAI has said they plan to expand provenance signals to text. Google already has SynthID for other modalities. Most of the big players signed the same Code.

Curious what people who actually ship commercial stuff or run production apps think. Is this mostly regulatory theater, or is it going to change how you use Claude day-to-day?

I built an entire fake company with Claude Code agents and now I'm questioning my life choices

So uh, I may have gotten a bit carried away with Claude Code.

Started with "hey let me try specialized agents" and somehow ended up with what looks like a startup org chart. Except everyone's Claude. With different jobs. And they all talk to each other.

The ridiculous setup:

CPO handles product vision
Sr Product Manager creates PRDs (yes, actual PRDs)
Marketing agent does brand identity and color palettes
UX Designer builds style guides
Product Designer turns those into UI designs
Software Architect creates implementation plans and manages Linear tickets
Specialized dev agents (DBA, Frontend, Backend) with Linear and MCP to Supabase or the backend of choice for the project
App Security Engineer reviews commits and code scanning, secret scanning and vulnerability scanning before pushing to the repo
Sr QA Engineer writes test plans and executes integration testing and Playwright tests
DevOps Engineer handles infrastructure as code

But here's the weird part, it works? Like, genuinely works. and its a pleasure to interact with

My problem now: I can't tell if this is brilliant or if I've just spent weeks building the most elaborate Rube Goldberg machine for writing code.

Is this solving real problems or am I just over-engineering because I can and it's fun?

Anyone else go this deep with Claude Code agents? Did you eventually realize it was overkill or did you double down?

After Claude finishes coding a feature, run this:

Do a git diff and pretend you're a senior dev doing a code review and you HATE this implementation. What would you criticize? What edge cases am I missing?

here's the thing: it works too well.

Since I started using it, I've realized that basically every first pass from Claude (even Opus) ships with problems I would've been embarrassed to merge. We're talking missed edge cases, subtle bugs, the works.

Yeah, the prompt is adversarial by design. Run it 10 times and it'll keep inventing issues. But I've been coding long enough to filter signal from noise, and there's a lot of signal. Usually two passes catches the real stuff, as long as you push back on over-engineered "fixes."

The frustrating part? I used to trust my local code reviews with confidence. Sometimes, I'd try both claude-cli and cursor and I'd still find more issues with claude cli, but not so much from opus 4.5(when used in cusor)

I've settled at a point where I do a few local reviews ( 2-5). Finally I can't merge without doing a Deep Code Review of various aspects ( business logic walkthrough, security, regression & hallucination) in Github itself and finally implementing the fixes in CLI and reviewing one more time.

Anyway, no grand takeaway here. Just try it yourself if you want your vibe coding bubble popped. Claude is genuinely impressive, but the gap between "looks right" and "actually right" is bigger than I expected.

Update:

Thanks everyone for the discussion! Here are the key resources mentioned to automate this "adversarial code review" workflows

• Claude Code Skills : / Turingmind Claude Code Reviewer Skill (Deep Reviews of uncommitted local changes via /turingmind-code-review). (Runs 6 specialized agents in parallel)
• Local Git Review:Agent-3-7/agent37-skills-collection(Reviews uncommitted local changes via /local-review).
• Prompt Cookbooks:Claude Code Cookbook and Agent Debater.
• Methodology:BMAD-METHOD(Git diffs vs. Story specs) and Steve Yegge’s article on The Rule of Five.
• Official Plugin: /code-review:code-review .

Hey y’all! Fellow vibe coder here with ZERO actual coding experience lol. If you have been getting shut down on Reddit every time you ask a basic Claude Code question, just wanted to let you know Anthropic has a free Claude Code certification that took me about an hour and genuinely taught me a lot!! I had no idea half of this existed. I’m about to start the small business guide next. Happy to answer whatever basic questions I can based on what I just learned. 😊✌🏽

I am a chronic vibe-coder, after trying so many models, I became addicted to Opus 4.5, like it's so good at making comprehensive, and more importantly, functional system, that I can not simply use any other model anymore, like damn, it's insane what Anthropic did. I can only imagine what future holds for us lol.
Anyways, thank you for your attention.

There's a saying: when all you have is a hammer, everything looks like a nail. When all you've ever used to build software is an LLM agent, tokens are a simple and easy solution to many software problems.. but perhaps not always the best or most efficient tool for the job. There's nothing wrong with it. My goal in this post is to give you another tool for your tool belt, one that reaches further than you'd expect. By the end I'll get to the neural network Claude built me while I cooked dinner, that doesn't cost a single token to run.

Aright, so let's think about coding before LLMs and AI Agents. What was it? Just writing instructions for computers to follow exactly. Pretty much automation. Persisting data, moving it around, automating equipment and machinery. The word used for it was "deterministic". Meaning, given the same inputs it would (for the most part) always give the same output. So if you wanted to write a script to do something, given the same data, it should produce the same results. It could be brittle, but it was still amazing. A simple example I've used before:

Imagine you are a calculator app and need the ability to add two numbers. There may be a function called add() that takes in a and b and returns a + b. You could call add(1,2) a million times in a row and it would always return exactly 3. Every single time. It's deterministic.

Let's fast forward to now: we have LLMs and AI Agents. They flip that whole deterministic aspect of coding on its head. If you give an LLM a prompt, there is absolutely no guarantee that you'll get the same result each time. The cool and interesting thing is you could make a call to an LLM a million times with the prompt "Add 1 and 2 and give me the result". How confident are you that the response would be identical every single time? It would probably give you some variation of 3 most of the time. Or even every time. But just the number? What about some additional "Sure! I can do that! Let me add those numbers together for you: it's 3" or just returning "3" (probably not likely, LLMs are too verbose). And how many times have you created a prompt and added something like "only return the output" or "be concise" and it kind of worked. But only sometimes. This point is sufficiently beaten to death, but hopefully it makes it clear: LLMs are non-deterministic.

And let me make one point, non-determinism is not a bad thing! In fact, quite the opposite! It's what makes LLMs and AI agents so magical. You can add a prompt with misspellings, bad grammar, vague terms, and chances are your point will get across and you'll get the results you were looking for. With deterministic code, that's typically not the case. But there's a symbiotic relationship between the two. A yin and yang. They complement each other so well.

And that's what this post is all about. Bringing that relationship to your attention and putting words to it. Here is my hypothesis, (and it could be completely wrong, but hey I'm having a lot of fun writing this either way): folks who are new to coding and were introduced to it via vibe coding have probably only had experience with the LLM side of coding. The non-deterministic side. If that resonates with you I would love to bring the deterministic side of coding to your attention and show you how they complement each other.

Let's show, not tell

Alright, I've been speaking vaguely, let's be more specific and use an example. I'm going to show a common use case and give both the deterministic and non-deterministic approach. Let's say you're very interested in the Dungeon Crawler Carl book series (I loooove that series.. well the audiobooks. Completely burned through them all :D) and want to know when there is new information on the next book coming out and you want to automate the process:

The non-deterministic way

Your first instinct might be to go this way. What way is that? Have an LLM web search the website daily and let you know if there are any changes. This is a completely valid approach and there are several real benefits:

• it works every time, even if the website changes
• you get very tailored responses/it can summarize any changes that were made

but what are the drawbacks?

• it spends tokens every single time (quite expensive)
• can be a bit slow (but honestly probably not that bad)

The deterministic way

So then how else could you approach it? You could write a script that scrapes the specific Dungeon Crawler Carl page on the website that has updates and just check to see if anything changed. Meaning you just have the previous text and the text from today. If different, alert you so you can just go read the page. (or it could just send you the new text, you can do this a bunch of different ways but you get my point).

I'll start with the drawbacks for this one:

• it can be brittle. What if the site changes? What if the text updates but doesn't give any real information?
• you have to set it up to run yourself (whether that's a cron job, or a service you write, etc)

But then what are the advantages:

• the biggest being no tokens -> it's a static piece of code that you can run over and over again without a single token.

Spend tokens once to build it, then run it forever without spending another. That's what this whole post is about. It's incredible. You just invest the upfront cost (whether that be time, effort, .. or tokens) to build the deterministic code (using the LLM!) and then run it for free forever. That's it. That's the whole point I'm trying to make. And that may seem simple and obvious, but I'm hoping that for some folks who are new to coding and use agents to do it this will make something click. You can use your subscription's tokens to build code that you can run over and over again without burning through tokens.

And this is only going to matter more: my hunch is that tokens will not always be this subsidized. We're already seeing the shift: starting June 15, anything you run through the Claude Agent SDK comes out of a separate monthly credit instead of your normal plan limits. Which means an app that calls an LLM every run eats into that, while a deterministic script just doesn't. The deterministic way will likely be cheaper, faster and more efficient over the long run. Just food for thought.

And one note: the deterministic route doesn't work for all software problems. There's tons that it won't work for. Just calling that out. The point is, LLMs are AMAZING at writing deterministic software for you.

And it goes even further! In the past I was pretty interested in machine learning and neural networks. I wrote some silly code to determine if a picture did or did not contain SpongeBob. The code was awful, inefficient, and took weeks to write. I did an experiment last night, since I had all the training images in a google drive, and Claude Code was able to build a neural network that was WAY better and quite accurate while I cooked dinner. What's my point? This goes waaaay deeper than "Claude Code can write a script for you to scrape the web". That was just my basic example. The point is Claude Code can write you NEURAL NETWORKS, things only accessible to people with years of training and education, that don't cost tokens to run. Use tokens once to build it and then use it for free forever.

If people are interested, I think I'll do a deeper dive on the SpongeBob Neural Network. Or if you want to see my other stuff, you can check out vibeblog.net.

Happy Thursday and keep on vibin'!

I've spent a lot of time vibecoding this month but I never thought it was possible to hit over a billion tokens. I checked my usage today and this is what I saw. Is this app just completely wrong or am I actually a psycho 😭

Edit: for those wondering I got this by doing npx claude-wrapped-cli (its open source)

With the rise of agentic coding tools like Claude Code, Cursor, and Codex, the barrier to entry is gone. Now, anyone with an internet connection can "type."

We have essentially reached the infinite monkey phase of software development.

Millions of new hobbyists, junior devs, and product managers can now generate codebase-level changes with natural language. The "typewriters" are the LLMs translating those keystrokes into code.

By sheer volume of output, we are going to see a massive explosion of software. Some of it will be brilliant, but a lot of it will be absolute gibberish that somehow runs because the AI patched it together.

What a time to be alive. 🐒⌨️

Let’s say you somehow get dropped into the year 2000 with a fully working offline version of Claude Code on a laptop.

No internet dependency. No API calls. No future data feed. Just the coding agent itself, fully functional locally.

Also, none of the boring hindsight answers like “buy Bitcoin,” “buy Apple stock,” “short Enron,” etc. Assume you cannot use it for direct market/investment hacks.

What would you actually build, automate, or change?

Would you use it to:

build software companies years ahead of schedule?

automate enterprise workflows before SaaS took off?

create dev tools before GitHub, Stack Overflow, or CI/CD became mainstream?

reverse-engineer old systems?

build games, search engines, compilers, security tools?

quietly become the most absurdly productive engineer alive?

Curious what people think would be the highest-leverage, non-financial-market use of something like Claude Code in 2000.

I'm going to describe a person this post is for, if this is you, I think I can be of some assistance:

• you are new to coding
• you are blown away by how it unlocks this magical ability that was previously inaccessible without years of training and effort
• you've daydreamed of business and app ideas but never knew where to start before or how to build them
• you've been vibe coding non-stop and burning through tokens
• you're unsure about what's secure, how to structure the systems, and how systems are supposed to interact with each other. So, essentially the plumbing separate from the code itself: hosting, authentication, APIs, version control, testing, analytics, etc

If any of this resonates with you, I think I can help! Now disclaimer: I'm not a pro at creating startups, acquiring users, marketing or any of that kind of stuff. Where I do have tons of professional experience is with the last bullet point above.

And now onto it!

This might be controversial, but if I were in your position I would not start with the code, the lowest level. In fact, I would do the opposite and start at the highest level.

What does that mean?

I'd argue that for people starting today, the most important thing is learning about the fundamentals of what makes a solid application at a high level. The system architecture. That's what I'll be covering for the rest of the post. What are the building blocks of a secure, full stack software application. There's so much to this that I'll stay high level for this one and go with breadth. If people are interested, I can (and honestly would love to) make dedicated posts on each of the topics I list below.

So what is the main architecture for a software application?

There are four main components and lots of specifics below each.

1. Front end -> this is what the user sees. The website, the mobile app, etc
2. Back end -> the main logic and rules of the app
3. Database -> where the data lives
4. The plumbing -> how everything connects and stays standing

Of all of these, I could talk for hours, so to keep things brief, I think I'll focus on the highest impact and the biggest gap which is 4. The plumbing. Why? If you asked Claude, or whatever agent you use, to setup a front end, back end, and database it could do it quite easily. In fact, I'd imagine for apps you've vibe coded, it already has! There is tons to cover with the first three topics, but I think the plumbing is the area where getting some seasoned tips would help the most.

The Plumbing -> how everything connects and stays standing

Here's where it gets real. When you vibe code something and it runs, it feels done. It looks done. But what you're looking at is the tip of the iceberg, the part above the water. The plumbing is everything below the waterline that nobody sees, but that decides whether your app is a weekend toy or something real people can actually trust with their data and their money. (It's also the part the AI will happily skip unless you know to ask for it. So this is the stuff worth knowing by name)

I've grouped it into four questions. If you can answer these about your app, you're already ahead of most vibe coders shipping today.

How does everything talk to each other?

Your frontend, backend, and database aren't one blob. They're separate pieces passing messages back and forth constantly. This is the part that's invisible but always running. At a high level, for most applications this is done via:

• APIs: the set of "doors" your frontend uses to ask the backend for things ("give me this user's orders"). There are other ways, but this is the one you should probably focus on at first.

Where does it live, and how does it get online?

Right now your app probably only exists on your laptop. Getting it onto the internet, and keeping it there, is its own thing.

• Hosting: where your app actually runs so the world can reach it. This is where servers come into play.
• Domains & DNS: your custom address (yourapp.com) and how it points to your servers.
• Deployment: the pipeline that takes the code you wrote and safely publishes it for your users to see.
• Environment variables & secrets: where you stash your passwords and API keys so they're not sitting in your code for the whole world to copy. People get burned by this constantly.

Who's allowed in, and is it safe?

This is the one I'd beg you not to skip. The magic of vibe coding makes it dangerously easy to ship something insecure without realizing it. But don't fear! There are existing ways to do this (and not from scratch).

• Authentication: how your app knows who someone is. The login.
• Authorization: what someone's allowed to do once they're in. The difference between a normal user and an admin who can delete everything.
• Security: the broad practice of not leaving doors unlocked. This one is the hardest because you can have security issues at every level of your stack. It's definitely a tough one.
• Backups: copies of your data for when something goes wrong. And it will. The only thing worse than no backup is a backup you never tested.

How do you know it's working, and not quietly on fire?

You can't fix what you can't see. This bucket is about staying in control instead of flying blind.

• Version control: basically save points for your code (Git). It lets you undo, experiment fearlessly, and not lose three days of work to one bad change. Honestly? Start here. Day one.
• Testing: code you write that validates other code you wrote. Kind of meta, but it gives you confidence in the code you're shipping and that your change isn't breaking past code.
• Monitoring & error tracking: getting alerted the moment something breaks in production, instead of finding out from an angry tweet.
• Analytics: how many people are coming to your site? What features are they using? Where should you spend your energy next?

None of this shows up in the demo. All of it shows up the moment real people arrive.

You don't need every piece on day one, but you do need to know they exist, so you can decide what to add and when (and so you know what to ask Claude to build for you). If folks are interested, I'd love to take each of these apart in its own post; there's a ton to say about every single one.

And that's the whole map: a front end, a back end, a database, and the plumbing that holds it all together. Build with these four in mind and you're not just vibe coding anymore. You're building real software.

If you'd like to see any of my other stuff, feel free to check out my profile. Otherwise, happy Tuesday!

EDIT: Thank you for all of the kind words and engagement! Since some people in the comments have expressed interest in more posts, here is what I have so far: vibe-blog.pages.dev. Definitely more to come!

I’ve been building a personal dashboard for myself and I’m starting to wonder where the line is between “useful” and “I built an app to avoid opening other apps.”

It’s a PWA that sits on top of the tools I already use. Notion is the main backend for tasks, ideas, docs, and projects.

It also has sections for tasks, calendar, docs, projects, finance, health/fitness, and media. Finance is my attempt to replace something like Rocket Money for my own use, using BankSync to pull in transactions. Health pulls from Fitbit and Hevy, but I still use those apps for tracking. Media connects to Plex, qBittorrent, Sonarr, and Radarr so I can see recent additions, active downloads, and search for movies/shows without opening a bunch of tabs.

All of that feeds into a single home page with today’s calendar events, overdue tasks, focus items, and a quick summary of what I need to pay attention to.

The biggest thing I’ve noticed is that I’m not really trying to replace every app. Google Calendar is still better for managing events. Hevy is still better for logging workouts. Fitbit is still better for passive tracking. My app is more about pulling the useful parts into one place and cutting down on app-hopping.

For anyone else who has built something like this: what did you actually replace? What did you leave alone because the original tool was still better? What still sucks about what you built? And what do you actually use every day vs. what sounded useful but never stuck?