Three unrelated-looking pieces from the Japanese tech blogging platform Zenn turn out to share a common thread: they all push back against assumptions developers make about how AI systems actually behave, versus how we imagine they behave on paper.
From prompt experiments to fixed pipelines
The first piece continues a series of thought experiments about what the author calls an ‘evolutionary pipeline’ — a system architecture where LLMs handle exploratory reasoning while a task is still undefined, and that reasoning gets ‘frozen’ into deterministic code once a stable pattern emerges. If the environment changes again, the system falls back into LLM-driven exploration.
The interesting question this article tackles is: how do you actually discover what that first fixed pipeline should look like? You can go pretty far with a whiteboard: define the product vision, sketch the UX, decide what each processing step needs as input and output. But the moment you try to fill in the middle — what actually happens between input and output — pure design documents run out of answers. No amount of architecture diagramming tells you what transformation logic a step truly needs, because that logic only reveals itself when it meets real data.
The proposed fix is refreshingly low-tech: don’t try to hand-code the processing step. Run it through a prompt first. Feed real inputs into an LLM instructed to perform that step, look at what it produces, and use the patterns you observe to reverse-engineer the actual processing rules. Only after the prompt-driven version has proven stable across enough real examples do you promote it to fixed, deterministic code. In other words, the LLM isn’t just a production component — it’s a discovery tool for finding the specification you couldn’t write from a whiteboard alone. This is a genuinely useful mental model for teams building AI features: treat your first LLM call not as the final implementation, but as a live requirements-gathering exercise that data itself is running for you.
Why asking a model ‘what version are you?’ is a dead end
The second article addresses a practical annoyance that’s become common as ChatGPT, Claude, and Gemini all roll out frequent silent model updates. According to the piece, as of a mid-2026 refresh, ChatGPT moved to GPT-5.6 (in Sol/Terra/Luna variants), Claude to Opus 5, and Gemini to Gemini 3.6 Flash — accessible simply by reselecting the model in each app’s picker UI.
The more important point, though, is a debugging trap many developers fall into: asking a chatbot directly “what model are you?” is not a reliable way to verify what’s actually running. The author explains that models have no built-in mechanism to inspect their own weights or deployment configuration — they can only answer based on whatever description happens to be embedded in their system prompt. If that system-prompt text is outdated or vaguely worded, the model will still answer confidently, just incorrectly.
This matters beyond mere trivia. Teams building products on top of these APIs sometimes use self-reported model identity as a sanity check in logs or as part of automated testing. That’s a fragile assumption: the model’s answer reflects what its operator told it to say, not ground truth about the underlying weights serving the request. If you need to confirm which model version handled a request, the only dependable path is checking API response metadata, vendor changelogs, or explicit version parameters — not conversational self-report. It’s a small but recurring lesson in AI engineering: models are excellent at sounding certain about things they have no actual way to know.
Entropy as a progress gauge in reinforcement learning
The third piece is a more technical primer on entropy in reinforcement learning, explaining that the entropy measured during RL training is Shannon entropy from information theory, applied to a policy’s action probability distribution at a given state. For a discrete action space, entropy is computed as the negative sum over actions of the probability of each action times its log-probability — a standard formula for quantifying uncertainty in a distribution.
What makes this relevant for practitioners rather than just theorists is what entropy tells you operationally: it’s a proxy for how much an agent is still exploring versus how confidently it has converged on a strategy. High policy entropy early in training signals healthy exploration across the action space; as training progresses and entropy collapses toward specific actions, that’s a signal the policy is exploiting learned behavior. Tracking entropy over training steps gives engineers an early warning system — entropy collapsing too fast can mean premature convergence to a suboptimal policy, while entropy staying stubbornly high can mean the reward signal isn’t sharp enough to guide learning. It’s the same instinct as the first article’s approach to pipeline design: watch the actual behavior of the system under real conditions, rather than trusting that the intended design is what’s actually happening.
Taken together, these three pieces make a consistent case for developers working with modern AI systems: don’t trust specifications, self-reports, or intentions at face value. Whether it’s a processing pipeline, a chatbot’s claimed identity, or a policy’s training dynamics, the ground truth lives in observed behavior on real data — and that’s where the debugging, and the design, actually has to happen.