AI
-
Teaching AI to Hide Messages in Plain Sight
It’s more of a party trick than anything else, but here’s the prompt:
Task: Construct a perfectly rectangular 4x26 ASCII block. The "Safe-Width" Symbol Set: ∫ √ ≈ ∆ ∑ ± ∞ ≠ ≡ ≥ ≤ ÷ ç ∂ Instructions: - Grid Specs: Exactly 4 rows and 26 characters per row - Hidden Message: Choose a 2-word uppercase phrase - Center the first word in Row 2 and the second in Row 3 - Fill all non-letter slots with random symbols from the set - Verify each row is exactly 26 charactersThose specific mathematical symbols maintain consistent width with uppercase Latin characters in monospaced fonts. This means the grid stays perfectly rectangular, and the words blend in better.
Is this useful? Not really. But it’s a neat demonstration of how to get AI to produce structured output.
Try it yourself and see what secret phrases you can embed.
-
I’m reading an article today about a long-term programmer coming to terms with using Claude Code. There’s a quote at the end that really stuck with me: “It’s easy to generate a program you don’t understand, but it’s much harder to fix a program that you don’t understand.”
I concur, while building it may be fun, guess what? Once you build it, you got to maintain it, and as a part of that, it means you got to know how it works for when it doesn’t.
-
Security and Reliability in AI-Assisted Development
You may not realize it, but AI code generation is fundamentally non-deterministic. It’s probabilistic at its core, it’s predicting code rather than computing it.
And while there’s a lot of orchestration happening between the raw model output and what actually lands in your editor, you can still get wildly different results depending on how you use the tools.
This matters more than most people realize.
Garbage In, Garbage Out (Still True)
The old programming adage applies here with renewed importance. You need to be explicit with these tools. Adding predictability into how you build is crucial.
Some interesting patterns:
- Specialized agents set up for specific tasks
- Skills and templates for common operations
- Orchestrator conversations that plan but don’t implement directly
- Multiple conversation threads working on the same codebase via Git workspaces
The more structure you provide, the more consistent your output becomes.
The Security Problem
This topic doesn’t get talked about enough. All of our common bugs have snuck into the training data. SQL injection patterns, XSS vulnerabilities, insecure defaults… they’re all in there.
The model can’t always be relied upon to build it correctly the first time. Then there’s the question of trust.
Do you trust your LLM provider?
Is their primary focus on quality and reliable, consistent output? What guardrails exist before the code reaches you? Is the model specialized for coding, or is it a general-purpose model that happens to write code?
These are important engineering questions.
Deterministic Wrappers Around Probabilistic Cores
The more we can put deterministic wrappers around these probabilistic cores, the more consistent the output will be.
So, what does this look like in practice?
Testing is no longer optional. We used to joke that we’d get to testing when we had time. That’s not how it works anymore. Testing is required because it provides feedback to the models. It’s your mechanism for catching problems before they compound.
Testing is your last line of defense against garbage sneaking into the system.
AI-assisted review is essential. The amount of code you can now create has increased dramatically. You need better tools to help you understand all that code. The review step, typically done during a pull request, is now crucial for product development. Not optional. Crucial.
The models need to review itself, or you need a separate review process that catches what the generating step missed.
The Takeaway
We’re in an interesting point in time. These tools can dramatically increase your output, but only if you build the right guardrails around them should we trust the result.
Structure your prompts. Test everything. Review systematically. Trust but verify.
The developers who figure out how to add predictability to unpredictable processes are the ones who’ll who will be shipping features instead of shitting out code.
-
Everyone crashing out over OpenCode situation. Why not just use Claude Code (2.1+)? Or you know, there’s AMP. AMP exists too, and it looks equally interesting to me.
-
Claude Code has been working great for me. OpenCode looks interesting, but uh, Opus 4.5 access is necessary for real work. I’m not doing any sketchy workarounds to get it running, and API pricing isn’t appealing either. So for now, OpenCode stays firmly in the “interesting” category.
-
Two Arguments Against AI in Programming (And Why I'm Not Convinced)
I’ve been thinking about the programmers who are against AI tools, and I think their arguments generally fall into two camps.
Of course, these are just my observations, so take them with a grain of salt, or you know, tell me I’m a dumbass in the comments.
The Learning Argument
The first position is that AI prevents you from learning good software engineering concepts because it does the hard work for you.
All those battle scars that industry veterans have accumulated over the years aren’t going to be felt by the new breed. For sure, the painful lessons about why you should do something this way and not that way are important to preserve into the future.
Maybe we’re already seeing anti-patterns slip back into how we build code? I don’t know for sure, its going to require some PHD level research to figure it out.
To this argument I say, if we haven’t codified the good patterns by now, what the hell have we all been doing? I think we have more good patterns in the public code than there are bad ones.
So just RELAX! The cream will rise to the top. The glass is half full. We’ll be fine… Which brings me to the next argument.
The Non-Determinism Argument
The second position comes from people who’ve dug into how large language models actually work.
They see that it’s predicting the next token, and they start thinking of it as this fundamentally non-deterministic thing.
How can we trust software built on predictions? How do we know what’s actually going to happen when everything is based on weights created during training?
Here’s the thing though: when you’re using a model from a provider, you’re not getting raw output. There’s a whole orchestration layer. There’s guardrails, hallucination filters, mixture of experts approaches, and the thinking features that all work together to let the model double-check its work before responding.
It’s way more sophisticated than “predict the next word and hope for the best.”
That said, I understand the discomfort. We’re used to deterministic systems where the same input reliably produces the same output.
We are are now moving from those type of systems to ones that are probabilistic.
Let me remind you, math doesn’t care about the differences between a deterministic and a probabilistic system. It just works, and so we1.
The Third Argument I’m Skipping
There’s obviously a third component; the ethical argument about training data, labor displacement, and whether these tools should exist at all.
I will say this though, it’s too early to make definitive ethical judgments on a tool while we’re still building it, while we’re still discovering what it’s actually useful for.
Will it all be worth it in the end? We won’t know until the end.
-
This “we” I use to mean us as in the human race, but also our software we build. ↩︎
-
-
Claude Cowork: First Impressions (From the Sidelines)
Claude Cowork released this week, and the concept seems genuinely useful. I think a lot of people are going to love it once they get their hands on it.
Unfortunately, I haven’t been able to get it working yet. Something’s off with my local environment, and I’m not entirely sure what. Claude Desktop sometimes throws up a warning asking if I want to download Node and I usually say no, but this time I said yes. Whether that’s related to my issues, I honestly don’t know. I did submit a bug report though, so hopefully that helps.
Here’s the thing that really impresses me: Anthropic noticed a trend and shipped a major beta feature in about 10 days.
That’s remarkable turnaround for something this substantial. Even if it’s not working perfectly for everyone yet (hi, that’s me), seeing that kind of responsiveness from a company is genuinely exciting.
I’m confident they’ll get it sorted before it leaves beta. These things take time, and beta means beta.
I have explored using the CLI agents outside of pure coding workflows and so I think there’s a lot more flexibility there than you might expect.
For now, I’m watching from the sidelines, waiting for my environment issues to sort themselves out.
-
OpenCode | The open source AI coding agent
OpenCode - The open source coding agent.
-
Amp is a frontier coding agent that lets you wield the full power of leading models.
-
After two days with Beads, my agent-based workflows feel supercharged. I’ve been experimenting with agents for about a month now, and something clicked. Could be the new Claude Code 2.1 upgrade helping too, but the combination is 🚀🚀🚀.