In this episode of Alexa's Input (AI), I sit down with Alex Zenla, founder and CTO of Edera.

Alex grew up in a small town in Alabama, found a computer young, and started building. Her story is unlike many in tech. She taught herself to program and got a job in tech at 14 years old. Since then, she's been actively building and involved in open source. She's currently the founder and CTO of Edera, a company whose product integrates security into the lowest layers of the platform without sacrificing performance or velocity.

In this episode, we get into where that path started, what it costs to be different in founder and venture rooms, and what breaks when infrastructure still ships with security off by default.

From the episode:

• Growing up in small-town Alabama without a path into tech
• Southern niceness as theory versus practice
• Full-time work at fourteen and presenting to executives as a teenager
• Being one of very few trans founders in venture rooms, and the tension between visibility and being treated as a token
• Elevator pitches that change with the audience
• Detection and response after a problem has already occurred
• Common Vulnerabilities and Exposures becoming untenable when tools like Mythos surface hundreds of findings per project per day
• Kubernetes and vendors selling yet another layer while the foundations underneath are misaligned
• Secure defaults as the path of least resistance for teams that just need a cluster that works

Alex's mission is to make secure computing the default. Today you work hard to get a secure environment, and she's building Edera to invert that. What stays with you is how personal that work is for her. The path from a small Alabama town into those rooms is not separate from the product. It's why the default being broken bothers her enough to build a company around fixing it.

GENERAL PODCAST LINKS
Watch: https://www.youtube.com/@alexasinput
Read: https://alexasinput.substack.com/
Listen: https://creators.spotify.com/pod/profile/alexagriffith/
More: https://linktr.ee/alexagriffith

LEARN MORE ABOUT THE HOST
Website: https://alexagriffith.com/
LinkedIn: https://www.linkedin.com/in/alexa-griffith/

FIND OUT MORE ABOUT THE GUEST
LinkedIn: https://www.linkedin.com/in/azenla/
Bluesky: https://bsky.app/profile/alex.zenla.io
Edera: https://edera.dev/
GitHub: https://github.com/edera-dev

RESOURCES
Edera docs: https://docs.edera.dev/

AI agents have created more possibilities for engineers than ever before. But what does daily life actually look like for the builders who've gone all in?

In my very first panel episode, I sit down with Adam Anzuoni from Cursor, Taylor Dolezal from Dosu, and Peter Bell from Gather.dev. Three builders running agents every day for real work, not demos. Peter runs nine API plans across three Mac Minis, with built-in adversarial review. Adam manages cloud agents from his phone. Taylor is building the context infrastructure that makes agent knowledge portable across teams.

We get into deterministic pipelines, skill systems that become their own technical debt, and what all three kept coming back to: attention is now the bottleneck. When agents can do everything, deciding what deserves your focus is the actual hard problem.

Three setups. One shared constraint. A conversation worth hearing.

Topics discussed:

• Attention as the real bottleneck when agents can do everything
• Deterministic pipelines vs. agentic orchestration — when to use scripts and when to use agents
• Peter's system: nine API plans, three Mac Minis, adversarial review, self-improving context
• Adam on Cursor cloud agents and managing builds from his phone
• Taylor on context distribution — making accumulated knowledge available to ephemeral agents
• The skill maintenance problem and why agent systems become their own technical debt
• The ADHD-like productivity loop that agent-driven work creates
• Plans matter more than prompts — all three panelists converged on this
• Intermediate artifacts as the key to quality output
• Product mindset as the engineer's next high-value skill
• Sandboxes, governance, and why "approve, approve, approve" puts your hard drive at risk

General podcast links

Watch: https://www.youtube.com/@alexasinput
Read: https://alexasinput.substack.com/
Listen: https://creators.spotify.com/pod/profile/alexagriffith/
More: https://linktr.ee/alexagriffith

Learn more about the host

Website: https://alexagriffith.com/
LinkedIn: https://www.linkedin.com/in/alexa-griffith/
X: https://x.com/alexa_griffith_

Find out more about the guests

Adam Anzuoni
LinkedIn: https://www.linkedin.com/in/adamanz/
Website: https://www.adamanzuoni.com/
Cursor: https://www.cursor.com/

Taylor Dolezal
LinkedIn: https://www.linkedin.com/in/onlydole/
Website: https://onlydole.dev/
Dosu: https://dosu.dev/

Peter Bell
LinkedIn: https://www.linkedin.com/in/peterfbell/
Gather.dev: https://gather.dev/
O'Reilly Book: Scaling AI Adoption in Engineering

Resources mentioned in this episode

Cursor: https://www.cursor.com/
Dosu: https://dosu.dev/
Gather.dev: https://gather.dev/
Anthropic Claude: https://www.anthropic.com/
The Phoenix Project (book reference by Taylor)
Kelsey Hightower productivity survey (referenced by Taylor)

Most engineers think reliability means avoiding outages. Vlad Leyberov learned the opposite lesson: sometimes you have to intentionally cause a 100% outage to fix the system faster.

Vlad is a Site Reliability Engineer (SRE) at Google, running systems that handle billions of requests per second. Before Google, he kept critical infrastructure running at Meta (billions of events a day) and Amazon (millions of Alexa devices).

In this conversation, we dig into cascading failures, incident responses, why consistency beats speed, how AI changes reliability engineering, and the philosophy behind running systems where downtime doesn't feel like an option.

Topics Discussed:

• How cascading failures propagate unpredictably in distributed systems (like nature, not machines)
• Incident responses: virtual panic rooms, on-call, paging procedures, and how to narrow down failure points
• The Alexa incident: why dropping an entire DynamoDB table was the right call
• Critical User Journeys (CUJ): measuring end-to-end customer experience vs individual SLOs
• Career journey from the USSR to maritime academy to business degree in Australia to SRE at Amazon, Meta, and Google
• Why consistency in API response times beats raw speed
• How AI makes it dangerously easy to create complex systems with poorly understood interactions
• Science fiction, the Borg as a distributed system, and the Three Body Problem trilogy
• Hot takes on reliability: all software development is maintenance, overrated 9s, underrated global failure modes

General Podcast Links

Watch: https://www.youtube.com/@alexasinput

Read: https://alexasinput.substack.com/

Listen: https://creators.spotify.com/pod/profile/alexagriffith/ More: https://linktr.ee/alexagriffith

Learn more about the host

Website: https://alexagriffith.com/

LinkedIn: https://www.linkedin.com/in/alexa-griffith/

Find out more about Vlad Leyberov

LinkedIn: https://www.linkedin.com/in/vladleyberov/ Google SRE NYC Tech Talks

Resources

Google SRE Resources:

• Google SRE Book: https://sre.google/books/
• Google Cloud Platform: https://cloud.google.com/
• Google Cloud Build: https://cloud.google.com/build (service discussed in outage story)
• Google Cloud Pub/Sub: https://cloud.google.com/pubsub (Vlad's previous role, billions of requests/second)

Sci-Fi Books Mentioned:

• Three Body Problem trilogy by Liu Cixin (Vlad's current favorite)
• Foundation series by Isaac Asimov
• Left Hand of Darkness by Ursula K. Le Guin
• Snow Crash by Neal Stephenson

Internal Google Systems Referenced:

• Borg: Google's internal cluster management system (Kubernetes predecessor), named after Star Trek Borg
• DynamoDB: AWS distributed key-value store (used in Alexa poison pill incident)

Intro Music:PR1BVOV7R4F1ASZC