DEV Community: Incomplete Developer

Vibe Coding Is NOT the Problem — Ignorance Is

Incomplete Developer — Wed, 15 Apr 2026 16:35:11 +0000

Vibe coding went from Andrej Karpathy tweet → Collins Dictionary Word of the Year → internet punching bag in under 12 months. That's an impressive fall from grace.

And honestly? We're blaming the wrong thing.

Here's my hot take: vibe coding isn't the problem. Developer illiteracy around AI coding methods is.

There's a whole spectrum of ways to use AI for coding — and most developers only know about the two extremes. Then they pick a side, plant a flag, and start a Twitter war about it.

Let's fix that.

Watch Full Video

First, why does vibe coding have a bad rap?

To be fair, the critics aren't entirely wrong. A 2025 Veracode study found that a significant chunk of AI-generated code ships with security vulnerabilities — including classic OWASP Top 10 hits. AI models hallucinate packages that don't exist. People accept generated code without reading it and then act surprised when prod breaks.

But here's the thing: none of that is a vibe coding problem. It's a wrong-tool-for-the-job problem.

Using vibe coding to build a healthcare data pipeline with strict compliance requirements is like using a butter knife to do surgery. The butter knife isn't broken. You just made a terrible choice.

The actual spectrum of AI coding (nobody talks about this)

Everyone frames this as a two-horse race:

🤠 Vibe Coding (chaotic, fun, dangerous?) vs. 📋 Spec-Driven Development (serious, responsible, slightly boring?)

But there are four distinct methods, and understanding all of them is the whole point:

1. 🎲 Vibe Coding

"Just tell the AI what you want and see what happens"

Direct prompts, zero formal planning, iterate until it works. This is the default starting point for basically everyone — developers and non-developers alike.

Tools like Bolt, Lovable, Replit, and Base44 have turned this into full app builders where a single prompt can spit out a working product with UI, backend, and deployment. Wild times.

Fun fact: Linus Torvalds vibe coded a component for his AudioNoise project and said it was "basically written by vibe-coding" in the README. If it's good enough for the Linux guy, maybe chill with the discourse.

2. 🤖 AI Code Assistants

"AI helps, but I'm still driving"

GitHub Copilot, OpenAI Codex, Cursor — living inside your editor, autocompleting your thoughts. Code completion, unit test generation, inline review.

Most professional devs are already here and just don't label it. You write the architecture, AI handles the boilerplate. This is the most mature and least controversial point on the spectrum.

3. 📝 Structured AI Coding

"I write context files, AI follows them"

This one doesn't have an official name, which is probably why it gets skipped in every hot take. No formal framework — just the developer writing detailed markdown files upfront: architecture decisions, coding standards, business context, constraints.

The AI doesn't get a spec. It gets a really good briefing. Works great for solo devs and small teams who want structure without the ceremony.

4. 📋 Spec-Driven Development

"Formal specs are the source of truth, code is almost a side effect"

Thoughtworks called this one of the most important practices to emerge in 2025. Tools like GitHub's Spec Kit and AWS Kiro turn detailed specifications into AI-executable task definitions.

The idea: stop treating AI agents like Google and start treating them like very literal junior devs who need exact instructions. Great for enterprise projects, compliance-heavy systems, and large teams. Comes with real overhead though — writing good specs takes serious time and upfront clarity.

Where vibe coding actually belongs (and shines)

Now that we have the full picture, let's be specific about where vibe coding is genuinely the right call — not a compromise, not a shortcut, but the correct tool:

🎨 Creative / UI work — interfaces, design explorations, landing pages. Fewer hard constraints. Small mistakes don't nuke your database. You don't need a spec to know if a button looks good.

🧩 Well-understood problems — want to build Tetris? Every AI model already knows how Tetris works. Writing a formal spec for Tetris is not rigorous, it's just slower. Same logic applies to any standard, well-documented problem domain.

⚡ Prototypes and MVPs — validate the idea first, add structure later. Vibe coding can get you from "shower thought" to "live demo" in a single afternoon.

🔀 Outside your domain — a backend dev who needs to build a frontend isn't going to write a spec for their first React component. They're going to prompt their way through it. That's not laziness. That's pragmatism.

Real talk: most devs already blend these

The developers doing the best work with AI aren't purists. They're switchers. They flow between methods based on the actual problem in front of them.

A realistic workflow might look like:

Start with vibe coding → get a rough UI prototype working

Switch to structured AI coding → feed context files for the backend

Bring in spec-driven practices → just for the payment flow with real compliance needs

Use AI assistants → throughout, for tests and review

No purity. No manifesto. Just pragmatism.

The truly ironic part? Even the most formal spec-driven projects often start with a quick vibe coding session to understand the problem before writing the spec. The method most opposed to vibing... starts with vibing.

The tools, for reference

Method	Tools
Vibe Coding	Bolt.new, Lovable, Replit, Base44, v0
AI Assistants	GitHub Copilot, Codex, Cursor, Windsurf
Structured AI	Cursor rules files, Claude Code + CLAUDE.md
Spec-Driven	GitHub Spec Kit, AWS Kiro, Augment Code

TL;DR

Vibe coding isn't bad. Spec-driven dev isn't always necessary. They're just different tools for different situations — and treating them as moral opposites is the actual problem.

The dev community loves a villain. This year it's vibe coding. Next year it'll be something else.

Meanwhile, the people actually shipping great software are quietly using whichever method fits the problem. Sometimes that's a one-liner prompt. Sometimes it's a 40-page spec. Most of the time it's something in between.

Learn the spectrum. Match the method to the problem. Stop blaming the hammer for being a bad screwdriver.

What's your go-to method for AI-assisted coding? Drop it in the comments — especially if you've got a workflow that doesn't fit neatly into any of these four categories.

Agent Skills Example - GitHub Copilot Visual Studio 2026

Incomplete Developer — Thu, 09 Apr 2026 11:46:28 +0000

Better late than NEVER. One of the newest capabilities introduced in GitHub Copilot for Visual Studio 2026 is Agent Skills — a feature that allows developers to capture repeatable development processes and reuse them automatically.

In this article, I’ll explain what Agent Skills are, how they work in Visual Studio 2026, and walk through a practical example where a Skill automatically scaffolds a Clean Architecture .NET solution.

Watch Video

What Are Agent Skills?

When working with AI coding tools, you often repeat the same prompts over and over again.

For example:

Creating a new solution
Adding projects
Installing NuGet packages
Setting up references
Organizing folders

You might initially guide the AI through this process step-by-step until it produces the correct result. But repeating the same instructions every time wastes time and tokens.

Agent Skills solve this problem.

A Skill captures a reusable process and allows the AI agent to execute it automatically. Instead of writing prompts repeatedly, you simply ask the agent to use the predefined Skill.

Think of it as:

Reusable automation for AI workflows.

Once defined, the Skill can be executed consistently by different models and agents.

Agent Skills in Visual Studio 2026

While the concept of Skills has existed for some time in AI ecosystems, support for them has only recently arrived in the full Visual Studio IDE.

This means developers can now integrate AI automation directly into their everyday development environment.

The idea originally gained traction through AI tooling built around large language models, but today the concept is becoming widely adopted across AI-assisted development workflows.

Creating a Global Copilot Skill

If you want a Skill to be available across all projects on your machine, it must be placed in a specific folder structure.

Inside your user profile, create the following structure:

.copilot/
   skills/
      MySkill/
         Skill.md

Each Skill lives inside its own folder.

The most important file is:

Skill.md

At minimum, this file should contain:

The name of the skill
A description of what it does

After that, you can include detailed instructions that tell the AI how to execute the process.

These instructions can reference other files packaged inside the Skill folder, such as:

Templates
Scripts
Documentation
Configuration files

Example: Scaffolding a Clean Architecture .NET Solution

To demonstrate how Skills work, I created one that automatically scaffolds a Clean Architecture .NET solution.

The goal is simple:

Create a consistent solution structure every time a new project is started.

Instead of manually performing all the setup steps, the Skill handles everything automatically.

When executed, the Skill performs tasks such as:

Creating a new solution
Generating multiple projects
Adding NuGet packages
Configuring project references
Organizing solution folders

Although this sounds simple, these tasks can actually be tricky for AI when relying only on prompts. Without a Skill, the AI may require multiple prompts and corrections.

Skills make the process much more deterministic.

What's Inside the Skill?

The Skill folder contains several components that work together.

1. Skill Definition

The Skill.md file describes:

The purpose of the Skill
When it should be used
Instructions for executing the workflow

2. Project Template

A template defines the structure of the solution.

This ensures every generated solution follows the same conventions.

3. PowerShell Script

The Skill also includes a script that:

Creates projects
Adds dependencies
Configures references

By combining instructions, templates, and scripts, the Skill ensures the AI produces the same result every time.

Making the Skill Available to Copilot

To enable the Skill in Visual Studio 2026:

Place the Skill folder inside:

.copilot/skills

Restart or reload Copilot.

Once the folder is detected, Copilot can automatically discover the Skill.

You can verify this by asking Copilot if the Skill is available.

Using the Skill

Once the Skill is detected, using it becomes extremely simple.

You can prompt Copilot to scaffold a new solution, and the agent will automatically execute the Skill.

Copilot then generates:

The solution file
Multiple projects
Correct project references
Organized solution folders

Within seconds, you have a fully structured solution ready for development.

Why Agent Skills Are Powerful

Agent Skills unlock a new level of automation in AI-driven development.

They allow developers to:

Capture complex workflows once
Reuse them across multiple projects
Reduce repetitive prompts
Make AI outputs more deterministic
Standardize development processes

For teams that regularly create new services or applications, this can dramatically improve productivity.

Final Thoughts

Agent Skills represent an important step forward for AI-assisted development.

Instead of treating AI like a chat assistant that responds to prompts, Skills allow developers to teach the AI repeatable workflows.

By packaging templates, scripts, and instructions together, you can create powerful automation that works directly inside Visual Studio.

As AI tooling continues to evolve, approaches like this will likely become a core part of modern development workflows.

Watch the Full Video

If you'd like to see the full walkthrough and live demonstration of the Skill in action, check out the video here:

https://youtu.be/wm_LdAVNYpA

If you're experimenting with Agent Skills yourself, I'd be curious to know:

What development tasks would you automate with a Skill?

OpenSpec (Spec-Driven Development) Failed My Experiment — Instructions.md Was Simpler and Faster

Incomplete Developer — Wed, 01 Apr 2026 20:51:39 +0000

There’s a lot of discussion right now about how developers should work with AI coding tools.

Over the past year we’ve seen the rise of two very different philosophies:

1. Vibe Coding — just prompt the AI and iterate quickly
2. Spec-Driven Development — enforce structure so AI understands requirements

Frameworks like OpenSpec are trying to formalize the second approach.

Instead of giving AI simple prompts, the workflow looks something like this:

generate a proposal
review specifications
approve tasks
allow the AI agent to execute the plan

In theory, this should produce better and more reliable code.

So I decided to test it on a real project.

Watch Video

The Experiment

I’m building a car classifieds web application.

The backend and basic functionality already exist, and the front-end is built using .NET Razor Pages.

The problem is the UI.

It works, but it looks very basic and a bit lifeless.

My goal was simple:

Use modern AI coding tools to generate a more premium looking front-end design.

This seemed like a perfect opportunity to test Spec-Driven Development with OpenSpec.

Attempt 1: OpenSpec + GPT-5.3 Codex

The first attempt followed the full Spec-Driven Development workflow.

Using OpenSpec and GPT-5.3 Codex inside VS Code, the process looked like this:

Generate a proposal
Review the generated specification
Approve the list of tasks
Allow the AI agent to execute the plan

This step alone took quite a bit of time.

One key feature of Spec-Driven Development is that the developer must review everything before execution.

This supposedly ensures that the AI clearly understands the requirements.

After about two hours of work and a lot of tokens, I finally had the result.

The new front-end looked almost identical to the original.

Not exactly the premium UI redesign I was hoping for.

Attempt 2: OpenSpec + GitHub Copilot + Claude Haiku 4.5

For the second attempt, I tried something slightly different.

Instead of GPT-5.3 Codex, I used:

GitHub Copilot
Claude Haiku

The idea was to keep the OpenSpec workflow but reduce token costs.

From a tooling perspective, this actually felt better.

Copilot’s integration with VS Code made the workflow smoother.

But the result?

Still disappointing.

More time reviewing tasks.
More agent execution cycles.
Still no meaningful improvement to the UI.

At this point the experiment had already consumed several hours.

Attempt 3: Skip the Framework

For the final attempt, I tried something much simpler.

I removed OpenSpec entirely and created a file called:

Instructions.md

No proposal stage.
No task planning.
No spec review.

Just clear instructions.

The first test was a small bug:

The image uploader was not working when updating a listing.

I wrote the instructions and executed the AI agent.

The bug was fixed quickly.

Token usage was minimal.

Execution time was dramatically shorter.

Trying the UI Redesign Again

Next I gave the AI the original challenge:

Create a more modern and premium looking front-end.

The result still wasn’t perfect.

But the difference was huge:

the process was faster
the cost was much lower
iteration was much easier

Instead of waiting for proposals and reviewing large spec documents, I could simply refine the instructions and try again.

The Hidden Cost of Spec-Driven Development

Spec-Driven Development is often presented as the solution to vibe coding chaos.

And there’s some logic to that idea.

AI models absolutely do misunderstand vague prompts.

But something that doesn’t get discussed enough is the cost of the framework itself.

Spec-Driven workflows introduce:

proposal generation
specification review
task planning
multi-step agent execution

Each of these steps consumes:

developer time
AI tokens
attention

If the output is still poor, the overhead becomes difficult to justify.

How Long Would a Human Take?

Out of curiosity I asked an AI model how long a developer might take to manually build the redesigned UI.

The estimate was 2–3 weeks.

Personally, I think a competent developer could do it in about five days.

Which raises an interesting question:

If a developer can build the feature in under a week, does it make sense to spend hours orchestrating complex AI workflows?

A Simpler Workflow Might Be Better

This experiment made me rethink something.

Maybe the future of AI-assisted development isn’t heavy frameworks.

Maybe it’s lighter workflows with better instructions.

Something like:

small tasks
clear instructions
rapid iteration
developer oversight

Instead of long orchestration pipelines.

Final Thoughts

Frameworks like OpenSpec are exploring an important idea:

How do we manage AI agents in large software projects?

That’s a real problem that will need solutions.

But in this small experiment, the results were clear.

The structured Spec-Driven Development workflow introduced a lot of overhead without delivering better results.

A simple Instructions.md approach was faster, cheaper, and easier to iterate on.

As AI development tools continue evolving, it will be interesting to see whether developers move toward:

structured frameworks or
lightweight instruction-based workflows

The answer may ultimately be somewhere in between.

Video Series

▶ Part 1 – Starting the Project

▶ Part 2 – OpenSpec Solution Scaffolding

▶ Part 3 – Data Access Layer

▶ Part 4 – Creating UI Front End

I Asked AI to Do Agile Sprint Planning (GitHub Copilot Test)

Incomplete Developer — Wed, 01 Apr 2026 20:50:21 +0000

AI tools are getting very good at writing code.

GitHub Copilot can generate entire functions, review pull requests, and even help refactor legacy codebases. But software development isn’t just about writing code.

A big part of the process is planning the work.

So I decided to run a small experiment:

Can AI actually perform Agile sprint planning?

Using GitHub Copilot inside Visual Studio 2026, I asked AI to review a legacy codebase and generate a Scrum sprint plan for rewriting the application.

The results were… interesting.

Watch Video

The Setup

The experiment was intentionally simple.

I gave Copilot an existing codebase and asked it to:

Review the code
Analyze the architecture
Generate a Scrum sprint plan for rewriting the project

I also added some realistic constraints:

Only one developer is working on the rewrite
The developer works 5 hours per day
Sprints are 2 weeks long
Only 7 days per sprint are development days

One important limitation:

The AI was not given any historical sprint velocity or team metrics.

That matters a lot, because in real Agile teams, effort estimates rely heavily on historical data.

But even for humans, sprint estimation is notoriously difficult, so this seemed like a good test.

Test 1 — ChatGPT 5.1 Codex Mini

The first model I tested was ChatGPT 5.1 Codex Mini.

It produced what it described as a detailed sprint plan, but the result was very high level and vague.

Looking at the structure of the plan, something immediately felt wrong.

The sprint plan looked more like Waterfall development than Agile.

Examples:

Sprint 1 focused only on low-level domain entities
There was nothing usable produced
Tests were scheduled in Sprint 3
Documentation and final sign-off appeared in the last sprint

This is basically the opposite of what Scrum tries to achieve.

Agile delivery is about incrementally delivering working software.

Instead, the plan delayed meaningful output until much later.

So for this task:

Codex Mini failed.

It didn’t appear to understand the practical workflow of Agile development.

Test 2 — ChatGPT 5.1 Codex

Next I tested the full ChatGPT 5.1 Codex model.

This time I changed the workflow slightly.

First, I asked Copilot to perform a code review.

The review itself required around three premium requests, but the output was reasonable.

After that, I asked the model to produce a sprint plan for the rewrite.

At first glance, the result looked much better.

The AI used the correct Scrum terminology:

Definition of Ready
Definition of Done
Sprint goals
Backlog features

But once again, reading the details told a different story.

When AI Sounds Smart (But Isn't)

The output looked convincing.

But many parts were too vague to be useful.

For example, the Definition of Done included generic statements but no measurable criteria.

The sprint plans also contained unrealistic assumptions.

Example: Sprint 1

Sprint 1 was titled:

Foundation & Structure – Establish .NET 10 Clean Architecture

The tasks themselves were mostly reasonable.

In fact, about 80% of them made sense technically.

But the time estimates were way off.

Given the constraints I provided, the work listed in Sprint 1 would realistically take about 10 hours.

That means it could likely be finished by day three of the sprint.

The same issue continued in Sprint 2.

Most of the work involved mechanical migration tasks, like converting entities into a newer format.

But there was still no real domain logic being implemented.

Another Agile Anti-Pattern

Looking at the overall milestone plan revealed another issue.

The AI scheduled Service Layer work and Test Coverage near the end of Sprint 3.

Again, this starts to look more like Waterfall than Agile.

Testing and functional behavior should evolve throughout the development process, not suddenly appear late in the project.

What This Experiment Reveals

Both models produced a lot of output that looked intelligent.

There were structured plans, Agile terminology, and detailed explanations.

But much of it was surface-level reasoning.

The AI struggled with the deeper realities of software development:

Understanding the actual complexity of the codebase
Identifying where business logic must be redesigned
Estimating effort realistically

Rewriting a system usually isn’t just about migrating code.

The core domain logic often needs to be rethought completely.

Even experienced developers usually need several days exploring a codebase before they can estimate the real work.

Was This Experiment Fair?

Not entirely.

Real sprint planning relies on information that the AI did not have access to:

Historical sprint velocity
Team estimation practices
Knowledge of the codebase
Developer discussions and consensus

Many teams use planning poker, where multiple developers estimate effort and converge on a shared estimate.

That process relies heavily on human experience with the system.

AI simply doesn’t have that context.

Final Verdict

So can AI perform realistic Agile sprint planning?

Not really.

AI can definitely help with:

Code reviews
Architecture analysis
Backlog documentation
Technical recommendations

But sprint planning still requires human judgment.

Especially when dealing with legacy systems and complex business logic.

AI can assist developers.

But deciding what can realistically fit into a sprint is still something teams need to do themselves.

Watch Spec-Driven Dev Playlist on YouTube

Spec Driven Development - YouTube

Spec-Driven Development is an emerging approach to AI-assisted software development, where AI agents generate code based on structured specifications instead...

youtube.com

Spec-Driven Development: Return of Best Practices

Incomplete Developer — Thu, 26 Mar 2026 12:21:17 +0000

AI has dramatically changed how developers write software. With modern AI coding tools, a developer can generate large amounts of code in seconds.

This shift has led to what many people now call “vibe coding.” Developers write quick prompts and let the AI generate the solution.

And it works — until it doesn’t.

Especially in a formal enterprise environment where teams are large and software engineering best practices are non-negotiable.

The Problem With Pure Vibe Coding

Vibe coding represents one of the biggest shifts in how software can be generated. AI can churn out large amounts of code at incredible speed.

But the biggest problem is not vibe coding itself.

The real issue is when developers start treating AI like a magic wand, relying entirely on quick prompts while ignoring the engineering practices that normally produce reliable software.

Over time, many developers began discarding things like:

Architecture planning
User stories and backlog management
Acceptance criteria
Task breakdown
Coding conventions
Testing strategies

All of these practices exist for a reason: they increase the probability of delivering a high-quality product.

Enterprise software development has never been about just writing code quickly.

It’s about building systems that can be maintained, extended, and understood by teams.

Enterprise Development Is More Than Code

In real enterprise teams, software development usually follows an Agile workflow.

That means:

Features are defined as user stories
Stories are implemented within iterations or sprints
Every story has acceptance criteria
Each story is broken down into technical tasks
Code must integrate with the existing architecture
Duplicate functionality must be avoided

When developers rely only on vibe coding, these safeguards often disappear.

The result can be:

Technical debt
Spaghetti code
Duplicate modules
Poor architecture
Systems that are difficult to maintain

Vibe coding excels at rapid code generation, but it can easily introduce long-term problems if it replaces structured development.

When Vibe Coding Meets Reality

Online memes about AI generating impressive code that quickly turns into a messy codebase capture this problem perfectly.

They illustrate what happens when vibe coding is used to build complex, enterprise-level systems.

Real software projects are long-running efforts.

They evolve across many iterations, releases, and sprints. Building a serious product is a marathon, not a sprint.

But AI chat sessions have context limits. They cannot remember the entire history of a large project over months of development.

Without structure, the AI quickly loses track of:

architecture decisions
previously implemented features
business rules
constraints in the system

And the code quality begins to degrade.

The Old-School Rules Still Apply

This is where Spec-Driven Development comes in.

Spec-driven development is designed for developers building professional, scalable software with AI.

It moves away from freestyle prompting and instead introduces structure and planning.

With spec-driven workflows, the fun and spontaneity of vibing with AI is replaced with something much more traditional:

Written requirements
Product vision
User stories
Acceptance criteria
Architecture plans
Tests and coding standards

In other words, all the “boring” processes that professional teams have relied on for decades.

Before spec-driven approaches became popular, many developers used AI to generate code without any of this structure.

The result was often a big ball of broken code that took longer to fix than it did to generate.

From Vibe Coding to Spec-Driven Development

Spec-driven development guides AI agents to behave more like a disciplined senior developer rather than a code-generation machine.

It’s designed for projects that may take months to complete, where the AI must maintain context about the product requirements and track development progress.

Instead of sending quick prompts, the developer creates a specification ("spec").

This spec becomes the single source of truth for the AI.

It usually includes:

A high-level application overview
Technology choices
Architecture constraints
Business rules
Implementation guidelines

The AI then generates code within the boundaries of that specification.

The Spec-Driven Workflow

The word “spec” might sound intimidating, but it simply means creating a structured plan for the application.

A typical workflow includes:

1. High-Level Application Information

A description of the product, its goals, and its main components.

2. Architecture and Implementation Plan

How the system should be structured and how modules interact.

3. User Stories and Development Tasks

The features that must be built, broken down into manageable units of work.

Developers don’t necessarily need to write all of this manually.

Several emerging frameworks help automate the process, including:

OpenSpec
GitHub Speckit
BMAD

These tools help generate structured specifications while keeping developers responsible for reviewing and approving the plan.

The Real Benefit: Enforcing Best Practices

The real power of spec-driven development isn’t just improving AI prompts.

It’s that the process forces developers to think about architecture and design before generating code.

It also encourages teams to focus on one feature at a time, similar to how Agile teams work in real life.

Just like in Scrum:

Every piece of code connects to a backlog item
Every story has a definition of done
Every task fits into a planned iteration

Spec-driven workflows therefore mirror the way professional teams already build software.

The Part AI Cannot Replace

The most important insight about spec-driven development is this:

It brings back the parts of software development that cannot be outsourced — even to AI.

Those parts include:

Thinking before coding
Defining product vision
Agreeing on requirements
Designing architecture
Establishing a definition of done

For solo developers, the spec acts as a thinking framework.

For teams, it becomes living documentation that captures the shared understanding of the product.

AI helps generate the code, but humans remain responsible for the thinking.

Vibe Coding Still Has Its Place

Vibe coding is still incredibly useful.

It’s great for:

Prototyping ideas
Exploring APIs
Rapid experimentation
Building small tools

But in enterprise environments, software development is about more than generating code at speed.

It’s about building systems that last.

And the practices that spec-driven development reintroduces — planning, architecture, and shared documentation — exist for a reason.

AI may accelerate development, but good engineering discipline is still what keeps complex systems from collapsing.

My First Honest Impressions of Spec-Driven Development

Spec-Driven Development vs Vibe Coding: My Honest First Impressions After Trying It

Incomplete Developer — Mon, 23 Mar 2026 13:33:46 +0000

Over the past year, AI-assisted coding has exploded. Tools like Copilot, Claude Code, and GPT-based agents have made it possible to generate large amounts of code simply by describing what you want.

As this space evolves, two very different approaches have started to emerge:

Vibe Coding — directly prompting the AI and iterating quickly
Spec-Driven Development — using frameworks that generate structured specifications, user stories, and tasks before code is written

Spec-Driven Development is currently being promoted as the correct way to build serious applications with AI. The idea is that instead of randomly prompting an AI model, you give it a structured environment where requirements are broken down systematically.

But after actually trying it on a real project, I found that the reality is more nuanced.

This article shares my first impressions after experimenting with Spec-Driven Development, using OpenSpec as the framework.

Watch Full Video

What Spec-Driven Development Actually Is

The simplest way to understand Spec-Driven Development is this:

Instead of telling an AI agent “build this feature”, you start by generating a structured set of documents describing the application.

These typically include:

Specifications
User stories
Detailed tasks
Architecture notes
Feature definitions

The AI agent then executes those tasks one by one instead of responding directly to a single prompt.

Frameworks such as OpenSpec and GitHub SpecKit are designed to automate this breakdown.

In theory, this should produce more reliable and maintainable AI-generated code, especially for larger projects.

Compared to vibe coding, the workflow looks more like a traditional software engineering process.

Why Vibe Coding Gets Criticized

Many developers argue that Vibe Coding only works for prototypes.

The common criticisms are:

Prompts are too vague
Context gets lost quickly
AI can generate inconsistent architecture
Large projects become chaotic

Spec-Driven Development attempts to fix this by introducing structured requirements and controlled execution.

Conceptually, that makes a lot of sense.

But once you start using these frameworks, you quickly notice some trade-offs.

The Hidden Cost of Spec-Driven Workflows

The first thing that stands out is how document-heavy the process becomes.

Frameworks like OpenSpec generate large numbers of markdown files containing:

specifications
user stories
task lists
development notes

Before the AI agent even starts writing code, the developer is expected to review these artifacts.

This introduces two new costs that people rarely talk about.

1. Human review time

Someone still needs to read through the generated tasks and verify that they make sense.

2. AI token usage

All of these markdown files must be processed by the AI agent.

That means tokens, API calls, and subscription credits are being used before any code is even written.

In some cases, the specification layer can become so verbose that the overhead starts to outweigh the benefit.

The Real Bottleneck Is Still the AI Model

One of the most important realizations when experimenting with Spec-Driven Development is this:

The framework is not the main bottleneck.

The AI model itself is.

Spec frameworks simply break down prompts into smaller steps. But the model executing those steps still determines whether the output is good or bad.

During my testing, the differences between models were very noticeable.

Some models were:

slow
required constant approval
struggled to execute task chains

Others were dramatically faster and more capable.

This means that when something goes wrong, it's not always obvious what the real issue is:

Was the prompt too large?
Was the specification poorly generated?
Or was the AI model simply not good enough?

Spec frameworks don't solve this problem.

They only reorganize how instructions are delivered to the AI.

Comparing Spec-Driven Frameworks

There are already several frameworks trying to define this workflow.

Two of the most visible ones right now are:

OpenSpec

Lightweight
Less process-heavy
Easier for solo developers

GitHub SpecKit

Much more structured
Feels designed for larger teams
Stronger emphasis on process

At the moment, SpecKit probably feels like the most complete implementation.

But the ecosystem is moving incredibly fast, so it's hard to predict what will dominate long term.

Interesting Experiments: Multi-Agent Systems

One of the more interesting ideas appearing in this space is multi-agent orchestration.

Frameworks like BMAD experiment with the idea of multiple AI agents working in parallel on a single specification.

Instead of one agent executing a long list of tasks sequentially, different agents can handle separate sections of the project.

Interestingly, modern tools like VS Code are already beginning to support similar ideas by allowing developers to run multiple AI agents simultaneously.

This concept may become a major part of AI-driven development in the future.

The Extreme Version: Spec as Code

Another fascinating project in this space is Tessl.

Tessl pushes the concept of Spec-Driven Development to its logical extreme.

The philosophy is simple:

The specification is the application.

In this model:

Developers primarily edit specifications
The code is generated from those specs
The entire application could theoretically be rebuilt from the specification alone

It's a powerful idea, but it also feels very futuristic for most real-world development teams today.

The Approach I Currently Prefer

After experimenting with these frameworks, I found myself preferring something slightly different.

Not pure Vibe Coding.

Not full Spec-Driven Development.

Something in the middle.

A workflow I would describe as Structured AI Coding.

The idea is simple:

Organize feature requests into folders
Write detailed instructions in markdown
Give the AI agent clear context
Let the agent generate a plan before writing code

What this approach avoids is the heavy pipeline of:

generated user stories
automated task breakdowns
large specification trees

Instead, the developer directly provides clear structured instructions for each feature.

Many modern AI coding agents already support this workflow through planning modes, where the AI shows its intended steps before making changes.

In practice, this feels:

faster
more direct
less bureaucratic

while still giving the AI enough structure to work effectively.

My Overall Take on Spec-Driven Development

Conceptually, Spec-Driven Development is a very strong idea.

It addresses a real limitation of Vibe Coding: AI needs context and structure when projects become large.

However, the current hype around Spec-Driven workflows sometimes ignores the cost vs benefit trade-off.

These frameworks introduce additional layers:

specification files
task breakdown systems
documentation pipelines

All of this adds complexity that both humans and AI must process.

And even after going through that entire workflow, the final output can still be limited by the capabilities of the AI model.

So while Spec-Driven Development is definitely an interesting direction, it doesn't magically solve every problem in AI-assisted development.

Right now, the most practical approach may simply be a lightweight structured workflow somewhere between Vibe Coding and full Spec-Driven Development.

And interestingly enough…

That middle ground hasn't really been formally defined yet.

Watch Playlist on YouTube

Spec Driven Development - YouTube

Spec-Driven Development is an emerging approach to AI-assisted software development, where AI agents generate code based on structured specifications instead...

youtube.com

GitHub Copilot Completes a Real Code Review (Claude Sonnet 4.5)

Incomplete Developer — Tue, 17 Mar 2026 10:25:25 +0000

One of the more interesting experiments I recently ran was asking GitHub Copilot to perform a full code review on a .NET application that it had also helped rewrite.

The original project was written in 2013. The application still worked, but the codebase had accumulated a lot of technical debt over the years.

Rather than trying to gradually refactor it, I decided to do a complete rewrite with Copilot’s help using modern conventions in the .NET ecosystem.

Once the rewrite was finished, I wanted to answer a simple question:

How useful is an AI-generated code review on a real-world project?

So I asked Copilot to review:

The original legacy codebase
The new rewritten solution

The results were interesting.

Watch Full Video

Starting With a Simple AI Code Review

The easiest way to run an AI code review is something like this:

Perform a code review on this project.

Copilot will usually return a fairly useful response that includes things like:

Naming issues
Readability improvements
Basic design observations
Possible refactoring opportunities

But there is a problem with this approach.

The review tends to focus mostly on surface-level code quality.

In my legacy project, the biggest issues weren’t small code smells. The real problems were architectural.

For example:

Many classes were static
Several classes simply passed calls directly to the data access layer
Domain logic and database logic were mixed together
The solution had no automated tests

The initial open-ended review mentioned some issues, but it completely missed the severity of the architectural problems.

The Other Problem: AI Doesn’t Know Your Standards

Another issue with AI reviews is that the model does not know your team conventions.

Every system has different priorities.

Some systems are mostly CRUD applications where fast queries are the most important factor.

Other systems might be financial or analytical platforms where things like:

deterministic calculations
validation rules
extensive unit testing

are critical.

Without guidance, Copilot evaluates code using generic best practices, not the standards that actually matter for your project.

AI Reviews Also Tend to Be Polite

Another thing I noticed is that AI-generated reviews tend to be very diplomatic.

They rarely say something like:

This architecture is fundamentally broken.

Instead they produce much softer language.

In fact, the first open-ended review Copilot generated described the legacy codebase as:

“A well-structured lottery simulation system with clear domain modeling and separation of concerns.”

That assessment was far more positive than reality.

Giving AI a Code Review Scorecard

To get a more realistic review, I gave Copilot a structured review scorecard.

Instead of asking for a general opinion, the AI had to evaluate the project across several weighted categories.

For example:

Category	Weight
Architecture	High
Testing	20%
Programming practices	15%
Maintainability	Medium

Interestingly, in this scoring model writing code itself only accounts for about 15% of the total score.

That reflects something many experienced developers already know:

Software quality is determined far more by architecture and testing than by individual lines of code.

The Result: Reviewing the Legacy Code

Once Copilot evaluated the legacy project using the scorecard, the results were dramatically different.

The system scored:

15 / 100

The review highlighted several major issues:

No clear architectural structure
Tight coupling between components
No automated tests
Poor separation of responsibilities

The final recommendation from the AI was very direct:

Do not attempt to fix this system incrementally.

Instead:

Treat the codebase as reference material
Perform a full rewrite
Avoid investing time into patching severe technical debt

This was the type of honest assessment that the simple open-ended review failed to produce.

Reviewing the Rewritten Version

After several days of work — with Copilot helping with much of the code — I ran the same structured review on the new version.

The rewritten solution followed a structure that most developers familiar with the .NET ecosystem would recognize:

clear project separation
cleaner domain organization
proper data access layers
improved maintainability

The application itself is a simple lottery simulation tool that can generate numbers based on historical results and simulate outcomes.

And like most lottery simulations, it demonstrates one consistent result:

Even when simulated millions of times, the expected outcome is still a loss.

An Interesting AI Behavior

When I ran the review on the new codebase, Copilot generated a detailed report but did not include the final score.

I had to prompt it again to output the result using the same scorecard format.

This highlights something important about working with AI systems.

AI responses are not fully deterministic.

Even when using the same prompts and templates, the output may vary slightly because the model is generating responses rather than executing fixed instructions.

If the responses were identical every time, it would behave more like a script than an AI model.

Key Takeaways

Using AI for code reviews can be extremely useful, but it works best when used correctly.

1. AI Needs Structure

Without a structured review framework, AI reviews will stay fairly shallow.

Providing guidelines dramatically improves the analysis.

2. AI Defaults to Being Polite

If you want honest feedback, you need to force the AI to follow strict evaluation criteria.

Otherwise the review may sound overly positive.

3. AI Is Not Deterministic

Even with identical prompts, AI responses may vary.

This is normal behavior for generative AI systems.

4. AI Works Best as an Engineering Assistant

AI tools can greatly accelerate tasks like:

code reviews
refactoring analysis
technical debt assessment

But they still work best when combined with human engineering judgment.

Final Thoughts

Using Copilot to both rewrite and review a codebase turned out to be a fascinating experiment.

The biggest lesson was simple:

AI becomes much more powerful when you give it structure.

A simple prompt produces interesting feedback.

A structured framework produces actionable engineering insight.

📚 Watch the Full Series

Episode 1: GitHub Copilot AI Code Review - Can AI Understand Legacy .NET Code?
https://youtu.be/P26t5EVz70U

Episode 2: Creating .NET Projects and Solution Structure
https://youtu.be/Vf0yULOHY3I

Episode 3: Legacy Code Rewrite - Random Number Generator
https://youtu.be/6DuaW9VjQa8

Episode 4: Working Without Agent Skills in Visual Studio 2026
https://youtu.be/dznUGMNhqSU

Episode 5: Vibe Coding Razor Pages
https://youtu.be/sQdByQML_w8

➡️ Episode 6: Code Review (this article)
https://youtu.be/omDvFGu8Vtc

Spec-Driven Development: Introduction

Incomplete Developer — Tue, 17 Mar 2026 08:27:45 +0000

Modern software development is changing quickly.
Today, a large portion of application code is often generated with AI tools such as ChatGPT or GitHub Copilot.

But as AI coding becomes more common, an important question emerges:

What’s the best way to use AI when building large, complex applications?

One answer gaining traction is Spec Driven Development.

The Two Common AI Coding Approaches

Right now, most developers tend to fall into one of two approaches when building software with AI:

Vibe Coding
Spec Driven Development

Vibe Coding

Vibe coding is the most natural and widely used approach.

You prompt an AI model with a task, it generates code, and you continue refining the system through a series of prompts.

For example:

“Create an API endpoint for user registration.”
“Add validation logic.”
“Generate a React component for displaying user profiles.”

For small features, prototypes, or experiments, vibe coding works extremely well. It’s fast, flexible, and often the easiest way to start building something.

But as a project grows, a few challenges start to appear.

Watch Full Video

The Problem With Large AI-Generated Projects

Imagine building a large application such as a car classifieds platform with many business rules:

Listing management
Vehicle search filters
User messaging
Payment integration
Moderation and approval workflows

This quickly becomes a large and complex system.

At that point, simply prompting an AI repeatedly can start to break down.

Common issues include:

The AI loses project context between prompts
It misinterprets requirements
It generates code that works but slowly introduces technical debt

The root problem is simple:

The AI does not truly understand the full system context.

This is exactly the problem Spec Driven Development tries to solve.

What Is Spec Driven Development?

Spec Driven Development (SDD) is a structured workflow where AI generates code from formal specifications rather than individual prompts.

Instead of repeatedly asking the AI what to build next, the project is defined using structured documents that describe the system.

These specifications typically include:

Application overview
Technology stack
Architecture guidelines
Coding standards
Features and user stories
Tasks and acceptance criteria

The specifications are usually stored in Markdown files, allowing AI tools to reference them consistently throughout the project.

By providing this structured context, AI can generate code that fits the system architecture and long-term design.

How Spec Driven Development Works

Most Spec Driven frameworks follow a similar workflow.

1. Initialize the Project Context

The first step is defining the foundational specification for the project.

This includes things like:

Application type
Technology stack (for example .NET, SQL Server, React or Blazor)
Libraries and dependencies
Business rules
Architectural constraints
Acceptance criteria

For example, the GitHub Spec Kit framework calls this document the “constitution.”

This file acts as the core context for the AI agent.

2. Break the System Into Structured Artifacts

Instead of working from a giant requirement document, the framework breaks the system into smaller pieces such as:

Epics
Features
User stories
Implementation tasks

These artifacts give the AI a clear roadmap of what needs to be built.

3. Review Before Code Generation

Before the AI writes any code, developers review the generated specifications.

Once approved, the AI agent executes tasks based on the specification rather than guessing from a prompt.

This greatly reduces misunderstandings and incorrect implementations.

Popular Spec Driven Development Frameworks

Several frameworks have emerged to support this workflow, including:

OpenSpec
GitHub Spec Kit
BMAD Method
Kiro
Tessl

These tools help manage specifications, organize requirements, and coordinate AI agents during development.

Spec Driven Development vs Vibe Coding

The key difference between the two approaches is how AI receives context.

Vibe Coding

AI works mainly from prompts
Context can easily be lost between sessions
Works best for quick tasks and experimentation

Spec Driven Development

AI works from structured specifications
Maintains system context
Better suited for large, complex applications

Vibe Coding Is Still Valuable

It’s important to note that vibe coding is not a bad approach.

In fact, it’s often the best way to start a project.

It’s ideal for:

Rapid prototyping
Small utilities
Experiments
Learning new frameworks

But once a project grows and starts to involve complex domain logic and long development cycles, a more structured workflow like Spec Driven Development becomes increasingly useful.

Final Thoughts

Spec Driven Development is essentially a way to turn AI into a structured member of the development team.

Instead of guessing the intent of each prompt, the AI works from a well-defined set of specifications that describe the system architecture and requirements.

As AI-assisted development becomes more common, workflows like this may become an important part of building larger, long-term software systems.

And in reality, most teams will likely use a combination of both approaches.

Sometimes you vibe code.

Sometimes you rely on structured specifications.

The key is knowing when each approach makes sense.

GitHub Copilot: Best Overall AI Model (VS Code & Visual Studio 2026)

Incomplete Developer — Mon, 09 Mar 2026 22:15:00 +0000

If you’re using GitHub Copilot inside Visual Studio or Visual Studio Code, you’ve probably experimented with different AI models.

The big question:

Do you optimize for raw intelligence… or workflow speed?

After using Copilot daily for C# and .NET development, here’s my take.

Anthropic Models Are a Safe Bet

In general, models from Anthropic (Claude variants like Sonnet and Haiku) consistently generate:

Cleaner code
Fewer obvious bugs
Better structural decisions
Less manual correction

It really feels like software engineering is a priority in their training.

If you’re on Copilot Premium, Agent Mode in Visual Studio makes this even more powerful — you can scaffold solutions, create projects, install NuGet packages, and even run structured code reviews.

The Real Issue with Free Models: Speed

Free models can handle most tasks.

But they’re slow.

In my own testing inside Visual Studio 2026, even simple scaffolding tasks were roughly 2–3x slower. That delay kills momentum — and momentum is everything when coding.

AI only helps if it keeps you in flow.

If I Had to Pick One Model

Right now, my default model is:

Claude Haiku 4.5

Why?

It handles about 80% of my daily coding tasks
It’s significantly faster than free models
It costs about one-third of Claude Sonnet 4.5
It preserves my premium request quota

When I use higher-end premium models for 6 hours a day in .NET 10, I can burn through my entire monthly quota in 10–15 days.

Haiku dramatically reduces that.

Speed Beats Power (Most of the Time)

When rewriting a large codebase, AI should be able to:

Create a solution
Add multiple projects
Wire up references
Install packages

Free models often struggle just to scaffold a basic shell.

Premium “top-tier” models handle it instantly — but using them for routine tasks can be overkill and expensive.

Most development work isn’t advanced algorithmic reasoning.

It’s execution.

And in those cases, speed matters more than raw intelligence.

My Strategy

Default: Claude Haiku 4.5
Escalate: Switch to stronger models when stuck
Use free models: Only when speed isn’t critical

For me, Haiku 4.5 hits the sweet spot between performance, quality, and cost.

What’s your default Copilot model right now — are you optimizing for power, speed, or budget?

I Tried Vibe Coding Classic Arcade Games with GPT-5.4 (Inside VS Code)

Incomplete Developer — Sun, 08 Mar 2026 13:29:26 +0000

Every new AI model release raises the same question:

Can it actually build something real?

So I ran a small experiment: vibe coding classic arcade games inside VS Code using GPT-5.4, and comparing the results with a previous attempt using GPT-5.3 Codex.

The rules were simple:

Minimal prompting (true vibe coding)
Classic games: Tetris, Snake, Pac-Man, Space Invaders
Everything generated inside a .NET Razor Pages project
Code must run locally, not just inside a chat sandbox

In other words: real source code, not a demo trick.

Watch Full Video

The Setup

The project shell was already created in Visual Studio Code using a simple .NET Razor Pages frontend.

Why?

Because it avoids:

installing frameworks
setting up build tools
dependency chaos

The AI just has to generate the games.

Sounds easy… right?

Flashback: GPT-5.3 Codex

I had already tried this challenge with GPT-5.3 Codex.

The result?

Not great.

Problems included:

weak UI design
games not working first time
missing mechanics
and the highlight…

Pac-Man wasn’t Pac-Man.

It produced something vaguely yellow and circular that moved around a screen. That was about it.

Enter GPT-5.4

For this run I used GPT-5.4 through the Codex extension in VS Code.

First task: build Tetris.

The result was… interesting.

The game worked, but the layout looked like a blog article instead of a game.

Seriously.

The page looked like it was designed for reading documentation. The play area required scrolling, which is not exactly ideal for a fast-paced arcade game.

A quick prompt fixed the layout, and the game itself actually played fine.

Already better than GPT-5.3.

Pac-Man: Redemption Arc

Pac-Man was the real test.

GPT-5.3 completely failed here.

GPT-5.4 did much better, but it still wasn’t perfect.

Problems included:

ghosts not actively chasing Pac-Man
weird map boundaries
extremely basic graphics

The overall vibe felt like:

“Impressive school project from 1998.”

Still… at least this time it actually resembled Pac-Man.

Progress.

The Simpler Games

Games like Snake and Space Invaders worked reasonably well.

Which makes sense.

AI tends to do well when the logic is simple:

player movement
collisions
scoring

Once you add enemy AI and complex mechanics, things start to wobble.

The Unexpected Part

GPT-5.4 took about 90 minutes to generate the full implementation.

That’s much slower than the flashy demos you often see online.

Why?

Because those demos usually run inside web chat environments, where the AI can generate quick prototypes.

In this challenge the model had to produce real source code that compiles and runs locally inside a project.

That’s a very different problem.

Plot Twist: The Best Result So Far

Surprisingly, the best implementation I've seen for this arcade challenge is still:

GitHub Copilot + Claude Sonnet 4.5

That combination produced the most accurate games overall.

Better UI.
Better gameplay.
Less weird behavior.

Final Verdict

GPT-5.4 is better than GPT-5.3 Codex.

But only slightly in this experiment.

Improvements:

more complete implementations
fewer obvious missing features
Pac-Man actually resembles Pac-Man

Still not perfect:

UI needs manual fixing
complex mechanics struggle
generation time is long

The Takeaway

AI coding tools are great at generating code.

But generating correct systems is still harder.

Vibe coding works surprisingly well for:

prototypes
small apps
experiments

But for anything complex…

You’ll still want a human in the loop.

Curious to hear from other devs:

What’s the most impressive AI-generated project you’ve seen so far?

Is There a Middle Ground Between Vibe Coding and Spec Driven Development?

Incomplete Developer — Tue, 03 Mar 2026 20:49:44 +0000

Spec Driven Development has become increasingly popular when working with AI coding agents — especially for complex applications with detailed technical and user requirements.

On the other side, “vibe coding” thrives on speed. One prompt. Immediate feedback. Iterate until it works.

But what if you’re building something and you genuinely don’t know how complex it will become?

Is there a middle ground between Vibe Coding and Spec Driven Development?

Not too reactive.
Not too formal.
Not too heavy.

I recently ran into this exact problem.

You can watch the full video on my YouTube Channel (CodeLess Developer)

The Scenario: Building an AI-Generated Game Arcade

I wanted AI to build a browser-based arcade of classic games:

Tetris
Pac-Man
Space Invaders
A fourth classic

Previously, I had done this challenge using GitHub Copilot inside Visual Studio 2026, powered by Claude Sonnet 4.5. At the time, Sonnet 4.5 felt like the best AI coding model available for that workflow.

This time, I wanted to try something different:

👉 Use GPT-5.3 Codex inside VS Code
👉 Avoid pure vibe coding
👉 Avoid heavy Spec Driven Development

Instead of prompting interactively, I started with an instructions.md file.

The instructions were simple:

Create 4 games
Each game in its own feature folder
Use .NET 10
Use C# Blazor
Apply best practices (separation of concerns, modular structure)

This should have been straightforward.

It wasn’t.

When “Simple” Isn’t Simple

Even the first step — creating the .NET solution and projects — took 13–15 minutes. GPT-5.3 Codex struggled to automatically scaffold the solution correctly.

That was surprising.

I would have assumed automated .NET solution creation is a common enough task that modern AI coding agents would handle it effortlessly.

Eventually, Tetris was generated.

But when running the solution in Visual Studio:

❌ The game wasn’t playable.
❌ The implementation failed.

The first attempt was an outright failure.

Where Vibe Coding Would Have Won

Ironically, if I had just vibe coded this — “Create Tetris in JavaScript and HTML” — I likely would have had a playable version almost immediately.

Instead, by explicitly choosing Blazor and C#, I pushed the AI into a weaker execution path.

This is where things got interesting.

Instead of forcing fixes through repeated reactive prompting, I tried something different.

Step Back: Ask the AI to Think First

I asked GPT-5.3:

What technology stack is most appropriate for building browser-based arcade games?

That changed everything.

Instead of forcing it into my initial assumption (.NET Blazor), I let the model reason about:

Rendering performance
Game loops
Canvas handling
Browser-native capabilities
Framework suitability

Then I went further.

I asked it to:

Propose high-level specs
Define an architecture
Create a docs folder with planning context
Outline orchestration before writing code

Now we were no longer vibe coding.

But we also weren’t doing heavy Spec Driven Development.

This felt like something in between.

Defining the Middle Ground

Here’s what I’ve observed so far.

❌ It’s Not Vibe Coding

Because:

We generate structured planning documents
We define architecture before implementation
We increase context before execution
We reduce randomness

❌ It’s Not Full Spec Driven Development

Because:

We are not formally reviewing specs for every change
We are not enforcing change proposals
We are not using structured spec frameworks like OpenSpec or SpecKit
We are not locking into governance workflows

So what is it?

Context-First Development

If I had to name it right now, I’d call it:

Context-First AI Development

The core idea:

Before writing code, generate structured thinking.
Let the AI propose architecture.
Clarify stack decisions.
Establish execution boundaries.
Then build.

No heavy process.
No formal spec review cycles.
No reactive chaos.

Just enough structure to prevent expensive misdirection.

The Real Tension

Here’s the problem I’m still wrestling with:

What happens when changes are required?

The moment you introduce:

Updates
Feature additions
Refactors
Corrections

You start drifting toward change proposals.
Then versioned specs.
Then review cycles.

And suddenly your “middle ground” becomes full Spec Driven Development.

If you don’t use a proper framework like OpenSpec or SpecKit, you end up inventing a lightweight version of one.

That’s the paradox.

Why This Matters

Most non-technical users:

Don’t want formal spec workflows.
Don’t understand architectural modeling.
Prefer vibe coding because it feels immediate.

But vibe coding becomes inefficient once:

The app grows.
State management becomes complex.
Modules interact.
Bugs compound.

Spec Driven Development solves this — but at the cost of overhead.

So the real question isn’t:

Which approach is better?

The real question is:

At what stage does structure become necessary?

The Working Hypothesis

Right now, my working model looks like this:

Stage 1 — Exploration
Use vibe coding to discover direction.

Stage 2 — Context Formation
Generate architecture, stack decisions, and high-level specs.

Stage 3 — Controlled Execution
Build within defined boundaries without heavy governance.

Stage 4 — Formalization (Optional)
Introduce structured spec workflows only if complexity demands it.

That might be the cleanest middle ground.

The Ongoing Experiment

In the next phase of this experiment, I’ll rebuild the arcade based on the planning documents generated by GPT-5.3 Codex.

The real test isn’t whether it builds Tetris.

The real test is:

Does this reduce iteration loops?
Does it reduce misdirection?
Does it outperform pure vibe coding?
Does it avoid the overhead of formal Spec Driven Development?

I’m still searching for the clean definition of this methodology.

But I’m convinced of one thing:

The future of AI-assisted development isn’t binary.

It’s not Vibe Coding vs Spec Driven Development.

There’s a middle ground.

We just need to define it.

I Let GitHub Copilot Build My Razor Pages UI (While Rewriting an Old .NET App)

Incomplete Developer — Tue, 03 Mar 2026 06:45:00 +0000

I'm currently rewriting an old .NET Framework application using modern .NET and AI tools.

In this part of the project, I experimented with letting GitHub Copilot inside Microsoft Visual Studio generate the entire user interface.

The result was surprisingly good — with a few interesting lessons.

First Attempt: Blazor

My first thought was to use Blazor, since it’s one of the modern front-end options in ASP.NET Core.

But after trying several quick experiments, Copilot consistently struggled to generate working Blazor projects.

For now, Razor Pages turned out to be far easier for AI-assisted development.

Architecture Before UI

Before generating any UI, the application was already organized into separate projects:

Domain – business logic
Data Access – persistence
Services – application layer
Composition Root – dependency wiring

This keeps the UI layer thin, which is ideal when working with AI tools.

The UI project simply references the Services layer, while the rest of the logic lives outside the frontend.

This structure works well for small, medium, and even larger projects.

Prompting Copilot

To make things easier for Copilot:

I created a Razor Pages project shell manually
I wrote a high-level prompt describing the page
I focused on DTOs and data layout

Interestingly, I did not describe UI controls in detail.

I didn’t specify things like:

dropdowns
textboxes
specific HTML controls

Instead, I described what data should appear and how it should be ordered on the screen.

That was enough.

What Copilot Generated

Copilot produced:

Razor pages
Page models
ViewModels

The solution compiled immediately, and the generated PlayLottery page worked.

The form allowed users to:

choose how many tickets to generate
select number generation strategies
use historical lottery numbers as results

The results page showed:

overall results
net profit or loss

Iterating with AI

From there, the workflow became simple:

Prompt → run → refine.

For example, I asked Copilot to:

display the winning numbers
show the generated tickets
add borders so the results look like actual lottery tickets

Each change required only a small prompt.

This makes UI iteration surprisingly fast.

Key Takeaway

For this workflow, Razor Pages works extremely well with AI coding tools.

The key seems to be:

keep business logic outside the UI
provide clear DTOs
describe data layout instead of UI controls
iterate with prompts

Blazor may still catch up, but right now Razor Pages feels much easier for AI-assisted scaffolding.

Full Video Walkthrough

I recorded the entire process here:

👉 https://www.youtube.com/watch?v=sQdByQML_w8&list=PLphsQTGN5DbKsbob0eN5y4zQhZXUzpow2

The video shows:

the prompt used for Copilot
the generated Razor Pages
running the application
refining the UI with additional prompts

💡 If you're experimenting with AI-assisted development in .NET, I'd be curious to know:

Have you had better results with Razor Pages or Blazor when using Copilot?