1necornbuilder

This matches something I've observed from the opposite end of the spectrum. I'm not a developer, I build production software entirely through AI chat (no IDE, no manual commits). My codebase is a computer vision system running on Google Cloud Run that monitors industrial cranes in real time. The strict-guardrails effect you describe is real, but from my vantage point the mechanism is slightly different. When I'm prompting Claude to build or fix something, a codebase with strict typing and tight lint rules gives the model a much narrower solution space. It's not just that the model anticipates constraints but it's that the constraints eliminate a whole class of "plausible but wrong" outputs that I, as a non-developer, would have no way to catch in review. Your cross-file invariant problem is exactly where things break down for me too. Individual files come back clean, but interactions between components, especially across my Flask routes, WebSocket handlers, and GCS integrations is where silent failures happen. I've started adding explicit integration tests as part of my prompts ("before you return code, verify this function's output will be consumed correctly by X") but it's still the hardest part of building production systems this way. Curious whether your team has found any tooling that helps surface cross-file contract violations earlier in the loop.

The "cognitive debt" framing resonates, but from an unexpected direction. I'm not a developer. I've never written a line of code. I built enterprise software, a live computer vision system monitoring industrial cranes, deployed on Google Cloud Run, generating six figures in contracts, entirely by chatting with Claude. No IDE, no terminal muscle memory to lose.

For me, there is no cognitive debt in the code. There's no ground truth I'm losing touch with, because I never had it. The ground truth I bring is domain knowledge: fifteen years of understanding what an industrial operator actually needs to see on a screen at 3am. What Breen describes as "junk food", the dopamine hit of watching Claude build a new feature is, for domain experts like me, the first time in history we could participate in building at all. The gap that existed wasn't "developer loses touch with code." It was "person closest to the problem could never build the solution." But his core point about writing holds, even here. The thinking that produces good software requirements, the careful articulation of what needs to be built and why, that remains irreducibly human. My most important contributions to my own codebase aren't commits. They're the precise questions I ask. Maybe cognitive debt is domain-specific. Developers accumulate it. Domain experts spend it.

Real-world CGNAT use case that might be relevant here: I'm running an industrial AI monitoring system (computer vision on live RTSP camera feeds) deployed on Google Cloud Run. The cameras are behind an ISP that blocks port forwarding entirely — a common apartment/SMB situation. Tailscale solved this completely. The Cloud Run container joins the tailnet, the camera's RTSP server gets a 100.x.x.x address via MediaMTX, and the container reads the stream over the private mesh as if everything were on the same LAN. No public exposure, no ISP negotiation, no port forwarding rules. The Peer Relay announcement matters for this setup specifically: my Cloud Run instance spins up fresh containers under load, and DERP relay fallback was occasionally adding latency during the NAT traversal handshake on cold starts. Peer Relays distributing that relay burden to edge nodes should reduce that.

One question for the Tailscale folks: for ephemeral compute (Cloud Run, Lambda, Fly.io), where containers may spin up/down frequently, how does peer relay selection work when the relaying node itself might be transient?