DEV Community: Mikul Gohil

Container Queries: The CSS Feature That Changed Everything

Mikul Gohil — Thu, 01 Jan 2026 18:13:12 +0000

For years I wrote media queries that felt like educated guesses. "The sidebar is 300px, and on mobile the content area is full width, so if the viewport is less than 768px..." This arithmetic was fragile. Move a component to a different layout and the breakpoints broke.

Container queries eliminated that mental math. Instead of asking "how wide is the screen?" I now ask "how wide is my parent container?" The component adapts to its actual available space, not some assumed viewport width.

After using container queries across multiple production applications since they reached full browser support in 2023, I can say they've fundamentally changed how I think about responsive design.

The Problem Container Queries Solve

Consider a product card component. In a three-column grid, each card has roughly 400px of width. In a sidebar, the same card has 280px. With media queries, you'd write:

/* This assumes specific layout contexts */
@media (max-width: 768px) {
  .product-card {
    flex-direction: column;
  }
}

@media (min-width: 769px) and (max-width: 1024px) {
  .product-card {
    flex-direction: row;
  }
}

But what if the sidebar appears on desktop? What if the grid changes to four columns? Every layout change requires recalculating breakpoints.

Container queries invert this logic:

.product-card-container {
  container-type: inline-size;
}

@container (min-width: 350px) {
  .product-card {
    display: flex;
    flex-direction: row;
  }
}

@container (max-width: 349px) {
  .product-card {
    display: flex;
    flex-direction: column;
  }
}

The card now responds to its container, not the viewport. Put it in a narrow sidebar it stacks. Put it in a wide grid cell it displays horizontally. No viewport calculations needed.

Browser Support in 2025

Container queries have excellent browser support. Chrome 105+, Firefox 110+, Safari 16+, and Edge 105+ all fully support size queries, style queries, and container units. That covers over 98% of global browser usage.

In my experience, you can use container queries in production without polyfills. For the rare legacy browser hit, your fallback is simply the default (non-queried) styles.

The Container Query API

Three CSS properties control container queries:

container-type

This property establishes a containment context. It tells the browser to track the element's dimensions.

.card-wrapper {
  container-type: inline-size; /* Track width only */
}

.full-tracking {
  container-type: size; /* Track width and height */
}

inline-size is what you'll use 90% of the time. It tracks the inline dimension (width in horizontal writing modes) and enables @container queries based on width.

container-name

When you have nested containers, naming them prevents query conflicts:

.sidebar {
  container-name: sidebar;
  container-type: inline-size;
}

.main-content {
  container-name: main;
  container-type: inline-size;
}

/* Target specific container */
@container sidebar (min-width: 300px) {
  .widget {
    display: grid;
    grid-template-columns: 1fr 1fr;
  }
}

@container main (min-width: 600px) {
  .article-card {
    flex-direction: row;
  }
}

container (shorthand)

Combine name and type in one declaration:

.panel {
  container: panel / inline-size;
}

This is equivalent to:

.panel {
  container-name: panel;
  container-type: inline-size;
}

Container Query Syntax

The @container rule works similarly to @media:

/* Anonymous container (nearest ancestor with container-type) */
@container (min-width: 400px) {
  .child {
    padding: 2rem;
  }
}

/* Named container */
@container card-container (min-width: 400px) {
  .card-content {
    display: flex;
  }
}

/* Multiple conditions */
@container (min-width: 300px) and (max-width: 600px) {
  .element {
    font-size: 1.125rem;
  }
}

Container Query Units

Container queries introduced new CSS units that scale relative to the container:

Unit	Description
`cqw`	1% of container's width
`cqh`	1% of container's height
`cqi`	1% of container's inline size
`cqb`	1% of container's block size
`cqmin`	Smaller of `cqi` or `cqb`
`cqmax`	Larger of `cqi` or `cqb`

These units enable fluid scaling without breakpoints:

.card-wrapper {
  container-type: inline-size;
}

.card-title {
  font-size: clamp(1rem, 4cqi, 2rem);
}

.card-image {
  border-radius: 2cqw;
}

.card-padding {
  padding: 3cqw 4cqw;
}

In my experience, cqi (inline size) is the most useful. It scales elements proportionally to the container's width regardless of the container's actual pixel dimensions.

When to Use Container Queries vs Media Queries

Both have their place. Here's how I decide:

Use container queries for:

Reusable components (cards, widgets, navigation items)
Components that appear in multiple layout contexts
Component libraries and design systems
Nested layouts where parent width varies

Use media queries for:

Page-level layout changes (switching from sidebar to stacked)
Global navigation changes (hamburger menu on mobile)
Typography scale changes based on device class
Print stylesheets

Hybrid approach (what I do most often):

/* Media query for page-level layout */
@media (min-width: 1024px) {
  .page-layout {
    display: grid;
    grid-template-columns: 1fr 320px;
  }
}

/* Container query for component-level adaptation */
.sidebar-widget-container {
  container-type: inline-size;
}

@container (min-width: 280px) {
  .widget-content {
    display: flex;
    gap: 1rem;
  }
}

The page layout uses media queries. The components within use container queries. Each tool handles its appropriate scope.

Real-World Patterns

Adaptive Card Component

This pattern handles cards that might appear in a grid, sidebar, or modal:

.card-container {
  container-type: inline-size;
}

.card {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
}

.card-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  object-fit: cover;
}

@container (min-width: 400px) {
  .card {
    flex-direction: row;
    align-items: flex-start;
  }

  .card-image {
    width: 40%;
    flex-shrink: 0;
  }

  .card-content {
    flex: 1;
  }
}

@container (min-width: 600px) {
  .card-image {
    width: 35%;
  }

  .card-title {
    font-size: 1.5rem;
  }
}

Dashboard Widget Grid

Dashboard widgets need to adapt to their panel sizes:

.dashboard-panel {
  container: dashboard-panel / inline-size;
}

.metric-widget {
  display: flex;
  flex-direction: column;
  padding: 4cqw;
}

.metric-value {
  font-size: clamp(1.5rem, 8cqi, 3rem);
  font-weight: 700;
}

.metric-label {
  font-size: clamp(0.75rem, 3cqi, 1rem);
  color: #666;
}

@container dashboard-panel (min-width: 300px) {
  .metric-widget {
    flex-direction: row;
    justify-content: space-between;
    align-items: center;
  }
}

Navigation That Adapts

Navigation items can switch between icon-only and full labels:

.nav-container {
  container-type: inline-size;
}

.nav-item {
  display: flex;
  align-items: center;
  gap: 0.5rem;
  padding: 0.75rem;
}

.nav-label {
  display: none;
}

.nav-icon {
  width: 1.5rem;
  height: 1.5rem;
}

@container (min-width: 200px) {
  .nav-label {
    display: inline;
  }
}

Style Queries

Container queries can also query CSS custom property values, not just dimensions. Every element is a style container by default no container-type needed:

.theme-wrapper {
  --theme: light;
}

.dark-section {
  --theme: dark;
}

@container style(--theme: dark) {
  .button {
    background: #333;
    color: #fff;
  }

  .card {
    background: #1a1a1a;
    border-color: #333;
  }
}

@container style(--theme: light) {
  .button {
    background: #fff;
    color: #333;
    border: 1px solid #ddd;
  }

  .card {
    background: #fff;
    border-color: #e5e5e5;
  }
}

This enables theme scoping without JavaScript or class toggling. Set a custom property on a container, and descendants respond.

Performance Considerations

Container queries use CSS Containment under the hood, which actually improves performance. The browser isolates the contained subtree, limiting the scope of style recalculations.

In my testing with Chrome DevTools, container queries outperform equivalent JavaScript-based solutions (like ResizeObserver with class toggling) by 20-30% in repaint time. The browser handles everything natively.

A few performance tips:

Use inline-size over size when you only need width queries
Name containers in complex nested layouts to avoid unnecessary query matching
Container units (cqw, cqi) are more performant than breakpoint-heavy queries for fluid scaling

Integration with React and Next.js

Container queries work seamlessly with component frameworks. No special setup needed just CSS:

// components/ProductCard.tsx
import styles from './ProductCard.module.css';

interface ProductCardProps {
  title: string;
  price: number;
  image: string;
}

export function ProductCard({ title, price, image }: ProductCardProps) {
  return (
    <div className={styles.container}>
      <article className={styles.card}>
        <img src={image} alt={title} className={styles.image} />
        <div className={styles.content}>
          <h3 className={styles.title}>{title}</h3>
          <p className={styles.price}>${price}</p>
        </div>
      </article>
    </div>
  );
}

/* ProductCard.module.css */
.container {
  container-type: inline-size;
}

.card {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
  padding: 1rem;
  background: #fff;
  border-radius: 0.5rem;
}

.image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
  border-radius: 0.25rem;
}

@container (min-width: 350px) {
  .card {
    flex-direction: row;
  }

  .image {
    width: 40%;
  }

  .content {
    flex: 1;
    display: flex;
    flex-direction: column;
    justify-content: center;
  }
}

With Tailwind CSS, you can use the container query plugin or inline styles:

<div className="@container">
  <div className="flex flex-col @[350px]:flex-row gap-3">
    {/* content */}
  </div>
</div>

Migration from Media Queries

If you're migrating existing components, here's my approach:

Identify components that appear in multiple layout contexts
Wrap each component instance in a container div with container-type: inline-size
Convert @media queries to @container queries using the container's expected sizes
Test the component in all its layout contexts
Remove viewport-specific media queries from the component

The key insight: component styles should use container queries, page layout styles should use media queries. This separation makes components truly portable.

2026: The Year of Agentic Development

Mikul Gohil — Wed, 31 Dec 2025 15:21:09 +0000

The shift happening in 2026 is fundamentally different from what we saw in previous years. We moved from autocomplete to conversation in 2024. We moved from conversation to collaboration in 2025. Now we are moving from collaboration to delegation.

AI coding tools are becoming agents. Not assistants that wait for instructions, but autonomous systems that take ownership of entire tasks, make decisions, and deliver completed work. The developer role is transforming from writing code to directing AI teammates.

Here is what this means for how we will build software in the year ahead.

From Assistants to Agents

The distinction matters. An assistant responds to your requests. An agent pursues goals.

When I use GitHub Copilot for autocomplete, it suggests the next line based on context. When I use Claude Code for a refactoring task, it executes a series of steps to achieve an outcome. The difference is agency: the ability to plan, execute, and adapt without constant human guidance.

2026 marks the year this capability matures from experimental to expected. The tools we will use daily will not just help us code. They will code on our behalf.

What Agent Capabilities Look Like

The current generation of AI coding agents can already:

# Example: Delegating a complete feature to an agent
claude "Implement user preference caching for the dashboard.
Requirements:
- Cache preferences in localStorage with 24-hour expiry
- Sync with server on changes
- Handle offline gracefully
- Add tests for all paths

Work autonomously. Checkpoint before major decisions.
Notify me only if you encounter blockers."

The agent breaks this into subtasks, implements each one, writes tests, and commits the work. I review the output rather than directing each step.

This pattern will become standard in 2026. The expectation will shift from "AI helps me code" to "AI handles this while I work on something else."

Devin and the Autonomous Engineer Wave

Devin, marketed as the first autonomous AI software engineer, represents where the industry is heading. It handles end-to-end project work: planning, coding, testing, debugging, and deployment.

The implications are significant:

Task delegation changes scope. Instead of asking AI to write a function, you describe a feature. Instead of a feature, you describe an outcome. The granularity of human involvement decreases.

Review becomes the primary skill. When AI generates complete implementations, the developer's job shifts to validation. Understanding what good code looks like matters more than writing it character by character.

Specialization increases. AI agents excel at well-defined tasks with clear success criteria. Human developers focus on ambiguous problems, stakeholder communication, and architectural decisions that require business context.

I expect to see more tools in the Devin category throughout 2026. Competition will drive capability improvements rapidly.

MCP and the Context Problem

One of the biggest limitations of current AI tools is context. They understand code but not the broader environment: your team's conventions, the business requirements, the deployment constraints.

Model Context Protocol (MCP) addresses this by standardizing how AI tools access external information. In 2025, early MCP adoption connected Claude Code to Figma, Slack, Jira, and internal documentation. In 2026, this ecosystem expands significantly.

// Example: MCP-enabled agent workflow
// The agent pulls context from multiple sources automatically

// 1. Reads the Jira ticket for requirements
// 2. Checks the Figma design for UI specifications
// 3. Reviews existing patterns in the codebase
// 4. Consults internal API documentation
// 5. Generates implementation matching all constraints

// All without explicit human instruction for each step

The agents that succeed in 2026 will be those with the richest context. Expect to see:

Persistent memory across sessions. Agents that remember previous decisions and learn from feedback.
Team-aware context. Agents that understand not just your code but your team's patterns, preferences, and constraints.
Business context integration. Agents that connect technical implementation to business requirements automatically.

Agent Harnesses: The New Infrastructure

AI labs are building what they call "agent harnesses" - infrastructure for running agents reliably over extended periods. This matters for software development because meaningful work often spans hours or days.

Current agents work well for tasks that complete in minutes. 2026 agents will handle multi-day projects:

Migrating a codebase from one framework to another
Implementing a feature across frontend, backend, and infrastructure
Conducting security audits and implementing fixes
Refactoring legacy systems with comprehensive testing

The infrastructure requirements for this are substantial. Agent harnesses provide:

Checkpointing and recovery. When agents work for hours, failures are inevitable. The ability to checkpoint progress and resume from failures becomes essential.

Resource management. Long-running agents consume API tokens, compute resources, and human attention. Harnesses manage these budgets.

Observability. Understanding what an agent did, why it made specific decisions, and where it might have gone wrong requires logging and tracing at a level we do not have today.

Small Language Models at the Edge

Not all AI development will happen in the cloud. Edge-deployed personal agents via small language models (SLMs) represent another 2026 trend.

The appeal is straightforward:

Privacy: Code never leaves your machine
Latency: No network round-trip for suggestions
Cost: No per-token charges for local inference
Availability: Works offline, on planes, in areas with poor connectivity

Current SLMs cannot match cloud models for complex reasoning, but for common tasks like:

Code completion
Boilerplate generation
Simple refactoring
Documentation writing

They perform well enough. I expect 2026 to bring SLMs specialized for coding that run efficiently on developer laptops and provide real-time assistance without cloud dependencies.

Testing Automation Accelerates

AI-powered testing tools made significant progress in 2025. Tools like Codium for real-time unit test suggestions, Diffblue Cover for Java test generation, and QA Wolf for end-to-end testing demonstrated that AI could handle significant testing workloads.

2026 takes this further:

Test generation becomes automatic. When you implement a feature, tests generate alongside it. Not as a separate step, but as an integrated part of the development workflow.

Visual regression testing scales. AI understands UI intent well enough to identify meaningful visual changes versus noise. Screenshot comparison becomes intelligent.

E2E test maintenance reduces. One of the biggest pain points with end-to-end tests is brittleness. AI agents that understand application structure can update tests when UI changes, reducing maintenance burden.

// Future pattern: Tests as implementation artifacts
// When you write this component...
export function UserProfile({ user }: { user: User }) {
  return (
    <div className="profile">
      <Avatar src={user.avatar} alt={user.name} />
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  );
}

// The agent automatically generates:
// - Unit tests for rendering with various user states
// - Accessibility tests for screen reader compatibility
// - Visual regression baseline
// - Integration tests for data fetching
// All without explicit instruction

The Changing Developer Role

Geoffrey Hinton's predictions about AI replacing human jobs extend to software development. While I do not expect developers to become obsolete in 2026, the role changes meaningfully.

Skills That Gain Importance

Specification clarity. The better you can describe what you want, the better agents perform. Prompt engineering evolves into specification engineering, where precision and completeness in requirements directly impact output quality.

Review and validation. Reading code becomes more important than writing it. Understanding whether AI-generated solutions are correct, secure, and maintainable is the core skill.

System design. Agents handle implementation details well. Humans handle ambiguity, tradeoffs, and decisions that require business context. Architecture and system design become more valuable.

Context curation. The MCP ecosystem rewards those who organize their context well. Documentation, architectural decision records, and well-structured codebases help agents perform better.

Skills That Lose Importance

Syntax memorization. Knowing exact API signatures matters less when AI can look them up instantly and use them correctly.

Boilerplate writing. Repetitive code that follows established patterns becomes AI territory entirely.

Simple debugging. Agents that can read stack traces and fix obvious bugs reduce the need for this traditionally time-consuming activity.

Preparing for the Shift

Based on these predictions, here is how I am preparing for 2026:

Invest in Agent-Ready Tooling

I am setting up my development environment for agent collaboration:

MCP integrations for my most-used tools (Jira, Figma, internal wikis)
Clear documentation that agents can parse and understand
Structured task descriptions that translate well to agent instructions

Practice Delegation Patterns

The skill of delegating to AI agents requires practice. I am experimenting with:

Giving agents larger scope tasks and reviewing outputs
Writing specifications before implementations
Building feedback loops to improve agent performance over time

Develop Review Expertise

Since review becomes central, I am focusing on:

Understanding common AI failure patterns in generated code
Building mental models for security and performance review
Creating checklists for validating AI outputs

Stay Current with the Ecosystem

The AI coding tool landscape changes rapidly. I am following:

Anthropic, OpenAI, and Google AI announcements
Emerging tools in the Devin category
MCP ecosystem developments
SLM progress from Meta, Mistral, and others

What This Means for Teams

For engineering teams, the agentic development shift has organizational implications:

Workflow changes. Code review processes need updating when AI generates significant portions of code. Ownership models may need revision.

Skill development. Teams need training on effective agent collaboration. The skills that made developers productive in 2023 are not identical to what works in 2026.

Tool standardization. Teams benefit from shared agent configurations, MCP integrations, and specification templates. Consistency helps agents perform better.

Quality assurance. New validation processes for AI-generated code become necessary. Security review, in particular, needs enhancement.

The Year Ahead

2026 will not replace developers with AI. But it will change what developers do daily. The mechanical aspects of coding, the tasks that are well-defined and repetitive, increasingly become agent territory.

What remains human is judgment, creativity, and the ability to navigate ambiguity. The developers who thrive will be those who learn to work with agents effectively, treating them as capable teammates rather than fancy autocomplete.

The tools are ready. The infrastructure is maturing. The only question is how quickly we adapt our workflows to take advantage of what agents can do.

I am excited about writing less boilerplate. I am excited about delegating tedious tasks. I am excited about focusing on the parts of software development that require genuine human insight.

2026 is the year AI stops assisting and starts doing. The question for each of us: what will we do with the time that frees up?

2025: The Year AI Became My Coding Partner

Mikul Gohil — Wed, 31 Dec 2025 15:17:11 +0000

Looking back at 2025, the shift is unmistakable. This wasn't the year AI learned to write code it already could. This was the year AI learned to understand my codebase, my patterns, my workflows. The difference between 2024 and 2025 is the difference between a translator and a collaborator.

My terminal became a conversation. My commits got better. My refactoring sessions that once took days now take hours. Here's what changed and why it matters.

From Autocomplete to Autonomous

The AI coding tools of 2024 were impressive pattern matchers. You'd start typing, and they'd finish your thoughts. Useful, but fundamentally reactive. You were still driving. The AI was just a faster keyboard.

2025 brought something different: agency. Tools stopped waiting for me to lead and started anticipating what needed to happen next.

Claude Code's evolution captures this shift perfectly. Early in the year, it was already a capable terminal companion. By December, it had become something I genuinely collaborate with checkpoints to rewind mistakes, subagents that verify my work independently, hooks that enforce team standards automatically.

The moment I realized things had changed was during a large refactoring project. I described the migration in plain English, walked away to make coffee, and came back to find not just the code changes but also the tests updated, the documentation revised, and a suggested commit message waiting. That's not autocomplete. That's partnership.

Claude Code: The Terminal That Thinks

I've written about Claude Code before, but the 2025 version deserves fresh examination. The features that landed this year fundamentally changed how I work.

Checkpoints Changed How I Experiment

Before checkpoints, experimental refactoring was risky. Make a wrong turn, and you're manually reverting or digging through undo history. Checkpoints changed this completely.

# Start a refactoring session
claude "Refactor the authentication module to use the new token pattern"

# If the direction is wrong, rewind
# Press Esc + Esc or use /rewind

Claude Code automatically saves state before making changes. When an approach doesn't work and many don't on the first try I rewind to the checkpoint and take a different direction. No manual cleanup, no lost work, no fear of experimentation.

In my experience, this single feature increased my willingness to try ambitious refactoring by at least 3x. The safety net makes exploration free.

Subagents Verify While I Work

The subagent system lets Claude Code delegate specialized tasks. The pattern I use most: verification subagents that check my work independently.

claude "Implement the payment processing module.
Use a subagent to verify that all error cases are handled
and no sensitive data is logged."

The main agent writes the code. A separate subagent reviews it against security criteria. Two perspectives, one command. I've caught issues this way that I would have missed in manual review edge cases where error messages inadvertently included PII, retry logic that could leak timing information.

Hooks Enforce Team Standards

Hooks transform Claude Code from a personal tool into a team-aware system. They're automated actions that trigger on specific events.

// Example: Pre-commit hook that runs linting
// .claude/hooks/pre-commit.js
export default {
  trigger: 'before-commit',
  action: async (context) => {
    await context.run('npm run lint:fix');
    await context.run('npm run typecheck');
  }
};

My team uses hooks to enforce design system usage, check for deprecated API patterns, and ensure test coverage on modified files. The standards apply automatically, regardless of which developer is working or how rushed the deadline.

Git Operations Became Conversational

This surprised me most. I now handle roughly 90% of my git operations through Claude Code rather than raw git commands.

# Instead of: git log --oneline --grep="auth"
claude "Show me all commits related to authentication changes in the last month"

# Instead of manually crafting commit messages
claude "Review my staged changes and write an appropriate commit message"

# Instead of complex rebase conflict resolution
claude "I have merge conflicts in the auth module. Help me resolve them,
preferring our implementation for the token validation logic"

The natural language interface isn't just more convenient it's more expressive. I can add context that raw git commands can't capture. "Prefer our implementation" would require multiple manual steps with standard git. With Claude Code, it's just part of the sentence.

MCP: The Protocol That Connected Everything

The Model Context Protocol (MCP) emerged as the hidden infrastructure story of 2025. It's not a flashy feature it's plumbing. But it's plumbing that made AI tools dramatically more useful.

MCP standardizes how AI tools access external context. Before MCP, each tool had its own integrations. Claude Code could read files. Copilot could see your editor. But connecting to Figma, Slack, Jira, your internal documentation each required custom work.

MCP changed this:

# Pull design context directly into coding session
claude "Implement the component from the latest Figma mockup
in the 'Dashboard Redesign' project"

# Connect to project management
claude "What Jira tickets are assigned to me for this sprint?
Summarize what code changes each will require."

In practice, MCP means I no longer context-switch between tools. The AI meets me where I am and pulls in what it needs. During a recent feature implementation, Claude Code pulled the spec from Notion, referenced the design in Figma, checked the existing API contracts, and generated code that fit all constraints without me opening any of those applications.

The Code with Claude 2025 event in San Francisco showcased real-world MCP implementations. Teams shared patterns for connecting internal tools, managing authentication across systems, and building custom MCP servers for proprietary platforms. The ecosystem is young but growing fast.

The Workflow That Emerged

After a year of experimentation, my daily workflow consolidated into distinct patterns:

Morning: Strategic Planning with Claude Code

# Start the day with codebase awareness
claude "What areas of the codebase have the most recent churn?
Any patterns in the changes that suggest refactoring opportunities?"

# Plan the day's work
claude "Given the tickets in this sprint and the current codebase state,
suggest an order for tackling them that minimizes merge conflicts"

This strategic layer didn't exist in 2024. AI tools could answer questions, but they didn't have enough context to offer meaningful strategic guidance. MCP integration with project management changed that.

Midday: Implementation with Checkpoints

Active coding uses checkpoints heavily. I work in exploratory bursts:

# Start a feature
claude "Implement user preference caching.
Checkpoint before each major decision."

# Review each checkpoint
# If the direction feels wrong, rewind
# If it feels right, continue

# When complete, review the full diff
claude "Summarize the changes made since the initial checkpoint.
Highlight any areas that warrant additional review."

Afternoon: Review and Integration

# Before pushing
claude "Review all changes against our style guide and security checklist.
Create any missing tests."

# Integration prep
claude "What's the migration path for these changes?
Any consumers that will break?"

End of Day: Documentation and Handoff

# Update documentation
claude "Update the README and API docs to reflect today's changes"

# Write meaningful commit messages
claude "Organize today's changes into logical commits with clear messages"

# Prepare for async collaboration
claude "Write a summary of today's work for the team standup"

What Actually Got Faster

The productivity gains aren't uniform. Some tasks accelerated dramatically; others barely changed.

Dramatically faster (5-10x):

Codebase-wide refactoring with consistent patterns
Generating tests for existing code
Documentation updates after code changes
Resolving merge conflicts with clear preference rules
Bulk API migrations (deprecated patterns to new patterns)

Significantly faster (2-3x):

Initial implementation of well-specified features
Code review preparation (identifying concerns before human review)
Debugging with clear reproduction steps
Setting up new projects with established patterns

Modestly faster (1.2-1.5x):

Complex architectural decisions (AI helps explore, but decisions are still mine)
Performance optimization (requires measurement and domain knowledge)
Security-critical code (I review everything carefully regardless)

Not faster:

Novel algorithm design (AI can implement, but creative solutions are still human)
Understanding legacy code with no documentation (AI hallucinates when context is insufficient)
Debugging intermittent issues (requires patience and observation that AI can't provide)

The pattern is clear: AI excels at tasks with clear specifications and established patterns. It struggles with ambiguity and genuinely novel problems. This isn't a limitation it's a useful heuristic for deciding when to lean on AI assistance.

The Skills That Matter Now

Working effectively with AI coding tools is a skill. A year of intensive use taught me what separates productive AI collaboration from frustrating false starts.

Specification Quality Matters More Than Ever

The clearer my prompt, the better the result. This sounds obvious, but the implication is important: investing time in clear specifications pays off more than it used to.

# Vague (produces mediocre results)
claude "Add error handling to the API"

# Specific (produces usable code)
claude "Add error handling to all API routes in /api/v2.
Catch database connection errors and return 503 with retry-after header.
Catch validation errors and return 400 with field-specific messages.
Log all errors to our existing logger with request ID correlation."

Checkpoint Discipline Prevents Rabbit Holes

I learned to checkpoint frequently. The cost is zero; the benefit is the ability to backtrack without frustration.

# My rule: checkpoint before any decision that could go wrong
claude "Checkpoint, then try approach A for the caching layer"
# Evaluate results
claude "That introduced too much complexity. Rewind and try approach B instead"

Review Everything, Trust Nothing Blindly

AI-generated code is not reviewed code. I treat every output as a pull request from a junior developer who knows patterns but might miss context.

The code is usually syntactically correct. It usually follows patterns. But it sometimes misses edge cases, uses deprecated APIs, or introduces subtle bugs that don't appear until production. Every AI output gets human review.

The Ecosystem Beyond Claude

While Claude Code became my primary tool, the broader ecosystem evolved significantly.

GitHub Copilot remained excellent for inline autocomplete. The subscription cost is low, the integration is seamless, and for quick suggestions while typing, nothing beats it. I use both Copilot for inline assistance, Claude Code for larger operations.

Cursor evolved its agent capabilities. For developers who prefer IDE-based AI rather than terminal-based, Cursor's 2025 updates made it genuinely competitive. The background agents can handle long-running tasks while you continue other work.

Gemini CLI emerged as Google's answer to Claude Code. It's open source, which appeals to developers who want to understand and modify their tools. The community extensions are interesting, though the ecosystem is less mature.

The tools are converging on similar capabilities agentic operation, codebase awareness, checkpoint-and-rewind but with different ergonomics. Terminal versus IDE. Subscription versus usage-based. Closed versus open source. The right choice depends on your existing workflow and preferences.

Looking Forward

2025 was the year AI coding tools became genuine collaborators. 2026 will likely push further in the same direction.

I expect to see:

Deeper integration between AI tools and testing infrastructure
More sophisticated multi-agent patterns (review agents, security agents, performance agents)
Better handling of genuinely novel problems through improved reasoning
Standardization around MCP making tool choice less lock-in

What I don't expect is for these tools to replace thoughtful engineering. They accelerate execution, but the judgment about what to build and why remains fundamentally human.

The developers who thrived in 2025 learned to collaborate with AI effectively clear specifications, checkpoint discipline, rigorous review. Those same skills will matter even more as the tools continue to improve.

My terminal now thinks with me. The code is still mine. The responsibility hasn't changed. But the friction is lower than it's ever been, and that's worth celebrating as we close out this year.