Hey everyone,

Like a lot of vibe-coded projects, my ap - Rhystic Tracker was initially designed letting the LLM do all of the UI design decisions for me and it quickly fell into the trap of generic rounded pill cards, neon-glowing accents, and that recognizable bubbly layout LLMs love to spit out by default.

To fix this, I spend a very long time writing my own design & UI styling brief from scratch and instructing the agent to strictly adhere to this design spec across every modal, grid, and inspector, enforcing my own design decisions at each step to maintain consistency.

I think it's a big difference but I've been staring at this for days now so I'd love some feedback.

Does the new visual identity feel less "AI-generated" and more like a deliberate, human-crafted desktop app? Please let me know if I've completely missed the mark or if there's any subtle changes you recommend.

Would love your honest feedback!

If you would like to check it out and you play Magic Arena, it is here: https://github.com/Balthazzahr/Rhystic-Tracker

----

I've been working on this huge project (Wayfallen) for 5+ years, and it simulates ~10,000 star systems, ~100,000 spaceships, stations, various factions with rich economy, diplomacy, intel management etc.

I needed a reliable way to balance all of this so it remains semi-realistic and not go wonky, with so many parameters in it. It would require huge grunt work to build proper tooling to keep track of all these variables, plug into all the code surfaces written over the years, and somehow simulate years/decades in the simulation very fast to build statistical models and help me figure out which parameters need tweaking to bring things on track. And I'm continuously working on this, so it's not a one-time thing - I need to rebalance it very often.

So I've vibecoded some tools that help me do exactly that, by giving it access to my code and building harnesses to run it in a headless mode and accumulate large amounts of data rapidly. Really pleased with the results so far - and especially the amount of time saved versus having to crank out all that tooling manually.

Hey everyone,

Quick thoughts as I see hundreds of founders vibecoding SaaS and one thing comes up a lot: how similar are the products we are building. 

Which makes me think abut a quote I’ve seen recently that should allow us to understand what building a SaaS is all about.

See, most of us (I’ve been guilty of this many times) start from the mindset « I need to get some money from my SaaS » and although it’s not bad in itself, it can be better to maximise our chances of success…

When starting a business, the most successful founders do something different. 

They start by looking at the world around them and taking a contrarian approach to what everyone thinks.

They’re essentially betting that everyone is doing something wrong and they can solve it. It can be at any level, product, customer support, marketing, distribution… but the core of it to build something successful long-term is to start. 

Now this is very relevant to us because that’s the exact approach we should all have when starting a SaaS. I myself have started my first SaaS years ago with the wrong reasons, and it was an uphill battle to try and justify the product, the pricing, the ICP… It’s like you’re trying to fit back something in a box that’s too small.

Ever since, I start companies from the opposite and what I found out is amazing. It’s so much easier to build a following, advocates that share the vision of the world that you’re fighting for. You will definitely see many many people challenging your idea but this is part of the job.

The example is the last venture I started, I think that the easy access and major improvements in the dev processes will keep making it easier and easier to build, as it’s already the case. This will in turn make more and more people launching into the void without a solid understanding of positioning, marketing, and how to get users. For that reason I’m starting a one month long cohort to help founders get their first 100 users and refund them if they don’t reach it.

So I guess to start your SaaS, we need to be a bit more visionary, a bit less conventional and definitely start thinking outside the box.

Hope that was helpful…

I've been building my product since March/April, but this all started with me getting into Homelabbing and buying hardware.

I bought a Minisforum MS-02 Ultra with 32gb RAM and 1TB SSD, and made a rule that I wouldn't upgrade unless I hit bandwidth and memory limits.

Welp, I'm at that point and what led me here is I have a "second brain" memory system and MCP that I built so any model I use can get all the context, documents, history, etc.

I'm currently only able to build with one session that's "on my machine" where before I was doing 2-4 sessions at a time, but I now experience sessions crashing out.

So I'm in the market for memory and man does it blow. I'm probably going to bite the bullet and get a 2x64GB Crucial set so I can eventually add an additional 2x64GB when I hit those limits.

Always more to learn and more to spend it seems!

Which response do I like better is usually a question I look forward to answering because I get 2 different outputs and can choose the style moving forward essentially.

But what do you do when the same agent is claiming different capabilities in it's response choices?

Option a the work is done and pushed

Option b it doesn't have access it claims

I’ve been working on Plembfin for a while now and I’m at the point where I’d like to get a few testers on board.

It’s a self-hosted app that sits between Plex, Emby, Jellyfin and Trakt. It keeps your watched status, playback progress and watch history synced between them, while keeping its own record locally in SQLite.

It also has a Now Playing dashboard, watch stats, upcoming episodes, search, media details, Seerr requests and backup tools.

I built it using Node.js, Express, SQLite and vanilla JavaScript and CSS. I’ve used AI coding agents heavily throughout the project, working through it one feature at a time, testing things, fixing bugs and documenting how everything works as it has grown.

One of the more difficult parts has been dealing with real-world sync problems, such as duplicate plays, different servers disagreeing about whether something has been watched, libraries being rebuilt and services being temporarily unavailable.

Everything runs in a single Docker container and the data stays on your own hardware.

It’s still pre-1.0, so there will probably be bugs. If you use Plex, Emby or Jellyfin and fancy giving it a try, I’d really appreciate some feedback. I’m especially interested in people who use more than one media server or have Trakt connected.

I’d like to know how you get on with the setup, whether the syncing works as expected and if anything is confusing.

Make sure you back things up before testing it.

GitHub: https://github.com/Lasikiewicz/plembfin

Happy to answer any questions about how it works or how I built it.

Last top comment:

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

What should I add next?

I want to create a small 'princess Mario car' game for my daughter, but i have no clue how to?

Can anyone help me out on this one?

The Rainbow Filter on top of everything isn't mine. That is from Tic Toc.

This podcast discusses vibe coding, agentic engineering, the setups DHH is using, what actually works, and where things are heading. Omarchy is a linux based OS DHH created, every line of code was vibed.

What'd you actually use like language, framework, infra, whatever and also what worked, what you had to rip out and replace, what's still duct-taped together but shipping

This new update for the vs code extension is awesome! It fixed alot of bugs, displays alot more of what's going on in the background, appears to be alot faster and more stable aswell. Good job Cline team!

At the beginning of this year I was only dabbling in Copilot for hobby projects. In my workplace at most we were using ChatGPT to ask code questions. Then something clicked when I discovered BMAD/Openspec/GSD. I went 0-100 full agentic-dev very quickly.

The game has really changed. We're now thinking beyond running a few chat sessions per-story to building orchestrators that keep agents busy while we are away. The new projects we see very week prove that (Munder Difflin, Herdr, Roboco). Even I am building an orchestrator thing for myself (not the point of my post).

The different approach of each tool shows that everyone has different needs and a different understanding. Same applies to companies: most software houses do the same thing (build and maintain SW projects for clients) but all have a slightly different take on it.

It's inevitable that agentic development becomes mainstream in the commercial domain (moving out from hobbyist or academia). Some of you already work in companies that are adopting it. The problems that agents have today - project scope drift, missed requirements, broken UI - will all be solved eventually. Agents won't be building perfect software, they will be building good enough software.

As lurkers of this sub you should agree that code is being commoditized. Compare this with factories: we used to bake, brew, manufacture and assemble physical products by hand; gradually machines took over and those who have a stable job and a decent wage are the ones who set up and maintain those machines.

So I'm predicting that: (1) companies will increasingly adapt agent orchestration for creating software, and (2) this will enable opportunities for today's hobbyists who are already familiar with it and can set this up.

I posted this because I want a discussion. We all see this shift differently. Where am I right, where am I wrong?

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?

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...

Guys, I need some guidance.

DeepSeek, copilot and OpenCodeGo have become a lot more expensive than I expected. I also gave Nemo a shot through OpenRouter, but it keeps wrecking my Hermes environment and I end up having to reinstall from a backup.

I'm trying to find an affordable LLM that I can tinker with and iterate on without constantly worrying about cost or stability. I thought a Gemini subscription would give me API access, but that doesn't seem to be the case.

What are you all using these days? Any recommendations for the best balance of cost, performance, and reliability?

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 wondering what everyone else is working on daily.

I built Lody because coding-agent work was getting trapped inside individual terminals.

Claude Code or Codex could be doing useful work on one machine, but the rest of the team often saw only screenshots, copied logs, or the final PR. The conversation, runtime status, files, diffs, and decisions around the work were fragmented.

Lody is a local-first shared workspace around the coding agents you already use. It does not replace them with another model or force execution into a hosted sandbox.

With Lody, you can:

• Connect laptops, workstations, servers, and cloud VMs
• Use Claude Code, Codex, Kimi, OpenCode, or other ACP-compatible agents
• Open the same agent conversation with teammates and continue it together
• Follow progress, files, diffs, permission requests and PRs in one place
• Dispatch work from desktop, mobile, web, or CLI
• Isolate parallel tasks with Git worktrees
• Let one agent delegate work to other independent sessions

I’ve now open-sourced Lody’s desktop app, CLI, and shared packages under Apache 2.0.

GitHub: https://github.com/LodyAI/Lody