e7h4nz

We had a similar journey with Neon's branching. Initially it was a huge win for our CI workflows — spinning up an isolated, production-shaped database per PR made migration testing and integration checks dramatically more realistic than seed fixtures ever were.

That said, we've since pulled back from branching production schemas, and the reason is data masking. In principle you can define masking rules for sensitive columns, but in practice it's very hard to build a process that guarantees every new column, table, or JSON field added by any engineer is covered before it ever touches a branch. The rules drift, reviews miss things, and nothing in the workflow hard-fails when a new sensitive field slips through.

Most of the time that's fine. But "most of the time" isn't the bar for customer data — a single oversight leaking PII into a developer environment is enough to do real damage to trust, and you can't un-leak it. Until masking can be enforced by construction rather than by convention, we'd rather pay the cost of synthetic data than accept that risk.

If AI agents can proficiently use whatsapp I would assume that two-thirds of the people chatting with me in my contacts are actually just bots messaging me.

In this problem domain, I believe humanity is still in a very early stage. What we can do is treat the agent and its operating environment as a "black box" and audit all incoming and outgoing network request traffic.

This approach is similar to DLP (Data leak prevention) strategies in enterprise-level security. Although we cannot guarantee that every single network request is secure, we can probabilistically improve safety by adjust network defense rules and conducting post-event audits on traffic flow

Did you actually read this article or try to understand what OneCLI does?

Removed microservices and RPC, keep all TypeScript codes in a single monorepo. Avoiding `any` and using ts-rest automatically keep types synchronized between the web and frontend applications.

This has made my life much easier.

I worked on a core Spring Boot project for five or six years at a very large enterprise. In my opinion, the most dangerous thing about this framework is that it makes its core users feel far too self-assured.

When looking at problems, your mind becomes consumed with how to force everything into design patterns—like architectural separation, DI, or interface / implementation split. This causes developers to lose sight of the actual essence of the problem because they are obsessed with conforming to the framework.

Because the ecosystem and toolchain surrounding Spring Boot and Java are so mature and well-supported, it is very easy to find community tools that make you feel like you are doing things the "right way."

I only realized these issues after I left Spring Boot and Java development behind. Now, I much prefer using TypeScript or Python to write code (for example, web servers).

I also prefer using various SaaS solutions to handle authentication and user registration rather than rebuilding it all myself with Spring Boot Security. I honestly never want to go back to the days of writing Java again.

Agreed.

we hit some wired case on Adreno 530, ran into bizarre GPU instruction set issues with the compute shader compressor, that only manifested on Adreno 53x. Ended up having to add a device detection path, and fall back to CPU compression. which defeated much of the point.

I really resonated with the end of README.md.

I have a huge stack of embedded development boards at home—all kinds of SBCs, microcontrollers, FPGAs, and more. Over the years, as a hobbyist, I've bought them consistently. Overall, I’ve definitely bought much more than I’ve actually used.

Before LLMs came around, the friction in using them involved dealing with various compiled manuals and spec requirements. Just setting up the environment could consume the entire focus of the project before I even started writing the actual logic or code.

Now, I use cc to specifically handle those inner layers that aren't really part of the creative design. When it comes to what I actually want to build, the most interesting part is the creative process. I use cc to handle the environmental noise, things like linking errors, driver conflicts, register initialization failures, etc, so I can focus on the work itself.

LLM for researching and writing the code, while human handles the architectural decisions. This seems like the correct way to divide the work.

On a practical level, you're right, most of my team's work is done in Verilog.

That being said, I still have a preference for the VHDL simulation model. A design that builds correctness directly into the language structure is inherently more elegant than one that relies on coding conventions to constrain behavior.