Reidar J. Boldevin | Principal Consultant, Fortytwo Technologies | March 2026
Disclaimer: While this post may be mostly AI generated, the prompts are longer than the end result!
The Confession
I am not a developer. I have never been a developer. My career for the past 20+ years has been in IT operations, identity management, and cybersecurity consulting. I configure Entra ID tenants, design Zero Trust architectures, and spend my days arguing with customers about conditional access policies. I don’t write for-loops for a living.
And yet, over the past six months, I have built and deployed three cloud-native applications to Azure. Full CI/CD pipelines, database backends, Entra ID authentication, AI integrations, infrastructure-as-code. All running right now. All built primarily through conversations with AI.
This is how that happened.
The False Start
I should mention that I didn’t start with Claude Code. My first attempt at AI-assisted scripting was with GPT-4, sometime in late 2024, on a PowerShell automation project for Entra ID. I ended up spending more time troubleshooting the generated scripts than I would have spent writing them from scratch. The model would confidently generate code that looked right but didn’t work. It hallucinated API methods that didn’t exist, invented configuration options for Azure services, and produced scripts referencing parameters that had been deprecated years ago. The net productivity gain was negative.
“I ended up spending more time troubleshooting the generated scripts than I would have spent writing them from scratch.“
On my first attempt with GPT-4
I shelved the idea for a while. When Claude Code came along and I gave it another shot, the difference was immediate. Not perfect; it still makes mistakes. But the mistakes are smaller, the hallucinations are rarer, and the iteration cycle actually works. That’s what made vibecoding viable for me.
What I’m Building (Broadly)
I have three proof-of-concept applications running in Azure. I’m keeping the details light on purpose; these are early-stage projects and I’d rather ship than share. But to ground this in something real:
- An identity governance and HR management platform; Azure Functions, Cosmos DB, React, Entra ID multi-tenant auth, AI copilot connected to Microsoft Graph.
- An AI-powered control center for Entra ID; natural language queries against your tenant, multiple AI backends, purpose-built tool integrations.
- A document ingestion and analysis platform; processing pipeline with extraction, chunking, embedding, indexing, and AI-generated structured outputs.
Common thread: Azure hosting, GitHub Actions, Bicep infrastructure-as-code, Entra ID authentication, Cosmos DB, TypeScript/Node.js. Each started as a conversation and became a running application within days.
These are not products. They’re proof-of-concept builds for testing ideas, validating architectures, and learning by doing. Some are personal projects; some are work-related. None are customer deliverables. But they’re not toy projects either; they have real authentication, real data isolation, real deployment pipelines, and real infrastructure.
The Process
People hear “vibecoding” and picture someone typing a vague prompt and getting a working app back. The reality is more structured than that.
Phase 1: Brainstorming and Validation
Every project starts before I open a code editor. Usually the seed is a conversation; with colleagues at Fortytwo, with peers in the identity and security community, or with a customer describing a pain point they keep running into. Ideas don’t show up fully formed. They come from noticing the same problem across multiple engagements, or from someone saying “why doesn’t this exist?” over lunch.
Once an idea has some shape, I start pressure-testing it with AI. Not just Claude; I also use ChatGPT and Gemini, depending on the problem. Each model reasons differently, and bouncing an idea off multiple models surfaces blind spots that any single model (or my own thinking) would miss. The AI doesn’t replace the human conversations that sparked the idea. It extends them into areas I wouldn’t explore on my own.
Sometimes I’ll draft a business proposal. Not for a client, but for myself. Writing out the value proposition, target market, and competitive landscape forces me to think about whether the thing is actually worth building. If I can’t explain why someone would pay for it, I probably shouldn’t spend a month on it.
Phone in hand, Claude’s voice mode running, walking around the neighborhood. Being away from the screen makes it easier to stay at the problem level instead of dropping into implementation details.
I also do walk-and-talks. Literally. This was particularly important for one project where the problem space was complex and I needed to challenge my own assumptions about what users actually need.
This phase might last a day or a week. The output is a rough architecture in my head, some notes, and enough confidence that the thing is worth building.
Phase 2: Architecture, Infrastructure, and Pipeline
This is where Claude Code becomes the primary tool. I set up a GitHub repo, a basic folder structure, and a CLAUDE.md file that describes what we’re building. Then I have Claude Code build the foundation:
- GitHub Actions workflows for CI/CD, using OIDC with federated credentials for passwordless Azure authentication.
- Bicep infrastructure-as-code modules for all Azure resources; Cosmos DB, Storage, Key Vault, Function Apps, App Service, AI Search, Application Insights.
- Application scaffolding; project structure, shared types, authentication middleware, health endpoints, configuration.
The only manual steps are what I call HITL (human-in-the-loop) prerequisites: creating the deployment app registration in Entra ID with GitHub federated credentials, and setting up secrets and variables in the GitHub repo. Everything else is automated and version-controlled.
I’ve recently started using GSD, an add-on for Claude Code that structures the planning phase before execution starts. It makes a noticeable difference; instead of Claude Code making architectural decisions on the fly, it works from a plan we’ve agreed on upfront.
The goal of this phase is a working pipeline. Push to main, GitHub Actions builds and deploys to Azure, infrastructure provisions automatically. I get to this state before writing any application logic. That way every subsequent change is deployed and testable within minutes.
Phase 3: Building the POC
With the pipeline in place, I start building features. This is where it gets highly iterative. I think about what I’d like to see in the application, describe it to Claude Code, and let it execute.
A typical session: I describe a feature. Claude Code writes the API endpoint, the service layer, the frontend component, updates the shared types, and modifies the deployment config if needed. I review, push, and the pipeline deploys it.
When something breaks; and it breaks constantly; the feedback loop is fast. Copy the error from the GitHub Actions log or the Azure portal, paste it into Claude Code, get a fix. The error-fix-deploy cycle might repeat 20 times in a day. Each iteration is a small, specific improvement.
I’ve also started using community add-ons like Everything-Claude-Code, a collection of battle-tested configurations, agents, and skills. Security review agents, code review agents, build error resolvers; they add structure on top of Claude Code’s base capabilities.
The POC phase is not about perfection. It’s about finding out whether the architecture holds, whether the UX makes sense, and whether the idea has legs.
The DevOps Pattern
All three projects follow the same DevOps pattern. That consistency is itself a product of AI-assisted development; once Claude Code learned the pattern for one project, it carried it forward.
- Code and infrastructure in the same GitHub repo.
- GitHub Actions for CI/CD, triggered by path-specific changes.
- OIDC with workload identity federation for Azure access; no stored secrets.
- Bicep modules for all Azure resources, with deletion-date tags to prevent forgotten dev resources from running up costs.
- Managed identity for passwordless access to all Azure services; Key Vault references where secrets are needed.
When I start a new project and say “set up the standard pipeline,” Claude Code knows what that means because it’s in the CLAUDE.md context.
What I’ve Learned
The Architecture Is Your Real Product
When you’re not writing the code yourself, the architecture document becomes everything. A well-structured CLAUDE.md with clear naming conventions, dependency graphs, and design decisions lets Claude Code maintain consistency across hundreds of files and dozens of sessions. Without it, you get drift, duplication, and subtle bugs that compound.
“My most mature project has a CLAUDE.md over 1,500 lines long. It’s not documentation for humans. It’s a contract between me and the AI.“
It specifies route registration rules, tenant isolation requirements, audit logging patterns, framework gotchas, and verification checklists. That document is the product; the code is the output.
Debugging Is the Real Skill
Building the first version is the easy part. Getting it to actually deploy, authenticate, and run is where 80% of the time goes. One project had 20+ deployment fixes in its first phase alone. Token validation edge cases, database region capacity constraints, cold-start timing, parameter mismatches, deploy regressions.
“The skill isn’t writing code. It’s reading the error and describing the problem clearly enough that the AI can fix it.“
That transfers directly from IT operations. I’ve been reading error logs for 20 years. The feedback loop is the same; something failed, read the output, figure out what went wrong, apply a fix. The only difference is that the fix comes from an AI instead of my own keyboard.
Domain Knowledge Still Matters
Claude Code doesn’t know your Azure subscription, your Entra ID tenant, your compliance requirements, or your organizational constraints. I bring two decades of Microsoft identity and security experience to every session. When the AI suggests something that would break tenant isolation, I catch it. When it reaches for connection strings instead of managed identity, I redirect. When it sets CORS to wildcard, I tighten it.
The AI accelerates execution. It doesn’t replace judgment.
Multiple Models Beat One
I don’t use Claude exclusively. The brainstorming phase benefits from model diversity. ChatGPT handles certain reasoning tasks well. Gemini brings a different perspective. Claude is strongest at code generation and long-context work. Using all three produces better results than any one alone.
For the actual coding and deployment, Claude Code is my primary tool because it directly edits files, runs commands, and holds project context. But the thinking that precedes the coding is model-agnostic.
Iteration Speed Beats Initial Quality
First-pass code from Claude Code is rarely production-ready. But the iteration cycle is fast. Error, fix, deploy, test. Repeat. What would take hours of context-switching and documentation-reading takes minutes when you can describe the problem and get a targeted fix.
One project went through 20+ deployment iterations in a single day. Each fixed a specific issue. By end of day, the pipeline worked end-to-end. That pace is hard to match without AI assistance.
The Uncomfortable Truth
I’ll be direct: what I’m doing is not traditional software development. I don’t understand every line of code in these projects. I couldn’t write the TypeScript from scratch. I can’t trace a complex async race condition by reading the source.
But I can describe what the system should do, evaluate whether it’s doing it, identify when something’s wrong, and direct the AI to fix it. I can architect systems, review changes for security issues, and make judgment calls about compliance, operational trade-offs, and user experience.
“Is that “real” development? I don’t care about the label. The applications run. Users authenticate. Data gets processed. Pipelines are green.“
What’s Next
I’m exploring Claude Code’s extension mechanisms; agent teams for parallel analysis, MCP sidecar approaches for real-time visibility into agent activity, custom skills for domain-specific workflows. The ecosystem is evolving fast. The tooling today is substantially better than what existed six months ago.
I use AI as a productivity multiplier and a discussion partner. Not to build customer solutions (with some exceptions), but to test ideas, validate architectures, and learn by doing. The barrier to building software is dropping fast. The barrier to building good software; secure, compliant, well-architected, maintainable; remains high. That’s where domain expertise and operational experience still earn their keep.
“I’m not a developer. But I ship code to production regularly“
And a lot of people in IT operations, security, and consulting are about to discover they can do the same.
Reidar J. Boldevin is a Principal Consultant at Fortytwo Technologies, specializing in Microsoft Identity and Security services. He has 20+ years of IT experience and recently completed an Executive Master of Management at BI Norwegian Business School. He vibes code.
Leave a Reply