Archive
1046 posts · Page 38 of 88. ← Blog
The dominant story of AI progress for years was training-time scale: bigger models, more data, more training compute. Test-time compute is a second, independent axis — spend more computation when you run the model, not when you train it, and get better answers on hard problems. It reframes a trained model not as a fixed-capability artifact but as one whose performance you can dial up per query by letting it think more.
The dominant story of AI progress was training-time scale: bigger models, more data. Test-time compute is a second, independent axis — spend more computation when you *run* the model, not when you *train* it, and get better answers on hard problems. It reframes a model as one whose performance you can dial up per query.
The opener for a Go series on building LLM and agent applications with Amazon Bedrock — what the service actually is, why it sits between your Go code and a dozen foundation models, and which aws-sdk-go-v2 packages you will lean on for the rest of the way.
The opener to a series on building LLM and agent applications on Amazon Bedrock in Go: what Bedrock actually is, what it adds over calling a provider API directly (one API across models, IAM auth, data residency), and the aws-sdk-go-v2 packages you'll use.
Wire the embedding client, vector store, and chat client from the last five posts into one working RAG pipeline in Go — ingest and chunk documents, retrieve the top matches for a question, inject them as grounded context, and generate a cited answer, all from scratch.
Assemble embeddings and vector search into a working RAG pipeline in Go: chunk documents, embed and store them, retrieve the top-k for a query, augment the prompt with grounded context (and cite sources), then generate — a baseline end-to-end Answer() built from scratch.
The core of the series: a minimal, original evaluation harness in Go. Run an agent under test through adk-go's runner, capture the tool-call trajectory and the final response behind an adapter you own, and score them with `go test`.
The core of the series: a minimal, original evaluation harness in Go. Run an agent under test through adk-go's runner, capture the tool-call trajectory and the final response behind an adapter you own, and...
Knowing the type system isn't the same as using it well. Idiomatic TypeScript is a set of judgments: lean on inference, avoid `any`, model impossible states out of existence, and know when a type earns its complexity. On a large, long-lived codebase these habits are the difference between types that catch bugs and types that are decorative noise. This closing post turns the mechanics of the series into a working discipline.
Knowing the type system isn't the same as using it well. Idiomatic TypeScript is a set of judgments: lean on inference, avoid any, model impossible states out of existence, and know when a type earns its complexity. On a large codebase these habits separate types that catch bugs from types that are decorative noise.
The observation that launched reasoning models was almost embarrassingly simple: if you ask a language model to "think step by step" before answering, it gets dramatically better at hard problems — with no change to the model at all. That a few words of prompting could unlock reasoning already latent in the model was a clue about something deep: the ability to reason was there, waiting to be elicited, and giving the model room to work was the key.
The observation that launched reasoning models was almost embarrassingly simple: ask a model to 'think step by step' and it gets dramatically better at hard problems, with no change to the model. That a few words could unlock latent reasoning was a clue about something deep.
Build a working in-memory vector store and exact k-nearest-neighbor search in Go by hand — no vector database — then understand precisely what HNSW, FAISS, and pgvector optimize when brute force finally runs out of road.
Build an in-memory vector store and exact k-NN search in Go by hand: a VectorStore with Add and Search, top-k selection with container/heap, normalize-on-insert, an honest look at when brute force is right, and when ANN (HNSW, FAISS, pgvector) earns its keep.
Before you can evaluate an agent in Go, you need a mental model of what "evaluating an agent" even means. This post unpacks the conceptual core of Google's Agent Development Kit eval framework — cases, trajectories, metrics, thresholds — the parts that are language-agnostic, so the rest of this series can implement them as plain Go types and functions.
Before you can evaluate an agent in Go, you need a mental model of what "evaluating an agent" even means. This post unpacks the conceptual core of Google's Agent Development Kit eval framework — cases,...
A complete guide to giving a Microsoft Agent Framework agent the ability to act — from a plain Python function the model can call, to provider-hosted sandboxes, remote MCP servers, and higher-level packaging patterns like Skills and CodeAct.
A complete guide to giving a Microsoft Agent Framework agent the ability to act: function tools, provider-hosted tools (code interpreter, file search, web search), local and hosted MCP, plus Skills and CodeAct — with the code and gotchas for each.
Types are only half of TypeScript; the other half is the machinery that compiles, configures, and connects your code to the vast JavaScript ecosystem. ES modules organize code, `tsconfig.json` controls how strictly the compiler checks it, and declaration files let typed and untyped code interoperate. Understanding this layer is what turns a working `.ts` file into a real, maintainable project.
Types are only half of TypeScript; the other half is the machinery that compiles, configures, and connects your code to the JavaScript ecosystem. ES modules organize code, tsconfig.json controls how strictly the compiler checks it (turn on strict), and declaration files let typed and untyped code interoperate. This is the practical infrastructure of a project.
The transition that breaks the most technical careers is the one from doing the work to leading the people who do it — because it's a switch from a domain where emotional intelligence is optional to one where it's the entire job. A leader's technical brilliance means little if they can't create the conditions for a team to do its best work: trust, safety, motivation, and healthy dynamics. This closing post is about EQ where it matters most, and where technical leaders most often struggle.
The transition that breaks the most technical careers is from doing the work to leading the people who do it — a switch from a domain where EQ is optional to one where it's the entire job. A leader's technical brilliance means little if they can't create the conditions for a team to do its best work.
For years, the way to make a language model better was to make it bigger — more parameters, more training data. Reasoning models represent a different bet: instead of only scaling what the model knows, scale how much it thinks before answering. A reasoning model spends extra computation at inference time working through a problem step by step before committing to an answer — and on hard problems, that changes what's possible.
For years, making a language model better meant making it bigger. Reasoning models represent a different bet: scale how much the model *thinks* before answering, not just what it knows. A reasoning model spends extra computation working through a problem step by step — and on hard problems, that changes what's possible.