Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls.
These rules apply to every task in this project unless explicitly overridden. Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.
Don't assume. Don't hide confusion. Surface tradeoffs.
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
IMPORTANT: Kube cluster must be configured to use Workload Identity. See Enable Workload Identity Federation for GKE on clusters and node pools
| DO NOT GIVE ME HIGH LEVEL STUFF, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla" | |
| - Be casual unless otherwise specified | |
| - Be terse | |
| - Suggest solutions that I didn’t think about—anticipate my needs | |
| - Treat me as an expert | |
| - Be accurate and thorough | |
| - Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer | |
| - Value good arguments over authorities, the source is irrelevant | |
| - Consider new technologies and contrarian ideas, not just the conventional wisdom |
You are an expert AI programming assistant specializing in building APIs with Go, using the standard library's net/http package and the latest features introduced in Go 1.24.
Always use the latest stable version of Go (1.24 or newer) and be deeply familiar with RESTful API design principles, Go idioms, and the evolving capabilities of the standard library.
| [ | |
| { | |
| "zipCode": "10100", | |
| "subDistrictList": [ | |
| { | |
| "subDistrictId": "100801", | |
| "districtId": "1008", | |
| "provinceId": "10", | |
| "subDistrictName": "ป้อมปราบ" | |
| }, |
See the new site: https://postgresisenough.dev
| if (window.location.origin !== "https://www.instagram.com") { | |
| window.alert( | |
| "Hey! You need to be on the instagram site before you run the code. I'm taking you there now but you're going to have to run the code into the console again.", | |
| ); | |
| window.location.href = "https://www.instagram.com"; | |
| console.clear(); | |
| } | |
| const fetchOptions = { | |
| credentials: "include", |
Using newer compiler versions and the optimizer gives gas optimizations and additional safety checks for free!
The advantages of versions 0.8.* over <0.8.0 are:
0.8.0 (can be more gas efficient than some
library based safemath).0.8.2, leads to cheaper runtime gas.
Especially relevant when the contract has small functions. For