Nobody asks a carpenter if they cut the wood by hand.
There's a growing chorus in tech that says if you used AI to help write your code, it doesn't really count. That you're not a "real" engineer. That the AI did the work and you just watched.
I'd like to push back on that.
What a Crutch Actually Looks Like
A crutch compensates for something missing. If I asked ChatGPT to "build me a compliance app" and shipped whatever came out, that would be a crutch. There's no understanding. No architecture. No judgment about what to build or why.
But that's not how thoughtful engineers use AI. That's not how I use it.
What a Force Multiplier Actually Looks Like
I'm building SallyPort, a desktop application that helps defense contractors achieve CMMC Level 2 compliance. Here's what's under the hood:
- A Tauri 2 desktop app with a Rust backend and React frontend
- Microsoft Graph API integration for automated evidence collection from M365 tenants
- Ed25519 code signing for tamper-proof controls bundles
- A custom assessment engine that maps 110 NIST 800-171 controls to real tenant configurations
- A fine-tuned 12B language model for compliance scoring (58% to 84% accuracy across four training rounds)
- Exportable operator documents — SSPs, SPRS scores, Plans of Action — the paperwork that actually gets a company certified
Did AI help write code in this project? Absolutely. Did AI decide the architecture? No. Did AI know that Graph API v2.0.3 has breaking changes in minor versions that would brick the build if I let it upgrade? No. Did AI understand that a construction subcontractor's compliance scope needs to be minimized to the point of existential necessity because they can't afford to secure systems they don't need? No.
That's the difference between using a tool and being used by one.
The Judgment Layer
Here's what AI cannot do for you:
Architectural decisions. SallyPort is a Tauri app, not an Electron app, because the Rust backend does double duty — it runs the assessment engine and calls Graph APIs with the performance characteristics a security tool requires. That's a judgment call informed by experience.
Domain encoding. I spent fifteen years in construction technology. I built estimating systems at glazing contractors, watched management ignore the tools that saved them money, then built the same system at a competitor in a quarter of the time. The compliance knowledge baked into SallyPort isn't from a training dataset. It's from doing the work.
Integration choreography. When your app talks to Microsoft Graph, handles OAuth flows, manages tenant-scoped tokens, validates CMMC controls against real configurations, signs bundles with ed25519 keys, and generates legal documents — the hard part isn't writing any single function. It's knowing how all of them fit together and what happens when they don't.
Building your own test infrastructure. Halfway through development, I realized you can't meaningfully test a compliance tool without a realistic M365 tenant to scan. So I built m365-sim — a simulator that stands up mock tenant configurations with realistic Graph API responses. I didn't plan to build a test harness. I recognized I needed one, designed it, and built it. AI helped write it. AI didn't know it was missing.
Debugging under pressure. AI is great at writing code. It's mediocre at understanding why code fails in production with real customer data on a tenant configuration it's never seen. That's still a human job.
The Real Skill Shift
The engineers who dismiss AI assistance are protecting a guild, not a definition. They've confused the ability to type syntax with the ability to build systems.
The skill hasn't disappeared. It's shifted. The best engineers I know — the ones shipping real products — spend less time writing boilerplate and more time on the things that actually matter: architecture, domain modeling, integration design, debugging, and talking to customers.
AI handles the volume. The engineer handles the judgment.
That's not a crutch. That's a table saw.
The Company You No Longer Need
Before AI, building something like SallyPort would have required a company. Not a big one — but you'd need a frontend developer, a backend developer, someone who understood Rust or could learn it, a designer, and a project manager willing to trust your vision long enough to see it through. You'd need funding to pay those people while you figured out if the market was real.
I've been on the other side of that equation. I built MAGIC — a construction management system — at a glazing contractor in the Bay Area. It worked. It tracked $25 million in projects across 16 jobs. Management didn't care. I built a similar system at a competitor and it contributed to their best profit year in a decade. Same vision, same architecture, different company willing to trust it.
Now I don't need the company. The vision, the domain knowledge, the architectural judgment — those were always mine. AI gave me the throughput to execute on them alone. Not because it replaced the engineering. Because it replaced the headcount.
That's the real disruption. It's not that AI writes code. It's that a single engineer with deep domain expertise and AI assistance can build what used to require a team. The bottleneck was never ideas or architecture. It was hands on keyboards.
What It Makes You
If you're making architectural decisions, encoding domain expertise, debugging the failures AI introduced, deploying the result, and putting it in front of paying customers — you're an engineer. Full stop.
The tool you used to write line 247 is the least interesting thing about what you built.