If you want to learn how to unicycle, and you speak Spanish, you may be interested in a booklet I wrote about how to learn to unicycle when my kids were learning: https://juanreyero.com/monociclo/
I have used the technique to teach other people, and it works surprisingly well.
Skills are also a convenient way for writing self-documenting packages. They solve the problem of teaching the LLM how to use a library.
I have started experimenting with a skills/ directory in my open source software, and then made a plugin marketplace that just pulls them in. It works well, but I don't know how scalable it will be.
is a unified interface across OpenAI, Anthropic, Google, and Ollama - same code works with all providers.
Use aliases instead of hardcoding model IDs. Your code references "summarizer", and a version-controlled lockfile maps it to the actual model. Switch providers by changing the lockfile, not your code.
Also handles streaming, tool calling, and structured output consistently across providers. Plus a human-curated registry (https://llmring.github.io/registry/) that I (try to) keep updated with current model capabilities and pricing - helpful when choosing models.
An MCP server and client are included, as well as the ability to help you define your aliases/models with an interactive chat.
It's a thin wrapper on top of the downstream providers, so you are talking directly to them. And it also comes with a postgres-backed open source server to store logs, costs, etc.
MIT licensed. I am using it in several projects, but it's probably not ready to be presented in polite society yet.
I built LLMRing (https://llmring.ai) for exactly this. Unified interface across OpenAI, Anthropic, Google, and Ollama - same code works with all providers.
The key feature: use aliases instead of hardcoding model IDs. Your code references "summarizer", and a version-controlled lockfile maps it to the actual model. Switch providers by changing the lockfile, not your code.
Also handles streaming, tool calling, and structured output consistently across providers. Plus a human-curated registry (https://llmring.github.io/registry/) that I keep updated with current model capabilities and pricing - helpful when choosing models.
MIT licensed, works standalone. I am using it in several projects, but it's probably not ready to be presented in polite society yet.
Technologies: Python, Common Lisp, Javascript, technical leadership, systems architecture, several other programming languages, mechanical engineering.
I pay for ChatGPT-4. It's helping me program noticeably better and much faster, even with mid-sized projects involving many files. This is the process that I follow:
- I write a system prompt with a succinct description of what I want to implement: "X is an online app that does Y, with these features: ..." I try to be exhaustive, and I write as I would if I were describing what I want to do to a very proficient programmer who needs to understand the problem and the solution. I save this to a prompts/0-system.txt file that will be part of the project.
- I design an architecture and define the general boundary conditions. I may ask ChatGPT for opinions, but at this stage, it's mostly based on experience. I add it to the system prompt.
- I write a description of the first chunk of functionality that I want to implement, usually a set of functions or a class, at the individual file level. For example, prompts/1-dal.txt.
- I (actually ChatGPT) wrote a very simple recursive cat script (https://github.com/juanre/catprompt) that combines several files into a single prompt (a file can include other files, etc). I add a line to prompt/1-dal.txt pointing to the system prompt, and use catprompt to create a combined prompt that will include the overall description and the specifics of the functionality I am after.
- I give this prompt to ChatGPT, and it produces the code. It's typically perfectly fine. I add it to the project, for example, as dal.py, review, and fix whatever may need fixing.
- I ask ChatGPT to create tests in the same session. This also tends to work fine.
- Then I move to the next piece of functionality, in a new session. I write another description, in another file, including the system prompt and usually the code already created.
The prompts remain: they become a description of the code (and of my intentions) for other programmers, and they can help ChatGPT write documentation as well.
I enjoy programming like this. The effort I make in writing concise descriptions helps me think more clearly. I used to love literate programming back in the 90s, and this feels very much like it. Knuth described it thus:
"Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do."
Replace "human beings" with LLMs, and I think that's where we are now.
I've essentially been using ChatGPT-4 in the same way and can confirm that the code it gives typically works. If not I just decompose pieces of it once and try again. If it fails there I just write it myself.
It certainly saves me time, and I end up with better code and better documentation. I can stay thinking at a higher level, which removes cognitive friction. I usually don't want to be programming: I want the functions I need to be written and working. ChatGPT-4 takes care of that quite well.
It uses PostgreSQL with pgvector, hybrid BM25, multi-query expansion, and reranking.
(It's the first time I share it publicly, so I am sure there'll be quirks.)
reply