This blog post is for folks working on harness engineering. My intention is to write down the tenets that I keep in my head: tenets that position us to ride the curve (as we upgrade a model, our agent becomes better) rather than constantly babysitting and tweaking our agents.
This article was originally published on the AWS DevOps Blog.
If you’re building an agentic product, especially in a large tech company, you’ll likely need to integrate with multiple partner teams that offer unique context or actions that enhance your agent’s performance. These integrations are most commonly vended as MCP tools. These tools come in vastly different granularities. On one end of the spectrum are deterministic, fast, “do one thing well”…
In traditional software engineering, we create customer value by working on small, focused features delivered frequently. When building products where generative AI is a key component, I’ve noticed organizations adopting the term “capability” with similar intentions.
As I progressed from a junior to senior software engineer within Amazon, I came to view leveling up as a function of wisdom - f(wisdom) - where as your applied or practical knowledge increased you were rewarded with a promotion. Therefore, when a peer got to level up to principal from senior engineer, my interpretation was that the organization valued my judgment less than my promoted peers, which…
In this post, we’ll explore how “goodput” (the rate of useful, successful work completed) degrades under increasing load, particularly in multi-step workflows that depend on rate-limited services. We’ll also see why throttling incoming requests leads to more useful work.
At large companies like Amazon, it’s inevitable that multiple independent teams will attempt to solve the same, or closely related, problems. One approach that optimizes for time-to-market is for each team to independently make decisions, build, and deliver solutions. At Amazon, this aligns with the “bias for action” leadership principle when a team needs to act swiftly:
At Amazon, we refer to any usability frictions or, more broadly, small product issues as paper cuts. A few paper cuts aren’t particularly damaging, but a thousand (paper) cuts cause significant customer pain. Fixing paper cuts and iterating on existing features is not only important to create experiences that customers are enthusiastic about, but at a personal level, it elevates our work to…
The goal of this blog post is to enumerate techniques, adapted from Ward Farnsworth’s The Socratic Method [1] and Adam Grant’s Think Again [2], for effective feedback while reviewing technical writings such as a RFCs or PR-FAQs. By effective, I mean leading the author towards a better technical direction by moving the author’s mind without being adversarial about it.
Let it happen, if it wants, to whatever it can happen to. And what’s affected can complain about it if it wants. It doesn’t hurt me unless I interpret its happening as harmful to me. I can choose not to. –Marcus Aurelius