Forem: aileen vl

Stop Burning Tokens on Redundant Context: Why your AGENTS.md is failing

aileen vl — Wed, 25 Feb 2026 01:28:04 +0000

Choose your language / Elige tu idioma:
🇺🇸 English Version | 🇲🇽 Versión en Español

Stop Burning Tokens on Redundant Context

There is a ritual that has become almost universal among developers adopting AI coding agents: You set up a new project, run a command like /init, and watch an agent generate a shiny AGENTS.md (or CLAUDE.md). It feels responsible. You feel like you’ve given your agent a "map" of the codebase.

But here is the reality check: you might be making your agent slower, more expensive, and less accurate.

Inspired by Addy Osmani’s recent deep-dive, I started looking into the data behind this "context ritual." Recent research from 2026 reveals a counter reality: auto generated context files can actually reduce task success by 2-3% while inflating costs by over 20%.

The Redundancy Loop

Why does this happen? According to research from ETH Zurich (Kocetkov et al., 2026), we are often giving agents a map of a room they are already standing in. If an agent can already see your package.json, your directory structure, and your docstrings, telling it "this is a React project" is just noise.

When you hand an LLM the same information twice, you aren't "reinforcing" it you are diluting its attention. Every redundant token in your context file competes with the actual task you want the agent to perform.

Focus on "Invisible Logic"

In my view, a README.md is for humans to understand the story of the project. An AGENTS.md should only contain the Invisible Logic the stuff that isn't obvious from reading the code itself.

Don't: Describe the tech stack or folder names (The agent can discover this via ls or grep).
Do: Document the Silent Constraints. For example: "The /legacy module is deprecated but required for the CI/CD pipeline—do not refactor."

Sharding Context: Why BMAD and Spec Kit are the future

One massive, monolithic file at the root of your repo is a structural failure for complex projects. A study by Lulla et al. (2026) showed that well maintained context files can improve efficiency, but only if they are relevant to the task.

This is where my recent experience with BMAD and Spec Kit comes in. These frameworks move away from "one file to rule them all" and toward Context Sharding:

BMAD: It allows you to shard context into roles (Analyst, Architect, Coder), ensuring each agent only gets the context relevant to their specific job.
Spec Kit: It focuses on Intent-Driven Development, using a /specify workflow that provides context only for the current task, keeping the token count lean.

The Mindset: Fix the Architecture, Not the Prompt

Think of your agent’s confusion as a signal of architectural friction. If an agent keeps putting utilities in the wrong folder, don't just add a rule to your context file. Fix the folder structure. Once the code is clear, you can delete the instruction from your context file.

The goal is a lean context layer that only tells the agent what it cannot possibly find on its own.

References

Stop using /init for AGENTS.md - Addy Osmani
The "Pink Elephant" Problem in Agentic Context - Kocetkov et al. (ETH Zurich, 2026)
Efficiency Metrics for Human-Authored Context - Lulla et al. (2026)

Deja de quemar tokens en contexto redundante

Existe un ritual que se ha vuelto casi universal entre los desarrolladores que adoptan agentes de IA: creas un nuevo proyecto, corres un comando como /init, y observas cómo el agente genera un flamante archivo AGENTS.md. Se siente como lo correcto; sientes que le has dado a tu agente un "mapa" del código.

Pero la realidad es otra: podrías estar haciendo que tu agente sea más lento, más caro y menos preciso.

Inspirado por el análisis de Addy Osmani, investigué los datos detrás de este "ritual de contexto". Investigaciones de 2026 revelan que los archivos de contexto auto generados pueden reducir el éxito de las tareas en un 2-3%, mientras inflan los costos en más de un 20%.

El Bucle de Redundancia

¿Por qué sucede esto? Según el estudio de ETH Zurich (Kocetkov et al., 2026), a menudo le damos a los agentes el mapa de una habitación en la que ya están parados. Si un agente ya puede leer tu package.json y tu estructura de directorios, decirle "este es un proyecto de React" es solo ruido.

Cuando le das a un LLM la misma información dos veces, no lo estás "reforzando", estás diluyendo su atención. Cada token redundante compite con la tarea real que quieres que realice el agente.

Enfócate en la "Lógica Invisible"

Desde mi punto de vista, un README.md es para que los humanos entiendan la historia del proyecto. Un AGENTS.md solo debería contener la Lógica Invisible: aquello que no es obvio al leer el código.

No: Describas el stack tecnológico o los nombres de las carpetas (el agente puede descubrir esto solo).
Sí: Documenta las Restricciones Silenciosas. Por ejemplo: "El módulo /legacy es necesario para el pipeline de CI/CD; no lo borres aunque parezca sin uso".

Sharding de Contexto: Por qué BMAD y Spec Kit son el futuro

Un solo archivo masivo en la raíz de tu repositorio es un fallo estructural. Un estudio de Lulla et al. (2026) demostró que los archivos de contexto mantenidos por humanos mejoran la eficiencia, pero solo cuando son específicos para la tarea.

Aquí entra mi experiencia con BMAD y Spec Kit. Estos frameworks se alejan del "archivo único" y se acercan al Sharding (fragmentación) de Contexto:

BMAD: Permite dividir el contexto por roles (Analista, Arquitecto, Programador), asegurando que cada agente solo reciba lo que necesita para su trabajo específico.
Spec Kit: Se enfoca en el Desarrollo Basado en Intenciones, usando un flujo de /specify que da contexto solo para la tarea actual, manteniendo bajo el consumo de tokens.

Mentalidad: Arregla la Arquitectura, no el Prompt

Piensa en la confusión de tu agente como una señal de fricción arquitectónica. Si un agente no entiende dónde va una utilidad, es probable que tu estructura de carpetas sea confusa. Arregla el código, y una vez que esté claro, podrás borrar la instrucción de tu archivo de contexto.

El objetivo es una capa de contexto ligera que solo le diga al agente lo que es imposible que encuentre por sí mismo.

Referencias

Stop using /init for AGENTS.md - Addy Osmani
The "Pink Elephant" Problem in Agentic Context - Kocetkov et al. (ETH Zurich, 2026)
Efficiency Metrics for Human-Authored Context - Lulla et al. (2026)

My Search to Become a DevRel: How Community, Teaching, WebAI and Vibe Coding Became My Path

aileen vl — Sun, 23 Nov 2025 23:49:17 +0000

For years I have been doing the work of a Developer Advocate without ever holding the title.

Not because I was trying to check a career box, but because I genuinely love teaching, building, speaking, and helping people unlock what is possible with the Web. My journey into DevRel did not start with a job description. It started with curiosity, community, and an obsession with sharing what I learn.

This is the story I want to tell.

From Teaching English to Teaching Tech

Long before I ever touched WebGPU, AI APIs, or agentic patterns, I was a teacher.

I taught English to pay for college, and I did not know it at the time, but that experience shaped everything. I learned how to explain complex ideas simply. How to read a room. How to make someone feel capable, even if they are just starting.

When I eventually transitioned into software engineering, I did not stop teaching.
I taught through local meetups, study groups, DMs, and later through tech communities I organized myself. Teaching has always been the throughline of my career.

Falling in Love With the Web Again Because of AI

I have always loved the Web. The openness, the flexibility, the creativity. The Web is the most accessible platform ever created.

But WebAI changed everything for me.

The idea that I could use my existing web knowledge, the same JavaScript and browser APIs I had been mastering for years, to create AI powered experiences was mind blowing. It made AI feel native, natural, and ours as web developers.

WebAI gave me a way in.
Vibe coding made the possibilities feel infinite.
And suddenly, I could not stop building.

But I also could not stop sharing.

I started recording videos.
I started writing.
I started speaking, first locally, then nationally, and then internationally.

My first international talk was in Romania, and it changed everything. I realized something important:
This is the work I want to do. This is the work I am already doing.

Becoming a Developer Advocate Before Becoming a Developer Advocate

DevRel is not about clout, stages, or airport lounges.

At its core it is about:

Teaching
Empowering people
Sharing knowledge
Building community
Connecting ideas with the people who need them
Exploring new tools and showing what is possible

And I have been doing all of that for three years, not because it was my job, but because I could not avoid doing it.

I have organized meetups in my city out of passion.
I have brought new technologies to local communities.
I have created videos and tutorials so people can learn faster than I did.
I have spoken at events on my own budget, sometimes using my vacation days to do it.

I did not realize it then, but I was doing DevRel the slow and difficult way.
Out of pure love, not sustainability.

The Burnout: When Passion Is Not Enough

At first it was fine.

But as more invitations came in, as communities grew, as more people asked for help, something shifted. I was doing the work full time without the support or resources of an actual DevRel role.

I was using my free time, weekends, vacation days, and often my own money to show up for communities. Eventually it created a type of burnout that hurts because it comes from something you love.

That is when I realized something important:

If I want to keep teaching, speaking, and enabling builders, I need to do it in a sustainable way. I need to do it as my actual job.

Not as a side passion.
Not as extra work squeezed into the edges of my life.
But as my career.

Because DevRel is not only something I am good at.
It is the way I naturally move through the world.

Why DevRel Is the Path I Want to Commit To

I believe that DevRel is not a performance. It is a service.

I want to serve developer communities by:

Teaching
Helping developers use the Web as a platform for AI experiences
Sharing how I build and experiment in public
Bringing powerful tools to places that rarely see them
Showing beginners and non engineers that they can build too
Creating content that teaches and inspires
Growing communities locally and globally

I have already done all of this. I simply need the chance to do it full time.

Why I Am Sharing This

This blog post is not only a reflection. It is a declaration.

I want to be a Developer Advocate.

Not someday. Not in an abstract way.
I am ready now.

I have built the habits, the skills, the community, and the love for the craft. I simply want the opportunity to keep growing, to keep teaching, to keep building bridges between technology and people.

DevRel is not a title I am chasing.
It is the role that finally matches the work I have been doing and the person I have become.

If You Are Reading This

If you are a DevRel professional, a manager, a founder, or someone who works in community or advocacy, or if you simply know me:

I am open to opportunities.
I am ready to create.
I am ready to contribute.
And more than anything, I am ready to help people build the future of the Web.

The Web taught me everything.
Community carried me forward.
Teaching is how I give back.

Bringing Cursor Café to Guadalajara ☕💻

aileen vl — Mon, 10 Nov 2025 00:04:45 +0000

It all started when I saw Cursor Café San Francisco. I’ve been a Cursor user and a coffee lover, so the idea of combining both worlds sounded like the perfect event to network. Many of us already work from coffee shops: creating, coding, shipping, and meeting people. The concept instantly clicked.

I remember Ben Lang posting about it on X (Twitter), and I fell in love with the idea, especially the collab with Terminal, a brand I personally enjoy. (Can’t wait to see a React Miami collab one day 👀☕). When Ben asked where Cursor Café should go next, I didn’t hesitate: it had to come to my city.

Bringing it to Mexico🇲🇽

Around that time, I was already hosting several tech events and looking for ways to collaborate with more people. I told Ximena, an amazing community builder known across all Mexican tech circles for her work and her recent efforts with Torc, which have helped her connect and grow the local ecosystem even more.

After talking, we realized Guadalajara was the perfect spot, especially because JSConf MX was happening there, bringing together developers and creators from all over the country.

So we proposed the idea to Ben, and he loved it. From there, things started moving quickly.

Making it real

Ben introduced us to Fawziyah, who guided us through everything needed to make a successful Cursor Café. She shared insights, checklists, and best practices from previous events.

Meanwhile, Ximena worked her local magic and secured a beautiful coffee shop in Guadalajara, while I focused on spreading the word and opening registrations. Soon, we had a full house, a stack of Cursor coffee bags, and backup plans for anything that might go wrong.

It was incredible to collaborate with Ximena; her experience running community events truly elevated the project.

The day of the event 🌤️

On October 29th, I arrived from Monterrey a bit late, but by the time I got there, Ximena and several local communities were already helping with check-ins, welcoming attendees, and making sure everything ran smoothly.

The best part was how natural it felt. People connected instantly, sharing projects, chatting, and meeting new friends. We hosted a demo time so builders could show what they were creating and gave out Cursor-branded coffee bags as a token of appreciation.

The coffee shop was buzzing with energy. The owner was thrilled to host, and attendees were already asking when the next one would be. Even some JSConf speakers joined, inviting everyone to stay involved in the community. Because truly, nothing beats learning together.

Perfect timing ☕ + 💡

Coincidentally, the same day we hosted Cursor Café Guadalajara, Cursor 2.0 launched, bringing tons of exciting updates. The atmosphere was electric, with people exploring new features, sharing projects, and showing how Cursor helps them code faster and more creatively.

A growing movement 💜

What made this event special was how supported we felt. Ben and Fawziyah were there every step of the way, encouraging and helping us make it happen.

And the best part? Cursor Café is expanding around the world.
The next one in Mexico city will be on November 15th, and you can check out the full list of upcoming events on the Cursor Café calendar to find one close to your city.

If you’re thinking about hosting, go for it. There’s already a strong, global community of creators sharing tips, ideas, and experiences.

So here’s my invitation to you:
Attend one. Host one. Be part of it.

You never know what kind of connections or collaborations can start over a cup of coffee ☕✨

📸 Photo credits

All the amazing photos from Cursor Café Guadalajara were captured by Vichy Valeria.
Her eye for community and detail made every shot feel alive, thank you for beautifully documenting the energy of the day!

on device models and how they work in the browser thanks to web assembly and webgpu

aileen vl — Fri, 17 Oct 2025 19:17:51 +0000

I’ve been a fan of WebAI for a while now, and the more I learn and work on this, the more convinced I am that on-device is the way forward.

If we want AI that feels fast, private, and easy to access, it should run right where people already are: in the browser. No installs, no waiting on a server, no cloud bills. Just you, your device, and a tab open.

This is possible thanks to two big breakthroughs: WebAssembly (Wasm) and WebGPU.

WebAssembly

WebAssembly changed everything. By compiling runtimes to Wasm, code could run almost as fast as native apps, but safely inside the browser. That opened up a whole new opportunity:

ONNX Runtime Web lets you take models trained elsewhere (in PyTorch or TensorFlow, for example) and run them directly in a tab. It compiles the CPU engine into Wasm, so it works everywhere without needing a GPU.
Transformers.js (from Hugging Face) builds on this by giving developers a one-line JS API for common NLP and vision tasks—things like embeddings, question answering, image classification, or even running Whisper for speech-to-text. Instead of wiring up a complex runtime yourself, you can just call pipeline('sentiment-analysis') in JavaScript and it works.

This was enough to get small and medium models running in the browser. Embeddings, sentiment analysis, and simple image classification suddenly became possible without a backend. And it worked everywhere—from laptops to mid-range phones.

Another important player here is TensorFlow.js. This library has been around for a few years and was one of the first to make ML in the browser feel approachable. It offers multiple backends (CPU, WebGL, Wasm, and now WebGPU), and it comes with lots of ready to use models like PoseNet (for body pose detection) or MobileNet (for image recognition). For many developers and myself, TensorFlow.js was the entry point to experimenting with browser ML before newer frameworks arrived.

WebGPU

Then came WebGPU. For the first time, the browser got a proper GPU compute API. Not just graphics tricks, but compute shaders, parallel math, and control over buffers.

This unlocked new possibilities:

Stable Diffusion generating images in a tab.
Segment Anything producing realtime masks on client images.
LLMs streaming tokens locally, without touching a server.

The performance gains are real too. Chrome added FP16 shaders (half-precision floating point) and packed 8-bit dot products (DP4a), both of which make models faster and lighter. Benchmarks show 2–3× speedups on text embedding and LLM decoding just by enabling these features.

And the ecosystem is catching up:

ONNX Runtime Web now ships with a WebGPU backend, meaning models that were too heavy for Wasm execution suddenly become practical.
WebLLM, built by the MLC team, brings large language models into the browser. It uses WebGPU under the hood and exposes a familiar API similar to OpenAI’s. Developers can call it as if they were talking to an API in the cloud, but everything runs locally in the user’s browser.
Now with Firefox shipping WebGPU on Windows and Safari preparing support, 2025 is shaping up to be the first year you can target GPU compute across all major browsers. That’s huge.

In summary

Here’s how I like to frame it:

Wasm is the backbone. It runs the runtime, keeps things portable, and gives a CPU fallback for older devices.

WebGPU is the muscle. It handles the heavy math—matrix multiplications, attention, convolutions.

Runtimes tie it together. ONNX Runtime Web handles general-purpose models, Transformers.js makes pipelines easy, TensorFlow.js covers a wide range of prebuilt models, and WebLLM brings LLMs to the browser with an already familiar API.

Together, these tools let you ship apps that are both accessible and powerful.

Why on-device matters to me

Latency feels human. When building in the browser, every second counts. Time-to-first-token under a second makes users relax and explore.
Privacy by default. Inputs never leave the device unless the user chooses. For health, finance, or education apps, this is the best way forward.
Costs. Inference runs on the user’s hardware, not your server bill. That makes scaling more predictable.
Reach. The browser is the largest runtime in the world. A single link is all you need.

What’s next?

With WebGPU in Chrome, Edge, Firefox, and soon Safari, the baseline is stronger than ever. Mobile support is also improving fast.

I hope 5–10B parameter models to become normal soon on consumer devices with quantization and smart caching.

Developers don’t need to reinvent the wheel. The frameworks are here, the APIs are stabilizing, and the performance is finally good enough to make real apps.

Resources to explore

ONNX Runtime Web
– run ONNX models in the browser with Wasm and WebGPU backends.

Transformers.js
– Hugging Face’s library for running models directly in JavaScript.

TensorFlow.js
– prebuilt models and training/inference support in the browser.

WebLLM
– large language models running fully client-side with WebGPU acceleration.

MDN WebGPU Docs
– a good overview of the WebGPU API itself.

Final thoughts

The browser is the runtime. Users already have it. Let’s build there.

With Wasm as the backbone and WebGPU as the muscle, we can deliver fast, private, and accessible AI experiences that were impossible just a couple of years ago.

Book Review — The Creative Act: A Way of Being by Rick Rubin

aileen vl — Fri, 10 Oct 2025 18:55:39 +0000

I picked up this book during a moment when I felt like I had lost touch with my creativity. I wasn’t feeling inspired in what I do, and something inside me felt hollow, like a quiet emptiness in my soul. Reading The Creative Act reminded me of who I used to be: a child who danced ballet, played the piano, performed on stage, someone who created, expressed, and moved through the world artistically.

Somewhere along the way, I lost that part of myself. I focused on sports, on productivity, on work. I started writing sometimes, but not consistently. I didn’t realize how much I missed the act of creating, how vital it was to my sense of aliveness.

When I entered the tech world, I believed it was possible to be creative there, but I couldn’t quite find how. I built, I coded, I solved problems, yet something in me still longed for expression. It wasn’t until I began speaking at events, sharing knowledge, and standing on stages that I recognized this too was a form of performance. The nervous energy before going on stage, the preparation, the act of expressing ideas in front of others, it wasn’t dancing, but it was something. My body and my soul had found another way to move.

Rick Rubin’s book gave me a framework to see creativity not as a discipline, but as a way of being. It reminded me that every act, whether building an app, telling a story, or writing a line of code, can be a creative expression if it’s done with awareness and presence. It’s not about what we produce; it’s about the state we inhabit while we create.

As a technologist, I found new meaning and purpose in my work through Rubin’s words. I started to see how creativity and art aren’t separate from innovation; they are its foundation. Without art, there’s no soul in what we build. Without creativity, technology becomes hollow.

I also kept thinking about how education today often leaves art behind, emphasizing engineering and technology instead. Yet art has always been how we remember ourselves, how we tell the story of who we were. From cave paintings to music to sculpture, art has been humanity’s record of feeling. In this digital era, as everything becomes more automated and optimized, I wonder: what stories will we leave behind?
Will museums one day display TikToks as cultural relics? Will AI-generated art replace human expression, or simply expand it?

The Creative Act doesn’t give answers; it gives space. It invites you to remember that creativity is not a profession, but a practice of being alive. It’s a reminder to listen deeply, to observe, to stay open, and to never stop creating, no matter the medium.

How to Connect Your Bolt.new Creation to a Custom Domain from Cloudflare

aileen vl — Sun, 24 Aug 2025 02:31:28 +0000

If you’ve created a portfolio, project, or personal site with Bolt.new, you’ll probably want to make it available on your own custom domain instead of the default Bolt link. In this guide, I’ll walk you through the exact steps I followed to connect my Bolt creation to a domain I registered with Cloudflare.
By the end, you’ll have your site live on your own domain in just a few minutes.

To make this work, we need to understand something called DNS. Don’t worry—it sounds technical, but it’s just the system that makes the internet usable.

🌐 What is DNS and Why Do We Need It?

Think of DNS (Domain Name System) as the phonebook of the internet.

Every website lives on a server with an IP address (a string of numbers, like 192.0.2.1).
Since no one wants to remember numbers, DNS translates easy names like paulinaave.com into the right server address.

When you type a website into your browser, DNS makes sure your request is sent to the right place.

That’s why, after buying a domain, you need to set up DNS records. These records are instructions that tell the internet:

A record → Points your domain to a specific server (like Bolt’s servers).
CNAME record → Creates an alias so subdomains (like www.myportfolio.com) also know where to go.

Without DNS configured, your domain won’t know which website to show—hence the common “site can’t be reached” error.

🛠 Step 1: Publish Your Bolt Creation to a Custom Domain

Inside your Bolt project:

Click the Publish button.
Select Custom domain.
Enter the domain name you already own (for example, myportfolio.com).
Bolt will verify the domain is registered.
Once verified, click Add Domain.

At this point, the domain is linked to Bolt, but won’t yet load your site until we fix the DNS records.

🔧 Step 2: Configure DNS in Cloudflare

Now we’ll fix the DNS issues Bolt reports. In my case, it asked me to add two records:

An A record
A CNAME record

Here’s how to add them in Cloudflare:

Log in to your Cloudflare dashboard and open the domain.
Go to the DNS settings tab.
Click Add Record.

➤ Add the A Record

Type: A
Name: (copy from Bolt’s instructions)
Value: (the IP address Bolt provides)

Click Save.

➤ Add the CNAME Record

Type: CNAME
Name: (provided by Bolt)
Target: (the Bolt target value)

Click Save.

⏳ Step 3: Verify and Wait for Propagation

After saving, Bolt should detect the updates.

You may see a status like “Waiting for updates” for a few minutes.
DNS propagation can take some time (anywhere from a few minutes to 24 hours).

Refresh your browser or check your domain in a new tab. Once the records are live, your Bolt site will load on your domain.

🎉 Final Result

That’s it! Your portfolio or project built on Bolt is now available at your custom domain.

If it doesn’t work right away:

✅ Double-check your DNS records.
✅ Make sure Cloudflare’s proxy (orange cloud) is disabled if Bolt requires direct DNS.
✅ Be patient—DNS can take a little while to update globally.

✨ Wrap-Up

DNS may sound intimidating, but it’s simply the system that connects domain names to websites.

Once you understand that adding DNS records is just filling in a form with the right “address,” connecting Bolt.new to your domain is straightforward:

Add your domain in Bolt.new.
Copy the DNS records.
Paste them into Cloudflare.
Wait for it to update.

Now your site looks polished and professional with a custom domain 🚀.

🎥 Watch the Tutorial Video

If you’d rather follow along with a video, here’s the full walkthrough I recorded:

I Don’t Fear Vibecoding, Because It Reminds Me of How I Got Here

aileen vl — Mon, 18 Aug 2025 23:03:21 +0000

From Industrial Engineer to Coder

I started out as an industrial engineer, but I quickly realized manufacturing wasn’t for me. I didn’t feel inspired by the work, and deep down I knew I was searching for something else. When I discovered coding, it felt like an entirely new world had opened up in front of me.

The beauty of programming is that you can build almost anything: an ecommerce store, a finance app, a game, or just a simple website. That variety was intoxicating. Every project was a doorway into a different domain, and every bug I solved taught me how things worked behind the curtain and loved the small wins.

Falling in Love with JavaScript

Back then, I was preparing for my first software job by practicing Java. But at the same time, modern JavaScript frameworks like Angular, Knockout, and Backbone were emerging. Suddenly companies were hungry for people who could use them.

My employer prepared an academy with CodeSchool courses for new graduates and trained them to work with clients. I was lucky enough to be part of one of those early cohorts.

That’s where I fell in love with JavaScript. It wasn’t just another language. With JavaScript I didn’t need heavy configuration, complex environments, or endless setup. I could simply open a browser, write some code, and see the results instantly. Tools like Grunt, Gulp, and Yeoman were the building blocks of that era, and they gave me a foundation I still carry today.

Learning Without a CS Degree

I didn’t have a computer science degree, and I often felt underqualified compared to my peers. But what I did have was curiosity and persistence. I poured effort into learning every day, always picking up new tools, patterns, and frameworks.

Luckily, that was also the era when coding initiatives were exploding. Platforms like code.org, freeCodeCamp, and dozens of bootcamps emerged, all fueled by the statistic that by the 2020s we would face a huge shortage of developers.

Developers were in demand, and the community was buzzing. Meetups became a way to learn directly from incredibly talented people. Entrepreneurship was booming. Everyone seemed to want their own startup. It was a thrilling time to be in tech, even if I sometimes felt like I was running to keep up.

Discovering AI Through JavaScript

A few years later, I began to notice AI creeping into the mainstream. Self-driving cars caught my attention first. They felt like science fiction come to life, and I was completely captivated by the potential of AI.

I wanted to dive in, but it seemed like the world of AI belonged primarily to Python. My whole career had been built in JavaScript, and starting over in another language would have meant sacrificing years of experience and beginning again as a junior.

Then I discovered something that reignited my excitement: AI in JavaScript. Libraries like TensorFlow.js and brain.js, along with the efforts of countless people in the community, showed that AI could also live on the web. Once again, JavaScript proved to be the gateway for accessibility. Just like when I first discovered the browser, I felt that same surge of possibility.

That excitement pushed me to start speaking at events. I wanted others to feel the same spark I had felt — that AI wasn’t locked away, but something we could all experiment with.

The Crazy Thought That Became Reality

Two years ago, I was serving on the advisory board of a large tech company at a time when AI was booming. ChatGPT had been released, and the energy in the room was electric.

I remember sharing an idea that felt wild at the time: programming languages are how we tell machines what to do, but what if we could just use human language instead?

It sounded like a thought experiment, not a near-future reality. Yet here we are. Today, with vibecoding and tools like Replit, Lovable, V0, Bolt, vibesDYI and Firebase studio, you really can turn an idea into an app with plain English. The “crazy thought” has arrived, and it’s transforming who gets to build software.

Why Vibecoding Matters

Of course, vibecoding comes with concerns. People worry about security, about what happens when creators don’t fully understand the code behind their app. These concerns are valid, but I believe curiosity will push people to learn more just as it did for me years ago.

And beyond curiosity, there’s a practical reality: there simply aren’t enough developers in the world to meet the demand for solutions. Opening up creation to everyone means more businesses, more experiments, and more problems solved that developers might never see. Vibecoding is not about replacing engineers. It is about expanding the circle of creation.

The Role of Developers in the Future

Developers will always be essential. There will always be a need for engineers to design infrastructure, ensure security, and push technical boundaries. The apps people create with vibecoding will still need innovation, scalability, and reliability all of which require strong engineering.

But vibecoding gives anyone the power to start. It hands the keys to people who have ideas but no technical background. Some of those ideas will be silly, some will be experimental, and some will be revolutionary. Just like the early days of the web, that mix is what creates progress.

Looking Ahead

For me, vibecoding feels like coming full circle. I remember being that non-CS graduate, feeling underqualified, wondering how I would ever get started. Today, I can see how much easier that first step could be for someone starting now.

AI is not just another tool; it is a source of endless possibilities. The future of innovation depends on bringing more people in, not keeping them out. Vibecoding is the open door.

And I am more excited than ever to see what happens when anyone, anywhere, can turn an idea into something real.

WebAI - Using Google Built-in AI APIs

aileen vl — Thu, 22 May 2025 23:09:37 +0000

With the many advancements in artificial intelligence, it's common to experience certain challenges.

Among them are the feelings of being left behind at work or falling short if you're not actively building or creating AI-powered apps.

But what if I told you that you can now use language models and machine learning directly from your browser?

This is possible regardless of whether you're a web developer or not — even if you have no prior experience working with AI.

This new opportunity comes in the form of Web AI:

An initiative that allows you to run AI models locally in the browser without sending data to the cloud.

What is Web AI?

Web AI is a way to use language models directly from the Chrome browser, thanks to Google’s Gemini Nano model.

This model is designed to run on your own computer (desktop or laptop), which offers two big advantages:

Greater privacy, since data doesn’t get sent to external servers
Less dependence on internet connectivity, as everything is processed on your device

The best part? You can start experimenting with these tools without having to install anything complex or waste valuable resources like your time.

Chrome’s New Built-In AI APIs

Google is testing a set of AI APIs built directly into Chrome.

They are part of an experimental feature (origin trial) available from Chrome versions 131 to 137.

Here’s what each API does:

Translator API

Dynamically translates user-generated or changing content.
Language Detector API

Automatically detects the language of a given text.
Summarizer API

Summarizes long texts — perfect for lengthy articles, emails, or dense content.
Writer & Rewriter API
- Writer: generates new text based on a specific task (e.g., product descriptions or emails)
- Rewriter: restructures and improves an existing piece of text.
Prompt API

Allows you to directly interact with the language model, unlocking more advanced features (though it requires some understanding of prompt engineering).

How to Try Them

Google has enabled limited origin trials for each API. To participate:

Choose the API you want to try:
- Translator API
- Language Detector API
- Summarizer API
- Prompt API
Click Register
Enter your site’s origin or extension ID (e.g., chrome-extension://YOUR_EXTENSION_ID)
Submit the form and copy the provided token
Add that token to the pages where you want the API to be enabled
If you're building a Chrome extension, follow the specific instructions for extensions

Technical Requirements

To use these APIs in your browser, you’ll need:

Chrome version 131 to 137
Windows 10/11 or macOS 13 or higher
At least 22 GB free on the drive where your Chrome profile is stored
GPU with more than 4 GB of VRAM
Unmetered internet connection

⚠️ Note: These APIs do not work on mobile devices (yet).

How to Enable in Chrome

Open Chrome and go to:

chrome://flags/#prompt-api-for-gemini-nano
Enable the corresponding flag
Restart Chrome

How to use them

Translator API

const translator = await Translator.create({
  sourceLanguage: "en",
  targetLanguage: "ja"
});

const text = await translator.translate("Hello, world!");
const readableStreamOfText = await translator.translateStreaming(`
  Four score and seven years ago our fathers brought forth, upon this...
`);

Language Detector API

const detector = await LanguageDetector.create();

const results = await detector.detect(someUserText);
for (const result of results) {
  console.log(result.detectedLanguage, result.confidence);
}

Summarizer API

const summarizer = await Summarizer.create({
  sharedContext: "An article from the Daily Economic News magazine",
  type: "headline",
  length: "short"
});

const summary = await summarizer.summarize(articleEl.textContent, {
  context: "This article was written 2024-08-07 and it's in the World Markets section."
});

Writer & Rewriter API

const writer = await Writer.create({
  tone: "formal"
});

const result = await writer.write(
  "A draft for an inquiry to my bank about how to enable wire transfers on my account"
);

const rewriter = await Rewriter.create({
  sharedContext: "A review for the Flux Capacitor 3000 from TimeMachines Inc."
});

const result = await rewriter.rewrite(reviewEl.textContent, {
  context: "Avoid any toxic language and be as constructive as possible."
});

Prompt API

const session = await LanguageModel.create();

// Prompt the model and wait for the whole result to come back.
const result = await session.prompt("Write me a poem.");
console.log(result);

// Prompt the model and stream the result:
const stream = await session.promptStreaming("Write me an extra-long poem.");
for await (const chunk of stream) {
  console.log(chunk);
}

My experience

I had the incredible opportunity to collaborate in a project to use this API's to help write with a Chrome extension, I thought right away how valuable that was, having so many things to read, write and share about, we are in the time where GenAI is being used to create content, but how can we keep it personal, valuable and human? I'm truly amazed by the power of AI, I myself am a web Developer and this type of APIs definitely helps you get acquainted to the use and benefits of AI while in the same space you have experience. We web developers shape a lot of what users consume day to day on the web, so it only makes sense for us to have the ability to create solutions using AI, to enhance the users experience, to help improve a product, to reinvent how the users use the web today and also how they are growing to learn how to interact with it.

Not only to mention, the close interaction web developers have to browsers, our daily tool to work with most of our projects, having the API's available just the same way we interact with other browser API's is an incredible approach by Google, also browsers have evolved so much with the power of resources available to run this models. The Chrome team continues to help evolve the WebAssembly and WebGPU standards to improve the web platform for machine learning.

The Good

The ability to run in the browser
Provide any user a way to run models without worrying about how to run them if not enough compute in cloud or locally
The API's to help write content one of the most useful task in GenAI today
The support and documentation provided by the team and forums to get help on building with these API's
Gemini Nano is a neat model to tackle these task
The focus and power given to web developers to open new possibilities to build the next frontier of web apps
Familiar syntax of the API's if you are already used to using other llms from the cloud

What can be improved?

Since it's still experimental, it can definitely fail at times—especially in the Prompt API. In several cases, the model didn’t return any response at all, not even a low-quality one. It would silently fail or hang, particularly on longer or more structured prompts.
Memory usage would sometimes skyrocket, causing the browser to slow down or freeze temporarily. I was testing on a MacBook Pro M1 with 16GB RAM. Generation tasks typically took around 20 seconds, and summarization tasks around 12 seconds. Running multiple tasks in sequence or on larger content made the slowdown much more noticeable.
Context window limitations often meant that RAG (retrieval-augmented generation) was necessary. Depending on the content size, this could lead to needing a cloud-hosted vector database, which defeats the purpose of a purely client-side setup. This was especially noticeable when summarizing larger documents—while there are workarounds, it still introduces friction and limits flexibility.
I'd love to see more use cases in Google products. Nothing validates a feature better than seeing it applied in real-world tools. Google has many powerful products (like Gmail, Docs, Sheets, etc.) that could benefit from this technology, but we’re not yet seeing it showcased or integrated.
Consider enabling support for more LLM models in-browser, or improving the current nano model's capabilities (e.g., quantization, progressive loading, caching strategies). More flexibility here would allow broader experimentation and more robust client-side apps.

*Lastly, standardization across browsers would be ideal. I really admire the Chrome team's work on these APIs and hope that similar efforts will extend to other browsers. A cross-browser standard would help make the ecosystem more open, accessible, and developer-friendly.

Last words

WebAI represents a pivotal moment in how we interact with artificial intelligence. It brings the power of machine learning models closer to the people who use the web every day and even closer to those of us who build it.

By lowering the barriers to entry, it empowers developers, educators, creators, and learners to explore what AI can do without feeling overwhelmed. It invites us to reimagine the browser not just as a tool for accessing content, but as a platform for creativity, intelligence, and innovation.

We’re just scratching the surface of what’s possible. But if this is the beginning, I’m incredibly excited to see where it leads.

Building a Multi-Agent Blog Publishing System with CrewAI

aileen vl — Wed, 09 Apr 2025 13:52:47 +0000

Introduction: The Power of AI Agent Collaboration

CrewAI is revolutionizing how we build AI systems by enabling multiple specialized agents to collaborate on complex tasks. Unlike single-agent approaches, CrewAI creates a coordinated "crew" of AI agents that work together, each handling different aspects of a workflow. This approach mirrors human team collaboration, where specialists combine their expertise to achieve outcomes greater than what any individual could accomplish alone.

My Multi-Agent Publishing System

For AI Agent Week MTY, I adapted an example from the DeepLearning.AI Multi-Agent Systems course and extended it to create a complete content production pipeline using CrewAI. Starting with the course's foundation of collaborative agents, I enhanced the system to not only generate content but also publish it directly to Dev.to. The system consists of four specialized agents:

Content Planner: Analyzes the topic, identifies trends, determines target audience, and creates a structured outline
Content Writer: Transforms the plan into engaging, SEO-optimized content with proper structure
Editor: Reviews the draft for accuracy, clarity, and alignment with best practices
Publisher: Formats the post for Dev.to, adds appropriate tags, and handles the API integration

What makes this implementation unique is that I adapted it to use Gemini instead of OpenAI, and added a custom publishing agent that can directly post content to Dev.to through their API.

Implementation: A Beginner's Guide to CrewAI

If you're new to CrewAI but familiar with Python, here's a complete walkthrough of how to build this system:

Step 1: Setting Up Your Environment

First, create a new Google Colab notebook (or use Jupyter) and install the necessary packages:

# Install CrewAI and supporting libraries
!pip install crewai==0.28.8 crewai_tools==0.1.6 langchain_community==0.0.29
!pip install requests
!pip install 'crewai[tools]'
!pip install langchain-google-genai

# Suppress warnings for cleaner output
import warnings
warnings.filterwarnings('ignore')

Step 2: Setting Up Your API Keys

CrewAI needs access to an LLM. I used Gemini instead of OpenAI, so we need to set up the Gemini API key:

import os
from crewai import Agent, Task, Crew, LLM
from langchain.tools import Tool
import requests
import json

# Set your API keys as environment variables
# Replace these with your actual API keys
os.environ["GEMINI_API_KEY"] = "your-gemini-api-key"
os.environ["DEVTO_API_KEY"] = "your-devto-api-key"

# Configure Gemini as our LLM
llm = LLM(
    model="gemini/gemini-2.0-flash-exp",  # Note the "gemini/" prefix
    temperature=0.7,
    api_key=os.environ["GEMINI_API_KEY"]
)

Step 3: Creating Your Agents

In CrewAI, each agent has a specific role, goal, and backstory that shapes how they approach tasks:

# Content Planner Agent
planner = Agent(
    role="Content Planner",
    goal="Plan engaging and factually accurate content on {topic}",
    backstory="You're working on planning a blog article "
              "about the topic: {topic}."
              "You collect information that helps the "
              "audience learn something "
              "and make informed decisions. "
              "Your work is the basis for "
              "the Content Writer to write an article on this topic.",
    allow_delegation=False,  # This agent works independently
    llm=llm,                 # Uses our configured Gemini LLM
    verbose=True             # Shows detailed output during execution
)

# Content Writer Agent
writer = Agent(
    role="Content Writer",
    goal="Write insightful and factually accurate "
         "opinion piece about the topic: {topic}",
    backstory="You're working on a writing "
              "a new opinion piece about the topic: {topic}. "
              "You base your writing on the work of "
              "the Content Planner, who provides an outline "
              "and relevant context about the topic. "
              "You follow the main objectives and "
              "direction of the outline, "
              "as provide by the Content Planner.",
    allow_delegation=False,
    llm=llm,
    verbose=True
)

# Editor Agent
editor = Agent(
    role="Editor",
    goal="Edit a given blog post to align with "
         "the writing style of the organization. ",
    backstory="You are an editor who receives a blog post "
              "from the Content Writer. "
              "Your goal is to review the blog post "
              "to ensure that it follows journalistic best practices,"
              "provides balanced viewpoints "
              "when providing opinions or assertions.",
    allow_delegation=False,
    llm=llm,
    verbose=True
)

Step 4: Creating a Custom Publishing Tool

The key innovation in my implementation is adding a custom tool that allows the Publisher agent to interact with the Dev.to API:

from crewai.tools import BaseTool, tool
from pydantic import BaseModel, Field
from typing import Type, List, Optional

# Define the input schema for our tool
class DevtoPublishInput(BaseModel):
    """Input schema for publishing to Dev.to."""
    title: str = Field(..., description="Article title")
    content: str = Field(..., description="Content in Markdown format")
    tags: Optional[List[str]] = Field(None, description="List of tags (max 4)")
    series: Optional[str] = Field(None, description="Series name if part of one")
    published: bool = Field(False, description="True to publish, False for draft")

# Create the custom publishing tool
class DevtoPublishTool(BaseTool):
    name: str = "publish_to_devto"
    description: str = "Publishes an article to Dev.to using its API"
    args_schema: Type[BaseModel] = DevtoPublishInput

    def _run(
        self,
        title: str,
        content: str,
        tags: Optional[List[str]] = None,
        series: Optional[str] = None,
        published: bool = False
    ) -> str:
        """Publishes an article to Dev.to."""
        api_key = os.environ.get("DEVTO_API_KEY")
        if not api_key:
            return "Error: Dev.to API key not configured. Set DEVTO_API_KEY."

        # Prepare the article data
        article_data = {
            "article": {
                "title": title,
                "body_markdown": content,
                "published": published
            }
        }

        # Add tags if provided (max 4 allowed)
        if tags:
            if len(tags) > 4:
                tags = tags[:4]  # Dev.to allows max 4 tags
            article_data["article"]["tags"] = tags

        # Add series if provided
        if series:
            article_data["article"]["series"] = series

        # Send request to Dev.to API
        headers = {
            "api-key": api_key,
            "Content-Type": "application/json"
        }

        try:
            response = requests.post(
                "https://dev.to/api/articles",
                json=article_data,
                headers=headers
            )

            if response.status_code not in [200, 201]:
                return f"Error: {response.status_code} - {response.text}"

            result = response.json()
            article_url = result.get('url', 'Not available')
            return f"Article {'published' if published else 'saved as draft'}. URL: {article_url}"
        except Exception as e:
            return f"Error connecting to Dev.to API: {str(e)}"

# Initialize our tool
devto_tool = DevtoPublishTool()

Step 5: Creating the Publisher Agent with Our Custom Tool

Now we can create a Publisher agent that uses our custom tool:

# Publisher Agent with Dev.to Publishing Tool
publisher = Agent(
    role="Dev.to Publisher",
    goal="Format and publish technical articles on Dev.to",
    backstory="You're a technical content strategist specializing in "
              "developer-focused content. You know how to format and "
              "optimize articles for the Dev.to platform to maximize "
              "engagement and visibility in the developer community.",
    llm=llm,
    verbose=True,
    tools=[devto_tool]  # Attach our custom tool to this agent
)

Step 6: Creating Tasks for Each Agent

Each agent needs a specific task that defines what they should do:

# Task for the Content Planner
plan = Task(
    description=(
        "1. Prioritize the latest trends, key players, "
            "and noteworthy news on {topic}.\n"
        "2. Identify the target audience, considering "
            "their interests and pain points.\n"
        "3. Develop a detailed content outline including "
            "an introduction, key points, and a call to action.\n"
        "4. Include SEO keywords and relevant data or sources."
    ),
    expected_output="A comprehensive content plan document "
        "with an outline, audience analysis, "
        "SEO keywords, and resources.",
    agent=planner,
)

# Task for the Content Writer
write = Task(
    description=(
        "1. Use the content plan to craft a compelling "
            "blog post on {topic}.\n"
        "2. Incorporate SEO keywords naturally.\n"
        "3. Sections/Subtitles are properly named "
            "in an engaging manner.\n"
        "4. Ensure the post is structured with an "
            "engaging introduction, insightful body, "
            "and a summarizing conclusion.\n"
        "5. Proofread for grammatical errors and "
            "alignment with the brand's voice.\n"
    ),
    expected_output="A well-written blog post "
        "in markdown format, ready for publication, "
        "each section should have 2 or 3 paragraphs.",
    agent=writer,
)

# Task for the Editor
edit = Task(
    description=("Proofread the given blog post for "
                 "grammatical errors and "
                 "alignment with the brand's voice."),
    expected_output="A well-written blog post in markdown format, "
                    "ready for publication, "
                    "each section should have 2 or 3 paragraphs.",
    agent=editor
)

# Task for the Publisher
publish = Task(
    description="""
    Prepare and publish the edited article on Dev.to. You must:
    1. Optimize the title for the developer audience
    2. Format the content properly in Markdown
    3. Select up to 4 relevant tags
    4. Decide if the article should be part of a series
    5. Save as a draft (published=False) initially

    Use the publish_to_devto tool to submit the article to Dev.to.
    """,
    expected_output="""
    A confirmation message that the article has been successfully published to Dev.to as a draft,
    including the title, tags selected, and URL of the article if available.
    """,
    agent=publisher,
    context=[edit]  # This provides the edited content as context
)

Step 7: Assembling and Running Your Crew

Finally, we create a crew with all our agents and tasks, then start the process:

# Create our crew with all agents and tasks
crew = Crew(
    agents=[planner, writer, editor, publisher],
    tasks=[plan, write, edit, publish],
    verbose=True  # Show detailed logs during execution
)

# Start the process with our chosen topic
result = crew.kickoff(inputs={"topic": "AI agents"})

# Display the results
from IPython.display import display, Markdown
display(Markdown(result))

That's it! This complete workflow will:

Generate a content plan for your topic
Write a blog post based on that plan
Edit the post for clarity and style
Publish it to Dev.to as a draft

Challenges & Solutions

The main challenge I faced was adapting the system from OpenAI to Gemini. This required:

Configuring the LLM differently: llm = LLM(model="gemini/gemini-2.0-flash-exp", temperature=0.7)
Handling different response formats between AI providers
Building a custom Dev.to publishing tool that could process the output format from Gemini

Results & Demo

This project successfully generated and published a comprehensive article on AI agents to Dev.to (view the published article) which is my previous blog post. The system demonstrates how CrewAI can automate complex workflows while maintaining high-quality output through specialized agent collaboration.

This approach has wide-ranging applications:

Content teams can accelerate production while maintaining editorial standards
Developers can build workflow automation systems that handle complex, multi-stage processes
Organizations can create scalable content strategies with consistent quality and messaging

When I showcased this project at AI Agent Week MTY, the audience was incredibly engaged. Developers were excited to see the system in action, asking thoughtful questions about agent collaboration and API integration. These discussions enriched the learning experience for everyone involved, as we explored different approaches and shared insights together. The collective enthusiasm demonstrated how multi-agent systems are capturing the imagination of the developer community and opening new possibilities for AI applications.

Acknowledgments

This code is based on the Multi-Agent Systems course from DeepLearning.AI platform, with additional custom functionality for publishing to Dev.to. If you're interested in learning more about CrewAI and multi-agent systems, check out their excellent course: Multi-AI Agent Systems with CrewAI.

You can find the complete implementation of this project in my GitHub repository: AI Agent Week MTY. Feel free to fork it, experiment with it, or contribute improvements!

AI Agents: A Developer's Guide to Autonomous Assistants and Intelligent Automation

aileen vl — Fri, 04 Apr 2025 04:18:37 +0000

AI Agents: Your Guide to Autonomous Assistants and Intelligent Automation

The rise of artificial intelligence is no longer a futuristic fantasy but a present-day reality transforming industries across the globe. In fact, a recent study by Gartner projects that AI augmentation will generate $2.9 trillion in business value by 2024. At the forefront of this revolution are AI agents, sophisticated systems designed to perform tasks autonomously and intelligently. This article provides a comprehensive overview of AI agents, their applications, and how businesses can leverage them to unlock unprecedented levels of efficiency and innovation.

What are AI Agents? (Defining the Basics)

AI agents, also known as artificial intelligence agents or autonomous agents, are computational entities that can perceive their environment, reason, learn, and act autonomously to achieve specific goals. They possess key properties that set them apart from traditional software programs. These include autonomy, the ability to operate independently without constant human intervention; intelligence, the capacity to learn, reason, and solve problems; a goal-oriented design, focused on achieving specific objectives; and interactivity, the capability to perceive and interact with their environment.

There are several types of intelligent agents, each with varying levels of complexity and capabilities. Simple reflex agents react to immediate stimuli based on predefined rules. Model-based reflex agents maintain an internal model of the world to make decisions. Goal-based agents strive to achieve specific goals by planning and taking actions. Utility-based agents optimize their actions to maximize a utility function, a measure of satisfaction. Finally, learning agents improve their performance over time through experience. Each type plays a unique role in different applications, allowing for tailored solutions to specific problems.

The Rise of AI Agents: Trends and Key Developments

Several key trends are driving the rapid adoption of AI agents. Advancements in AI and machine learning algorithms provide the foundation for more sophisticated and capable agents. The increasing availability of data fuels the training and improvement of these agents. Growing demand for AI automation in various industries is pushing businesses to explore and implement AI solutions. The need for personalized experiences is also a major driver, as AI agents can tailor interactions and services to individual user preferences.

The integration of generative AI is significantly enhancing AI agent capabilities. Generative AI models enable AI agents to create content, automate creative tasks, and personalize user experiences in unprecedented ways. Furthermore, the seamless integration of AI agents with other technologies like cloud computing and the Internet of Things (IoT) expands their reach and potential applications. For example, edge AI agents are being deployed on edge devices for real-time processing and reduced latency.

AI Agent Applications Across Industries: Real-World Examples

AI agents are transforming industries by streamlining processes, improving decision-making, and enhancing customer experiences. In customer service, AI assistants like chatbots provide instant support and resolve common issues, freeing up human agents to handle more complex inquiries. In healthcare, AI agents assist with diagnosis, drug discovery, and personalized treatment plans, improving patient outcomes. The benefits of using AI agents for customer service are particularly noticeable in reduced wait times and 24/7 availability.

The financial sector utilizes AI agents for fraud detection, algorithmic trading, and risk management, safeguarding assets and optimizing investment strategies. Manufacturing leverages autonomous systems for process optimization, predictive maintenance, and quality control, increasing efficiency and reducing downtime. Retailers use AI agents for personalized recommendations, inventory management, and supply chain optimization, enhancing customer satisfaction and streamlining operations. These are just a few examples of how AI agent examples are making a real-world impact.

Building and Implementing AI Agents: A Practical Guide

Building and implementing AI agents involves several key steps. First, it's crucial to define clear goals and objectives for the agent. Next, you need to select the right AI agent platform or framework, considering factors like scalability, ease of use, and integration capabilities. Gathering and preparing high-quality data is essential for training the AI agent model. The model then needs to be trained and evaluated rigorously to ensure accuracy and reliability. Finally, the AI agent is deployed and continuously monitored to optimize its performance.

Data quality and security are paramount throughout the entire process. It's crucial to implement robust data governance policies and security measures to protect sensitive information. Ethical considerations and responsible AI development are also vital, ensuring that the AI agent operates fairly and without bias. Building and managing AI agents requires a diverse set of skills and expertise, including data science, software engineering, and domain knowledge. Platforms like AutoGen, CrewAI, and LangChain are emerging as popular choices for building custom AI agents.

Challenges and Considerations

While the potential of AI agents is immense, there are also challenges and considerations to address. Data privacy and security concerns are paramount, requiring robust measures to protect sensitive information. Ethical considerations and potential biases in AI algorithms must be carefully addressed to ensure fairness and prevent discrimination. The lack of transparency and explainability in some AI models can make it difficult to understand their decision-making processes.

Integration complexities can also pose challenges, requiring careful planning and execution. The cost of development and deployment can be significant, particularly for complex AI agent systems. Responsible AI development and deployment are crucial, requiring adherence to ethical guidelines and best practices. Regulations and guidelines may be necessary to govern the use of AI agents and ensure their responsible application.

The Future of AI Agents: What to Expect

The future of AI agents is bright, with ongoing advancements promising even more sophisticated and capable systems. We can expect to see more autonomous agents that can operate independently and adapt to changing environments. Increased integration with other technologies like robotics, IoT, and cloud computing will further expand the capabilities and applications of AI agents. Wider adoption across industries will drive innovation and transform business processes.

New AI agent applications will emerge, addressing a wider range of challenges and opportunities. The potential impact of AI agents on society and the workforce is significant, requiring careful consideration and proactive planning. As AI agents become more prevalent, it's crucial to address ethical considerations, ensure responsible development, and mitigate potential risks.

Conclusion

AI agents are revolutionizing industries by providing AI automation and intelligent solutions to complex problems. From enhancing customer service to optimizing manufacturing processes, AI agents are driving efficiency, reducing costs, and improving decision-making. While challenges remain, the potential benefits of AI agents are undeniable. As the technology continues to evolve, businesses that embrace AI agents will be well-positioned to thrive in the future.

What is DevRel? or at least what is to me

aileen vl — Wed, 12 Mar 2025 19:40:42 +0000

I was recently accepted into the 4th cohort of DxMentorship program to kickstart my DevRel career. This blog post is one of the tasks from the program - to share my understanding of what DevRel (Developer Relations) is. As I begin this journey, I wanted to share my thoughts on this position that bridges technology and community.

Having excellent technology isn't enough. Based on what I've seen, successful products need both technical excellence and human connection. This is exactly why Developer Relations (DevRel) plays such an important role.

What is DevRel and What Do They Actually Do?

At its core, Developer Relations is about building relationships between a company and the developers who use (or might use) its products. But what does this look like in practice?

DevRel position typically:

Create educational content (tutorials, blog posts, sample projects)
Speak at conferences and meetups
Build and nurture developer communities
Collect and relay developer feedback to product teams or internal developer teams
Provide developer support beyond standard documentation
Advocate for developers' needs within the company and for developers using the tools
Host workshops, hackathons, and other hands-on events

I think of it as the human face of technical products, that translates complex capabilities into tangible value and practical applications.

Why DevRel Matters

It's easy to assume that well-documented APIs, chatbots and self-service products eliminate the need for human connections. My experience suggests otherwise. Here's why I believe DevRel is not just helpful but essential:

Documentation Is Never Enough

Even the most comprehensive documentation cannot answer every question or address every use case. Having actual people who understand both the product and developers' challenges creates a layer of support that documentation alone cannot provide.

When developers hit roadblocks, they don't want to search through pages of documentation—they want to ask someone who gets it. Even friction with the simplest documentation can drive developers away from your product permanently. DevRel teams provide that critical human touchpoint that can mean the difference between rejection and adoption, especially when documentation alone isn't cutting it.

Community Creates Momentum

Individual developers or companies using a product in isolation don't create momentum. What drives adoption is a thriving community where developers:

Share their experiences and solutions
Contribute improvements and extensions
Help each other overcome challenges
Create content that expands the product's reach

DevRel teams cultivate these communities, turning isolated users into connected advocates. They facilitate the knowledge sharing that transforms occasional users into dedicated champions 🏆 .

Visibility in The Market

The internet is vast, and developers have countless tools and products competing for their attention. Having dedicated people who actively engage with developer communities helps products stand out in this crowded space.

DevRel professionals attend events, participate in relevant online communities, and create content that reaches developers who are most likely to benefit from the product.

The Feedback Loop That Drives Improvement

Perhaps one of the most valuable functions of DevRel is establishing a clear feedback channel between developers and product teams. This two-way communication ensures that:

Developers feel heard when they encounter issues
Product teams understand real-world usage patterns
Improvements align with actual developer needs
Future roadmaps consider developer priorities

The Challenges of Measuring DevRel Impact

Despite these clear benefits, DevRel teams often face challenges in demonstrating their value. Traditional metrics don't always capture the full impact of relationship-building work. Some important considerations:

Long-term investments: Community building takes time, and the payoff isn't always immediate or directly attributable.
Indirect contributions: DevRel influences adoption, retention, and product direction in ways that can be difficult to isolate in analytics.
Global reach: The 24/7 nature of global developer communities means DevRel work often spans multiple time zones, creating both challenges and opportunities.

My Perspective: DevRel as Education, Empathy, and Evangelism

Based on my experience, effective DevRel combines three critical elements:

Education: Beyond explaining how to use a product, DevRel professionals teach the underlying concepts, best practices, and problem-solving approaches. Translating complex technical details into plain, accessible language is incredibly challenging—yet it's often exactly what developers need. Whether creating comprehensive tutorials, simple how-tos, or conceptual overviews, DevRel professionals are great at transforming technical documentation into meaningful learning experiences that anyone can understand, regardless of their expertise level.

Empathy: Great DevRel professionals genuinely understand developers' challenges, whether from their own technical experience or through deep listening and engagement. This empathy enables them to communicate and advocate effectively for their needs.

Evangelism: Not in a sales way, but through authentic enthusiasm for solutions that truly help developers. When DevRel professionals believe in the value of what they're representing, that conviction is contagious.

Building Bridges That Last

The most valuable DevRel work happens in the seemingly small interactions—answering questions in community forums, troubleshooting issues on calls, gathering feedback after demos, or connecting developers with similar challenges. These interactions might not always yield immediate results, but they build relationships that create lasting value.

I believe the human connections that DevRel teams foster remain irreplaceable. They transform products from tools into communities, users into advocates, and feedback into improvement.

For any company creating products for developers, investing in DevRel isn't just nice to have—it's beneficial for building products that truly meet developer needs and achieve their full potential in the market.

Final Thoughts

I'm grateful for the opportunity to write this blog post as part of my DevRel mentorship journey. These thoughts reflect my current understanding, but I recognize I still have so much to learn. I'm excited to hear different perspectives and expand my knowledge of this dynamic field as I continue on this path.