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.

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

This has made my life much easier.

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.

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

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.

Technologies like ARM AFRC and PVRIC4 can only be used on modern flagship devices. Since flagship memory bandwidth isn't particularly strained to begin with, we end up spending a massive amount of effort on optimizations that only benefit a fraction of users. In most cases, teams are simply unwilling to pay that development cost.

The driver behavior of PVRIC4 perfectly encapsulates the current state of mobile GPU development: 1. The API promises support for flexible compression ratios. 2. The driver silently ignores your request and defaults to 1:2 regardless. 3. You only discover this because a PowerVR developer quietly confirmed it in a random comment section.

This is a microcosm of the "texture compression hell" we face. Beyond the mess of format fragmentation, even the driver layer is now fragmented. You can't trust the hardware, and you can't trust the software.

While the test results for ARM AFRC are genuinely impressive—it's not easy to outperform a software encoder in terms of quality—it remains problematic. As long as you cannot guarantee consistent behavior for a single codebase across different vendors, real-time CPU and GPU encoders remain the only pragmatic choice.

For now, hardware compression encoders are just "nice-to-haves" rather than reliable infrastructure. I am curious if anyone has used AFRC in a production environment? If so, I’d love to know how your fallback strategy was designed.

VHDL had this figured out as early as 1987. I spent many years writing Verilog test benches and chasing numerous race conditions; those types of bugs simply don't exist in VHDL.

The Verilog rules—using non-blocking assignments for sequential logic and blocking assignments for combinational logic—fail as soon as the scenario becomes slightly complex. Verilog is suitable when you already have the circuit in your head and just need to write it down quickly. In contrast, VHDL forces you to think about concurrent processes in the correct way. While the former is faster to write, the latter is the correct approach.

Even though SystemVerilog added some patches, the underlying execution model still has inherent race conditions.

I fully agree, without clear architecture docs, I wouldn't trust an infra service either. We're working on technical documentation now.

Here is some quick summaris about our arch, we uses E2B's managed sandbox (Firecracker microVMs), and keep working on our own Firecracker runner implementation (independent of E2B) with experimental network firewall features.

We use E2B because easy to start, no infrastructure needed, but self-hosted give developer full control, custom security policies, run on your own infra.

We're at an early stage and planning to release end of Jan. Detailed architecture docs are coming soon. Feedback welcome!