I really love seeing more and more serious engineering being put into making LLMs actually work in production. They’re too cool a tool not to use or integrate into consumed software, but nobody actually wants more shitty chat bots. Making them work reliably to actually make software better requires structure and effort, and this is one cool way of thinking about it I hadn’t come across before.
Without additional artifacts beyond what human-driven CD requires, agent-generated code accumulates drift and technical debt faster than teams can detect it.
I always appreciate these kinds of candid analyses. I’ve become convinced that all the various things people refer to as “AI” are indeed very useful, but they don’t obviate the need for actual engineering. At this point it’s been many years since LLMs became broadly available and the benefits remain largely hypothetical and in the future but the harms are very much real and present today.
I was about to write a post about the current state of the art in LLM/agent "memory". But before I publish that and the ensuing who-knows-many follow ups, I have to admit I was one of those people who, two years ago, said LLMs were just yet another annoying hype cycle. […2 min read]
I've been thinking about versioning (for work) lately and I'm reminded of Rich Hickey's take on it from his Spec-ulation talk. The gist of it is that it’s more useful to think in terms of breakages and accretions as opposed to the more vague notion of “versions”. He (perhaps controversially) suggests that breaking changes should just be considered new things, the concept of having a new “version” of something that is not compatible with the old one is incoherent if you think about it.
This really hit home for me. Lately I've been feeling very overwhelmed and bored at work, feeling like I'm just drowning in AI slop and cannot possibly keep up. AI-generated PRs are flying through our previously robust process, production problems are way up, most of what I read day to day is not AI-generated, and it's frankly exhausting.
This was an interesting read with some useful advice on how to not go crazy at work. I've worked at lots of places and even the best of them come with their share of problems. It seems like there's just something about trying to get a large number of humans to coordinate on achieving a common goal that never goes very well.
This was a great read, an interesting takeaway is that we should be thinking about interacting with APIs differently when writing "agents" (I like Simon Willison's definition of "agent" as an LLM that runs "tools in a loop to achieve a goal").
I work with a lot of different kinds of data, and I'm very interested in the processes around how we transform the piles and piles of messy information that are so ubiquitous these days into useful data. I'm learning about data observability on Coursera and just came across this article that I think articulates many of the biggest problems in data engineering and data science right now really well. In particular this point:
I love Randy Au's newsletter in general, but this one makes a particularly useful point: Not thinking about why you're doing something ahead of time is expensive and wasteful.