I ran GitHub Spec Kit on a 5,500-line Nuxt 2 app and still got lost.
Most of the GitHub Spec Kit tests I'd seen ran on light to-do apps. I don't work on those, so in an October 2025 video I ran it on the front end of my contractor SaaS. It didn't go the way I hoped.
The business case
I want more speed from AI on an application that already exists. The app I tested manages contractors, jobs, work orders, billing, dispatch, time tracking and purchase orders. The code goes back about four or five years, and we've been making small improvements since. Lately I've been trying to add features faster with AI, which is why Spec Kit caught my interest.
So the question is whether Spec Kit holds up on a sizable project you already run. I'd bet you're working on a larger codebase too. YouTube has plenty of demo applications. I'm fine with demos, but I want to see how people do this in production so I can apply it to mine.
In the video I said Spec Kit is early technology, and in a couple of months it might turn into something great. The future I care about is vibe coding on existing applications, where you add new parts to code that's been around for years. I also said that in every experiment I'd run up to then, I hadn't been able to get Spec Kit to work the way it was being sold. I documented where it stood in October 2025 so you can judge whether it fits your project.
The app I tested
The front end has about 5,500 lines of code, counted with a command I got from ChatGPT. That count leaves out the back end. In the video I called it not super large, but not small either. It prints to PDF, sends email, generates invoices, runs calculations and tracks time.
The stack is Nuxt 2 and Vue 2, so it's on the older side.
I also had a GitHub board full of outstanding tasks. My plan was to export that list and have Spec Kit create specifications for those tasks. I respect the work the GitHub team is doing on Spec Kit. I put this test out so other developers chasing more speed from AI can learn from where I got stuck. If I was using it wrong, I asked people to tell me in the comments.
This was the deeper pass after my earlier video on why Spec Kit isn't for me.
Set the constitution
I ran specify init with GitHub Copilot, then set up the constitution, which holds your non-negotiables. I asked for Nuxt 2 best practices based on the Nuxt documentation. That run took about four and a half minutes.
The first problem showed up right away. I asked for a specification file, and Spec Kit put a task list in place too. I keep running into that. It generates more than I ask for with GPT-5. It did the same with Claude, back when I thought Claude was the problem.
I then had it change the constitution to client-side only, with no server-side rendering and Auth0 protecting the whole application. I also told it to use JavaScript only, because Nuxt 2 doesn't support TypeScript well.
I walk through the whole run on screen, from the constitution to /implement, in the full video on my channel: Spec Kit on a large Nuxt 2 project on YouTube.
Describe the product
Specify comes next, where you describe what you're building. I described construction management software for the trades, such as plumbers, electrical companies, garage door and HVAC businesses. It covers quotes, jobs, work orders, technicians in the field, scheduling, billing, multiple locations, signatures, invoices and payments. The draft specification took another five or six minutes.
Then I ran /plan with the stack: Nuxt 2 and Vue 2, no TypeScript files, a centralized API layer, components, and the existing design and style guide. I had already put the stack in the constitution by mistake, so the plan overlapped with it.
Feed it the board
I exported my GitHub board as a TSV file and ran /tasks against it. Forty minutes into the process, all the tasks sat in one file under a single 001 spec folder. The documentation example looked different, and I didn't think all of those tasks belonged in one file. Maybe I was thinking about it all wrong.
Clarify asked me five questions. One of them assumed I was building an MVP. This is a full-fledged application, not an MVP.
Analyze reported that the implementation plan was empty, so I had to run /plan again. I didn't know what to put in it the second time. By then Spec Kit had created 28 files, including YAML files, a task file, a specs file and a research file. I couldn't tell what /implement would do. It might work one task at a time, go to town on everything, or only tackle the tests.
Where I got stuck
I ran /implement next, and it told me there were 30-plus test specs to write across integration and UI, and a backlog of 101 items. It hadn't built anything yet. I told it to proceed. Two hours in, another 28 files had changed. After I asked it to fix the test setup, I had another 35 files of tests, and I didn't know what they were testing.
In the video's intro I put my time on this at around four hours. By the end I felt overwhelmed. I'd have to sit down and go through those files one by one to understand them. Spec Kit was producing files faster than I could review them. I came away lost and confused, with no clear end.
I'm probably doing something wrong, and I said so on camera. Something about the concepts wasn't clicking for me yet. My opinion from the earlier video still stood.
Test it on your codebase
The point of a Spec Kit trial is whether it helps you add features to an application you already run. Demos teach you the commands. I needed to see the workflow on billing, PDFs and a real backlog.
If you're trying to get more speed from AI on a large existing codebase and want a second set of eyes on your next move, that's what I cover in a 1:1 strategy call.