In a hurry? Skip to the TLDR summary 😉

A while ago, I read Meagan Longoria’s excellent blog post about “Crawl, Walk, Run with Agentic Development”, and the concept resonated with me immediately because it perfectly described my own journey. The funny thing is: I’m still crawling — and despite all the hype around AI, I think that is perfectly fine.

I’m a BI Engineer and DBA, working roughly 80% with SQL Server and 20% with Power BI Report Server. I’ve spent years with databases, performance tuning, troubleshooting, reporting, and T‑SQL development. This is my comfort zone, where I know what good solutions look like — which is probably why AI often impresses me the least there.

For a long time, my AI experience consisted mostly of M365 Copilot chats: lots of copy and paste, lots of manually transporting context between applications, lots of “No, that’s not what I meant.” Sometimes it worked surprisingly well and genuinely accelerated my work, sometimes I spent so much time providing context that the productivity gains disappeared. Reading Meagan’s framework made me realize that I’m still very much in the crawl phase — and honestly, that’s still where I am today.

A few weeks ago, I got access to GitHub Copilot and was immediately excited. My expectation was simple: finally, AI directly inside the tools where I actually work. Around the same time, I started experimenting with agents. Building an agent was easy; teaching it to behave consistently was much harder. Sometimes it did exactly what I expected, sometimes it took completely different approaches to the same problem. I spent far more time refining prompts, instructions, guardrails, and behavior than anticipated.

Eventually, I stopped fighting the agent and instead asked AI to help me build an application that solved the problem directly — and surprisingly, that worked much better. I failed at building an AI solution but successfully used AI to build a traditional software solution. That taught me an important lesson: sometimes AI is most valuable not as the final product, but as the accelerator that helps you build the final product.

Even while I’m still crawling, GitHub Copilot already feels noticeably faster than basic M365 Copilot — not because of the model itself, but because of the integration. The difference between constantly moving context between applications and having AI directly available inside the development environment is much bigger than I expected.

There is one observation I can’t stop thinking about: the areas where I have the least experience are exactly the areas where GitHub Copilot impresses me the most, and the areas where I have the most expertise are often the areas where it impresses me the least. Whenever I work in technologies I barely know, AI feels almost magical. Whenever I work in technologies I know extremely well, AI feels merely decent — not bad, just not revolutionary.

This is where vibe coding shines for me. I’ve had great experiences with it: for example, building a custom delivery extension for Power BI Report Server in C# to prevent empty emails. Could I have written that from scratch? Probably not efficiently. With AI, I focused on the business problem while getting support for the language details, and the result worked. Another example was a Java application that determines possible join paths between database tables. Java is not my home turf, but AI lowered the barrier dramatically. Instead of spending weeks learning language details, I focused on the actual problem — and those moments feel transformational.

Then comes T‑SQL, and everything changes. My internal dialogue becomes: “I would have done that differently”, “Copilot, you misunderstood what I want”, or “Nice, but this didn’t really make me faster.” The generated SQL is often not wrong — the issue is that my expectations are much higher. I immediately notice questionable join strategies, unnecessary complexity, performance concerns, missed edge cases, and implementation choices I wouldn’t make. When I review Java code, I think: looks reasonable. When I review T‑SQL, I start debating indexing strategies with a machine. That may not be an AI problem — it may be a Martin problem.

When I first received GitHub Copilot access, my expectations were sky high. I imagined Copilot knowing my database context so well that I barely needed to explain anything. Reality was more complicated. Yes, the integration is valuable. Yes, it has more context than a browser chat. But no, it does not magically understand years of business logic, naming conventions, architecture decisions, and organizational history. You still need to explain things — just less than before.

GitHub Copilot feels very different depending on the tool. In VS Code, it feels mature: Ask mode, Edit mode, Plan mode, Copilot Agents, full transparency regarding token consumption — the experience feels polished. In SSMS, it still feels like a preview: no visibility into token consumption, usage information only for admins and delayed, Agent Mode only recently available, Ask Mode can execute queries directly but Agent Mode cannot. The agent creates a query, asks me to execute it manually, and then works with the results. Technically logical, but from a user perspective strangely indirect.

My biggest disappointment is code completions. Brent Ozar wrote positively about Copilot’s SQL capabilities, and I agree: it’s better than nothing. But I’ve been using Redgate SQL Prompt for years, and it has spoiled me. When a specialized tool is already excellent at suggesting join paths, table names, and completions, my patience for hallucinated column names is low. A colleague of mine is happy with Copilot’s completions because she had nothing before — so the productivity gain is real. For me, the baseline is different. I don’t compare Copilot to nothing; I compare it to SQL Prompt, and that’s a tougher comparison (not advertising SQL Prompt here).

The more I think about it, the more I wonder whether this is a perception issue. When AI generates C# or Java code, I don’t know enough to critique every detail. I mainly see that I solved a problem I otherwise wouldn’t have solved — and that’s valuable. When AI generates T‑SQL, I see every shortcut, inefficiency, questionable design choice, and missed optimization. Perhaps AI isn’t performing worse in my area of expertise — perhaps I’m grading it more harshly.

The real superpower of AI is not replacing expertise but helping us move outside our expertise. AI allows me to build things in technologies I barely know. It enables projects I would have postponed, outsourced, or never started — and that alone justifies the excitement.

TLDR

I’m still in the crawl phase of AI adoption, and I’m increasingly unsure why AI feels so different across my skill areas. GitHub Copilot feels almost magical when I work in technologies I barely know, because it helps me build things I wouldn’t normally attempt. In C# or Java, the acceleration is real and noticeable. In T‑SQL, however, AI often feels less impressive, and I keep wondering whether that’s due to my higher expectations or simply how I work. I see every inefficiency immediately, which makes the output feel more like review work than acceleration. That contrast makes me question how I can use AI more effectively in the areas where I’m already an expert. I’m still trying to understand why the gap feels so large and how to close it. Even so, AI already enables projects outside my comfort zone that I wouldn’t have tackled before.

Call To Action

I’m genuinely curious: do others experience the same thing? Does AI feel magical in areas where you’re still learning, and less impressive where you’re already an expert? I’d love to hear your experiences.

Disclaimer

This article was created based on my personal notes with support from Microsoft Copilot. While Copilot assisted in structuring and refining the content, all technical details have been carefully reviewed and developed by me.