EODHD Academy
‹ Build Your First Tool Lesson 2 of 16
Contents Lesson 2 of 16

6 min read · foundations

Your cockpit — where vibe-coding actually happens

"Vibe-coding" describes a way of working, not a product. The same loop runs in four quite different environments, and the one you pick changes what you can see, what you can review, and how easy it is to ship. Choose deliberately rather than settling for whatever was already open.

Products change every quarter. The four modes below have been stable for years, so learn the modes and treat the product names as examples.

Mode 1 — the terminal agent

An assistant that lives in your shell, with permission to read your repository, edit files, and run commands. You watch diffs go by and approve them. Claude Code, Codex CLI and Gemini CLI work this way.

This is the mode with the most leverage and the most rope. The assistant can run your tests, read the error, and fix it without you copying anything — and it can also rewrite eleven files while you were reading the first one. It suits people who are comfortable in a terminal and want the assistant working on the whole project rather than on a snippet.

This academy is built this way. The lesson you are reading, the proxy in the starter repo, and the tests that guard it were written in a terminal agent, reviewed diff by diff.

Mode 2 — the IDE

Your editor, with an assistant inside it: Cursor, VS Code with Copilot, Windsurf. Changes appear as inline diffs in the file you are already looking at, in the editor you already know.

The best default for most people. You keep every habit you have — file tree, search, debugger, git panel — and the assistant becomes another way to edit rather than a separate world. It is weaker than a terminal agent at multi-step work ("run the tests, read the failure, fix it") and much better at staying inside the lines.

Mode 3 — the chat window

claude.ai, chatgpt.com: you describe, it writes, you copy, you paste, you run, you paste the error back.

Honest assessment: excellent for a function, a regex, an explanation of an error message — anything self-contained. Poor for a repository. The assistant cannot see your files, so it guesses at your structure, and every guess has to be corrected by hand. If you build a whole project this way you will spend most of your time being a clipboard.

Mode 4 — the cloud builder

bolt.new, v0, Replit, Claude's own artifact-and-code surface: describe an app, watch it appear, get a URL. No local setup at all.

Astonishing for the first ten minutes and the right choice for a throwaway prototype. The trade is control: it is harder to see what was written, harder to bring the result into a repository you own, and the environment decides things for you. This course goes the other way — you will own a repository and a deployment — but if you want the fastest possible "something exists", start here and port it out.

Which one for this course

Any of the first two. The lessons assume you can see a diff before it lands and run a command; both the terminal agent and the IDE give you that. Chat will work with more friction. A cloud builder will fight the fork-and-deploy step in unit 4.

Wiring your assistant to real market data

Here is the part that changes the quality of generated code more than the choice of cockpit does.

By default your assistant is guessing about the EODHD API: it remembers field names from its training data, some of which are wrong, and it cannot check. You can give it the real thing:

  • The MCP server connects an assistant to the live API, so it can query real endpoints while it writes your code and see the actual response shape instead of predicting one.
  • The Claude skills pack teaches an assistant the whole API surface at once.
  • The ChatGPT assistant does the equivalent inside ChatGPT.

All three are linked in this lesson's sources. Wire one up before unit 2 and the difference is immediate: code that uses fields which exist, with the types they actually have.

One boundary, and it holds for the whole track. The assistant queries the API at build time; your deployed tool never does. Your running application talks to the API through the server-side proxy you will build in the next lesson, and only that way. Build-time and runtime are different worlds with different rules, and confusing them is how keys leak.

Try it now

Pick a cockpit and prove it works before you need it. Open the starter repository in it, ask your assistant "what does src/lib/eodhd.ts do and where is the API key read?", and check its answer against the file yourself. You are testing two things at once: that the tool can see your code, and that you can tell when it is right.