Writing

GLM-5.2 High: Excellent Results on a Green-Field Project

· 8 min read

I've been running Claude's Opus model through my agent stack for months. It's excellent. So when I started a new green-field project — a personal AI assistant called "Second Brain" — I expected to use it and move on. Instead, I tried GLM-5.2 High on a whim, and I haven't switched back.

This isn't a benchmark post. It's a "I used this model to build a real thing and it went remarkably well" post. The thing was a Slack-integrated, SMS-capable, voice-controlled personal assistant called Second Brain. Second Brain itself runs its agent loop locally via Ollama, but I used GLM-5.2 High through Devin Desktop as the coding model to build it. The experience was excellent for this specific kind of work, and I want to explain why.

The project

Second Brain is a personal life assistant. It runs locally via Ollama, talks to me through Slack, and has tools for managing my Todoist tasks, Google Calendar, Gmail, SMS messages, and LogSeq notebooks. It can send texts through a Tasker bridge on my Android phone, draft and send emails, create calendar events, and respond to voice commands through a Tasker widget with text-to-speech.

The architecture is straightforward: a FastAPI HTTP server, a Slack bot in Socket Mode, a ReAct-style (Reasoning + Acting) agent loop, and a SQLite-backed memory store. The agent uses tool calling to interact with external services, and a Slack-based approval gate for higher-risk actions like sending emails to other people or sending SMS to someone who hasn't texted me recently.

This is green-field work. No existing codebase to learn, no legacy patterns to follow, no established conventions to respect. Just a blank directory and a list of things I wanted the assistant to do.

Why GLM-5.2 High surprised me

I've used Claude's Opus model extensively through my agent fleet at Stonepath. It's the model I trust for production work. When I started Second Brain, I figured I'd use it. But GLM-5.2 High was available as a model option in Devin Desktop, and I wanted to see how it handled a from-scratch build.

The difference showed up in the first session and stayed consistent throughout development. Here's what I noticed:

It writes code that runs the first time

This is the metric I care about most for agentic coding, and it's where GLM-5.2 High consistently impressed me. Not every snippet — that's not realistic. But the hit rate for "the code does what I asked without a syntax error or a missing import or a wrong API call" was noticeably high. I spent less time in the debug-edit-retry loop and more time building the next thing.

With Opus, I've gotten used to a rhythm: the model writes something close, I fix one or two things, we move on. With GLM-5.2 High, the fixes were rarer. The first pass was more often correct. That compounds over the course of a project.

It follows complex, multi-constraint instructions

Second Brain has a layered approval system. SMS replies to recent inbound texts are auto-approved. New SMS messages to contacts who haven't texted me require approval in a Slack thread — approvable by emoji reaction or by replying with a keyword. Email drafts need no approval. Sending emails to myself is auto-approved; sending to anyone else is gated. Calendar events and Todoist tasks are auto-approved (low risk). Notebook writes are gated.

That's a lot of conditional logic to explain to a model and have it apply correctly across different tool calls. GLM-5.2 High got the gating right. It didn't over-gate (asking for approval when it shouldn't) or under-gate (sending something without approval when it should have asked). The system prompt describes the rules in prose, and the model applied them correctly in practice.

It doesn't over-explain

This sounds minor but it matters for a personal assistant. When I ask "what's on my list today?", I want the tasks, not a paragraph about how it queried the Todoist API. GLM-5.2 High's responses were concise without being terse. It gave me the information and stopped. Claude tends to be more verbose — helpful in a blog-writing context, less helpful when you're reading the response on a phone screen or hearing it through TTS while driving.

It handles tool-calling naturally

The ReAct loop requires the model to decide when to call a tool, which tool to call, what arguments to pass, and when to stop calling tools and give a final answer. GLM-5.2 High made these decisions cleanly. It didn't hallucinate tool arguments. It didn't call tools it didn't need. It didn't get stuck in a tool-calling loop. The tool-use behavior felt more like a model that's been trained on real agentic workflows than one that's been told about them in a system prompt.

Where it's not better (yet)

Honesty matters here. GLM-5.2 High is not universally the best model for every task. It excelled for this specific kind of work — green-field agentic coding with tool use. There are areas where I'd still reach for other models:

  • Long-context reasoning. When I need to feed a model an entire codebase and ask "where is the bug?", Opus handles the volume better. GLM-5.2 High is good, but Opus has a longer effective context window in practice.
  • Complex refactoring. For surgical edits across a large existing codebase with established patterns, I'd still trust Opus more. The green-field advantage flips when the field isn't green.

The point isn't that GLM-5.2 High is the best model. The point is that for a specific and increasingly common use case — building something new with an agent that calls tools and writes code — it's the best experience I've had.

The vendor-agnosticism payoff

This is where the architecture I wrote about in my last post pays off. I didn't have to migrate anything to try GLM-5.2 High. I was already using Devin Desktop (formerly Windsurf) for development, and GLM-5.2 High was available as a model option. I just selected it and started building. No SDK swap. No infrastructure change. No code modification.

If I had built directly on a single provider's SDK, trying GLM-5.2 High would have meant either writing a new integration or giving up on the experiment. Instead, it was a model selection. That's the vendor-agnosticism thesis in practice: the cost of trying a new model should be zero, and when it is, you actually try new models.

Devin is running a promotion for free GLM-5.2 High use through August 15th, which made the experiment cost nothing. I kept using it because it was better. Neither of those things would have happened if I'd been locked into a single provider.

What I built

To give a sense of the pace: with GLM-5.2 High as the coding model, I built:

  • A FastAPI HTTP server with endpoints for GPS updates, inbound SMS, outbound SMS queue polling, SMS sent confirmation, and voice messages
  • A Slack bot with Socket Mode integration, approval gating with emoji reactions and keyword-based thread approval
  • A ReAct-style agent loop with tool calling for Todoist, Google Calendar, Gmail, SMS, Google Contacts, LogSeq notebooks, and GPS-based reminders
  • An SMS connector with a queue-based pull model (Tasker polls the server, sends texts natively, confirms back)
  • A Gmail connector with draft creation and risk-based send approval
  • A Google Contacts connector for name-to-phone and name-to-email resolution
  • A voice integration via Tasker's Get Voice action and TTS — speak a question, get a spoken answer back
  • Emoji shortcode stripping for SMS (because :partying_face: in a text message is not a party)
  • An async job system for voice requests so Tasker's 40-second HTTP timeout doesn't kill long agent responses

That's not a list of "the model wrote this for me." I drove every session. I made the architecture decisions. I debugged the Tasker JavaScriptlet issues (there were many). But the model was the coding engine, and the pace was faster than I've experienced with Opus on similar green-field work.

Would I use it for client work?

For green-field prototypes and internal tools — yes, without hesitation. For production systems with existing codebases, complex refactoring, or long-context requirements — I'd evaluate per project. The model is good enough that it's worth the evaluation. That's the bar, and GLM-5.2 High clears it.

The broader point is that the model landscape is moving fast enough that "which model is best" is now a per-project question, not a universal one. The systems that win are the ones that can switch models in one line. The systems that lose are the ones that have to plan a migration every time a new model ships.

Closing

I didn't expect to write this post. I expected to use Opus, build my assistant, and move on. Instead, I tried a model on a whim, it was better for the work I was doing, and I kept using it. I now have a fully functional personal AI assistant with SMS, email, calendar, voice, and task management — and the model that built it with me wasn't the one I would have predicted.

That's the value of vendor-agnostic infrastructure. Not that any specific model wins, but that you can find out which one does without paying a switching cost to learn.

If you're building agentic systems and want to talk about model selection, vendor insulation, or the specific architecture decisions that make hot-swapping models a one-line change — get in touch. I'm taking a small number of conversations with teams that are thinking through these decisions.