|
Autonomous Software Development for the Enterprise (Sponsored)
 |
Blitzy is built for large, complex software projects that other coding agents cannot handle: new feature development, large-scale refactors, scaled vulnerability remediation, and undocumented legacy systems.
Blitzy’s Sandbox lets engineers evaluate Blitzy on their own software estate, at their own pace. Eligible organizations can connect real applications, reverse-engineer up to 1 million lines of code, generate up to 25,000 lines of E2E tested code, and surface prioritized security vulnerabilities across their software estate.
This week’s system design refresher:
API Concepts Every Software Engineer Should Know
5 Way to Defend Prompt Injection
New Course: Rebuild YouTube with AI Starts in a Week
12 AI Papers that Changed Everything
Monolithic vs Microservices vs Serverless
7 Key Load Balancer Use Cases
API Concepts Every Software Engineer Should Know
Most engineers use APIs every day. Sending a request and reading JSON is one thing. Designing an API that other people can rely on is something where things get complicated.
 |
A lot of problems begin with basic HTTP details that seem small at first. Methods, status codes, request formats, and response structure can make an API feel clear and predictable, or confusing and inconsistent.
Then there are the bigger design choices. REST, GraphQL, gRPC, webhooks, and WebSockets each make sense in different situations. The challenge is knowing what actually fits the system and the use case.
A lot of API problems also comes from design decisions that do not get enough attention early on. Naming, pagination, versioning, error responses, and backward compatibility often decide whether an API is easy to work with or frustrating to maintain.
Security is another area where weak decisions can cause real problems. API keys, OAuth, JWTs, scopes, and permissions are easy to mention. Getting them right is harder, and mistakes here can be costly.
Reliability matters too. Timeouts, retries, idempotency, rate limits, and caching are often easy to ignore until the system is under pressure.
And once an API starts growing, the supporting work matters too. Clear documentation, solid specs, observability, and contract testing make it much easier for teams to trust the API and use it without guessing how it works.
Over to you: What’s the most overlooked API concept in your experience?
5 Way to Defend Prompt Injection
Prompt injection tops the OWASP LLM Top 10 and there’s no single fix.
Instead, you stack defenses, each one catching what the others miss.
 |
Defenses come in two families: model-level and system-level.
Model-level defenses teach the model to resist injection.
Spotlighting wraps untrusted text in control tags like <UNTRUSTED>...</UNTRUSTED> and tells the model to treat anything inside as data, not instructions.
Instruction Hierarchy fine-tunes the model to rank the developer’s system prompt above the user’s message, and both above third-party content.
System-level defenses build a system around the LLM that bounds the damage.
Least-Privilege Tools: Give the agent the minimum tools it needs.
Human-in-the-Loop: Require explicit user approval before any sensitive action runs.
Planner / Executor Split: Two separate LLMs. The planner has tool access but never sees untrusted content. The executor reads untrusted content but has no tools.
No single defense is enough. Production systems like Gmail stack them, and together they make indirect injection manageable.
Over to you: what’s the one defense you’ve seen work in production that isn’t on this list?