Hey {{first name | there}}. Over the last couple of years, I've spent a good amount of time in startups and individual contributor roles. Much of this has been great as I have gotten to explore problems that scratch my itch for building infrastructure.
In today's Technical Notes:
What changed in my thinking as I went from writing features to owning the product
Why the hard part was never the code
Why this was true before LLMs, and still is
Divine built an AI chat app back in 2023. It worked until it didn't.
A redeploy mid-conversation wiped the session, and an OOM error on Kubernetes did the same. The frustrating part was that stateless, single-turn requests were never built to remember a conversation in the first place.
Trigger.dev's new AI Chat framework (chat.agent) runs each conversation as a durable, long-lived task, so the state survives refreshes, deploys, idle gaps, and crashes.
It also ships human-in-the-loop controls out of the box: tool approvals, mid-stream steering, session branching.
And it is open source, which is usually where we start paying attention.
Check it out → https://fandf.co/3ScD98A
Thanks to Trigger for sponsoring this newsletter.
📰 TECHNICAL NOTES: Great, another code is cheap post
To begin, I would like to establish that this issue wasn't born out of the recent sentiment that code is cheap; the crux of the discussion here is how my thinking has evolved as I have gone from individual contributor to product owner.
So what are you on about?
At the very beginning of EverythingDevOps, a lot of my thinking revolved around how I can bring my technical knowledge to produce the best possible content for our clients.
Divine and I would often have debates about why a more elaborate demo doesn't always translate into adoption. This is because users don't always care about a complex use case but how quickly they can solve the problem they came to your website for.
I struggled with this because in my mind there were two extremes: a basic demo and a strong demonstration of any given product. The "middle ground" is how you produce mediocre content.
In hindsight, a lot of this comes from ego engineering that will have you over-build, but I digress.
Asking the right questions
When I say "code wasn't the hard part," I'm referring to the technical aspects of building a product or producing technical content.
I say this because code does not live in isolation. If the other parts of the business, i.e sourcing leads, keeping existing clients happy, and other things like tax, were not in place, there would be no code to write.
As an IC or someone earlier in their career, this is typically someone else's problem. But as you move up, you'd find the core of the business should influence product decisions and not the other way around.
For the longest time, this was the part I struggled with, and only after fully grasping this was I able to understand how the features I build impact revenue and also customer experience.
Where this leaves you
My point here is it's harder to know what to build and who to build it for versus the implementation; this has been true before LLMs and remains true in the age of LLMs.
Today's issue was a bit more theory than I'd like, but as I've mentioned most days, there are other "business problems" you have to face as a member of a founding team.
🌍IN THE ECOSYSTEM
Don't be a meat proxy — his pick. On refusing to be the human who just relays messages between systems without adding judgment.
Why write code in 2026 — Doug Turnbull on why writing code by hand still matters even when most of yours is AI-generated: it's how you experience the fragility an agent can't see.
Writing code isn't the bottleneck anymore, reading is — Three Dots Labs on how the real constraint quietly shifted from producing code to reading and understanding it.
Divine built an AI chat app back in 2023. It worked until it didn't.
A redeploy mid-conversation wiped the session, and an OOM error on Kubernetes did the same. The frustrating part was that stateless, single-turn requests were never built to remember a conversation in the first place.
Trigger.dev's new AI Chat framework (chat.agent) runs each conversation as a durable, long-lived task, so the state survives refreshes, deploys, idle gaps, and crashes.
It also ships human-in-the-loop controls out of the box: tool approvals, mid-stream steering, session branching.
And it is open source, which is usually where we start paying attention.
Check it out → https://fandf.co/3ScD98A
Thanks to Trigger.dev for sponsoring this newsletter.
⏱️UNTIL NEXT TIME
Going from writing the code to deciding what is worth building changes the job. You have to think beyond the technical work and start paying attention to the business decisions behind it too.
If you've made that transition, or you're still figuring it out, reply and tell me what helped you make the shift.
And if you know another engineer wrestling with the same thing, share this link with them
Jubril Oyetunji
CTO, EverythingDevOps