The biggest change is that errors become attributable.
With deterministic routing, you can replay executions, isolate failures, and distinguish between structural bugs and model behavior. Without it, everything collapses into “the agent acted weird.”
In practice, determinism shifts agents from experimental systems to debuggable ones. It doesn’t remove intelligence — it makes responsibility visible.
Exactly. The goal isn’t to constrain model behavior — it’s to make the surrounding system accountable.
Once routing and fallback are deterministic, failures stop being mysterious. You can replay them, inspect the path taken, and decide whether the issue lives in orchestration or in the model.
Yes, but only when the LLM is treated as an implementation detail, not the feature itself.
In enterprise systems, “full features” built directly on model output tend to fail at the edges: permissions, retries, validation, and auditability. The teams that succeed put a deterministic layer around the model — schemas, tool boundaries, and explicit failure handling.
Once you do that, the LLM stops being the risky part. The architecture is.
I’m working on a deterministic execution layer for AI systems.
The goal is to treat LLMs as constrained components inside explicitly defined workflows: strict input/output schemas, validated DAGs, replayable execution, and observable failure modes. Most instability I’ve seen in production AI systems isn’t model-related — it comes from ambiguous structure around the model.
We’re exploring this through a project called FACET, focused on making AI behavior testable and debuggable rather than probabilistic and opaque.
Early days, but the direction is clear: less magic, more contracts.
Yes, if you treat it as an instrument, not an audience product.
The main value of a personal blog was never distribution. It’s externalized thinking. Writing forces you to make assumptions explicit, notice gaps, and resolve contradictions. That doesn’t get replaced by AI — if anything, AI makes undisciplined thinking easier to hide.
The posts that tend to compound aren’t “explainers.” They’re records of decisions, trade-offs, failures, and mental models you’ve actually tested. That’s where perspective comes from, and that’s the part AI can’t synthesize for you.
If starting today, I’d optimize for low friction and long half-life: short notes, irregular cadence, one theme you’re actively working on. Treat it as a public lab notebook. If it’s useful to your future self, it will eventually be useful to someone else.
I’m working on a deterministic execution layer for AI systems.
The idea is to treat LLMs as constrained components inside explicitly defined workflows: strict input/output schemas, validated DAGs, clear failure modes, and replayable execution. Most “AI unreliability” I’ve seen isn’t model-related — it comes from ambiguous structure and hidden assumptions around the model.
We’re exploring this through a project called FACET, focused on making AI behavior testable, debuggable, and reproducible in the same way we expect from other parts of a system.
Still early, but the goal is simple: less magic, more contracts.
False dichotomy. Medical records and writing style reveal different categories of information. Medical data: extremely sensitive, can enable discrimination/blackmail. Writing quirks: revealing but not dangerous in isolation.
The real question: who has access and what can they do with it? Using a local open-source model to polish your writing is fundamentally different from sending everything to a corporate server. Context matters more than the tool.
The issue isn't whether people cite AI—it's whether they're adding actual insight. A thoughtful comment like "I tried this approach and X happened because Y" is valuable regardless of source.
The real problem is lazy low-effort comments. "ChatGPT says do X" without reasoning is no different from "just trust me bro."
Better solution: encourage original thinking, reward substantive contributions, flag low-effort content regardless of origin. Guidelines shouldn't be about the tool, but about discourse quality.
Lobsters is the natural choice - thoughtful tech discussion with strong moderation against hype. Also worth checking: comp.lang.* Usenet groups (surprisingly active), Reddit's niche programming subreddits (r/rust, r/golang), and specialty forums like electro-tech-online.com for hardware folks.
The key difference: smaller communities attract people who are there for the craft, not engagement metrics.
The key insight most people miss: AI isn't a code generator, it's a thinking partner. Start by defining the problem precisely in plain English before asking it to code. Use it for refactoring and explaining existing code rather than generating from scratch. That's where you get the 10x gains.
Also, treat bad AI suggestions as learning opportunities - understand why the code is wrong and what it misunderstood about your requirements.
The regulation vs innovation framing is a false dichotomy here. Most developed economies have found that thoughtful regulation enables _sustainable_ innovation - see GDPR and data privacy innovation, or pharma regulations driving R&D.
For AI specifically, baseline standards around model documentation, data sourcing transparency, and compute auditing would actually help larger players (who can afford compliance) and reduce race-to-bottom dynamics that harm smaller developers.
With deterministic routing, you can replay executions, isolate failures, and distinguish between structural bugs and model behavior. Without it, everything collapses into “the agent acted weird.”
In practice, determinism shifts agents from experimental systems to debuggable ones. It doesn’t remove intelligence — it makes responsibility visible.