I started using Copilot early, back when it was just an IDE suggestion plugin: I was working in a large, under-documented legacy codebase, and I noticed that if I wrote a good comment block first, Copilot would sometimes have a flash of brilliance and produce almost exactly the method I was about to write. Later I used it to build .NET Interactive notebooks that pulled AWS logs and document DB queries for debugging. Copilot could basically write the whole thing once I gave it a framework for what I was trying to do. Useful. Empowering, even. But not life-changing.
Trial by Terraform
Then we lost our DevOps guy.
I had DevOps experience but had never touched Terraform and was no AWS expert. Fortunately, before he left, he had put our entire four-environment infrastructure into Terraform and documented it somewhat, but now I owned it, ready or not. And we needed SSO integrations with a dozen private third-party providers, most with spotty support teams and almost no documentation. Copilot (mostly GPT models at the time) helped me learn Terraform on the fly and work through that set of seriously hard-to-debug code. I came out of it proud of the solution because it was repeatable and not overly complex to onboard new providers and it got us over the line to making money that year. Cognito and Terraform deserve credit too, but I'm not sure how I'd have made it without the AI help.
Next I tackled the thing our frontend team could never get around to: admin screens. I have an old-school frontend background. I was once great with CSS, HTML, and JavaScript, and was an early adopter of TypeScript back when I was compiling it manually, before Angular and React were a thing. But I never got the chance to get good with React. So, I pointed the AI at examples of the routers and styles my team liked and got the screens I needed. I didn't even try to understand the code. The screens were just for me, and they worked. No more risky SQL update scripts against prod. It took the burden off the team, and everyone was happy.
Survival Mode
Then a funding glitch took the whole team. It was me, my founder CEO, and one guy who knew our mobile app. We couldn't stop building, though; our v2 platform, while getting traction, wasn't yet what our founder had envisioned, and more importantly, not yet what our customers were hoping for. So we made a bold call: take our hard-learned lessons from the design failures of prior versions and build v3 with Claude.
Our CEO made a prototype. I spent a week talking to Claude and building a plan; telling it everything I hated about our prior versions. What we did right, what we did wrong, and what I did wrong, since I was chief architect of the biggest pieces: the Database First approach with SSDT and EF Core Power Tools, the massively over-complicated process templating structure that left the database in real need of refactoring. Then I ran that plan all weekend with occasional check-ins.
By Monday I had a working system I could deploy and migrate v2 onto. It had the same infrastructure, but moved to Postgres (goodbye SQL Server licensing fees), clean EF, networking, Terraform, and CI/CD essentially done. Two months later we've built in most of the new features, including a new mobile app, and I haven't manually touched more than a single line of frontend code. It's better tested, more secure, less chatty, and simpler than what it replaced. Better in every metric I can measure, and I am measuring. Iām not imagining the security improvement, I designed it.
Why It's Better
Because I'm working at a higher level with a fleet of skilled just-in-time implementers. I'm less concerned with physically making and organizing classes and Iām more focused on serving the application and the users. I planned at a level of detail I'd never have tried with a human team. People don't like being told what and how to do things, especially developers. Human teams need to build consensus, and often never truly arrive at it even after a lot of debate. I simply dictated.
Where I knew I was ignorant, I asked for help, learned the right way, made a decision, and documented the ever-living daylights out of it. This project has more documentation than anything I've ever built: ADRs, verbose comments, and brief/design/plan docs for most major features. It proves its worth daily when I imagine potential issues and can query the code/docs to figure out if a bug scenario is already covered or not.
We're also far less limited by inexperience with a tool now. In the time it would take to hold a meeting about a better way to use Sentry, for example, I can have a comprehensive, codebase-aware set of requirements drafted with a detailed working plan I can examine and when I get a down hour, I can implement it over an afternoon cup of coffee.
There have been errors and missteps. That's nothing new; our hand-written projects had bugs too. But I fix issues faster now, so the process has shifted: more time planning and drafting requirements, less time building, more time actually using the app. I have more patience when I'm testing and more eagerness to squash each and every little issue. My testing notes turn into tickets, which turn into PRs, in minutes.
I dunno, Claude is pretty cool. š¤
-- Don Rolling