Cherif Yaya

AI, Agents and Outcomes

2025-11-11T08:00:00.000Z

date

Nov 11, 2025

slug

ai-agents-outcomes

status

Published

The Autonomy Dial: Your New Superpower

Agentic workflows represent AI-driven processes where autonomous agents make decisions, take actions, and coordinate tasks with minimal human intervention, adapting to real-time data and unexpected conditions.

The autonomy dial is a mental model for the future of work. Instead of micromanaging AI tools, you'll set the level of independence appropriate for each task. For example, applied to coding:

Dial at 20%: AI suggests improvements to your existing code

Dial at 60%: AI writes entire functions based on your specifications

Dial at 90%: AI agents autonomously implement features from high-level requirements

Modern agentic AI systems are structured around four components: Perception (data collection), Decision-Making (algorithmic guidance), Learning (continuous improvement), and Action (real-world execution).

Notice 90% not 100%. For now, we’ll always need humans in the loop (at least until AGI, but that’s another topic).

What This Means for You

The agentic revolution isn't coming, it's here. 93% of IT executives are highly interested in agentic AI for business, with the global AI market projected to reach $267 billion by 2027.

We're at the cusp of autonomous outcomes, where AI agents will work at the layer of results rather than processes. The companies that understand this shift, that focus on outcomes, that embrace the autonomy dial, that treat LLMs as infrastructure rather than novelty, those are the ones that will thrive.

The future isn't about replacing humans with AI. It's about humans working with AI agents to achieve outcomes that were previously impossible. The question isn't whether this will happen, but how quickly you'll adapt your mental models to this new reality.

How this blog works

2025-11-02T07:00:00.000Z

For years I ran this site on a DIY stack: a VPS, a weblog engine, and a recurring calendar reminder to log in and renew the TLS certificate before it lapsed. It felt empowering at first, but the maintenance treadmill, especially chasing expiring SSL certs, slowly drained the fun out of posting. I wanted the control of self-hosting without the stress of playing midnight sysadmin and the speed of Next.js static pages. I’ve been looking a solution for years. Then I stumbled upon Nobelium.

From Servers to a Notion Page

These days every post on the site starts as a simple Notion page. I duplicated the Nobelium template, dropped it into my workspace, and pointed the project at that shared database. Notion gives me the writing environment I already live in, plus tags, drafts, and filters with zero configuration. When I press “Publish” in Notion, the content is already structured for the site, no markdown exports or front‑matter required. And the refresh is fast.

Meet the Stack

The front end is built with Nobelium, an open-source starter that pairs Notion with Next.js. Nobelium pulls new content through Notion’s API, renders it with react-notion-x, and bakes the whole thing into static pages. That means the site is fast, accessible, and easy to theme with Tailwind CSS.

Deployment now lives on Vercel. A fresh build kicks off automatically the moment I update content in Notion, thanks to incremental static regeneration. I no longer SSH into a server or babysit Docker containers; Vercel handles the infrastructure, global CDN, and uptime monitoring behind the scenes.

The End of Certificate Churn

The biggest quality-of-life win: I never think about TLS certificates anymore. Vercel provisions and renews SSL for the custom domain automatically. No more surprise downtime when Let’s Encrypt runs out, no more messing with certbot, and no more calendar reminders.

Publishing from My Phone

One unexpected bonus: I can publish from anywhere using the Notion mobile app. Whether I'm commuting, waiting in line, or inspiration strikes while I'm away from my desk, I can draft, edit, and hit publish right from my phone. The post goes live within seconds, no laptop required. Loving it.

Publishing Is Finally Fun Again

Today’s workflow is simple:

Draft and polish in Notion.

Hit publish.

Let Vercel rebuild and refresh the static site a minute later.

If I want to tweak the look or add features, I still have the full Next.js project in the repo, so the door to customization stays open. But the routine friction that kept me from writing is gone.

If you’ve been clinging to a self-hosted blog out of principle while dreading the maintenance, consider stealing this setup. Less time wrangling servers, more time sharing learnings, that’s a trade I’ll take every time.

From LLMs as OS to Outcomes

2025-07-05T07:00:00.000Z

Andrej Karpathy's talk is a great watch. One idea from his presentation keeps echoing in my head: LLMs as the operating system for computational intelligence, and the autonomy dial. These are already flipping our approach to work.

The Operating System of Intelligence

What if we think of LLMs not as smarter autocompletes but as the abstraction layer for computational intelligence? Just as traditional operating systems provide a clean interface that hides the messy complexity of hardware from applications, LLMs hide the incomprehensible complexity of those transformer weights and neural networks behind a simple, shared, natural interface: human language. Brilliant.

This is what Karpathy calls Software 3.0. Where instead of writing explicit code, we access raw computational intelligence through natural language. The transformer architecture and those billions of trained weights? They're the "hardware"—the actual computational substrate where intelligence lives. The LLM is the OS that makes this intelligence accessible.

And prompts are the modern syscalls of this new operating system. Instead of calling functions like malloc() or read(), we make requests in English. "Analyze this data," "write this function," "deepsearch this problem"—these are our new system calls to the intelligence layer underneath.

We now have almost free-at-the-margin intelligence. And the exciting thing? We're at the same stage with LLM as OS as we were with mainframe computers eras of the early 70s where we accessed computers through timeshares.

We have the infrastructure—now we're hunting for the killer apps. And the first one? It's already here.

Coding: The First Killer App

Arguably, the first breakout application for GenAI isn't customer service chatbots or content generation (even though those are moderately successful), it's agentic coding. The Product Market Fit is highest for this category (as demonstrated by the sky high valuations of startups such as AnySphere/Windsurf).

AI agents are particularly effective in software development because code follows defined patterns and is ultimately very repeatable and trainable. It's also verifiable. Through automated tests, agents can iterate using test results as feedback, and output quality can be measured objectively.

This is where Karpathy's autonomy dial concept fits nicely. The progression:

Low autonomy: AI-powered autocomplete (like GitHub Copilot)

Medium autonomy: Chat-based code generation and debugging

High autonomy: AI agents that understand requirements and implement complete solutions

We're already seeing AI agents resolve real GitHub issues and generate complete workflows from simple prompts. It's clear the future of software engineering will include AI agents in one shape or another.

What's Next? The Excel and Photoshop Moments

But coding is just the beginning. Think about the PC revolution: first came the operating system (DOS, then Windows), then the killer app that proved the concept (VisiCalc, then Excel), and finally the creative applications that expanded what was possible (Photoshop, PageMaker).

We're living through that exact sequence right now, just compressed into a much faster timeline.

The infrastructure is live. The first killer app is proven. Now we're racing toward the applications that will define the next decade of work.

And honestly? I can't wait to see what we build.

Simple, Right, Complex

2025-03-15T07:00:00.000Z

I’ve been thinking about this pattern I’ve noticed over years of building software. It’s fascinating how engineers naturally gravitate toward three distinct approaches when solving problems.

The Minimalist Approach

These are your “if it works, ship it” folks. Love how they keep things dead simple - one function, minimal dependencies, quick deploys. Sure, some might call it too basic, but I’ve seen these solutions outlast many overengineered alternatives. They just work.

The Maximalist Zone

This is where most of us land at some point (guilty as charged). You know the type - implementing every design pattern they’ve just learned, breaking a simple app into 15 microservices, adding Redis to cache a static page. Classic architecture astronaut stuff. We’ve all been there, turning a simple form submission into an event-sourced distributed system.

The Pragmatic Sweet Spot

This is where it gets interesting. After years of swinging between too simple and too complex, you start developing this sixth sense. You pick the right tool because you’ve used the wrong ones. You know when to grab something off the shelf versus building custom. It’s not about showing off your technical chops - it’s about delivering value.

This mirrors most developers’ natural journeys. We start simple because we don’t know any better. Then we learn all these patterns and frameworks and go nuts applying them everywhere. Finally, if we’re lucky, we figure out when complexity is actually worth it.

Here a few things I’ve learned along the way:

Simple doesn’t mean simplistic - choosing simplicity is different from being limited by it

Make complexity prove its worth - every abstraction should fight for its place in your system

The best engineers aren’t the ones who know the most patterns, but the ones who know when to use them and (perhaps) more importantly when NOT to use them

Next time you’re designing something, try this mental check: Does this really need to be complex? Am I solving the actual problem or just showing off? Will this scale with real needs (not imagined ones)?

The goal isn’t to impress at tech talks. It’s to solve real problems in ways that won’t make future-you curse past-you.

Would love to hear your experiences with this. Where do you find yourself on this curve?

Drop your thoughts below.

The Power of Incremental Progress

2024-07-28T07:00:00.000Z

In the fast-paced world of software development, we often fall into the trap of grand, sweeping changes. We dream of complete overhauls, ground-up rewrites, and revolutionary new systems. But here’s a hard truth: these all-or-nothing propositions are often a recipe for disaster.

Let’s talk about incrementality. It’s not glamorous. It doesn’t make for exciting presentations or bold mission statements. But it’s the secret weapon of successful engineering teams everywhere.

Consider a recent example from my time at Airbnb. We aimed to add a critical feature to our device testing lab for end-to-end testing, promising faster and more comprehensive test runs. The project hinged on the edge networking team developing a safe VPN tunneling solution, initially estimated to take one quarter. However, this dependency stretched to nine months due to unforeseen complexities, security challenges, and competing priorities, leaving our e2e testing project in limbo and causing cascading delays across multiple teams.

This experience starkly illustrates the pitfalls of all-or-nothing thinking in software engineering. Complex systems are prone to unexpected challenges and shifting priorities. Our mistake wasn’t in trusting the edge networking team, but in failing to plan for contingencies and interim solutions. It underscores the critical need for incremental progress and flexible planning, breaking large projects into smaller, independently valuable pieces that can deliver benefits even when other components face delays.

This isn’t just an Airbnb problem. It’s an industry-wide issue. We get caught up in the allure of the perfect solution, the comprehensive fix. We convince ourselves that if we just wait a little longer, we’ll have everything we need to do it “right.”

But software doesn’t work that way. Neither does business.

Instead of waiting for the perfect solution, we should have broken the project into smaller, manageable pieces. We could have implemented an interim solution, something that got us 80% of the way there without the network dependency. Then, we could have iterated, improved, and adapted as new capabilities became available.

This approach does more than just deliver results faster. It de-risks the entire project. By shipping incremental improvements, we get real-world feedback earlier. We catch issues before they become critical. We build momentum and maintain team morale.

Incrementality isn’t about lowering our standards or settling for less. It’s about recognizing that progress is better than perfection. It’s about understanding that in the real world, requirements change, technologies evolve, and businesses pivot. By working incrementally, we stay flexible and responsive to these changes.

So how do we put this into practice?

Break big projects into smaller, independently valuable pieces.

Prioritize these pieces based on immediate value and feasibility.

Ship early and often, even if it means using temporary solutions.

Gather feedback and iterate rapidly.

Be transparent about the incremental nature of the work to set proper expectations.

Remember, every line of code you ship is a line of code that’s providing value, being tested, and moving you closer to your ultimate goal. Every feature you roll out is an opportunity to learn and improve.

The next time you’re faced with a big project or a daunting dependency, resist the urge to wait for everything to be perfect. Instead, ask yourself: “What can we do right now, with what we have, to move in the right direction?”

Incrementality isn’t just a development strategy. It’s a mindset. Embrace it, and watch as your projects start delivering value sooner, adapting to change more easily, and ultimately succeeding more often.

In software engineering, as in life, the journey of a thousand miles begins with a single step. So take that step. Then take another. Before you know it, you’ll have traveled further than you ever thought possible.

Hello

2020-04-10T07:00:00.000Z

Welcome! I am a Javascript, iOS and Technology enthusiast. I did iPhone stuff at Apple for a while. Now at Facebook where I tech lead teams.

I constantly share relevant iOS, JS, and Node.js tips and tricks. This is the place!