DEV Community: Girish R

Why Developers Feel Like Spectators in the Age of AI Coding

Girish R — Fri, 27 Feb 2026 07:44:03 +0000

There is a conversation happening quietly in engineering teams around the world. Developers are shipping more code than ever before, pull requests are merging faster, and backlogs are shrinking at unprecedented rates. Yet behind this surge in output, many experienced engineers report a growing unease-a sense that, for all the productivity, something essential has been lost.

The question is not whether AI coding tools work. They do. The question is whether the developer is still the one doing the work.

The Craftsman and the Machine

Software development, at its core, has always been an act of creation. The engineer who solves a particularly thorny algorithmic problem, designs an elegant data model, or architects a system that gracefully handles failure - these are acts of genuine intellectual authorship. The satisfaction they produce is not incidental; it is the primary reward mechanism that sustains long careers in a demanding field.

When an AI assistant generates that solution in seconds, the output may be functionally identical. But the psychological experience is fundamentally different. The developer did not solve the problem. They accepted a solution.

This distinction matters far more than the productivity metrics suggest.

Understanding the Accomplishment Gap

Psychological research on motivation offers a useful framework here. Self-Determination Theory identifies three core human needs that drive intrinsic motivation: autonomy, competence, and relatedness. AI-assisted development, when not thoughtfully managed, can erode all three:

Autonomy: When the AI generates the implementation, the developer's role shifts from author to reviewer. Decisions that were once deliberate choices become passive acceptances.
Competence: Mastery is built through struggle. The cognitive effort of working through a difficult problem creates durable expertise. Bypassing that struggle may accelerate delivery, but it simultaneously bypasses the learning that builds real seniority.
Ownership: Code you wrote feels like yours. Code you accepted from a model feels borrowed. This matters for long-term engagement, pride in one's work, and professional identity. The result is what we might call the** Accomplishment Gap** - the widening distance between lines of code shipped and the felt experience of having built something meaningful.

The Developer's Dilemma

This phenomenon is particularly acute for senior engineers. A developer with ten years of experience has an acute internal sense of what it means to have truly solved something. They know the difference between understanding a solution and having accepted one. AI tools, to them, can feel less like an amplifier of their capabilities and more like a replacement for the very activities that defined their professional identity.

Junior developers face a different but equally serious risk: they may accumulate output without accumulating expertise. The muscle memory of debugging, the intuition built through repeated architectural decisions, the judgment that comes from having made-and lived with-consequential trade-offs. These cannot be shortcut.

The Missing Link: Intent and Specification

What AI-assisted development currently lacks, in most implementations, is a structured mechanism for preserving the developer's intellectual authorship at the level that matters most-the design of the solution, not just its implementation.

This is the insight that drives Specification-Driven Development. Learn more about Why SDD?.

When a developer authors a specification before any code is generated-defining requirements, architectural decisions, edge cases, and acceptance criteria-they remain the genuine architect of the system. The AI becomes a capable executor of a plan that originated in the developer's own reasoning. The authorship is preserved where it most matters: in the conception.

.specs/requirements.md

REQ-001: User Authentication Flow

Users must authenticate via OAuth 2.0

Session tokens expire after 24 hours

Failed attempts exceeding 5 within 10 minutes trigger a lock

Rationale: Compliance with internal security policy SEC-004

This specification is not AI-generated. It reflects the developer's understanding of the problem domain, their judgment about trade-offs, and their anticipation of failure modes. When the AI subsequently generates code to satisfy these requirements, the developer can recognize the output as an implementation of their design-because it is.

Reclaiming the Craft

The path forward is not to reject AI tools, nor to use them uncritically. It is to restructure the workflow so that developers remain genuinely engaged with the problems that define professional software engineering:

1. Invest in the specification, not just the prompt. Time spent on clear, detailed requirements is time spent on the intellectually rewarding work of system design.
2. Review generated code with structural intent. Move beyond syntax checking. Ask whether the code correctly expresses the design, handles the specified edge cases, and aligns with the architectural principles you defined.
3. Treat the AI as a junior engineer, not an oracle. A good senior developer reviews, challenges, and improves the work of junior teammates. That relationship preserves judgment and ownership.
4. Celebrate architectural decisions, not just merged PRs. Teams that measure success only by velocity will inadvertently devalue the design work that gives velocity its meaning.

A Different Metric for Success

The engineering industry has spent years optimizing for lines of code, story points, and deployment frequency. AI tools will continue to drive those numbers higher. But the developers who sustain long, fulfilling careers will be those who measure themselves differently-by the quality of the problems they defined, the elegance of the systems they designed, and the depth of the expertise they built along the way.

But restoring the sense of creative authorship in AI-assisted development requires intentionality-from individual engineers, from engineering leaders, and from the tools themselves.

We are building SpecPilot with that intentionality at its core. We would be glad to hear how your team is navigating this challenge.

📖 Full post: https://specpilot.dev/blog/why-developers-feel-like-spectators-in-the-age-of-ai-coding

SpecPilot.dev: A Spec-Driven Approach to AI-Assisted Development

Girish R — Sun, 15 Feb 2026 07:19:00 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built SpecPilot - an open-source, spec-driven development tool that helps engineers move away from “vibe coding” and toward intent-first software design.

SpecPilot sits at the intersection of AI and engineering rigor. Instead of jumping straight from prompt → code → fix → repeat, it encourages teams to slow down just enough to define:

Clear intent
Constraints
Acceptance criteria
Architectural boundaries

before code is generated.

This project is personal for me. Over the months, I’ve seen how AI doesn’t create bad engineering practices—it amplifies existing ones. SpecPilot is my attempt to create a lightweight but opinionated workflow that helps teams use AI responsibly, without turning software into a fragile house of cards.

SpecPilot is fully open source and available on GitHub:

👉 https://github.com/girishr/SpecPilot

👉 https://specpilot.dev

Demo

GitHub Repository: https://github.com/girishr/SpecPilot
Website: https://specpilot.dev (Its got a terminal emulator that shows how the tool works)

The repo includes:

CLI workflows
Example specs
End-to-end flows showing how specs evolve into implementation-ready artifacts

I’m actively iterating in the open, so the demo evolves as the project grows. (you can check out the .spec folder in https://github.com/girishr/SpecPilot/blob/main/.specs/planning/tasks.md to see what is planned)

My Experience with GitHub Copilot CLI

GitHub Copilot CLI played a meaningful role in building SpecPilot—but it wasn’t the only tool in the loop.

I used Copilot CLI primarily for:

Exploring CLI command flows quickly
Generating shell scripts and scaffolding logic
Rapid iteration while staying inside the terminal
Sanity-checking ideas without breaking context

At the same time, I paired it with:

GitHub Copilot Chat inside VS Code for deeper reasoning, refactoring, and architectural discussion
Multiple models depending on the task:
- Claude Sonnet for structured reasoning and spec clarity
- GPT-5.2 Codex for implementation-heavy work
- Grok Code (free) for fast experimentation and alternate perspectives

This mix-and-match approach felt natural. Different problems benefit from different strengths, and Copilot CLI fit nicely as a terminal-native accelerator, not a replacement for thinking.

One thing I appreciated was how Copilot CLI reduced friction. It didn’t try to “own” the workflow—it supported it. That aligns well with SpecPilot’s philosophy: AI should assist intent, not replace it.

SpecPilot vs GitHub SpecKit

I’m aware that GitHub already offers a similar concept with SpecKit.

SpecPilot wasn’t built as a competitor.

It exists because I personally felt there were a few gaps and ideas not fully addressed by SpecKit—particularly around opinionated workflows, extensibility, and how specs evolve alongside AI-assisted coding.

That said, both tools are aligned on the same core principle:

Better specs lead to better software.

I see SpecKit and SpecPilot as different interpretations of spec-driven development, each with its own philosophy and trade-offs. Choice is a good thing, especially in a space as young and fast-moving as AI-assisted engineering.

Closing Thoughts

This challenge wasn’t just about using Copilot—it was about understanding where AI fits best in real developer workflows.

For me, Copilot CLI shines when it:

Reduces context switching
Speeds up experimentation
Lets ideas flow without ceremony

SpecPilot is still evolving, but GitHub Copilot—especially in the CLI—has already become a trusted companion in that journey.

Thanks to the GitHub and DEV teams for running this challenge. It’s exactly the kind of space where thoughtful, open experimentation belongs.

Lightweight CLI for Specification-Driven Development

Girish R — Tue, 10 Feb 2026 20:00:00 +0000

Specification-driven development sounds great in theory.
In practice, it often breaks down.

Specs become outdated.
Docs drift away from reality.
Tools feel too heavy for everyday development.

After seeing this pattern repeatedly across teams, I started working on SpecPilot.

What is SpecPilot?

SpecPilot is a lightweight, open-source CLI tool for specification-driven development.

The idea is simple:

Write specs first
Keep them close to the code
Make specs actionable, not just documentation

Instead of heavy formats or platforms, SpecPilot uses Markdown-friendly specs and works directly from the terminal.

🔗 Website: https://specpilot.dev
🔗 GitHub: https://github.com/girishr/specpilot

Why I Built It

Most spec tools fail for one of two reasons:

They introduce too much ceremony
They don’t fit real developer workflows

SpecPilot is intentionally:

CLI-first
Git-friendly
Lightweight
Framework-agnostic

The goal isn’t to replace OpenAPI or enterprise tooling.
It’s to support teams that want clarity early without slowing down execution.

What SpecPilot Helps With

Defining clear specifications before implementation
Keeping specs versioned alongside code
Generating a clean, structured project scaffold
Reducing ambiguity during project kick-off
Improving alignment in small to mid-sized teams

Who It’s For (and Who It’s Not)

Good fit if you:

Prefer simple, readable specs
Want specs that evolve with the codebase
Work on small to mid-sized projects
Value flexibility over strict schemas

Probably not for you if you:

Are deeply invested in heavyweight spec platforms
Need strict contract enforcement at all times
Want full enterprise governance features

Current Status

SpecPilot is open source and actively evolving.
I’m rolling it out in small internal projects to test real-world usage, learn where it breaks, and improve it incrementally.

Feedback at this stage matters more than features.

Get Involved

If this sounds interesting:

⭐ Star the project: https://github.com/girishr/specpilot
🧪 Try it on a small project
🐞 Open issues or suggest improvements
🔧 Contribute if you’d like to help shape it

If you’ve tried spec-first development before and it didn’t stick, I’d especially love to hear why.

Thanks for reading.