Tom Hundley
Part 1 of 5
🤖 Ghostwritten by Claude · Curated by Tom Hundley
This article was written by Claude and curated for publication by Tom Hundley.
A confession, a challenge, and the beginning of an experiment that might fail spectacularly.
I haven't written a line of code in two years.
Let that sink in. I'm a software developer. I've been building software for over two decades. I came up through the classic Microsoft stack—ASP.NET, C#, SQL Server, the whole ecosystem. I was a Microsoft fanboy before it was cool, stayed a fanboy when it wasn't, and only recently stopped being one.
Yet here I am, running a development team at Elegant Software Solutions, shipping production applications, and I haven't typed public class or void Main or any of it in roughly 730 days.
What changed? I learned to orchestrate AI agents to write code for me.
In February 2025, Andrej Karpathy—former AI director at Tesla, OpenAI co-founder, and one of the most respected voices in machine learning—coined a term that perfectly captures what I've been doing. He called it "vibe coding."
His original post on X described it this way:
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good."
Karpathy explained that he talks to Cursor Composer with SuperWhisper—barely touching the keyboard—asking for things like "decrease the padding on the sidebar by half" and always clicking "Accept All" without reading the diffs.
The term resonated so strongly that Collins Dictionary named "vibe-coding" its Word of the Year for 2025. Google Cloud defines it as "an emerging software development practice that uses artificial intelligence to generate functional code from natural language prompts." IBM calls it "a workflow where the primary role shifts from writing code line-by-line to guiding an AI assistant to generate, refine, and debug an application through a more conversational process."
By March 2025, Y Combinator reported that 25% of startup companies in its Winter 2025 batch had codebases that were 95% AI-generated. Sundar Pichai revealed that over 30% of new code developed at Google now comes from AI.
This isn't a fringe movement anymore. This is the future arriving faster than anyone expected.
I didn't plan to stop writing code. It happened gradually, then suddenly.
It started with Claude Code and Cursor. I was skeptical at first—we all were. AI-generated code seemed like a novelty, good for demos but not for real work. Then I tried it on a real project. A Next.js application. I described what I wanted. The agent wrote it. I reviewed it, asked for changes, and it fixed them. Hours of work compressed into minutes.
Then came React components. Then C# backend services. Then a full Blazor application that's now running in production. Each time, the pattern was the same: I described the intent, the agent produced the code, I reviewed and refined through conversation.
The key insight—and this is what separates vibe coding from "just using AI"—is that domain expertise matters more than syntax knowledge. I know what good software architecture looks like. I understand business requirements. I can spot when something's wrong. What I no longer need to do is translate that knowledge into keystrokes character by character.
I've become what we at ESS call an Agent Orchestrator—someone who directs AI systems to achieve outcomes rather than writing code directly. The role is less like being a craftsman hammering nails and more like being a conductor directing an orchestra.
And it works. Really works. For modern stacks.
Here's where my confession turns into a challenge.
Part of my team works with Microsoft Dynamics 365 Finance & Operations (D365 F&O). If you've never had the pleasure, let me paint you a picture of what development looks like in this ecosystem.
Imagine you want to write a simple customization—maybe add a field to a form, write some business logic, extend a workflow. Here's what the traditional D365 development experience requires:
Step 1: Provision a Development VM Through LCS
You start at Lifecycle Services (LCS), Microsoft's cloud-based management portal for D365. LCS is where you manage environments, deploy updates, and—relevant to our story—provision developer virtual machines.
You need an Azure subscription connected to your LCS project. You navigate to "Cloud-hosted environments," select your topology, agree to licensing terms, and deploy. Then you wait. The VM provisioning takes significant time, during which you're burning Azure credits and doing nothing.
Step 2: Connect to Your Dinosaur
The development VM you receive is pre-configured with:
Now, Git is technically supported—Microsoft even recommends it now that they're phasing out TFVC. But walk into most D365 shops and you'll still find teams running TFVC because migrating requires extra configuration, extra pain, and—here's the kicker—Lifecycle Services still checks for a TFVC repo when you deploy build environments. So some teams maintain a dummy TFVC repo alongside their actual Git workflow. Just to make LCS happy.
This is the D365 developer experience in a nutshell: technically modern options exist, but the ecosystem drags you backward at every turn.
Step 3: Wait. Then Wait Some More.
Now you're ready to write code. Except you're not, because first you need to sync the database. Then compile the models. Then wait for the AOS to start.
And the compilation times? They're legendary in the worst way possible.
Denis Trunin's benchmarks document what D365 developers already know: compilation is brutally slow. Community forum posts report the Application Suite taking "more than 9 hours" to compile in some cases.
One developer put it bluntly: "It seems to me like as a developer in Microsoft Dynamics AX 365 for Finance and Operations, I am spending the majority of my time waiting for Microsoft Dynamics AX 365 for Finance and Operations to compile, and not actually developing code."
Another: "Microsoft has to do something to improve the speed significantly because the development experience is so bad even I have 50GB RAM in the Azure."
This isn't just frustrating—it's expensive.
A typical cloud-hosted D365 development VM runs around $500-770 per month for a D13 v2 configuration. That's per developer. A team of five developers is burning $3,000-4,000 monthly just on VM costs, not counting the actual D365 licensing.
But the real cost is human time. When every build cycle takes 30+ minutes, when every deployment requires multiple manual steps, when you click a button and then wait... and wait... developers aren't developing. They're watching progress bars.
I watch my team deal with this, and I feel bad for them. They're talented developers doing work that matters. And they're trapped in a development paradigm that feels like stepping back 15 years.
Oh, and the language? It's called X++. It's a proprietary language that only exists in the Dynamics AX/365 ecosystem. It looks like C# had a baby with SQL, and that baby was raised by enterprise accounting software.
The tooling is limited. The documentation is... let's say "specialized." The community, while passionate, is small compared to mainstream languages. IDE support exists within Visual Studio, but it's a plugin ecosystem within an already-constrained environment.
Modern AI coding assistants are trained primarily on JavaScript, Python, TypeScript, C#, and other popular languages. X++ is a rounding error in their training data.
I used to defend Microsoft reflexively. Azure? Fantastic. .NET Core going cross-platform? Brilliant. VS Code? Game-changer. GitHub acquisition? Better than expected.
But when it comes to AI-assisted development, Microsoft fell behind—and I'm not sure they're catching up.
It started with copy and paste. ChatGPT would write code, I'd paste it into my editor, run it, hit an error, copy the error back into ChatGPT, get the fix, paste again. Crude, but the productivity gain was undeniable. That was my "holy shit" moment—AI could actually write the code for me.
Then I discovered Sourcegraph's Cody, and I was floored. No more copy-paste gymnastics. The AI was in the editor, reading my codebase, suggesting changes in context. One of my developers told me about Cursor when it first launched, and I initially refused to switch because Cody was already doing agentic coding—not just autocomplete, but actually executing multi-step tasks. Then Cursor got serious funding, the ecosystem exploded, and it became the go-to. From there I moved to Claude Code.
Here's the insight that emerged from using all these tools: the IDE is the body, and the LLM is the brain. The breakthrough wasn't any single tool—it was making the models interchangeable. You could swap brains depending on the task. Claude Sonnet for complex reasoning. GPT-4 for certain code patterns. Different models for different jobs.
Copilot never embraced this—not until it was too late. And for years, you couldn't even figure out what model you were using.
When Copilot launched in 2021, you got OpenAI Codex, a GPT-3 derivative fine-tuned for code. That was it. No choices. In 2023, Copilot Chat moved to GPT-3.5, then GPT-4—but GitHub was maddeningly opaque about which model was actually running. Users dug through logs and found both GPT-3.5 and GPT-4 being called. When pressed, a GitHub rep admitted "both models are in play" without clarifying when or why. The API endpoint still said "copilot-codex" even though—as a staffer later confessed—"we do not use the codex model any more." I remember having long debates with people deep in the Microsoft partner ecosystem, trying to figure out what the hell model we were actually paying for.
Meanwhile, Cursor was letting developers swap models based on the task. Claude Sonnet for complex reasoning. GPT-4 for rapid iteration. The ability to pick the right brain for the job.
Then Claude 3.5 Sonnet dropped in June 2024, and everything changed. It solved 64% of coding problems in benchmarks—up from 38% for Claude 3 Opus. Developers on Reddit started saying things like "Claude smokes GPT4 for Python and it isn't even close" and sharing stories of building entire apps that would have been impossible before. In August, Karpathy himself tweeted that he'd switched from GitHub Copilot to Cursor with Sonnet 3.5 because it was "now a net win."
The community had moved on. And Copilot? Still locked to GPT-4. No Claude. No choice.
Copilot didn't add model selection until October 2024—announced at GitHub Universe, four months after Sonnet 3.5 had already changed the game. Four months of developers saying "why would I use GPT-4 when Sonnet is so much better?" while Copilot users had no alternative.
Microsoft justified this with claims of "enterprise awareness" and "enterprise safety." I've heard these arguments in sales calls and boardrooms. With respect: it's a deflection. Governance and safety are real concerns—I take them seriously—but they're orthogonal to model selection. You can have rigorous security controls and still let developers choose capable models. The tools that are actually winning do exactly that.
Even now, Copilot lags. I recently tried using it for code reviews instead of dedicated tools, and the latest models still weren't available. They're playing catch-up, trying to stay relevant.
When someone tells me their development team uses Copilot exclusively, I know they haven't been paying attention to what's happening in this space. That's not tribalism—it's observation. The teams shipping the most impressive AI-assisted work aren't using Copilot as their primary tool.
Microsoft is investing in Copilot integration across Dynamics 365—there's a GitHub Copilot integration for X++ development that promises to "turbocharge" development with code suggestions and auto-completions. At Directions EMEA 2025, Microsoft announced new AI-first development options for Business Central, including coding agents that can "plan and execute entire coding tasks in a loop autonomously."
But that's Business Central, not F&O. And even there, the demos show agents working on relatively simple scenarios with modern AL language patterns, not the gnarly reality of enterprise X++ customizations with decades of accumulated complexity.
For D365 F&O specifically, the AI story is still catching up. Which is exactly why this experiment matters.
So here's what I want to try: Can we bring vibe coding to Dynamics 365 F&O?
Can I enable my developers to describe what they want in natural language and have AI agents produce working X++ code? Can we compress those 30-minute compile cycles by writing better code the first time? Can we eliminate the drudgery of boilerplate while preserving the domain expertise that makes customizations actually work?
I genuinely don't know if this is possible.
The challenges are substantial:
I have no expectation of unqualified success. This might be a journey that ends with "we tried, and here's why it doesn't work yet."
But I'm going to document the whole thing.
Over the coming months, I'll be publishing updates as we attempt this experiment. Expect to see:
Part 2: Setting Up the Agent Environment
What tools and configurations are we trying? How do we feed D365 context to AI agents? What does the workflow look like?
Part 3: First Attempts and First Failures
Real examples of what works, what doesn't, and what we learn from the failures.
Part 4: Patterns That Emerge
If we find approaches that reliably produce usable X++ code, we'll document the patterns.
Part 5 and Beyond: The Verdict
Is this viable for production work? What's the honest assessment after months of trying?
Two reasons.
First, for other developers and businesses in the same position. If you're running a D365 practice and wondering whether AI-assisted development is ready for enterprise ERP, this series will give you real data points, not marketing promises. If it works, you'll know how. If it doesn't, you'll know why.
Second, for the honest record. The AI hype cycle is real. Every vendor promises transformation. What's missing is documented reality—the friction, the failures, the edge cases where the demos don't match the daily work. I want to contribute that reality to the conversation.
This is a journal, not a sales pitch. I'm committing to:
If you're interested in following along, subscribe to our blog or check back periodically. I'll update this series as we make progress—or fail to.
Let's see if we can drag the worst developer experience in enterprise software into the age of AI.
Next in the series: Part 2 - Setting Up the Agent Environment (Coming Soon)
Have experience with AI-assisted D365 development? I'd love to hear what you've tried. Reach out through our contact page.
Discover more content:
