Back to Blog
How We Use AI to Ship Faster — Without Replacing Engineers

How We Use AI to Ship Faster — Without Replacing Engineers

Dennis Reinkober3 min read

Every other LinkedIn post tells you AI is about to replace software engineers. We've been using LLMs in our daily workflow for over a year now. Here's the honest version: AI makes us faster. It doesn't make us unnecessary.

What We Actually Use

Let's skip the theory. These are the tools and workflows we use on real client projects, every day.

Code Generation: The 80/20 Split

LLMs are excellent at generating boilerplate. Prisma models, API route handlers, React components with standard patterns — this is where AI shines. We estimate it handles about 80% of the repetitive code we used to write manually.

// Prompt: "Create a Next.js API route for fetching paginated orders with status filter"
// What AI generates in seconds — and it's usually correct:

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);
  const page = parseInt(searchParams.get("page") ?? "1");
  const status = searchParams.get("status") as OrderStatus | null;

  const orders = await prisma.order.findMany({
    where: status ? { status } : undefined,
    skip: (page - 1) * 20,
    take: 20,
    orderBy: { createdAt: "desc" },
    include: { items: true },
  });

  const total = await prisma.order.count({
    where: status ? { status } : undefined,
  });

  return NextResponse.json({ orders, total, page });
}

The other 20%? Business logic, edge cases, architectural decisions. That's where the code needs a human brain, not a statistical model.

The Real Productivity Gain

AI doesn't write code 10x faster. It eliminates the 30 minutes of typing that surrounds the 5 minutes of actual thinking. The thinking still takes the same amount of time.

Code Review: A Second Pair of Eyes

We run AI-assisted reviews on every PR. Not as a replacement for human review — as a pre-filter. It catches:

  • Unused imports and dead code
  • Inconsistent naming conventions
  • Missing error handling at API boundaries
  • Obvious security issues (unsanitized inputs, exposed secrets)

What it doesn't catch: whether the approach is right, whether the feature actually solves the user's problem, whether the abstraction will hold up in six months.

Documentation: The One Thing Nobody Wants to Write

This is arguably where AI delivers the most value. We use it to:

  • Generate JSDoc comments from function signatures
  • Draft API documentation from route handlers
  • Write initial README sections for new packages
  • Summarize PR changes for non-technical stakeholders

The output needs editing, always. But going from a draft to a final version is dramatically faster than going from a blank page.

What Doesn't Work

"Just Let AI Write the Whole Feature"

We tried this. Multiple times. The result is always the same: code that looks correct, passes a surface-level review, and breaks in production because it made assumptions about business logic that no model could know.

// AI-generated: looks reasonable
async function processRefund(orderId: string) {
  const order = await prisma.order.findUnique({ where: { id: orderId } });
  if (!order) throw new Error("Order not found");

  await prisma.order.update({
    where: { id: orderId },
    data: { status: "REFUNDED" },
  });

  await sendRefundEmail(order.customerEmail);
}

// What it missed:
// - Partial refunds (not every refund is for the full amount)
// - Payment provider webhook confirmation before updating status
// - Inventory restoration when physical goods are involved
// - Audit trail for compliance
// - Rate limiting to prevent refund fraud

AI generates the happy path. Production lives in the edge cases.

The Dangerous Middle

The worst AI-generated code isn't the obviously wrong code — it's the code that's 95% correct. It passes tests, it looks clean, and it ships. Then it fails silently in a scenario nobody tested because nobody thought to question the AI's output.

Architecture Decisions

"Should we use a message queue or direct API calls?" — no LLM can answer this for your specific system. It doesn't know your traffic patterns, your team's operational experience, your client's budget, or your deployment constraints.

We've seen teams adopt unnecessarily complex architectures because an AI suggested Kafka for a system that processes 50 events per day. Context matters. AI doesn't have yours.

Debugging Production Issues

LLMs can explain stack traces. They can suggest possible causes. But debugging a real production issue requires reading logs, understanding deployment history, knowing which features shipped last week, and sometimes just asking the person who wrote the code six months ago. That's not something you can prompt your way through.

Our Rules for AI in Production Codebases

After a year of iteration, we've settled on a few principles:

  1. AI writes, humans review. Every AI-generated line goes through the same PR process as human-written code. No exceptions.

  2. Never trust AI with business logic. Use it for plumbing (routes, models, CRUD). Write the business rules yourself.

  3. AI is a draft machine. Treat its output as a first draft, not a finished product. Expect to edit 30–50% of what it generates.

  4. Don't use AI to avoid understanding. If you can't explain what the generated code does, don't ship it. AI-generated code you don't understand is tech debt with a timer on it.

  5. Measure the real gain. We track time-to-merge, not lines-of-code-generated. Speed without quality is just faster debugging.

The Bottom Line

AI is the best junior developer we've ever worked with. It's fast, it never complains, and it writes decent boilerplate. But it needs supervision, it makes confident mistakes, and it has no idea what your users actually need.

We use it every day. We'd never ship without a human in the loop.

Similar Posts