Last week a Newton customer messaged me: "My AI's long replies are getting cut off mid-sentence." First instinct was a token limit — but the cut-off responses were short, way shorter than where the model would naturally stop. No "..." either. Something was clipping output before it reached the screen. Bug, not a length issue.
Handing the Case to My AI
I didn't sit down and start digging through code. I sent the support ticket to my AI agent with one line: "go figure out what's causing this."
This is the part of running a business with AI that still feels strange — I don't triage anymore. I forward. The same way I'd hand a ticket to a senior engineer on a team. Except this engineer never sleeps, never context-switches, and reads every file in the codebase before opening its mouth.
Diagnosis: 15 Minutes
The AI didn't guess. It worked methodically:
1. Reproduce first. It tried different message shapes against the chat UI until it found a class of inputs that triggered the truncation. Specific pattern: replies that contained HTML-looking content (like a code snippet with <script> in it).
2. Trace the render path. It opened the markdown renderer and walked through it line by line. Found the culprit: when converting markdown to HTML, the renderer wasn't escaping HTML inside code blocks, inline code, or table cells.
3. Explain why it broke. When the AI responded with code like <script src="...">, that string got rendered as raw HTML. The browser parser saw a real script tag, entered "script-data-state", and started swallowing everything until it found a closing </script> — which never came. So the rest of the response just disappeared into the void.
Hidden bug. Most chat replies don't include HTML-looking content, which is why nobody had triggered it before. This one customer happened to ask a question with a script tag in it.
11 Tests Before the Fix
What I really like about this AI agent — and what makes it feel different from the "use AI to write code" tools I've tried — is what it did next. It didn't patch and call it done.
It wrote an 11-case test suite first:
- Code blocks containing HTML tags
- Inline code with HTML tags
- Table cells with HTML tags
- Unclosed HTML tags
- Self-closing tags
- HTML entities (
&,<, etc.) - ...and 5 more edge cases
Ran the tests against the unfixed code first — most of them failed, exactly as expected. That's how you confirm your tests actually catch the bug before you go fix it.
Then it patched escapeHtml() in three places — code blocks, inline code, and table cells. Reran. 11/11 passed.
This is senior engineer behavior. The AI didn't just want to "make the bug stop" — it wanted regression coverage so this exact class of bug couldn't sneak back in. I've watched a lot of my AI fix production bugs in real time — including the time it traced a blurry-clip issue to a hidden Facebook Graph API limit and rewrote the downloader on the spot — and the test-first instinct is what separates "AI that does work" from "AI that types code."
The Real Magic: Multi-Server Deploy
Here's the part I want to talk about most.
Newton currently has 6 customers. Each one runs their AI agent on their own dedicated server — fully isolated, full root access, their data, their domain. That's the whole point of Newton: it's not a shared platform, it's your server.
Which is great for ownership and privacy. But it means hotfixes don't ship in one deploy. They ship six times.
Old-school workflow:
- SSH into customer 1's server
git pull- Restart the service
- Tail logs, verify the service came up clean
- Repeat × 6
I did exactly zero of those steps. The AI SSHed into each server one at a time, ran the update, watched the service restart, confirmed it was healthy, then moved to the next. About 30 seconds per server. I sat there with a coffee and watched the terminal scroll.
From the moment the customer messaged me to the moment all 6 servers were running the patched version: under an hour.
Why This Matters
I write a lot about AI agents, and the thing I want people to understand is that this isn't ChatGPT-with-extra-steps. The AI in this story did the entire production engineering loop:
- Diagnose — reproduced the bug from a customer description
- Investigate — read the code, traced the render path, found root cause
- Test — wrote regression tests before changing anything
- Fix — patched three call sites
- Deploy — pushed the fix to 6 production servers
- Verify — confirmed each server came up healthy
One pipeline, no handoffs, no "I'll get to that tomorrow." That's the difference between an AI agent with server access and a chatbot that types suggestions.
The Managed Server Advantage
Most people don't immediately get why Newton is a managed server, not just "rent a VPS and install Claude Code yourself."
This story is the answer.
If those 6 customers were self-hosting, here's what would have happened: I'd post about the bug, customers would have to know they were affected, customers would have to read release notes, customers would have to remember to git pull and restart. Some would. Most wouldn't. The bug would silently affect users for weeks.
Because Newton is managed, the customer didn't have to do anything. Most of them never even noticed there was a bug — by the time they next opened the product, it was already fixed.
It's like owning a car. The car is yours, you drive it where you want, you customize it, you park it in your garage. But when there's a recall for a safety issue, you don't have to figure out the fix yourself — the manufacturer pulls you in and patches it.
Newton is the same model for AI infrastructure: you own everything, but we keep it healthy.
Self-Host vs Managed
To be clear, I'm not saying managed is better than self-hosting in every case. They're for different people:
Self-host if you're a developer, you enjoy server admin, you want to know exactly what's running on your machine, and you don't want anyone else with a key to it. Totally legitimate. Most of the early builder culture works this way.
Managed (Newton) if you're a business owner who wants AI doing real work — running ads, replying to support, building tools, managing content — but you don't want to wake up at 3am because a service crashed. You want hotfixes to just happen. You want to focus on your business, not your infrastructure.
The customer in this story is the exact person Newton is built for. They reported a bug. An hour later it was fixed. They didn't read changelogs. They didn't restart anything. They just kept using the product.
The Loop, End to End
This case is one of the cleanest examples I have of what it actually looks like when AI runs the engineering side of a SaaS. Real customer ticket. Real production code. Real deploys to real servers. No simulation, no demo, no "imagine if AI could…"
And the only thing I had to do was forward the message and watch. Same instinct showed up the morning a 3% provisioning bug took down a brand-new customer's server at 5am — I told the agent "go look" and went back to sleep.
If you're a business owner who wants this kind of operation running for you — your own AI agent, your own server, automatic hotfixes pushed by a team that quietly handles infrastructure — try Newton. Setup takes about 10 minutes. Hotfixes are on us, forever.
— Pond