Skip to content

Home

Jump to bottom
Christian Ledermann edited this page Jan 5, 2026 · 36 revisions

Developing with SpecKit, what I learned

Rationale

I decided to learn rust a while ago and needed an engaging project to do that as rust is not something I use at work.

I always wanted to rewrite my old arcanoid/breakout 🧱 style game YaAC 🐧 in a modern game framework.

I started by manually implemented the core foundations of the gameplay by hand, reading the documentation and following examples. After I implemented the basic proof of concept - the basic mechanics of the gameplay -, it became clear that it would take a long time and a steep learning curve

At the same time, I wanted to try out spec driven development with GitHub :octocat: speckit.

Searches:

Any websites or video recommendations would be probably outdated 🦕 🪦⏳🕰️ when you read this, instead search 🦆 for:

Links

Learnings:

Rust and spec driven development with AI agents is a good match because the restrictions of the language provide solid guard rails.

Rusts documentation and the second mover effect provide a solid foundation for LLM training, there is just not much horribly outdated legacy code to be trained on, and LLMS are probably trained on the rustlings.

Choose the right model for Bevy, ask the model: "What is the latest version of Bevy?". If it answers "0.10", it is probably better to avoid it and look for a more up to date one, even with the constitution stating the latest pattern and antipatterns. "0.15" is Okay-ish at the time of writing 0.18 is a release candidate.

If you are running a markdown linter in your pre-commit exclude the speckit artifacts

      exclude: '(^\.specify/templates/|^\.github/prompts/|specs).*'

Let it document itself, add the requirements for documentation to the constitution with clear guidelines. This may also serve well as a quasi integrated memory for agents.

Always thoroughly review the created artifacts (1) spec.md, (2) plan.md, research.md, (3) tasks.md ... before moving on tho the next stage. The videos make this look as you could YOLO this, but this could not be further from the truth.

Do NOT let it introduce feature creep, when it asks you: "Do you also like me to implement 'some feature'?" answer with: "No stay on Mission, but this sounds like a good idea, create a follow-up issue to add to the roadmap."

At the end of a session, let the LLM reflect in a retrospective, and incorporate the findings in your constitution if applicable. Prompts:

create a retrospective for this session and check if the developer guide should be amended

check the retrospective.md if all follow up items are addressed

create github issues for the Future work items

You need some time to learn how to use speckit efficiently, it took me about a week to use it properly. Use a fairly complex problem to learn the usage, simple TODO apps just won't cut it.

Embrace the issue tracker, this is where you flesh out future work and the foundation of what you feed into /speckit.specify

TODO:

Clone this wiki locally