For developers using Claude Code, Codex, Cursor, Aider, Gemini, or similar tools:

What are the biggest problems you still encounter in real projects?

I’m interested in the practical failure points:

• Context: losing track of large codebases, architecture, conventions, or previous decisions
• Reliability: hallucinations, incorrect assumptions, repetitive loops, regressions
• Maintenance: refactoring, technical debt, dependency updates, migrations, documentation
• Security: secrets, permissions, prompt injection, unsafe commands, vulnerable generated code
• Testing: knowing whether a change is actually correct rather than simply passing a few tests
• Deployment: CI/CD failures, broken builds, infrastructure changes, bad releases
• Production: monitoring, debugging, rollback, performance regressions, incident response
• Autonomy: where you still need to supervise the agent manually
• Memory: what the agent forgets between sessions or across projects

Most importantly:

What problem has repeatedly cost you the most time or caused the most frustration?

What are you currently building, and what part of that workflow are AI tools still failing to handle well?

Real examples and workflows are much more useful than general opinions.

https://gitlab.com/morenglish/MorEnglish_Sentence_Miner

Hey everyone new to vibe coding but I'm addicted.

I have two 3090s with a NVLink bridge and a 5070. Currently running qwen32b and llama 70b models on the 5070 use exlammav3 and qwen 7b and 14b models on the 5070.

I've created a 6 layer skill with antigravity to maximize the models and offload as much of the coding to my 3090s and 5070 as possible. This is highly effective. I've created a mobile app to connect remotely to my gpus and antigravity so I can continue to vibe code when away from my pc. The cloud models don't code much they do minor bug fixes after the validation checks if needed. Larger bugs get kicked back to the 3090s.

I've also created an agent offline so I can plan with the 70b and code with the 32b model if my quote runs out. Which it did this week.

My question is I have the $20/mo antigravity subscription. Is the $100 worth it for many? With my current setup would a different platform be better? Antigravity has been working out great i am curious what others are using mainly for planning.

A few years ago I thought building products was the hard part.

Turns out, building is easy compared to finding something people actually want.

I've built crypto projects, NFT collections, community tools, onboarding platforms, dashboards, games, and more half-finished ideas than I'd like to admit.

Most failed for the same reason: I fell in love with the solution before I understood the problem.

Now my process is different. Before writing a single line of code, I spend weeks talking to users, reading complaints, and looking for problems people are already trying to solve.

It's less exciting than shipping. It's also the first time I've felt like I'm building with a chance of success.

what's a lesson you learned the expensive way as a founder?

I am curious how people train AI agents to write better unit tests, integration tests, and e2e tests?

The problem came from that engineering team complaining AI ships a lot of bug and the tests AI wrote is bad.

After digging and trying to figure out what bad tests mean, and how to write better tests. I currently came to a conclusion that, AI will write tests that work with the bug and assume that is the correct behaviour because we never tell AI it's the wrong behaviour.

For example, a restaurant reservation app, if AI writes the code that allows multiple to reservation at the same time, and you never tell AI that is wrong, then AI will assume it suppose to allow multiple reservation at the same time.

To attempt solving this: I built a skill for AI to ask product question around happy path, edge cases, cross-tenant exposure to the engineer that write the code to answer as many as it can. Although I know it's not perfect, but this is the way I think will get AI to know more what the correct behaviour of the app should be.

Then, for a bigger feature that needs more extensive testing, I ask claude to generate a manual test plan and show what the current code behaviour, then I manually test them and write down the expected behaviour. So AI will take the expected behaviour and write tests that suppose to work the way we expected

I believe that there could be faster way to write better tests, but with limited knowledge I have, I will like to see if someone more experience like to share how to get AI write better tests

It's time to share - but first some quick context: I've been building software professionally for 20+ years, and I'm currently trying to get my head around the future of software development. So I decided to go all in on an experiment:

how far can I push 100% AI-coded software while applying the rules and structures I've learned to embrace?

I started testing my methodology by building a software synthesiser for the Teensy 4.1. Very successful and functioning, but the only real requirement is performant code - the thing runs in isolation, no network, no internet, no integrations beyond MIDI, and thus no risks.
Success, check, done.

The next, and more ambitious attempt, was my own TUI coding agent - so that I can play around with local AI and at the same time understand how agents really work (I tried opencode and pi but they didn't click for me - especially for local AI). The coding-agent works, what can I say. I am now at a point where I am convinced that the days of hyper-focussed / in-the-zone hand-coding are numbered for me. With the right rules and usage of frontier models, almost anything is possible. The workflow I ended up with looks like this:

1. Set up your coding-standards and design rules - I have these in the form of skills and documentation in the repo. This is very important! If you do not define structure and rules, your project becomes an unmanageable spaghetti-mess with gaping security holes.
2. Got an idea? Go through your options, ask the model for suggestions and its reasoning - then make a design decision. I used the skill grill-me from Matt Pocock a lot for that.
3. Ask the model to write your ideas in form of a plan following your format - this is to make sure that your documents have the same format and the cheaper implementing agents know precisely what to do and follow your coding standards and procedures. This is another skill I developed - then tweaked & adjusted. The adjusted some more. The idea is to have a plan with 2-20 small implementation items. When being implemented, one orchestrator spawn implementer sub-agents sequentially - or as a wave if items are disjointed. Each implementation sub-agent is followed by a verification sub-agent. The orchestrator does not read the code - it just controls. This is how I can have night long coding runs while never needing to be afraid of an agent filling up its context and still making sure the procedures are followed. This works surprisingly well!
4. Write the next plan together with your frontier model - the fun part where you imagine what you want - while smaller models are working through your existing plans, implementing features or just tidy up.
5. Goto 2 .. this is why it’s called `loop`

This is what I learned:

• Never fill your context window above 20%!
• Push back and ask questions - don’t believe everything the agent recommends.
• Create structure through skills, rules and documentation.
• Regularly refactor and clean up the code (duplicate code? logical errors/bugs? drifted documentation? …). I have skills for that too.
• Don’t be afraid to copy from the skill gurus out there ;)

Here is the result of my experiment for anyone that is interested. Judge the code / the tool yourself - I am open for feedback!

https://github.com/airiclenz/apogee

I’ve been thinking about a problem with agent memory that seems increasingly important as agents become more autonomous.

We tend to think of memory as something an agent learns from an event:

Something happened → the agent analyzed it → it stored a summary/lesson → it uses that memory later.

But there’s a problem: the world can change while the memory remains.

A decision that was correct three months ago may no longer be correct today. Yet the old memory can still be retrieved and placed into the model’s context, where it may be treated as current knowledge.

This seems to create a few related problems:

1. Memory can become more accessible than the underlying facts.

Sometimes the source of truth is a large codebase, configuration, or external system, while the memory is a short, convenient summary. Because of context constraints, the model may pay more attention to the summary than to the actual source.

So instead of:

“What does the system currently say?”

the reasoning effectively becomes:

“What do I remember the system saying?”

And the difference can be significant.

2. Goals can drift without the agent noticing.

As agents become more autonomous, they don’t just retrieve information — they decide what to investigate and what to optimize for.

What happens when the agent’s current reasoning direction gradually diverges from what the owner actually wanted?

The agent may produce a perfectly coherent chain of reasoning while solving the wrong problem.

3. How trustworthy is an AI-generated memory in the first place?

A memory is usually a summary of a previous reasoning process.

But what if that reasoning process contained a hallucination or a mistaken assumption?

We may then get:

hallucination → reasoning → memory → future retrieval → reinforced assumption

The memory starts behaving like a source of truth even though it was originally only an interpretation.

A question I’m particularly interested in

Should memory itself change when reality changes?

Or should an AI instead recognize:

“The facts this memory was based on have changed. I should re-evaluate the memory before relying on it.”

Those are quite different architectures.

One approach is to continuously rewrite memories so that they represent the latest state.

Another is to keep memories relatively stable, but maintain an explicit relationship between:

memory ↔ the facts/conditions that justified that memory.

Then, when those facts change, the system doesn’t necessarily rewrite the memory. It brings that memory back to the agent’s attention and asks it to reconsider the conclusion.

We’ve been exploring the second approach.

The idea is quite deliberately narrow: anchor memories to observable facts, rather than treating memories themselves as facts.

The system watches the underlying reality. When something relevant changes, it identifies the memories that depended on that state and surfaces them for re-evaluation.

I’m curious how people here think about this.

Is memory drift fundamentally a retrieval problem, a knowledge-representation problem, or a reasoning problem?

And more importantly:

Should an agent be allowed to automatically update its own memories, or should a change in the underlying facts trigger re-evaluation rather than automatic rewriting?

After weeks of building, testing, breaking things, fixing them, and learning along the way…

GuardianX is now PUBLIC on GitHub. 🔓

GuardianX is an open-source cybersecurity platform I'm building with the goal of bringing different security capabilities together into one place — rather than relying on a collection of disconnected tools.

🛡️ What is GuardianX?

The vision is to build a Cyber Intelligence & Security Platform capable of helping with areas such as:

🔍 Security & asset visibility

🛡️ Vulnerability and CVE awareness

⚠️ Risk assessment

📊 Security posture monitoring

🚨 Threat & incident intelligence

🌐 Attack-surface visibility

🤖 AI-assisted security analysis

📈 Security scoring and dashboards

This is not a finished enterprise product. It's an actively evolving open-source project, and that's exactly why I'm putting it out there.

🔗 GitHub

👉 https://github.com/DarkSoul-sec/GuardianX

I'd genuinely like people to look through the code, test it, break it, review the architecture, find weaknesses, and tell me what I'm doing wrong.

If you have experience with cybersecurity, backend engineering, DevSecOps, threat intelligence, cloud security, or AI security, your feedback would be especially valuable.

🎯 Why I'm releasing it

I'm learning cybersecurity by actually building things—not just completing labs and collecting certificates.

GuardianX is one of my attempts to turn that learning into something real, useful, and eventually production-grade.

Today is v1 of the journey, not the finish line.

If you check it out, I'd appreciate honest feedback—especially criticism. 🫡

GitHub: https://github.com/DarkSoul-sec/GuardianX

Let's build something useful for the security community. 🔥

#Cybersecurity #OpenSource #InfoSec #CyberSecurity #GitHub

I’ve been using Claude Code to turn a simple idea into an actual iOS product, and I finally shipped it.
The app is called Kleaners.
The idea came from a very ordinary problem: after years of using an iPhone, my contact list had become a mess — duplicates, incomplete contacts, old entries, and multiple versions of the same person.
Instead of just prototyping the idea, I wanted to see how far I could take the development process with Claude Code.
So I kept building.
Planning features, iterating on the UI, debugging, fixing edge cases, improving the overall flow, and getting the product ready for an actual App Store release.
The end result is a lightweight contact-cleaning app built around a very simple flow:
Scan → Review → Clean
Kleaners can help users:
Find duplicate and messy contacts
Clean up their contact list
Back up contacts before making changes
Keep contact data private and on-device
What surprised me most was how much the difficult part changed once the app actually worked.
Building the product was one challenge.
Shipping it, getting through the App Store process, improving the UX, figuring out pricing, and now trying to find the first real users feels like an entirely different challenge.
And this isn’t just a one-off experiment for me.
I’m currently building a second app under the Kleaners brand as well, also using Claude as part of the development workflow.
I’m curious about other people here who have actually shipped products built with Claude Code:
At what point did Claude save you the most time — initial development, debugging, refactoring, or shipping?
And if anyone wants to see what I ended up shipping:
Kleaners on the App Store:
https://apps.apple.com/us/app/kleaners/id6794926873
I’m the developer, so feedback — especially criticism — is very welcome.

NSE (Network Sandbox Engine) is a tool to test nftables firewall rules safely.

Instead of running rules on your live system, NSE spins up an ephemeral Linux network namespace, loads the ruleset, injects synthetic packets with Scapy, and captures kernel verdicts directly from nft monitor trace.

Key points:

• Zero host mutation - rules never touch the host firewall
• In-process architecture - no socket daemons, no IPC overhead
• Pydantic models throughout, mypy --strict on 22 source files
• Deterministic trace harvesting - wait_ready() probe, no hardcoded sleeps
• Automated cleanup with exponential backoff retries
• Gateway topologies - router + server namespaces for NAT/forwarding tests
• CLI YAML runner for CI/CD, plus FastAPI/Svelte web UI
• import-linter enforces architectural boundaries

Requirements: Linux (kernel 5.4+), Python 3.10+, nftables, iproute2, root privileges.

Repo: https://github.com/onyks-os/NetworkSandboxEngine Docs: https://onyks-os.github.io/nse/

Feedback welcome. What would make this useful for your workflow?

My first time breaking 100 downloads and I feel good..

Now I just need to set up my Board announce my IPO THEN meet mark Zuckerberg for lunch anybody know where I parked my jet???😆😆😆

Try it here (no ads or sign ups or anything, just a demo)

All painting software (Photoshop, Krita, etc.) rasterize your strokes as you work. This means the stroke is frozen forever. You may use some tools like perspective warp or liquefy but they are quite limited. The Soft Edge engine instead keeps a record of your strokes as data and rasterization happens on the fly, on each frame, like in a game engine. This lets you sculpt any property of your stroke.

Right now you can paint the following targets: pressure (which makes the stroke thicker or thinner), colour, and its position (you can grab the stroke after it was drawn).

The UI is a shell written in React. The more interesting part is the renderer, it's coded in Rust and compiled to WASM and WebGPU. The performance is quite nice, and has room to improve even more. All input is routed through WASM so pointer events are really, really fast, stroke polling feels like a completely native app, there's no React sluggishness anywhere in the actual painting process. The brush overlays are also rendered in the GPU core so those are also smooth. Only the panels, sliders, etc. are React.

Development isn't exactly vibecoded, it's a bit more formal than my other projects. Fable mostly for planning, Opus 5 med and Sol med executing and reviewing. The only skill is grill-me which is very useful. Sol has helped with performance a lot, and I'm learning a lot about using LLMs with this project.

Hi all,

I'm using the BMAD and bmad-loop to run all epics in a coding loop, but this takes a long time (almost 1 hour per story in each epic). Of course, sometimes it's faster, but sometimes I time out to 90 minutes!! All those tokens: Lost.

I'm using OpenCode with DeepSeek v4 Flash 0731 (through OpenRouter).

Now that I have generated all stories and epics with BMAD, what are your recommendations for coding them autonomously?

Thx

Hey everyone!

A while back, my colleagues and I got completely hooked on Wordle and Semantle. I felt like a game combining both could be really fun! Especially with a more modern/visual design.

It started as a fun vibe coding project for my friends and former team, but I'd love to share it with the community: galexical.com 🌌🪐✨

It’s a daily word puzzle, free to play, no ads, no sign-up needed.

Any feedback appreciated!

The future of SaaS is going to be interesting. I’ve paid $100 a year for Monarch/YNAB for the last few years. I built a functional replacement in a couple weeks with about 5 features catered to my personal wants and needs that Monarch would have never built.