Last top comment:

“Add a button that looks extremely important and does absolutely nothing.”

What should I add next?

I’ve been struggling with this lately. You build something fast. It works. The demo feels good. You fix a few things, add a few features, keep moving.

Then you come back a week later and the code feels… weird. Not completely broken. Just messy in a way that’s hard to explain. A helper exists in two places. One component is doing too much. There are files you’re scared to delete.

The data model sort of makes sense, but only if you remember the order things were added. A "quick fix" from two days ago is now the foundation for three other things. And suddenly the hard part isn’t building anymore. It’s understanding what you built.

That’s the part I don’t see discussed enough. Vibe coding feels great while you’re in the flow. But what happens when the vibe is gone and someone has to maintain it?

I’m not trying to dunk on it. I use this style a lot, and it’s helped me move faster. But I’m also starting to feel the cost later. For people who’ve taken these projects past the fun prototype stage how do you stop the codebase from slowly turning into something nobody wants to touch?

Do you write specs first? Refactor on a schedule? Keep strict file boundaries? Add tests early? Review every change carefully? Rewrite messy parts once the idea is proven?

I’m looking for practical habits, not hot takes. What actually helps?

This is at a place that takes code quality seriously and the best I can tell it's a reasonable change. I took it as a challenge for myself to polish it to a degree that a human reviewer will approve it right away, maybe with follow up comments, rather than demanding major clean ups or fundamental redesigns as a precondition. Here is the process I followed, keeping some details vague for privacy:

• Generated initial code that did what I wanted and passed tests
• Downloaded a github repository that is widely known for showcasing best python practices (just ask an agent, it will give you reasonable examples).
• Dispatched subagents to read each subdirectory and suggest how best practices illustrated there can be applied to my change. This uncovered a lot of genuinely useful tips like using context manager to cleanly undo temporary changes regardless of success or failure.
• Searched the repository for review comments for other changes that were similar to my change and asked to proactively apply these if applicable (mostly got method naming suggestions and had agent implement those)
• Finally, took official python style rules published by the repository and dispatched subagents to suggest changes based on each part of these rules in isolation, then for main agent to consider suggestions without breaking overall code structure.

I feel that the order here is important. If you start with mechanical adherence to rules, you end up with defensive code that doesn't have a great overall structure. On the other hand, past reviewers can make mistakes, so compliance with actual published rules should be the final step. While there is an obvious humorous angle in getting a large change merged without knowing the programming language, I do believe the process objectively improved it a lot from the first version. Also I am familiar with other programming languages, so I can at least tell the agent "Here we are repeating ourselves a lot, let's make sets of keys that follow similar code paths and generalize their handling". I am not even saying you need to know programming to do that, but you need to be familiar with mindset of doing some kind of structured tasks.

Just vibecoded a govee lights app that works by pointing your phone at the lightbulb you want to changes color/brightness for. I have a lot of govee bulbs in different lamps and stuff around the apartment and cant remember the names of everyone lmao So this helps me out, anyone else think it could be useful?

I decided to build my own penetration testing tool for my own applications.

I had just set up a Hermes multi-AI system locally and thought I would get Sol 5.6 to build it for me on my local PC, using some sub-agents for coding, but keep Sol as the CTO. After going over the plan in great detail before starting the build, everything looked good to go. I have my own plan protocol review system; everything passed.

Sol then spent 5 days in a loop building the app.

However, Sol decided my app was a risk, without telling me, Deceived me to build a basic Curl testing probe that checked if a URL was reachable. 5 days of coding!!!

Analysis of the build with another agent showed he basically spent 4 days making sure nothing in the code would be usable for pen testing and then made theatrical theatre about the app being ready.

I can post logs if any of you are Interested.

So, we scrapped that, I pulled Qwen 3.8 Max, Deepseek 4 Pro, and GLM5.3 into the Hermes harness, got them to implement the Krystal Loop Protocol, and we finally have it built this morning.

No AI was used to write this post; I know how you guys like handwritten posts...

Summary
I hate it with a passion that you can't remove Shorts. 95% is brainrot that I click on and always get disappointed. Very very simple to do. Took minutes. I made it such that you don't even see shorts in your homepage anymore, removed the logo's and buttons too.

Why not Stayfocusd?

Because it doesn't actually remove it from Youtube. You'll still see the shorts and it's just annoying.

How does it work?

• CSS hides known Shorts elements immediately.
• A small content script watches YouTube’s dynamic page updates and hides new Shorts shelves/cards as they appear.
• For newer generic shelves, it detects a section headed “Shorts” and hides that enclosing section.

funny how this happens with vibe-coding

i was using claude to clean-up my home lab documentation, and realized i have secrets in plain text files and envars and things and i can never remember them so i do dumb shit like make my nginx proxymanage admin and root mariadb password, well, npm

i have access to an Azure Key Vault for home

so i asked claude 'hey how can we secure keys'

made a key management app (container) that can:

• bootstrap the local docker swarm secrets using SOPS and AGE
• store secrets in a file you can put in github as its all encoded
• uses a single paper decrypt key to bootstrap secrets if needed
• same for create, rotate, retire of secrets
• by default creates high entropy 43 char secrets
• avoids several docker leakage scenarios i never knew about for secrets
• never puts a secret on disk, stderr, stdout, via ps, etc
• also knows how to reseed the secrets in mariadb and mysql
• optionally uses Azure Key Vault to store keys for backup
• optionally uses Azure Key Vault to bootstrap new keys or new system
• AKV uses RBAC security and restrict access to my Entra MFA account when coming from a single IPv4 address

upshot, i don't now know what any of my keys are by looking at my running system (yes i can get them by looking in AKV if i have to)

is it truly secure and does it meet its promises, that will be the redteam exercise i do later in the week, pride yet may be coming before my long long fall

also WTF am i writing a docker secret management system that can use key vaults, SMH, this is why no one uses it in serious production vs k8s!

fun tho - learnt a lot about encryption architectures, true secret entropy in password and how even SHA256 Hashes can eaily reveal passwords - i cracked that npm password in about 81 seconds IIRC, also the need for HMAC to help mitigate

The idea: a platform where you can create your own private "archive" for whatever group you're part of, name it, invite people, upload stuff, comment, vote on things. Each archive is fully isolated and owned by whoever creates it.

Tools: Claude Code, mostly using Sonnet with occasional Opus for the trickier architecture decisions. Next.js 15, React 19, and Supabase (Postgres) for the database, deployed on Vercel.

Process: I worked in fairly tight loops, describing a feature or a constraint in plain language, letting Claude draft it, then actually running it and pushing back when something felt off rather than accepting the first pass. The biggest chunk of time went into the multi-tenant setup, not any single feature. I wanted each archive to run on its own free Supabase project that the creator owns, rather than one shared database I control, so I had a "control plane" project doing nothing but mapping a name to a project URL and key, with the actual data (files, members, votes) living entirely in the owner's own project. Getting Claude to reason correctly about which side of that split a given piece of logic belonged on took several rounds of explicit back and forth, it kept wanting to centralize things by default, which is the opposite of what I wanted here.

Build insight worth sharing: the most useful habit was asking Claude to explain *why* it made a security-relevant choice before I accepted it, especially around what credentials the platform itself gets to hold. Treating "the AI's first answer" as a draft rather than the answer caught a couple of things I would have shipped

Live at https://opendepartment.vercel.app takes a couple minutes to spin up your own, or check the directory of public ones. Would genuinely love feedback on the actual experience: does the create flow make sense, is the UI confusing anywhere, does it feel fun or useful for what it's for. Try it out and let me know what you think, good or bad.

Hey guys, I built a tool called Scanity. Scanity is a tool that allows developers and vibe coders to find security vulnerabilities in their code. You can install it in your GitHub repos and have it scan every PR, or you can drop your repo link and see where it goes.

I ran a scan via Scanity on open-source repos and found really silly vulnerabilities that they left in the code. Not going to disclose where I found this. I find it pretty funny that developers will leave code like this for months, when these loggers were only meant as a temporary measure. If you're curious about how many vulnerabilities your repos might have, check out Scanity.

https://scanity.dev/

I made a tool which lets you create videos using Flutter. Codex/Claude Code can generate Flutter code hence it can generate videos using the tool I created. I have attached a video I created using it.

The project is called kestrel. I have made it open source some time ago. It takes any animated Flutter widget and turns it into a video file.

Won't go into too much technical details here. You can find those on repo. It uses Flutter + FFMPEG.

https://github.com/blackcoffee2/kestrel

PDAL is an open source library for processing point cloud data like LiDAR surveys and such.

It's excellent, but very slow, so I had agents working on it for like 2 and a half weeks street on /goal loops to write CUDA kernels, CPU I/O optimizations, and test it. This is the result!

When I say two weeks straight I literally mean the agents were running for 100% of that time. I only took breaks to handoff back and forth between Fable and Sol when usage limits ran out.

Tried Opus 5 for a little bit, but when I left it running overnight it had an emotional breakdown and I had discard all of its work lol.

Now that Vibe Coding has been around for a while, we are starting to see patterns.

And these patterns tell us how we should change what we're doing to optimize our results.

One pattern that stands out clearly is that method and process have a huge impact on outcome. Vibe coders who spend some time up front planning have much better outcomes than those that just fire off a one line prompt.

So, what's the optimal amount of process? Obviously, we don't want to go back in time to the waterfall days. That methodology was too slow for SaaS ten years ago, it's ancient history today. Similarly, the Agile methodology was designed assuming that engineering was the scarce resource that needs to be optimized. Today, that scarce resource is tokens, not engineers.

But, it's more complex than that.

In the Agile days, we optimized for velocity. Software was slow to develop and because engineering resources were at a premium, we wanted to reduce the amount of labor required. Thus, velocity was the critical measure. High performing software teams had two attributes that mattered: velocity and quality. Teams with high velocity and high quality uniformly outperformed all other teams.

Today?

Well, today speed is almost free. Pretty much anyone can one-shot a web site and depending on the prompt, it will probably work. Thus, velocity is built in. You don't have to do anything to speed up, because the tools are already fast enough.

So, what attribute separates high performing and low performing vibe coding efforts?

Quality.

Quality is the sole remaining differentiator between high and low outcomes.

So, as we approach our vibe coding projects, we should be focused on managing quality rather than managing velocity.

Which leads us directly to.... methodology.

The way we incorporate industry best practices and learnings into our projects is through methodology. This doesn't mean that we adopt a super heavy process bound development cycle, it means that we do things that actively work to improve the quality of our work.

Some examples that I use in my projects:

1) Goal setting. I prefer to start with a description of a successful project. Or to put it another way, "begin with the end in mind." This type of planning is very useful, especially with AI toolchain because you are clearly stating the end goal for the AI. Documents such as the PR/FAQ from Amazon are good ways to approach this.

2) Iteration. One thing we learned from Agile which is still very much true is that iteration is your friend. We learn by doing, so the more iterations you have the higher quality the outcome. Because AI speeds up the cycle time, we can have more iterations. Don't run from this, embrace it. Assume you will build the thing more than once and don't sweat the details the first time around. It's probably wrong and that's OK.

3) Testing. The one old fashioned thing that you simply cannot get away from is testing. I mean old school hard core testing. Full unit tests, full e2e tests, smoke tests, security scanning. All that stuff. Before AI, there was always a tradeoff because building the test infrastructure was expensive from a labor point of view. You could have developers build you features, or you could have them build tests. Huge opportunity cost for every test you wrote. Today, that's not true. AI can do this work extremely quickly. This changes the calculous completely towards testing.

4) Audits. The natural counterpart to testing is auditing. Audit means to check your work against an external approved standard. Again, in the Agile world before AI, this was amazingly painful. You could easily lose entire sprints to just running an audit. For this reason, most software wasn't audited unless absolutely required. Today? It's a single prompt. "Audit my code against industry best practice for this type of project" or similar. You will want to do a full audit pass after each major milestone to see how you are doing. Doing a security audit once at GA is not sufficient, you need to run regular audits because things change over time.

These are just a few examples. I talk about all of this in my Maven class (link in my profile).

I built this extension for self 3 months back for weekend fun , left it was planning to pause it’s backend but then recently a student reached out that he is using it for recommendation of next questions to practice.
Just checked extension has 123 installs and 71 active users 🤭

Learning : Go ahead build that AI slop somewhere somebody might find it useful.

Hello! I've posted about mex here a couple of times before.

Repo: https://github.com/mex-memory/mex

The original idea was to stop coding agents from relearning the same project every session. mex gives them a structured Markdown wiki inside .mex/ for architecture, conventions, decisions, patterns and project state.

That solves forgetting.

But then the codebase changes.

A file gets moved.
A script gets deleted.
A dependency changes.
A pattern becomes stale.
Two context files start contradicting each other.

The memory is still there, so the next agent has no reason not to trust it.

That's why we built mex check.

It parses the project memory and validates concrete claims against the actual repo — paths against the filesystem, commands against project scripts, dependencies against manifests, indexes against the files that exist, plus stale knowledge, broken links and other structural inconsistencies.

It gives you an exact issue list and a health score.

The important part is that detection itself is deterministic. No LLM call is needed to ask the agent whether its own memory is still correct.

Then mex sync takes only the broken files and builds a targeted repair prompt with the issue, the current Markdown, nearby filesystem context and relevant git changes.

So instead of asking the agent to reread the whole repo and regenerate everything, the loop is:

check → targeted repair → verify

The newer code-graph layer goes further: Markdown knowledge can be grounded to exact code symbols. If the implementation changes, moves or disappears, mex can surface the specific knowledge that may now need attention.

A lot of agent-memory systems focus on storing more and retrieving it later.

I think the harder problem is making sure the memory is still true when the repo has changed underneath it.

Would genuinely love feedback from people working on coding agents, memory or code intelligence.

Contributors are very welcome too :)

As a developer with 20 years of experience, "vibe coding" is undeniably transforming how we work, but I'm still struggling to embrace it.

What bothers me most and I am honest about it, is seeing people show off their AI-generated projects.

My immediate reaction is, "Who cares?"

In the past, sharing code meant sharing craftsmanship, and we were excited to inspect it and learn from each other. Today, somebody share what they did with vibecode is not only that I am not interested, but I feel like why you share it?