AI-Augmented Development: My Workflow

There's a strange disconnect in how the tech industry talks about AI coding tools. On one end, you have people dismissing them as autocomplete toys. On the other, you have breathless predictions that developers are obsolete. Both are wrong, and both miss what's actually happening in daily engineering work.

Here's what I've found after integrating AI deeply into my workflow over the past year: AI doesn't replace the engineer. It changes where the engineer spends their time. The thinking, the architecture, the "why" — that's still entirely human. But the translation from intent to working code, the exploration of an unfamiliar API, the tedious boilerplate — that's where AI compresses hours into minutes.

I want to be specific about what I use, where it works, where it fails, and the one conviction I hold about this space that most people underestimate: AI tooling evolves so fast that whatever was cutting-edge three months ago already feels outdated. I mean this literally — my workflow today looks nothing like it did in mid-2025. If you're reading this six months from now, parts of it will already be obsolete. That's the pace we're in.

My actual toolset

I don't use a single AI tool. I use a combination, because each one is good at different things. Here's my current stack:

The key insight is that these tools aren't interchangeable — they have different strengths, and the real value comes from crossing them. Claude Code handles the heavy lifting with direct file access. Claude Web and the Chrome extension help me think through problems and pull in browser context. For code review, I deliberately run PRs through models from different companies — Copilot and Codex on GitHub — because each one catches things the other misses. ChatGPT Plus and Gemini serve as second opinions when I want a fundamentally different perspective.

The MCP advantage

One of the biggest productivity multipliers I've found isn't an AI model — it's the infrastructure around it. MCP (Model Context Protocol) servers have changed how effectively AI tools interact with my actual development environment.

For teams, tools like the Linear, Notion, and Figma MCP servers mean that AI can read your tickets, reference your design specs, and understand project context without you copy-pasting everything. But the real game-changer for me has been building custom MCP servers tailored to my daily workflow.

I built and open-sourced two that I use every day:

• mongo-scout-mcp — An MCP server for MongoDB that lets AI tools explore database schemas, run queries, and understand data structures directly. When I'm debugging a data issue or building a new feature, the AI can see the actual collections and documents it's working with.
• postgres-scout-mcp — The same concept for PostgreSQL. Schema introspection, query execution, data exploration — all accessible to the AI through MCP.

The difference this makes is substantial. Before MCP, I'd have to describe my database schema to the AI. Now it can look at it directly. The generated queries are more accurate, the data model assumptions are correct, and the whole feedback loop is faster.

Where AI actually saves time

Onboarding to existing projects

This is the use case I underestimated the most. When I join a project that's already in progress — which, as a consultant, is most of the time — the ramp-up used to take days of reading through files, tracing call chains, and building a mental model of the codebase. Now I point Claude Code at the project and have it walk me through the architecture, the patterns in use, the naming conventions, the dependencies between modules. It surfaces things I'd miss on a manual scan: a utility function that already does half of what I need, an edge case in a related handler, a convention I should follow to keep things consistent.

That consistency angle is underrated. When you're new to a project, you risk introducing patterns that clash with what's already there. AI that can see the full codebase keeps your contributions aligned with the existing style — not just formatting, but structural decisions.

Bug investigation: 5x faster to root cause

When a bug is found but the root cause isn't obvious, AI does essentially the same thing I do — traces through call chains, identifies which combination of inputs could produce the observed behavior, suggests hypotheses to test. The difference is it does it roughly five times faster. It can hold more context, scan more files in parallel, and doesn't lose its train of thought. What used to be hours of inserting log statements and staring at stack traces often resolves in a fraction of the time.

Studying Figma designs

This one's less obvious: when I need to implement a design from Figma, AI tools with visual context can analyze the design, extract the relevant details, identify patterns and spacing, and help me understand the designer's intent before I start building. It cuts down the back-and-forth between the design file and the code.

Building specific things instead of researching them

When I need a specific utility — a date formatter, a validation function, a data transformation — the old workflow was: search for a library, evaluate it, check the API, write the integration. Now, if the thing is straightforward enough, I just describe what I need and have AI generate it. No dependency added, no API to learn, no abandoned npm package to worry about in six months. For simple, well-defined problems, creating is faster than finding.

Cross-model code review

This is where my multi-tool approach pays off the most. I run code reviews through both GitHub Copilot and ChatGPT Codex — models from different companies, trained on different data, with different blind spots. One might catch a performance issue the other misses. One might flag a security concern the other ignores. It's the same principle as having multiple reviewers on a team, except the reviewers are available instantly and never have calendar conflicts.

When AI fails: the Moment.js story

I want to tell a specific story about an AI failure, because the failure modes are important to understand.

I had a query that needed to find at least one record near a given timestamp. The logic was simple: start at the timestamp, then expand the search window by 8 hours in each direction until at least one result comes back. The code was generated by AI, it looked correct, and it worked — sort of. Except sometimes the search window was expanding way beyond what it should. Instead of searching ±8 hours, ±16 hours, ±24 hours, it was jumping to ±7 days. A seemingly small, invisible bug.

The cause? Moment.js object mutability.

const baseDate = moment(record.timestamp);

for (let attempt = 1; attempt <= maxAttempts; attempt++) {
  const start = baseDate.subtract(attempt * 8, 'hours');
  // .subtract() MUTATES baseDate. start === baseDate.
  //
  // Intended:  -8h, -16h, -24h from original
  // Actual:
  //   attempt 1: subtract(8h)  → baseDate is now -8h   ✓
  //   attempt 2: subtract(16h) → from -8h, so -24h      ✗
  //   attempt 3: subtract(24h) → from -24h, so -48h     ✗
  //   attempt 4: subtract(32h) → from -48h, so -80h     ✗
  //
  // Each iteration stacks on top of the previous shift.
  // Within a few loops: the window spans days, not hours.

  const records = await query(start, end);
  if (records.length > 0) return records;
}

The fix was trivial — baseDate.clone().subtract(attempt * 8, 'hours'). One missing .clone() call. But the AI generated the code without it, because .subtract() is a valid Moment.js method that does exactly what it says. The mutability is documented behavior — it's not a bug in the library. It's a bug in how the code uses the library, and it's the kind of thing that looks perfectly correct at a glance.

(And yes — this is also a strong argument for using date-fns or Luxon instead of Moment. Immutable by default eliminates the entire class of bug.)

The pace of change

I want to emphasize something that gets lost in "best tools" listicles: the AI tooling landscape is evolving at a speed that makes any specific recommendation temporary. What I'm using today is materially different from what I was using three months ago. Claude Code didn't exist in its current form a year ago. MCP servers went from niche to essential in a matter of months. Features that required workarounds last quarter are now built-in.

This has a practical implication: the skill that matters isn't learning one specific tool — it's developing the judgment to evaluate and adopt new ones quickly. The developers who fall behind aren't the ones who pick the "wrong" tool. They're the ones who pick a tool and stop looking.

My advice: dedicate a few hours every month to trying new tools and updating your workflow. It's not optional overhead — it's a competitive advantage that compounds over time.

The rules I follow

1. Never commit code I don't understand. If AI generates something I can't explain line by line, I either learn it or rewrite it. My name is on the commit.
2. Architecture is a human decision. I use AI for implementation details. System design, data model decisions, and technology choices come from experience and context that AI doesn't have.
3. Cross models for code review. Never rely on a single AI for review. I run PRs through models from different companies — they have different training data, different blind spots, and different strengths. Consensus across models means more than confidence from one.
4. Small units, fast review. I generate small chunks of code, review them, and iterate. Never an entire module at once — that's how subtle issues like the Moment.js bug compound into a mess.
5. Security and auth code is always hand-written. Authentication flows, authorization checks, anything involving cryptography. The cost of a subtle error is too high.
6. TypeScript makes everything better. A well-typed codebase makes AI output dramatically more accurate. The types constrain the AI's output space, and the compiler catches its mistakes. I wrote about this connection in my TypeScript post.

What this means for clients

The practical outcome of this workflow is that I onboard faster, ship faster, and catch more issues — without cutting corners. When I join a project in progress, AI compresses the ramp-up from days to hours. When I'm building, the mechanical parts — boilerplate, test scaffolds, Figma-to-code translation — are handled quickly, which frees me to spend more time on the things that actually determine project success: architecture, edge cases, and cross-model code review that catches what a single reviewer would miss.

It also means I can take on a wider scope as a solo consultant. Tasks that would have required dedicated implementation time can now be done alongside architecture work and code review, because the implementation phase is compressed. This is particularly valuable in a fractional CTO or tech lead engagement, where the breadth of responsibilities is high.

The engineers who will thrive aren't the ones who ignore AI or the ones who blindly trust it. They're the ones who know exactly where to draw the line — using AI as a powerful amplifier while keeping their hands firmly on the wheel for the decisions that matter.