Yesterday I set out to add Cosmos to my demonstration project. The goal was to keep track of all queries, even after the browser is closed. My plan was to work with Spec Kit and Copilot, as described in my previous blog post. I didn’t know enough about working with Cosmos, but I was not intimidated; I had help.
The first step was to create a specification, saying what I wanted to build. (I reused the existing Constitution).
Replace the local JSON-only session store with a Cosmos DB for NoSQL-backed IBlogSessionStore implementation. Persist each complete BlogSession under its signed-in Microsoft Entra object ID, expose a console command that lists the owner’s 20 newest sessions, and retain the existing resume <session-id> and follow-up workflows. Use optimistic concurrency so a stale client cannot overwrite a newer saved session.
Actually, even that statement was written by Copilot. My initial statement was a bit sparser. In any case, with the plan in place, I could write my plan. When I did so, Spec Kit asked a number of clarifying questions to make sure it knew exactly what I wanted.
Q: How should the application identify the owner of each saved session?
It created a series of User Stories to ensure that I agreed with the acceptance criteria. With that in hand, it created a series of phased tasks and their implementation dependencies (e.g., you can’t do User Story 2 until you’ve finished the work for User Story 1).
I’m simplifying because this was covered in the previous blog post.
Spec Kit documented the research it did and the decisions it made, along with its rationale.
Decision: Reuse a single Cosmos client and use asynchronous APIs
Rationale: Reusing the client avoids connection churn, and asynchronous cancellation-aware operations match the existing store contract. Cosmos SDK retry behavior handles transient throttling; conflict responses remain user-actionable and are not retried as writes.
Alternatives considered:
- Construct a client per operation: adds latency and risks socket exhaustion.
- Retry every write: may hide stale-write conflicts and violate the specified reload behavior.
It was ready to list the tasks that would break down the work to be done. As part of creating the tasks, it created tasks.md, which listed what had to be done and which would contain boxes to check off as it proceeded.
Very cool. I set it free to write the code. It touched or added 17 files, not counting the documentation. It took a while to review all that code, but it was very well commented, and I didn’t have to make any changes.
I then asked it to provision a Cosmos database on Foundry, which it did, using my pre-existing resource
With this, I could observe the entries into the database. For each entry I could get the search request and its related metadata
It also added the “list” prompt to the console. When I click list, it displays the last 20 (configurable) queries.
All of this took two to three hours—and then only because I carefully read all the code as I went (and took one or two phone calls and made a cup of coffee). I would guess that this represented a 5-10x productivity improvement. And I ended up with extensive documentation, better than I could (or would) have written myself.
Next step: right now to resume a session, you have to enter the session ID (a GUID). I will have it number the entries (e.g., [1]) and then recall that session based on that number.
I love programming; I’ve been doing it for over 30 years (Assembly, C, C++, C#) but I don’t imagine I’ll be doing much keyboard banging any more. Yes, you need to know the language and idioms to check the code, but with this kind of productivity improvement it seems irresponsible to cling to the old way of creating applications.
Statement of the week related to the above: No one ever wanted a ½” drill bit. What they want is a ⅛” hole.
Followup
I grew impatient, so I put in another hour’s work with Spec Kit and Copilot and implemented the feature allowing the user to pick a number from the list and hiding the GUID
