|
| 1 | +# Yes, Bot! How I Learned to Stop Worrying and Love the AI (Responsibly) |
| 2 | + |
| 3 | +*A Holiday Gift from DevRel: IRIS PGWire and the Art of Structured Creativity* |
| 4 | + |
| 5 | +**By Thomas Dyar, Sr. Manager AI Platform and Ecosystem, InterSystems** |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## The Rut |
| 10 | + |
| 11 | +I'll be honest: Up to a year agoI was not doing much coding -- I was sick of it. |
| 12 | + |
| 13 | +I had been a hands-on software engineer and data scientist After years, but a few years before starting at InterSystems I had gotten worn down by the tedium of software development. The endless cycle of boilerplate, debugging, and context-switching left me creatively depleted. Like Jim Carrey's character in *Yes Man*, I found myself saying "no" and "not *again*" -- so much so that I switched jobs! But I must say that I missed the creative aspects of coding. |
| 14 | + |
| 15 | +Then AI coding assistants arrived. And I became a "Yes Man" for bots. |
| 16 | + |
| 17 | +--- |
| 18 | + |
| 19 | +## Act I: Exuberance ("Yes to Everything!") |
| 20 | + |
| 21 | +When I first started using AI coding assistants (Windsurf, then Cline, then Roo Code, now Claude Code), it felt like magic. Natural language → working code. I said "yes" to every suggestion, every refactor, every wild idea. |
| 22 | + |
| 23 | +My first major AI-assisted project was an internal project I started a few months ago - a vector search and "RAG templates" collection for IRIS. I was so excited I let the bot run wild: |
| 24 | + |
| 25 | + |
| 26 | +*"Implement semantic search!"* Yes! |
| 27 | +*"Build a full RAG pipeline!"* Yes! |
| 28 | +*"Make it extensible!"* Yes! |
| 29 | +*"Add MCP support!"* Yes! |
| 30 | + |
| 31 | +The creative energy was back. Code was flowing. I felt productive again. |
| 32 | + |
| 33 | +Then my intern - a software engineering major - looked over the codebase. |
| 34 | + |
| 35 | +He was **NOT impressed**. |
| 36 | + |
| 37 | +Though I had implemented about 6 complete RAG methods based on academic papers, only 2 of them "really worked" -- the pytests were passing, but they had a lot of mocks that were being used instead of real database queries. In many cases "fast iteration" was admittedly "AI slop" - inconsistent patterns, duplicated logic, questionable architectural decisions. The bot had said "yes" to everything I asked, but nobody was saying "no" to bad ideas or "wait, let's think about this first." |
| 38 | + |
| 39 | +--- |
| 40 | + |
| 41 | +## Act II: The Trough of Reality |
| 42 | + |
| 43 | +That intern review was a wake-up call. Like Jim Carrey learning that saying "yes" to everything creates chaos, I had to face the downsides: |
| 44 | + |
| 45 | +- **Hallucinations**: The bot confidently generated code for APIs that didn't exist -- easy to spot, but annoyingly frequent and time-consuming to debug. |
| 46 | +- **Context drift**: Long sessions lost track of architectural decisions |
| 47 | +- **Quality variance**: Some outputs were brilliant; others needed complete rewrites |
| 48 | +- **The "Yes, and don't..." dance**: Every prompt became "Yes, add this feature... and don't break what we did yesterday... and don't forget that thing I mentioned three hours ago...", and many many exclamation points and ALL CAPS as I tried to communicate the severity of the issue ;) |
| 49 | + |
| 50 | +I had to admit that I was spending more time managing the bot than it was worth. The exuberance phase had ended, and I wasn't alone in being disillusioned. I needed a different approach, a course correction. |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +## Act III: Enter specify-kit ("Taming the Beast") |
| 55 | + |
| 56 | +I came to realize: **I needed a system, not just a bot.** |
| 57 | + |
| 58 | +That's when I discovered [spec-kit](https://speckit.org/) - a code assistant-agnostic workflow that transforms interaction with AI assistants. (AWS's [Kiro](https://kiro.dev) is another flavor of spec-driven AI-assisted development - the pattern is emerging across the industry.) Instead of freeform "yes," I now have structured specifications: |
| 59 | + |
| 60 | +### The Workflow |
| 61 | + |
| 62 | +``` |
| 63 | +/specify → /clarify → /plan → /tasks → /implement |
| 64 | +``` |
| 65 | + |
| 66 | +Each step produces artifacts that survive context windows: |
| 67 | + |
| 68 | +| Command | Output | Purpose | |
| 69 | +|---------|--------|---------| |
| 70 | +| `/specify` | `spec.md` | User stories, requirements, acceptance criteria | |
| 71 | +| `/clarify` | Updated spec | Resolve ambiguities before coding | |
| 72 | +| `/plan` | `plan.md` | Implementation strategy, architecture decisions | |
| 73 | +| `/tasks` | `tasks.md` | Ordered task list with dependencies | |
| 74 | +| `/implement` | Code + tests | Actual implementation | |
| 75 | + |
| 76 | +### What Changed |
| 77 | + |
| 78 | +**Before specify-kit:** |
| 79 | +> "Add Open Exchange support... no wait, don't auto-start the server... actually, check if module.xml exists first... and make sure the tests pass..." |
| 80 | +
|
| 81 | +**After specify-kit:** |
| 82 | +> `/specify make this an Open Exchange package` |
| 83 | +
|
| 84 | +The system asks clarifying questions, documents decisions, and generates implementation plans. When I picked "manual start" vs "auto-start" during `/clarify`, that decision was encoded into the spec and carried through to implementation. |
| 85 | + |
| 86 | +--- |
| 87 | + |
| 88 | +## The Proof: IRIS PGWire |
| 89 | + |
| 90 | +IRIS PGWire is my Christmas gift to the InterSystems developer community. It's a PostgreSQL wire protocol server that lets you connect **any** PostgreSQL client to IRIS: |
| 91 | + |
| 92 | +- **psql, DBeaver, Superset, Metabase, Grafana** - zero configuration |
| 93 | +- **psycopg3, asyncpg, SQLAlchemy, pandas** - all your Python favorites |
| 94 | +- **pgvector syntax** - use `<=>` for cosine similarity, `<#>` for dot product |
| 95 | + |
| 96 | +```bash |
| 97 | +# Quick Start |
| 98 | +git clone https://github.com/isc-tdyar/iris-pgwire.git |
| 99 | +cd iris-pgwire |
| 100 | +docker-compose up -d |
| 101 | + |
| 102 | +# Connect with any PostgreSQL client |
| 103 | + |
| 104 | +### Quick Demo: From Zero to Analytics |
| 105 | + |
| 106 | +Once your container is up, you’re not just connected to a database—you’re connected to an ecosystem. |
| 107 | + |
| 108 | +**1. The Classic Handshake (psql)** |
| 109 | +```bash |
| 110 | +psql -h localhost -p 5432 -U _SYSTEM -d USER |
| 111 | +``` |
| 112 | + |
| 113 | +**2. Standard SQL, IRIS Power** |
| 114 | +```sql |
| 115 | +-- This runs on IRIS, but feels like Postgres |
| 116 | +SELECT COUNT(*) FROM MyPatients WHERE category = "Follow-up"; |
| 117 | +``` |
| 118 | + |
| 119 | +**3. The "Killer Feature": pgvector Syntax on IRIS** |
| 120 | +This is where it gets interesting. You can use standard `pgvector` distance operators, and IRIS PGWire translates them into native IRIS vector functions on the fly: |
| 121 | + |
| 122 | +```sql |
| 123 | +-- Semantic search using the pgvector <=> (cosine distance) operator |
| 124 | +SELECT id, content |
| 125 | +FROM medical_notes |
| 126 | +ORDER BY embedding <=> TO_VECTOR("[0.1, 0.2, 0.3...]", DOUBLE) |
| 127 | +LIMIT 5; |
| 128 | +``` |
| 129 | +psql -h localhost -p 5432 -U _SYSTEM -d USER -c "SELECT 'Hello from IRIS!'" |
| 130 | +``` |
| 131 | + |
| 132 | +### The "Impossible" Connection: No IRIS Driver? No Problem. |
| 133 | + |
| 134 | +This isn’t just about making things *easier*—it’s about making things *possible*. |
| 135 | + |
| 136 | +Take **Metabase Cloud** or **Prisma ORM**. |
| 137 | + |
| 138 | +- **Metabase Cloud** is a beautiful, managed BI tool. You can’t upload an IRIS JDBC driver to their cloud servers. You are limited to their pre-installed list. |
| 139 | +- **Prisma** is the standard ORM for modern TypeScript developers. It uses a custom engine that doesn’t (yet) speak IRIS. |
| 140 | + |
| 141 | +Without a wire protocol adapter, these tools are locked out of your IRIS data. With **IRIS PGWire**, they just see a high-performance PostgreSQL database. |
| 142 | + |
| 143 | +**Demo: Prisma with InterSystems IRIS** |
| 144 | +Just point your `schema.prisma` at the PGWire port: |
| 145 | + |
| 146 | +```prisma |
| 147 | +datasource db { |
| 148 | + provider = "postgresql" |
| 149 | + url = "postgresql://_SYSTEM:SYS@localhost:5432/USER" |
| 150 | +} |
| 151 | +``` |
| 152 | + |
| 153 | +Now you can use Prisma’s world-class CLI and type-safety: |
| 154 | +```bash |
| 155 | +npx prisma db pull |
| 156 | +npx prisma generate |
| 157 | +``` |
| 158 | + |
| 159 | +### Built with Structured AI Collaboration |
| 160 | + |
| 161 | +What makes this project interesting isn't just the code - it's how it was built. The `specs/` directory contains **27 feature specifications** documenting the entire development journey: |
| 162 | + |
| 163 | +``` |
| 164 | +specs/ |
| 165 | +├── 001-postgresql-wire-protocol/ # Where it all began |
| 166 | +├── 002-sql-query-processing/ # Query translation layer |
| 167 | +├── 003-iris-integration-layer/ # IRIS backend connection |
| 168 | +├── 006-vector-operations-pgvector/ # AI/ML vector support |
| 169 | +├── 008-copy-protocol-bulk-operations/ |
| 170 | +├── 010-security-production-readiness/ |
| 171 | +├── 012-client-compatibility-testing/ # 8-language test matrix |
| 172 | +├── 019-async-sqlalchemy-based/ # FastAPI integration |
| 173 | +├── 025-comprehensive-code-and/ # Quality validation |
| 174 | +├── 026-doc-review/ # Documentation audit |
| 175 | +└── 027-open-exchange/ # This publication! |
| 176 | + ├── spec.md # Package requirements |
| 177 | + ├── research.md # Market analysis |
| 178 | + ├── plan.md # Publication strategy |
| 179 | + └── tasks.md # Implementation steps |
| 180 | +``` |
| 181 | + |
| 182 | +Each feature started as a natural language description like: |
| 183 | + |
| 184 | +> *"PostgreSQL Wire Protocol Foundation - SSL/TLS handshake, authentication, session management, and basic protocol compliance"* |
| 185 | +
|
| 186 | +And became a structured specification with user stories, acceptance criteria, and `[NEEDS CLARIFICATION]` markers for decisions that required human judgment. |
| 187 | + |
| 188 | +**The Evolution:** |
| 189 | +- **Spec 001**: "Can we make PostgreSQL clients talk to IRIS?" |
| 190 | +- **Spec 006**: "What about vector search and AI workloads?" |
| 191 | +- **Spec 019**: "FastAPI developers need async support" |
| 192 | +- **Spec 027**: "Let's share this with the world" |
| 193 | + |
| 194 | +**The result:** 171 tests passing across 8 programming languages. Production-ready. |
| 195 | + |
| 196 | +--- |
| 197 | + |
| 198 | +## What I Learned |
| 199 | + |
| 200 | +### 1. Specifications are Force Multipliers |
| 201 | + |
| 202 | +A 30-minute investment in `/specify` and `/clarify` saves hours of debugging and rework. The bot doesn't have to guess your intent when it's documented. |
| 203 | + |
| 204 | +### 2. Clarification Questions Reveal Gaps |
| 205 | + |
| 206 | +When specify-kit asked "Should the server auto-start after ZPM installation?", I realized I hadn't decided. That one question prevented a design mistake that would have affected every user. |
| 207 | + |
| 208 | +### 3. The Spec is the Source of Truth |
| 209 | + |
| 210 | +When context windows overflow or sessions restart, the spec survives. The bot can read `spec.md` and get back to work without re-explaining everything. |
| 211 | + |
| 212 | +### 4. Test-First Still Matters |
| 213 | + |
| 214 | +Every user story in the spec maps to acceptance criteria. Every acceptance criterion maps to a test. The bot doesn't "forget" to write tests because they're required by the spec. |
| 215 | + |
| 216 | +--- |
| 217 | + |
| 218 | +## Try It Yourself |
| 219 | + |
| 220 | +### IRIS PGWire |
| 221 | +- **GitHub**: https://github.com/isc-tdyar/iris-pgwire |
| 222 | +- **Open Exchange**: Coming soon! |
| 223 | +- **Quick Start**: 60 seconds with Docker |
| 224 | + |
| 225 | +### specify-kit |
| 226 | +- **GitHub**: https://github.com/github/spec-kit |
| 227 | +- **Usage**: Add to your Claude Code project at the command line with `specify init --here`and then in Claude Code run `/specify <what you want to build>` |
| 228 | +- **Alternative**: [Kiro by AWS](https://kiro.dev) - similar spec-driven approach in a full IDE |
| 229 | + |
| 230 | +--- |
| 231 | + |
| 232 | +## The Balance |
| 233 | + |
| 234 | +I'm no longer a "Yes Man" for bots. I'm not saying "no" either. |
| 235 | + |
| 236 | +I'm saying: **"Yes, with structure."** |
| 237 | + |
| 238 | +The creative energy is back. The tedium is managed by the bot. But the specifications ensure we're building the right thing, the right way. |
| 239 | + |
| 240 | +Happy Holidays from InterSystems. May your prompts be clear and your tests be green. |
| 241 | + |
| 242 | +--- |
| 243 | + |
| 244 | +*Thomas Dyar is Sr. Manager of AI Platform and Ecosystem at InterSystems, where he works on developer enablement, AI tooling, and making databases accessible to everyone. When he's not taming AI bots, he's probably watching Kubrick films and thinking about human-machine collaboration.* |
| 245 | + |
| 246 | +--- |
| 247 | + |
| 248 | +## Resources |
| 249 | + |
| 250 | +- [IRIS PGWire GitHub Repository](https://github.com/isc-tdyar/iris-pgwire) - The "after" (27 specs, 171 tests) |
| 251 | +- [Internal project started a few months ago](https://github.com/isc-tdyar/iris-vector-rag) - The "before" (no specs, AI slop) |
| 252 | +- [specify-kit Claude Code Workflow](https://github.com/ProfSynapse/specify-kit) |
| 253 | +- [Kiro - AWS Spec-Driven Development](https://kiro.dev) |
| 254 | +- [Claude Code Documentation](https://docs.anthropic.com/claude-code) |
| 255 | +- [InterSystems Open Exchange](https://openexchange.intersystems.com) |
0 commit comments