“Kernels” is a test of a way to capture smaller thoughts that have percolated throughout the week, similar to how I would previously used Twitter as a memex or Alex Komoroske’s weekly bits and bobs.
Consider all of these the seeds of something rather than strongly held, coherent views. Put another way: these are ideas I'm actively wrestling with, far from final form.
Also a programming note: if you have emailed me recently, I may have only seen it in spam…yesterday! My apologies! I am going through and replying back to the many emails that Gmail failed me with this week. As always, I really, really value receiving replies and comments.
Thinking about how to mitigate new existential risks to SNAP
I'm not sure it has reached broader attention that the recently-passed OBBB law creates something approaching an existential risk to the SNAP program, at least in certain states.
Specifically, in a provision that is effective in 2028 (but which looks at error rates for 2025 and 2026), some states will have to start paying a portion of the cost of SNAP benefits. Until now, these costs have been fully federally paid for. States will have to pay between 5% and 15% of benefit costs unless they can get their payment error rate down below a very low threshold, one that it is extremely difficult to imagine all states getting below it in the near term.
What makes this risk “existential” to me is that it drastically increases the potential state fiscal liability, to tens or hundreds of millions of dollars per year. And for the largest states like California and Texas, on the order of $1-2 billion per year.
The verbiage I'm using may sound hyperbolic, but let me unpack what I mean:
To this point, it's been a given that every state operates the SNAP program for its residents.
One of the reasons for that is that it's 100% federal benefit dollars. So it's a very good deal in terms of helping lower-income residents of a state while also pumping lots of money directly into the economy through grocery purchases.
But this new state fiscal liability has the potential to make states stop the operation of SNAP in that state completely.
I'm not sure everyone outside the weeds even realizes that that is a possibility. But it is. In fact, it’s baked into the CBO analysis of the bill’s cost reductions.
Part of what's been keeping me up at night is the question of how to maximally mitigate this more existential risk of some number of states wholesale ceasing the operation of SNAP.
Probably obvious to regular newsletter readers, but I work at Propel and do applied research using AI to help people navigate various aspects of the SNAP program. I’m also lucky to have a role at an organization that also supports me publishing our work in the open regularly, which I often cross-post here!
First, worth emphasizing that I’m thinking out loud and only speaking personally here. But it's hard for me not to think about the unique position the Propel app’s extremely large reach (~25% of SNAP households using the app) creates on a very specific aspect of the payment error rate (PER). Because getting PER down is the biggest opportunity to mitigate states bearing higher costs, and therefore states considering withdrawing from the program.
The thing about the SNAP payment error rate to know here is that one of the biggest sources of errors is when someone has a change in their situation but does not report it to their state.
And so when quality control samples their case, let's say 4 months into getting benefits, and they got a new job but didn't mention it. They're now getting more benefits than their income makes them eligible for. That is then a counted as an error.
And it’s a real error: the person’s situation has changed (and beyond the threshold of needing to report it) and their benefit amount is no longer what their situation makes them eligible for.
It’s also a particularly difficult problem for state agencies because it's not something that is simply a matter of improving internal processes or technology to process applications or recertifications with more accuracy.
Instead, it requires SNAP clients to be aware of on reporting rules and taking action on them — all outside their regular, recurring interactions with the state agency.
By way of this USDA infographic, 40% or so of payment errors are attributable to client errors, like failure to report new income.
The thing I can't help but put two and two together on is that…the Propel app has approximately 25% of the total enrolled SNAP population using the app every month, more regularly than they use pretty much any other SNAP surface area (e.g., state online portals). Something like a check-in regularly about whether anything in their situation has changed seems incredibly powerful here. There's also upside for the person here because if something has changed that would increase their benefit amount, they could be made aware of it too.
At the scale of ~5 million monthly users, it's hard not to think that that could make a real dent in SNAP payment error risks. But this is truly a kernel and I'm still wrestling with the idea. I very much welcome your thoughts if you're in SNAP land.
Code-to-spec, software systems, socio-technical technical systems, resource feedback loops: the four layers of a real software thing
I really enjoyed this conversation on the Dialectic podcast with Linus Lee. Linus had a line of thought in there that struck me:
One way I've grown as an engineer in the last year is that when I was really young, I viewed my job as writing code that solves the problem. The end artifact, the deliverable, was the source code.
I grew a little more mature and wiser, and my perspective changed. My job wasn't just to write the source code, but to deliver a running system. The system is derived from the source code, but it has to be reliable and hit certain operational metrics. It has to be understandable and debuggable. If something goes wrong, you need to be able to root cause it and fix it. If you want to make a change, you need to be confident that it's going to be good.
That's the second layer : the operational aspect of the software. More recently, I've been thinking about a third layer, which is especially important when working in a team. The first two layers make sense for a solo developer—writing the source code and then maintaining the software. The third layer you have to deliver is a people system or an organization capable of continuing to make changes to that software and evolve it as the world evolves.
In some ways, the thing you have to deliver is not just the software, but the processes, the culture, and the team itself. If you were removed from that equation, the whole system would be self-sustaining, resilient, and robust. It would continue to deliver a resilient, operationally excellent piece of software, as well as really good source code.
Building these three systems—the source code, the running system, and the team—in a way that is easy to change, understandable, and debuggable is what good engineering is, at least as I understand it at this point in my life.
This is a very nice articulation of something I think people have found hard-fought, and is a bit related to my second kernel above.
Code working to spec is simply one component. If salt-fat-acid-heat is the right metaphor for tasty food, then salt alone doesn't give you that much
The additional layer I would add on as fourth here is that for the socio-technical systems of people to make these things work and perpetuate and be a flywheel is: making a resource feedback loop work.
The “resource feedback loop” is a rudiment in my thinking that I've come back to time and again.
People will talk about business models and that kind of gestures at it, but it's misleading.
Because when you talk about a business model for a non-profit, it somewhat fits but is clearly a little weird relative to a commercial for-profit organization.
But when you get to something like a government agency, it really doesn't fit. A business model is a bit strange, but a resource feedback loop model is absolutely a reality embedded within it.
A company must figure out a model that yields profit.
But a non-profit must figure out a feedback loop that brings in philanthropic donations as a function of its activities. Hopefully more than its expenses, which one could call excess revenue, or one could call sustainable growth.1
And public sector entities have structurally the same thing!
The difference is that the resource feedback loop shows up in the form of budget committee hearings, and negotiations with executive offices, and similar resource allocation points.
Across all of these there is is a consistent, somewhat technical problem of optimizing the activities for effective resource drawdown from that resource feedback loop.
(A kernel for another day is my associated rudiment and thinking, which is something I’ve labeled in my own notes the arbitration of value. One wonderful delight from having studied political economy at Berkeley is that it was impressed on me quite early that value is not an objective thing, but rather is always mediated and arbitrated by someone.
In markets, it's usually consumers through their purchasing decisions. In non-profits, it's usually donors in their giving decisions. In government, it's usually budget decision makers and policymakers who are elected.
But it's always arbitrated, and always mediated by that arbitration, which is something that I think goes into my bucket of 40 reflections at 40 that someday I'll crank out. Because it's deeply misleading for someone at age 22 to think that value is objective when, in reality, what they're gesturing towards is value having some plurality agreement, or value in one form being rough consensus. It's still arbitrated. It's still mediated. And that subjectivity is an important substrate that if you ignore, you ignore at your peril.)
Some thoughts on the tech in civic tech
Something I've noticed is a phenomenon over the past many years, but particularly in the past year or so, of a very regular and strongly held view being asserted that the tech in civic tech is really either minor or non-consequential.
(Now, of course, “civic tech” is less an idea with coherence or coalition working with clear coordination, and more a semiotic gesturing at a big tent broadly aligned with a set of problems, but fairly fractured on elements of an agenda and the respective priorities assigned to those elements.)
While I think any reasonable approach to acting on systems means that no one lever is sufficient, I do think that some of the casual claims I hear overplay the case. It's worth not losing the ways in which technology is a differentiated lever from others in systems. Some of these, to me, are:
Drastic changes in the relative cost of different options that decision makers in various corners of the system have to choose from.
Increased legibility with many things, which allows for new options. With paper forms, you can do relatively small-scale usability testing and identify very large issues at some cost (including anti-inertia-capital cost if you want to do it inside a large organization.) By contrast, instrumenting page drop-off and time-on-page in a web-based multi-page form flow is effectively free, and continuous.
Overall, enabling a shift away from pure zero-sum games towards more positive-sum ones (for example, between workers processing paperwork and people filling it out). Again, using forms as an illustration, the argument is no longer about including a question or not. An online service makes it possible to hide conditional, irrelevant questions, satisfying more than one goal. And it does require technical capabilities and underlying shifts in the technological foundation to do the bigger things: for example, replacing a requirement to submit paper paystubs for income verification with a sufficient data service that requires no action by a person.
There's also a higher-order thing that I wrestle with here. I think a risk in throwing away technology as part of the bundle is that, sometimes, you end up left with only the previous levers that actual administrators have had available to them for some time — but which they are deeply constrained from using for reasons they will readily tell you.
I also think this is one of the reasons that sometimes administrators jump on technology: because if something really is different and newly possible, that enables them to do something without simply making a zero-sum trade-off on the set of options they've been sitting with for years or decades.
Example: lots of people make hay of the addition of chatbots to websites, and even transactional portals. They say, “instead you should be making core changes to the flow of those portals.” Absent constraints, absolutely!
But I think more about what's going on in the head of the decision maker there. It's not naivete about chatbots as panacea — though in some cases that may be a component undoubtedly — it's that the alternative you're saying they should do instead are something they believe is impossible, at least within the constraints they face. I'm all for pushing to do the thing that is more meaningful! But a push without some plausible offering for how those constraints can be removed is not compelling. It's more or less a re-shuffling of a zero-sum agenda.
And that might be the greater fear I have right now: that given that agendas truly are zero-sum in a way (whether you frame that as political capital or attentional energy inside a complex organization) it can create a blind spot on the very real, historically recurring, and often transformational positive-sum step functions that can occur when the underlying technological frontier of the possible shifts.
(Aside: I think we’re facing a big one right now.)
Or one could be particularly cynical and say, well, it's essentially profit with a special allocated purpose.
Another brilliant mind writing tidbits? How lucky we are. Thanks for this. Love the kernel and appreciate the reframe on "resource feedback loop" and subjectivity substrate.
Very thoughtful. Helpful to see how you unwind the ideas. The 4 layers of engineering is brilliant. Now I see why I, as a non tech user, struggled so much to get software projects done.