The Making Of Tako Gallery

Motivation

I wanted to toy around with the Tako API and experiment with some 'vibe coding' tools. For context: Tako is a data visualization service, and if you don't know what 'vibe coding' is I'll also explain that in a moment.

But essentially Tako's software takes natural language queries, finds relevant data, then autogenerates charts for that data, which are saved as 'cards'. I thought building a gallery to showcase Tako cards would give me a good feel for their API.

Vibe Coding Tech Stack

For those unfamiliar, 'vibe coding' is like actual coding, aside from the part where you write code. Basically, all you do is plan, then just have an AI agent do everything else for you. One imagines he is tasting what it is like to be a project manager in the sci-fi future.

Anyways, For this project, I used:

• Initially: Vercel's v0 - I used this for the first half of the project
• Later: VSCode with the Cline extension and Claude Sonnet 3.7 - I switched to this setup when the project complexity increased

The Vibe Coding Process

Step one is to create a roadmap.

When I plan to let the AI loose to do as it may, I find it helpful to pre-establish some clear direction. Helps keep it on track. You could craft this yourself, carefully planning out how you want the project to look, ensuring you're keeping best practices in mind, minimizing complexity, so on and so forth,

Or... you could just have the AI do all that for you too. Usually I beseech the most advanced reasoning model I happen to be paying for, but this time I just asked Vercel's v0, since I wanted to try it out.

Prompt Structure

The structure I use for most big prompts is something like:

• Initial ask: What I want from the AI, as simply as I can phrase it
• Context: Elaboration on the ask, details, exceptions, immediately relevant info like API definitions.
• My life story: Anything relevant that comes to mind. Why I want the thing built, what I'm going to use it for, what features I want to see, childhood trauma that's made me the person I am today.
• (Optionally): Reiterate ask. Literally I just repeat the initial ask at the end of a long prompt. Dunno if this is necessary, but it feels useful sometimes

I'd like to build the applet as a gallery of 'cards' from generated from queries to the Knowledge Search API of the company Tako. Tako is a company that automatically generates charts from semantic search queries.

Can you construct a plan for the applet such that:
- It accepts a Tako API key and a query string, which it uses to run a Tako Knowledge search
- It then saves the resulting card to a hosted mongodb atlas database (I will save the atlas database credentials as the `MONGODB_URI` environment variable)
- It hashes the Tako API key, stores that in the database, then associates a 'collection' of cards with each unique API key
- Allows the user to choose a unique 'username' for the API Key/collection, which will be the URL endpoint for users to view all cards generated with that API Key
- Allows a user to delete a card by entering the API key used to generate it.
- It is all hosted on vercel

Don't produce any code just yet. First let's create a design specification and implementation plan for this applet. Try to minimize complexity. Write the plan with an AI coding agent in mind.

---

For context, here is the API specification for the Tako Knowledge Search API:
[... API documentation was pasted here ...]
[Like literally I just copied the pages and pasted them in here.]

---

The goal for the gallery applet is to create a sort of stateless public archive of Tako queries. Anyone with a Tako API key can use the applet, but the applet itself has minimal authentication--essentially piggybacking off of Tako's own auth setup, and storing only the necessary credentials to use my mongodb atlas cluster and to associate cards with API keys to have separate collections. The database should also only store the json representations of the Tako cards, taking advantage of the fact that tako hosts the meat of the representation.

Tako cards should be shown in a minized form and should expand when selected. Expanded Tako cards should furthermore have an option to show their associated grounding info. 

The webapp should automatically generate a new collection page when an as-yet unused API key is used *successfully* to make a query, and should prompt the user of the API key to select a username, which will then be used as the URL endpoint for the user's collection page.

Given this specification document, can you devise a series of commits to take this project from scratch to a production ready state? Start from the initial commit with just vercel project scaffolding, then describe what code to write at each step to build that scaffold into the full gallery, collection, and database app described in the design specification.

Each enumerated commit should include a list of files to modify, the functions of those files, and what state the project will be in before and after the commit. An AI coding agent will later implement each commit in turn, so please ensure the commits are written with that in mind.

Please enumerate the commits that we will need to perform.

Development Journey

With all that ready, I set up a Github Repository and then started asking v0 for files.

The v0 Phase

v0 breezed through the initial commits with no problems. It set up the project structure, implemented the Tako API integration, and created the database models. My initial dump of the Tako API documentation proved to be sufficient for it to just figure everything out with no further direction.

I had to step in briefly when setting it up to associate all requests with the same API key to the same user. My fault, really, that the AI didn't understand what I was doing. It made sense at the time:

'All requests made by the same API key go to the same collection. Therefore, the API key defines the collection.' Simple. Elegant even, if you're lying to yourself about your motivations so you can avoid rolling auth. Anyways, much like a human, the AI gets confused when presented with wacky kludges so I had to help it out.

Anyways after tweaking that, v0 successfully completed through commit 12 in the roadmap (embedding Tako cards in the page). No major issues. Commit 13, however, (creating a collection page to display all a user's cards) proved too much for it. I suspect the issue was that I asked it to deviate from the original roadmap and store collections at the endpoint /collections/[username], rather than just /[username].

Switching to Cline + Claude

At this point, the v0 context was becoming cumbersome, and the issues were becoming difficult to resolve with pure, thoughtless vibe coding. I decided to switch to my normal workflow of using VSCode with the Cline extension and Claude Sonnet 3.7.

From there, I implemented the rest of the commits, mostly using a prompt scaffold like this:

I've been working on this webapp that's mean to be a gallery project of 'cards' from Tako, a data-visualization service. Now I need to add a readme and some documentation, which would be step 21 of an ongoing implementation plan, described here:

```
## Commit 21: Final Polishing and Documentation

**Files to create/modify:**

- `README.md`
- `app/about/page.tsx`
- Various component updates for final polish


**Functions:**

- Create comprehensive documentation
- Add about page with usage instructions
- Final UI polish and consistency checks
- Prepare for production deployment


**State before:** Project with analytics but limited documentation
**State after:** Production-ready project with complete documentation
```

For full context, see the roadmap.md file.
For the design spec that this exists within, see v0-implementation-plan.md.

Could you help me add a readme and an about page to this webapp?

Notably, I never had to provide the Tako API specification again. Simply pointing the AI to my existing v0-implementation-plan.md and letting it read from my files was enough for it to make no errors (that I'm aware of) while interfacing with Tako or MongoDB.

I even expanded my filtering setup to use more Tako response info (methodology, source name, source index), and a dump of the documentation page contents here was sufficient for that too.

Lessons Learned

The Main Snag

But yeah the main issue I ran into in all this that REALLY required me to stop vibe coding and instead troubleshoot manually was related to performance optimizations. Later in the project, (the roadmap's step 19), I got it in my head to try a bunch of pre-fetching and caching tricks, but once I had it all set up, I realized these tricks were making it so new cards wouldn't show up after being created.

Ultimately I wound up reverting the whole feature, since I let it get pretty entangled in there and the AI was just trying ineffectual cache-busting strategies that were adding a bunch of complexity while not fixing the problem. Pretty sure the revert is in the commit history somewhere, if you wanted to go see my shame.

Now though, the project is finished. Check it out! Generate some cards of your own!

See It In Action

Here's an example of a Tako card generated and stored in the gallery: