9 Months as an AI-First Company: What Actually Changed (And What Didn't)

Nine months ago, we decided to run SpockyMagicAI as an AI-first company. Not "AI-enabled" — where you add ChatGPT to a few workflows and call it a day. Actually AI-first: every engineering decision, content pipeline, and operations process designed around AI assistance from the ground up.

Here's what that's actually looked like. Not the polished version — the version with the failed experiments, the unexpected wins, and the things we got completely wrong.

What "AI-First" Actually Means in Practice

The term gets thrown around a lot, usually to mean "we use AI tools." That's not what we mean.

AI-first means AI is in the default path, not the exception path. A human reaching for a keyboard to write a function or draft a post without first trying to do it with AI assistance is the exception — it requires a reason.

The shift in mindset is harder than the shift in tooling. We had to actively fight the habit of just doing things ourselves when it felt faster than setting up the context for AI.

Spoiler: after the first two months, it usually wasn't faster. The context setup cost amortizes.

What Worked Better Than Expected

Claude Code for the whole engineering stack. Not just for boilerplate — for the architecture decisions, debugging novel errors, writing migrations, reviewing PRs. The quality floor on our code went up significantly. We catch more issues before they reach production because we can afford to iterate more quickly on each feature.

The key insight: Claude Code isn't just faster typing. It lets you think at a higher level. Instead of mentally tracking syntax, you can focus on what the code should do. We write more tests, more documentation, and spend more time on edge cases — not because we're more disciplined, but because the mechanical parts got cheaper.

Async content at scale. One person can now maintain a consistent publishing cadence across blog, social, and video that previously required three people. The content isn't "AI-written" in the sense that it has no human judgment — the strategy, angle, and quality control is still human. But the first draft, the rewriting, the formatting — all assisted.

Documentation that actually stays current. Documentation rot is a universal problem. We fixed it by treating docs as part of the code feedback loop — if Claude Code can't figure out how something works from the docs, the docs get updated. This is a forcing function.

What Didn't Work (The Honest Part)

Autonomous agents for anything that matters. We spent significant time in months 2-3 building multi-agent pipelines that would handle things end-to-end without human review. These worked fine in demos and failed in production in interesting ways.

The problem: AI agents are excellent at tasks where the definition of "done" is clear and measurable. They're poor at tasks where the definition of "done" involves judgment that's hard to specify in advance. Business decisions almost always have that judgment component.

We pulled back to a model where AI does the work and a human checks the output. More conservative, but actually ships.

Early investment in specific tools. We over-invested in tools that were the right choice in early 2025 and became the wrong choice by late 2025. The AI tooling space moves fast enough that decisions made 12 months ago are often wrong today.

The lesson: optimize for optionality in tooling. Don't build deep dependencies on specific model APIs if you can avoid it.

Replacing human judgment in creative decisions. Content engagement rates dropped when we let AI optimize creative choices. Paradoxically, AI-assisted content that had clear human editorial voice performed better than AI-generated content that was optimized for engagement metrics.

The explanation we landed on: AI optimizes for patterns it has seen before. Distinctive creative choices, by definition, deviate from patterns. AI assistance for execution is great; AI autonomy for creative direction produces regression to the mean.

The Unexpected Middle Ground

The biggest surprise wasn't the wins or the failures — it was the category of things that changed in unexpected ways.

Debugging became exploration. Before AI assistance, debugging was often a grind: add a print statement, run the code, read the output, repeat. With AI assistance, debugging became more like pair programming with someone who has read every Stack Overflow post ever written. You describe the symptom; you get a list of five possible causes with explanations; you rule them out or confirm them.

This changed our relationship to hard bugs. We no longer dread "I don't know where to start." We start by describing the symptom clearly.

Onboarding got faster, but for different reasons. We expected AI assistance to speed up onboarding by helping new people find things faster. It did, but the bigger effect was on confidence: people working with an AI pair programmer felt less afraid to try things they didn't fully understand yet. The floor on "I don't want to break something" got lower.

Communication improved. Writing clear prompts for AI forces the same clarity you need for good communication with other humans. Engineers who got better at prompting got better at writing specs and bug reports. It's the same skill: describe the desired outcome precisely.

What the Hype Gets Wrong

"AI will replace developers." After 9 months of this: no. AI changes what developers spend their time on, not whether developers are needed. The demand for engineering judgment — when to build what, how to structure things, what not to build — has gone up, not down. What went down was demand for low-level implementation work.

"Prompt engineering is a special skill." It's not. Writing a clear description of what you want and why is a general professional skill. The people who are best at working with AI at our company are the people who write the clearest requirements, not some separate skill set.

"You need to customize the model." For almost everything we do, the base model is fine. Fine-tuning and RAG have narrow use cases. Before you go down that road, ask whether better prompting and context would achieve the same thing. In our experience, it usually does.

What We'd Do Differently

Start with CLAUDE.md and hooks from day one. We spent months in a cycle of re-explaining our codebase to Claude at the start of each session. Setting up persistent project context (CLAUDE.md) and automated feedback loops (hooks) would have saved us hundreds of hours.

Measure before optimizing. We made a lot of changes based on intuition that turned out not to be improvements. The discipline to measure first — even crudely — would have kept us from a few expensive mistakes.

Define "AI-first" narrowly. "AI-first" as a blanket statement led to applying AI to things where human work was clearly better. Defining exactly which categories of work benefit from AI assistance, and being honest about which don't, would have been more useful.

The Bottom Line

Nine months in: the productivity gains are real, but they're not evenly distributed. Engineering and content production had large, measurable improvements. Business and creative decisions didn't benefit the same way.

The companies that will win with AI aren't the ones who use AI for everything — they're the ones who know exactly which decisions benefit from AI assistance and which need human judgment, and who've built workflows that reflect that distinction.

We're still figuring ours out. But if you're considering going AI-first, the most important thing is to start: run one workflow through an AI-assisted process, measure the result, and let reality tell you where it actually helps.

If you're looking to build Claude Code into your actual engineering workflow — not just as a productivity tool but as infrastructure — we're covering exactly this in the Claude Code Mastery course.

→ Join the waitlist at agentic-movers.com/courses/claude-code-mastery/

We share what we're learning as we go — follow Spocky on Instagram if you want the unfiltered version.