1290 posts · Page 50 of 108. ← Blog
Where good eval cases actually come from — seeding by hand, harvesting from production telemetry, and curating a golden dataset in Go that doesn't rot the moment your prompt changes.
Where good eval cases actually come from — seeding by hand, harvesting from production telemetry, and curating a golden dataset in Go that doesn't rot the moment your prompt changes.
What if you could compute on data while it stays encrypted the entire time — never decrypting it, never seeing it, yet getting the correct result? It sounds impossible, but cryptography makes it real. Homomorphic encryption and secure multi-party computation let parties jointly compute on sensitive data that none of them can read, closing the one gap the other privacy techniques leave open: protecting data even during the computation itself. This post covers the most mathematically remarkable tools in the privacy toolkit.
What if you could compute on data while it stays encrypted, never seeing it, yet get the right result? Homomorphic encryption (math on ciphertext — private inference) and secure multi-party computation (secret sharing — the basis of secure aggregation) close the gap of protecting data in use — the strongest and most expensive tools.
gRPC isn't just request-and-response. Because it rides on HTTP/2, it offers four distinct call patterns: unary, server streaming, client streaming, and bidirectional streaming. Each fits a different shape of problem, and choosing the right one is a real design decision — it changes how your API feels, how it performs, and how it handles data that arrives over time rather than all at once.
gRPC isn't just request-and-response. Riding on HTTP/2, it offers four call patterns: unary, server streaming, client streaming, and bidirectional. Each fits a different shape of problem, and choosing the right one is a real design decision — it changes how your API feels, performs, and handles data that arrives over time rather than all at once.
A reasoning model thinks harder on its own — but you can spend test-time compute on top of any model, reasoning or not, to squeeze out more accuracy. Generate many answers and vote. Generate many and pick the best with a verifier. Search a tree of reasoning steps, pruning the bad branches. These techniques share one shape — do more work at inference, then choose well — and understanding them turns test-time compute from a model property into a toolkit you control.
A reasoning model thinks harder on its own — but you can spend test-time compute on top of any model to squeeze out more accuracy. Generate many answers and vote. Generate many and pick the best with a verifier. Search a tree of reasoning steps. These techniques share one shape: do more work, then choose well.
An agentic coding tool that lives in your terminal, reads and edits your real codebase, runs commands, and works through multi-step tasks — not an autocomplete, but a collaborator you delegate to.
The opener to a Claude Code series: what an agentic, terminal-native coding tool actually is — it takes a goal and executes multi-step work on your real codebase, with permissions keeping you in control — and the mental model that makes it click.
Part software engineer, part consultant, part product manager — the forward deployed engineer works inside the customer's world to turn a hard problem into working software, then carries what they learn back to the product.
The opener to a forward deployed engineering series: the FDE role as a blend of engineer, consultant, and product manager — embedded at the customer, building real software against a vague problem, then carrying the learnings back to the product.
The opening post of a hands-on series for builders: what it means to systematically stress-test an AI system — model, prompts, retrieval, tools, and guardrails — to surface its failures before adversaries or ordinary users do, how that differs from pentesting and robustness testing, and the frameworks and ethics that keep the work rigorous.
The opener to a defensive AI red-teaming series: stress-testing AI systems (models + prompts + RAG + tools + guardrails) to find failures before adversaries do — how it differs from pentesting, the frameworks (OWASP GenAI, MITRE ATLAS, NIST AI 100-2), and ethical rules of engagement.
The opening post of "The Software Architect's Path" — demystifying the role by separating what architecture actually is (the decisions that are hard to reverse) from day-to-day coding, and arguing for the hands-on architect over the ivory-tower one.
The opener to an architect series: what architecture actually is (the significant, hard-to-change decisions), the architect's real responsibilities, the hands-on architect-who-codes model vs the ivory tower, and the myths worth discarding.
The first post in a practical series on code review — what the practice is actually for, what it is not, and why treating it as a collaboration rather than a gate is what makes it worth the time it costs.
The opener to a code-review series: what review is actually for — catching defects early, better design, knowledge sharing, collective ownership — and what it isn't (gatekeeping, style bikeshedding), plus the healthy team norms that make it work.
The opening post of a DevSecOps series — how security stops being a gate at the end of delivery and becomes an automated, shared responsibility built into every stage of the pipeline.
The opener to a DevSecOps series: building security into the delivery lifecycle instead of bolting it on — shift-left (and shift-right), security as everyone's job, the CI/CD pipeline as the enforcement point, and the automated controls the series wires up.
Why APIs became the primary attack surface, how API risk differs from classic web-app risk, and the OWASP API Security Top 10 framework this series builds on.
The opener to an API security series: why APIs are the primary attack surface, the OWASP API Security Top 10 (BOLA, broken auth, BFLA, SSRF, misconfiguration, inventory…), how API security differs from web-app security, and how to threat-model an API.
The opening post of a series on designing APIs people actually enjoy using — why an API is a contract and a product, the qualities that separate a good one from a bad one, and why the contract should exist before a single line of implementation.
The opener to an API design series: an API is a contract and a product whose users are developers — the qualities that matter (consistency, evolvability, hard-to-misuse), API-first vs code-first, the interface/implementation boundary, and the paradigms you'll weigh.