DEV Community: Incomplete Developer

Suno AI for Absolute Beginners: A Quick Roadmap

Incomplete Developer — Wed, 14 Oct 2026 18:08:00 +0000

What is this?

A fast, high-level intro to Suno, the AI music generator. Think of it as a learning roadmap, since each advanced topic deserves its own deep dive.

Your First Song

In Simple Mode, describe an idea, hit Create, and you get a song in seconds. When you want more control, switch to the Advanced tab and add:

Lyrics: your own words or structure
Styles: a detailed description of the sound

Full Video Here

Pick a Plan

Free: good for experimenting, but you get no usage rights. You can't upload your songs to YouTube or anywhere else.
Pro: what most people use. You get downloads, usage rights and stronger models.
Premier: more downloads, plus access to Suno Studio.

Check the monthly download limit before you subscribe. Suno caps downloads partly to discourage AI spam.

Pick a Model

V6 Mini: the only model on the Free plan
V6 Wild: more human and authentic, but makes more mistakes
V6 Pro: more reliable

My workflow: start with Wild, and switch to Pro if it can't get it right. Every Create click spends credits.

The Catch: Everything Sounds the Same

Everyone uses the same models and the same AI voices, and Suno only draws on its training data. Basic generations end up generic. To stand out, you need to level up.

How to Level Up

Learn the sliders. Find them under More Options in the Advanced tab.
Upload a demo. Hum, sing or play a rough idea. Suno builds instruments around your melody, which is the best route to originality.
Learn prompting. Steer the intro, verses, instrumentation and even the musical era. Many people use ChatGPT or Gemini to help write prompts.
Try Suno Studio. Control each instrument and melody, moving from generating songs to producing them.

TL;DR

Go paid for download rights, master the Advanced tab and prompting, upload a demo, then explore Suno Studio.

Plans, prices and model names change often. Check suno.com for current details.

What are you building with Suno? Tell me in the comments!

Suno V6 Mini Review: What the Free Plan Can't Do

Incomplete Developer — Fri, 09 Oct 2026 08:25:33 +0000

If you've never paid for Suno, V6 Mini is the only model you get. I tested it across several genres, then pushed it on originality, control, demos, and solo instruments.

Short version: it's a good sandbox, but you won't want to stay there.

Video Here

How it sounds

Deep house: generic. Listenable, but forgettable.
Pop: fine, though pop is the easiest genre to get away with.
Rock/alternative: better than expected.
90s R&B: decent, but not convincingly 90s.
Hip hop: the weakest. The melody and beat felt cheesy and too familiar.

Overall: average. Nothing broken, nothing groundbreaking.

How it compares

Paid plans add two more models. V6 is the default and clearly stronger than Mini. V6 Wild is more experimental and shines on era-specific music (1980s, early 90s), sounding more authentic and less robotic.

The limitations

1. Usage rights. This is the big one. On the free plan you don't get rights to use songs outside Suno, so no social media and, as far as I know, no YouTube. Downloads and stems (the separated vocals, drums, bass, etc.) are also restricted. Read Suno's current terms before publishing anything.

2. Originality takes control. Distinctive results need detailed prompts, lyric direction, and the creativity sliders. Mini isn't powerful enough to make good use of them.

3. Demos don't go far. I uploaded a demo and asked for a talk box treatment. Mini produced something, but no real solo, and I couldn't get the sliders under control.

4. Solo instruments are hit and miss. I asked for "solo organ only, instrumental" and explicitly excluded drums, bass, and kick. Mini added drums and everything else anyway.

Is it worth using?

For a beginner, yes. It's a free, low-pressure way to learn how Suno works. My advice: spend a week or two on Mini, then reassess. Once you want something convincing, original, or release-ready, you'll almost certainly upgrade to V6 or V6 Wild.

Tried V6 Mini yourself? Tell me how it went in the comments.

SUNO Speech is Impressive on Indigenous Languages

Incomplete Developer — Thu, 08 Oct 2026 10:57:49 +0000

I have just tested SUNO Speech (BETA) on South African languages (Sotho and ZULU)

Created a set of scripts where there are 2 people talking
For Sotho/Sepedi, its two ladies preparing trying to buy concert tickets
For Zulu its 2 guys preparing for a marathon

The outcome is relatively impressive (far from perfect) given this is still in BETA

here is the Video

I Tested SUNO's New Speech Feature (BETA): Why Speech Is a Harder Problem

Incomplete Developer — Sun, 04 Oct 2026 18:24:32 +0000

Heads up: SUNO's Speech feature is still in beta and not officially released. Everything below applies to the beta only and may change a lot.

Music is a bounded problem. Speech isn't.

SUNO made its name generating songs. Now it's added Speech: you give it a script, and a voice reads it out. I spent some time with the beta, focusing on speech generation and mostly skipping songs and background music.

Testing it made me think about how different the two problems are. Music can be categorized by genre or style, and the main challenge is novelty. Speech is open-ended, organic, and unpredictable, and a model has to handle several things at once:

Voice variety: "male" or "female" isn't enough

Languages: not everyone speaks a European language
Age and accent: including the many accents within a single language
Context: the subject matter should shape the delivery

For anyone building on top of generative audio, it's a good reminder that each of these is another dimension your prompt has to control.

What I tested

Simple mode with the default football coach prompt
Advanced mode with custom script, tone, gender, and music settings
A child's voice: a young girl rallying her soccer team
Accents: Australian English and British/European English
South African languages: Sotho, Zulu, and Afrikaans
Spanish as a point of comparison

I won't spoil the results here. I'll just say the outcomes weren't uniform, and one prompting detail made me wonder how the model parses instructions.

Watch the full tests

You can hear every test and my full thoughts in the video:

👉 https://youtu.be/66LDOI4MOhQ

My conclusion: SUNO may have just dipped its toes into some waters, and it's unclear how deep they go.

Have you tried the Speech beta? Tell me which voices, accents, or languages to test next.

Suno AI: Prompting for a True Single Instrument Solo

Incomplete Developer — Sat, 26 Sep 2026 12:03:20 +0000

Suno is designed to generate complete musical arrangements, which makes it surprisingly difficult to get a genuine one-instrument performance.

Simply prompting for:

“Solo piano”

does not always produce a true solo. Suno may still add drums, bass, percussion, synths, or other instruments associated with the genre.

I experimented with a prompting-only approach in Suno V6, without using Suno Studio, voice input, or voice-to-instrument techniques.

The basic idea

The prompt needs to do more than identify the instrument.

I use Suno's Advanced mode with:

Lyrics:
[Instrumental]

Styles:
A combination of instructions such as:

solo [instrument]
intimate studio recording
close microphone
dry signal
single track
strictly no accompaniment
no drums

Then I add genre-specific exclusions.

This is important because Suno tends to associate a genre with its normal instrumentation. A house track may introduce drums and synths; salsa may introduce percussion; funk may introduce bass and drums.

The trick is therefore:

Specify the one instrument you want + explicitly exclude the instruments you don't want.

Testing the approach

I tested the method across several very different styles, including house piano, 1980s funk slap guitar, gospel/church organ, 1980s romantic electric piano, French romantic accordion, and a 1950s male a cappella group.

The approach worked across all of these tests, although results can still vary between generations.

I also compared Suno V6 and V6-Wild as part of the experiment.

Using AI to build the prompts

Creating genre-specific exclusions manually can become tedious, so I also used AI to expand the basic template into a more complete prompt for each instrument and genre.

The goal is to make the process reusable rather than manually constructing every prompt from scratch.

I go through the actual prompting process and examples in the video:

Watch the full Suno V6 solo-instrument prompting tutorial on YouTube

The main takeaway is simple:

Don't just tell Suno what instrument to use. Tell it what the performance must contain — and what the genre is NOT allowed to add.

Suno AI Struggles With True Solo Instrument Tracks - The Work Around

Incomplete Developer — Fri, 08 May 2026 10:55:49 +0000

AI music generation has improved incredibly fast over the past few years. Tools like Suno can generate surprisingly polished songs in seconds, often sounding like fully produced studio recordings.

But after spending time experimenting with Suno, I noticed something interesting:

Getting the AI to generate a true solo instrument performance is surprisingly difficult.

Even when you explicitly ask for:

only one instrument,
no vocals,
no drums,
no bass,
and no backing instruments,

Suno often ignores those instructions and creates a full arrangement anyway.

Watch Video

The Problem: Suno Defaults to “Full Song Mode”

Most of the time, Suno seems heavily biased toward creating complete songs rather than sparse or minimal performances.

For example, I tried generating a simple organ solo inspired by the classic Hammond B3 sound.

Instead of producing a standalone organ performance, Suno generated:

drums,
bass,
backing instruments,
and a full Soul Jazz arrangement.

The result actually sounded pretty good.

Just not what I asked for.

The same thing happened with another test using a solo acoustic guitar prompt for an R&B ballad. The song began correctly with only guitar, but after a few seconds the drums entered and the AI shifted into a full-band arrangement.

This behavior happens consistently enough that it clearly is not random.

Why Does This Happen?

From a machine learning perspective, the behavior actually makes sense.

Generative music models rely heavily on patterns learned from training data. Certain words inside prompts carry much stronger weighting than others.

For example, if your prompt includes genre keywords like:

R&B,
Pop,
Rock,
Soul,
Jazz,

the model immediately associates those genres with typical production patterns.

And in most commercial music, those genres usually include:

drums,
bass,
layered instrumentation,
rhythmic accompaniment,
and full arrangements.

So even if the prompt also says:

“solo instrument only”

…the genre association may overpower the negative instructions.

This is one of the most fascinating aspects of generative AI systems: the model is not truly “understanding” instructions the same way a human would. Instead, it predicts likely musical structures based on statistical relationships in its training data.

Silence Looks “Wrong” to the AI

There is another subtle reason solo performances are difficult for AI music generators.

True solo instrument recordings contain a lot of empty space.

Human musicians understand that silence and spacing are part of musical expression. But AI systems trained on dense commercial music may interpret those gaps differently.

To the model, minimalism can appear incomplete.

So the AI tries to “fix” the perceived emptiness by introducing:

drums,
pads,
bass,
ambient textures,
or rhythm sections.

From the model’s perspective, it is improving the song.

From the user’s perspective, it is ignoring instructions.

The Prompt Engineering Workaround

At the moment, generating convincing solo performances in Suno requires a lot of prompt engineering.

One of the biggest discoveries I made was that genre keywords dramatically increase the chance of unwanted backing instruments.

So instead of writing prompts like:

“Solo R&B acoustic guitar ballad”

you often get better results with something more neutral like:

“Single acoustic guitar performance, expressive fingerstyle, intimate solo recording, unaccompanied”

Notice what is missing:

no genre labels,
no strong production associations,
no references to band-oriented styles.

This reduces the AI’s tendency to fall back into full-song mode.

Reinforcing the Prompt

Another trick is reinforcing the solo requirement multiple times throughout the prompt.

For example:

Style Field

solo guitar
single instrument
unaccompanied
minimal arrangement
isolated performance

Lyrics Field

Even though there are no lyrics, adding tags can still help:

[instrumental]

solo instrument only

no drums

no bass

no backing instruments

Does this guarantee success?

No.

But it noticeably improves the odds.

In many ways, using Suno currently feels less like traditional music production and more like negotiating with the model’s default behavior.

Using ChatGPT, Claude, or Gemini Helps

Ironically, one of the best ways to prompt an AI music generator is by first using another AI model.

I found that tools like:

ChatGPT
Claude
Google Gemini

are extremely useful for generating highly structured Suno prompts.

Instead of manually experimenting with wording, you can ask another model to create:

optimized Suno prompts,
negative prompts,
instrument-focused descriptions,
and reinforcement tags.

This approach tends to be far more repeatable than directly improvising prompts inside Suno itself.

An Interesting Observation About Suno Versions

One thing I noticed while testing different Suno versions is that newer models are generally better at following instructions.

However, older versions like Suno 4.5 sometimes generate music that sounds more natural or musically pleasing.

That creates an interesting tradeoff:

Model Behavior	Result
Newer models	Better instruction following
Older models	Sometimes better musicality

In practice, this means the “best” model depends entirely on what you value more:

controllability,
or raw musical output.

Final Thoughts

The solo instrument issue highlights a broader truth about generative AI systems:

AI models have strong default behaviors shaped by training data.

And sometimes those defaults overpower direct user instructions.

Right now, there is no perfect prompt that consistently guarantees a true solo instrument performance in Suno. Instead, success comes from a collection of workarounds:

avoiding genre-heavy keywords,
reinforcing solo instructions,
minimizing production associations,
and using other AI tools to structure prompts more carefully.

As AI music generation continues improving, I expect these models will become much better at understanding negative prompts and nuanced creative intent.

But for now, generating a clean solo instrument track in Suno is still part music production… and part prompt engineering experiment.

Playlist Created with Suno

Old School 80s Slow Jams & Funk | New Jack Swing Vol. 1 (AI Music) - YouTube

Step into the groove with this curated collection of **old school 80s slow jams, funk, and New Jack Swing vibes**. From smooth, emotional ballads to upbeat f...

youtube.com

I Spent 2 Weeks Using Suno AI as a Software Developer — Vibe Composing

Incomplete Developer — Thu, 07 May 2026 07:21:00 +0000

AI is doing two very different things to the world of work at the same time.

First, it’s eliminating certain kinds of jobs and compressing the value of entry-level work.

Second, it’s democratizing specialised fields that previously required years of training to even participate in.

As a software developer, I’ve already watched this happen in coding. So I decided to try the same experiment in another field:

Music.

For the last two weeks, I’ve been using Suno AI almost daily to see how far someone with little musical knowledge can go using modern AI music tools.

The experience felt very similar to vibe coding.

And it exposed both the incredible promise and the very real limitations of generative AI.

Watch Video

AI Is Eating Everyone’s Lunch

Let’s stop pretending this isn’t happening.

A lot of work that once required specialised skills can now be done — or partially done — by AI.

In software development, non-developers can now build surprisingly functional apps using AI coding tools and good prompts. The output often isn’t production-grade, but it’s “good enough” for many use cases.

That matters.

Because “good enough” at massive scale changes industries.

And now the same thing is happening in music.

Suno Makes Music Creation Ridiculously Easy

The first thing that impressed me about Suno is how accessible it is.

You don’t need music theory.
You don’t need production knowledge.
You don’t need instruments.

In many cases, you just need:

an idea
a decent prompt
and optionally ChatGPT to help generate lyrics and structure

Within minutes, you have a full song.

That alone is kind of insane.

A few years ago, creating music involved:

recording equipment
DAWs
mixing knowledge
instruments
vocal ability
production experience

Now someone with none of those things can generate a polished-sounding track in minutes.

That’s a major shift.

But Here’s the Reality After the “Wow” Factor

After the first few days, patterns started to emerge.

And this is where the gap between AI-generated and professionally created music becomes obvious.

Problem #1 — The Songs Aren’t Truly Original

This became the biggest issue very quickly.

Most generated songs sound:

familiar
safe
formulaic
predictable

The melodies often feel generic.
The chord progressions are usually standard.
The structures are extremely mainstream.

The AI is very good at reproducing patterns it has learned.

But creativity?
That’s a different thing entirely.

The most interesting outputs usually happened when I fed Suno something more original first:

a unique melodic idea
a custom vocal input
or a more specific creative direction

At that point, Suno became incredibly useful.

Not as a standalone artist.

But as an AI-powered production assistant or backup band.

And honestly, that distinction matters a lot.

Problem #2 — The Sound Quality Still Needs Humans

This was the second major reality check.

I know very little about audio engineering or mastering, and I assumed modern AI tools would abstract most of that complexity away.

Not really.

A lot of generated tracks had issues like:

too much reverb
muddy mixing
artificial sounding vocals
strange compression artifacts
inconsistent balance between instruments

Some songs sounded impressive initially, but the longer you listened, the more obvious the “AI texture” became.

And this creates an interesting contradiction.

The marketing around AI music suggests:

“Anyone can create professional music.”

But in practice, professional-quality output often still requires:

mixing
mastering
editing
stem processing
sometimes even re-recording sections manually

Which means experts are still needed.

The expertise layer didn’t disappear.
It just shifted.

The Hidden Complexity of AI Tools

This reminded me a lot of software development.

At first, AI tools make everything feel simple.

Then eventually you hit the wall.

In coding:

architecture matters
scalability matters
security matters
maintainability matters

In music:

production matters
mastering matters
arrangement matters
originality matters

The deeper you go, the more expertise starts reappearing.

Then There’s the AI Slop Problem

This is the uncomfortable part.

When millions of people suddenly gain the ability to mass-produce content, quantity explodes.

And when quantity explodes faster than quality, platforms get flooded.

We’re already seeing it:

AI-generated songs uploaded at scale
low-effort content farms
spam playlists
algorithm-chasing music
disposable content created purely for monetisation

This isn’t just a music problem either.

It’s happening across:

writing
art
video
software
social media

AI dramatically lowers creation costs.

But lowering creation costs also lowers the average effort behind what gets produced.

That creates noise.

A lot of noise.

The Copyright and Licensing Mess

Another thing that became obvious:
AI music licensing is still messy territory.

Sometimes generated tracks sound uncomfortably close to existing songs.

Not direct copies.
But close enough to raise questions.

And once money enters the equation, things become complicated very quickly:

ownership
copyright similarity
training data concerns
licensing rights
commercial usage

The legal side of generative AI still feels far behind the technology itself.

So What Is Suno Actually Good At?

After two weeks, I think Suno is genuinely excellent at a few things:

1. Rapid ideation

You can prototype musical ideas incredibly quickly.

2. Personal entertainment

Generating custom songs for yourself is honestly fun.

3. Creative assistance

It works well as a collaborator or augmentation tool.

4. Lowering barriers

Non-musicians can finally participate in music creation.

And that last point is important.

Because despite all the criticism, democratization is real.

Final Thoughts

My overall conclusion is surprisingly similar to how I feel about AI coding tools.

Suno does not magically turn someone into a professional musician.

Just like vibe coding doesn’t magically turn someone into a software engineer.

But it does dramatically increase what beginners are capable of producing.

And that changes industries whether professionals like it or not.

The real lesson from using Suno for two weeks is this:

AI is not removing expertise.
It is changing where expertise becomes necessary.

The entry barrier is collapsing.

But the ceiling for truly exceptional work still exists.

And for now, humans are still the ones pushing against that ceiling.

Actual Playlist I Created

Offcourse Suno allows any genre to be created, the modern Pop, Rap, Dance.

But why not the old school 1980's playlist. A mix of New Jack Swing, slow ballads, acapella

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.