DEV Community: Kiell Tampubolon

I Struggled with Data Analysis. Claude for Excel Changed Everything.

Kiell Tampubolon — Fri, 08 May 2026 12:02:15 +0000

At 2 AM, I was ready to throw my laptop out the window. I had just spent hours gaining zero insights from a sprawling sea of data. Then I stumbled upon Claude for Excel, and suddenly everything clicked into place.

The Problem with Real Error or Messy Code

Like many developers, especially those of us who aren't formally trained as data analysts, Excel can sometimes feel like a jungle. I was trying to generate reports that needed to highlight sales trends, which required me to wrangle all that data into a coherent narrative. I needed to create pivot tables to analyze the responses, but navigating through cumbersome formulas was turning my brain into mush. I spent hours merging cells, applying filters, and trying to remember whether I used SUM or AVERAGE last time.

One day, I spent an entire Sunday trying to get a complex formula to work. I ended up with #VALUE! errors splattered across my sheet, leading to frustration that lasted longer than I care to admit. My family could see my stress levels rising as I muttered incoherently about Excel's cryptic syntax. I wanted to blame the software, but the truth was, I was the one wrestling with messy data and unrealistic expectations on myself. The more I struggled, the more irrational I became.

The Fix

Enter Claude for Excel—a tool that instantly began to take the burden off my shoulders. After a brief introduction and tutorial, I realized this could be my new best friend in the world of data. The functionality was like getting handed a magic wand; it could analyze data without needing me to trip over complex formulas.

For example, I was once stuck trying to calculate the year-over-year growth of sales figures across various regions, which involved a spreadsheet of about 3,000 rows. Typically, I would have diced and sliced this data manually, hoping to avoid errors along the way. Instead, using Claude, I could simply upload my data set and ask it for the required analysis in plain language:

Analyze the sales data and show year-over-year growth by region.

Within seconds, not only did Claude give me the results, but it also generated a pivot table for me. I couldn't believe my eyes. The tool had processed the entire sheet seamlessly, saving me at least three hours of work. I was able to use the generated table to make decisions swiftly and present findings during Monday’s meeting with confidence. This was not magic—it was just a smart combination of AI and my ongoing need for efficiency.

Furthermore, when I felt extra adventurous, I asked Claude:

Show me the top 5 products based on customer feedback.

Again, I received a neat summary sans the usual headache.

The Bigger Principle Behind the Fix

What I learned through this process was simple yet profound: embracing tools that streamline techniques is essential. Rather than getting tangled in the complexity of data manipulation, using Claude for Excel allowed me to focus on what truly mattered—insightful analysis and decision-making. I began to see an increase in my productivity, as I could spend time analyzing results rather than scrambling over formulas. In concrete terms, I've gone from spending about 20 hours a month on data analysis down to fewer than 10.

So what's the bigger principle here? It's about understanding your limitations and recognizing when to employ technology that complements your skills. Claude for Excel shifted not only the way I handled data but also my perception of it. Instead of feeling overwhelmed, I started feeling empowered, knowing I had a sophisticated partner by my side.

Reflecting on the time wasted before discovering this tool, I can’t help but chuckle. I wish I had found it sooner. If you're knee-deep in data analysis and feel like you’re drowning in formulas, I highly recommend you take a look at Claude. Just make sure to remember the old saying: it's not about knowing it all, but knowing how to ask the right questions.

If you've had similar experiences with data tools, what’s the most significant win you've achieved with a new software? What one tool would you recommend to others drowning in data that could provide clarity without the headache?

I Struggled with a Bug for Days — Here's What I Learned About Clean Code and Debugging

Kiell Tampubolon — Thu, 07 May 2026 15:14:19 +0000

As I sat in front of my computer screen one humid evening in Batam, covered with the shadows of unfinished projects, I felt a sinking frustration deep in my chest. For days, I was plagued by a bug in a JavaScript function that seemed to mock me, with every test yielding inconsistent results. I was convinced I had a handle on clean code principles, but the hours spent chasing this elusive problem made me question everything I knew.

Context & Stakes

debugging effectively is essential for any developer, especially when working in tight deadlines or collaborative environments. I was leading a small team on a client project, a dynamic web application intended to streamline local business operations. Our success depended on delivering clean, efficient code, and I was the one responsible for reviewing and finalizing it. The stakes were high, and with each failed attempt to fix the issue, our timeline slipped further.

The bug originated in a function designed to fetch user data from an API, but the data only loaded half the time. After scanning and re-scanning the code, everything seemed fine — I had followed all the recommended practices. Yet, the problem persisted. This relentless loop of testing and frustration forced me to confront my limitations head-on. Would I be able to solve this before our deadline?

CHALLENGE

What I had overlooked was a crucial aspect of my code's asynchronous nature. Here’s the snippet that tripped me up:

async function fetchUserData(userId) {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  const data = await response.json();
  return data;
}

At first glance, this code looked correct, but the challenge was in the way it interacted with the rest of the application. I was using this function in multiple places within the codebase, but because the API could occasionally be slow, I hadn’t handled the failures correctly in the components calling it. This led to intermittent fraying of user experience, with components loading only half the time or throwing unhandled errors.

I felt the weight of inefficiency weighing down my team. The pressure to deliver without compromising quality left me juggling multiple hats, and I realized that my understanding of clean, maintainable code had been superficial. I needed to dig deeper into both debugging techniques and code readability practices to navigate this complexity.

BREAKTHROUGH

The breakthrough came when I decided to systematically approach the problem. Instead of diving straight into fixing it, I first resurfaced and rewrote the function to make it clearer and more manageable:

async function fetchUserData(userId) {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) {
      throw new Error('Network response was not ok');
    }
    return await response.json();
  } catch (error) {
    console.error('Fetching user data failed: ', error);  // Logging error with context
    return null;  // Handle this gracefully on the calling side
  }
}

By adding error handling and a try/catch block, I octupled my chances of catching errors early. However, the biggest revelation was shifting my mindset from fixing bugs to devising solutions that make the code robust against future issues. I took the time to document the expected outcomes in the comments as a reminder to myself and my teammates. This transparency in the code not only made it easier for us to follow, but it also set the stage for better collaboration.

DEEPER INSIGHT

Through this experience, I gleaned a larger principle: clean code is not just about aesthetics or following patterns; it is about making it maintainable and resilient. As developers, we must anticipate how our code may misbehave under unexpected conditions. The cleaner and more explicit we write our code, the easier it becomes for us and others to debug it — saving precious development time in the long run.

Additionally, the experience reinforced the idea that debugging is as much about mindset as it is about skill. It’s easy to get lost in the weeds of our code; stepping back to reassess the problem can sometimes bring clarity, especially with peer programming, where you can have a fresh set of eyes or someone to help brainstorm.

WHAT I'D DO DIFFERENTLY

Upon reflection, here are a few actionable steps I’d take to improve my approach to debugging and code quality moving forward:

Prioritize Error Handling: Always include explicit error handling strategies within asynchronous functions. Errors are inevitable; planning for them pays off.
Encourage Team Code Reviews: Foster a culture of peer reviews within your team. Fresh perspectives often unearth issues that one might overlook.
Document Potential Errors: Add comments to clarify how functions behave in edge cases. Documentation can be a lifesaver.
Test-Driven Development (TDD): Implement TDD practices for new features to catch bugs early in the development cycle, enhancing code reliability.
Set Up Monitoring: Utilize tools like Sentry to catch runtime errors and log issues transparently into the application, so you can react in real-time.

By taking these steps, I believe we can significantly minimize bugs and build a more resilient infrastructure for our applications.

CLOSING QUESTION

What debugging techniques or coding practices have you found essential in your own projects? How have you dealt with seemingly insurmountable bugs? Let's discuss in the comments!

I Deployed My First Cloudflare Worker — Here's What I Learned

Kiell Tampubolon — Wed, 06 May 2026 11:32:05 +0000

I sat there staring at the screen, my heart racing as I clicked 'deploy' on my first Cloudflare Worker. What should have been a straightforward process felt like a rollercoaster of confusion and excitement. Just moments before, I'd lined everything up: my code looked good, my environment seemed solid—how could anything go wrong?

But then it hit me. 401 Unauthorized. What? I hadn’t encountered this in all my testing. Little did I know, the culprit was hiding in the shadows of a misconfigured secret token, like a ghost refusing to leave its haunted house.

The Setup

Being a developer, I often toggle between creative solutions and technical bottlenecks. I’ve spent countless late nights coding, occasionally stacking hundreds of browser tabs filled with information, guides, and articles. Typical developer life, right? In an attempt to re-organize my chaotic digital world, I finally utilized Notion Web Clipper. It became my sidekick, ensuring that everything I stumbled upon would be neatly packed away for when I needed it. But nothing prepared me for the impending chaos with Cloudflare Workers.

I was eager to build a simple API service that could run globally. After all, deploying on Cloudflare should have been a piece of cake. I picked a couple of templates and dived in, but secret management? Talk about a headache! I had breezed through the initial setup, barely taking note of how tokens should be correctly managed in the environment variables.

The Challenge

The panic kicked in when my worker returned a loud, resounding 401 Unauthorized error. I felt defeated. It felt like grasping at straws, trying various approaches that led me further into confusion. I had mistakenly selected a template that wasn’t suitable for my use case, throwing my authorization strategy out the window like an old shoe.

The main issue was that I lost sight of what tokens I was using for authentication. I had multiple API keys lying around from various services, and sure enough, I grabbed the wrong one. It reminded me of those ‘SELECT A TEMPLATE’ dropdown menus you see on documentation pages that you just don’t read. Instead of reading through the instructions, I assumed I knew it all. Classic developer hubris.

The Breakthrough

Eventually, instead of banging my head against the desk, I took a deep breath and revisited the documentation for Cloudflare Workers. Turns out, the secret management was not just a convenient feature; it was crucial for keeping my application secure and functional. They even had detailed instructions on how to handle these secrets correctly.

I quickly updated my API tokens using Cloudflare's secret management tools with these steps:

Revisit the dashboard: Ensure that you've saved your tokens properly.
Use .env file: If you're unsure of where to place your secrets, Cloudflare Workers let you conveniently manage these in the dashboard.
Go with the right template: Choose wisely! The correct template would seamlessly integrate with your authentication flow.

After implementing the right token, I deployed it again. It felt surreal to see the 200 OK response this time; everything felt right in the world again.

Deeper Insight

What I realized through this whole ordeal is much larger than just the technical issue. It served as a reminder of the importance of understanding the tools we use—rushing into a setup without learning the fundamentals can be disastrous. This situation taught me that our tools can either propel our success or hinder it, and we should respect the complexity involved in building software. Reading documentation isn’t just for beginners; it’s for anyone looking to level up.

In my experience, spending a bit more time upfront in understanding the scope and limits of what I was working on saved me hours of troubleshooting later.

What I'd Do Differently

Take Notes: Throughout the cloud worker setup, I started losing track of what I was doing. If I’d kept notes or a checklist, I could’ve avoided such an embarrassing mistake.
Don’t Rush: I was so eager to deploy my worker that I skimmed through critical documentation. In the future, I'll be more patient and thorough.
Debugging Tools: Use Cloudflare's built-in development tools. They can help you pinpoint those pesky authorization issues sooner.
Ask for Help: Instead of trying to figure it all out alone, asking in developer communities could save time—like moments of doubt and confusion I faced.

Closing Question

Have you ever overlooked an essential detail in your development work that led to a frustrating error? How did you recover, and what lessons did you take away from it? I’d love to hear your stories in the comments!

I Thought I Understood State Management in React. Then a Memory Leak Happened.

Kiell Tampubolon — Wed, 06 May 2026 11:27:58 +0000

I was deep in debugging a React application one lazy afternoon, staring at the console as error after error cropped up. I had implemented a pretty standard state management pattern to ensure that my component re-renders whenever specific data changed. But somehow, things were behaving strangely. Components were unmounting; states weren’t resetting; everything felt like a mess despite my confidence. What I thought was a straightforward approach was crumbling right in front of my eyes.

The Stakes

I was working on an important project that involved managing complex user interactions with real-time data. If I couldn’t contain the bugs swarming around my application, we risked missing a critical deadline. Not just that—I was also concerned about the user experience. A leaked memory could mean sluggish performance, and nobody wants to use an app that feels like it’s dragging its feet. I needed clarity, and I needed it fast.

Before diving deeper, let's take a look at the state management approach I had employed:

import React, { useState, useEffect } from 'react';

function UserProfile() {
    const [userData, setUserData] = useState(null);

    useEffect(() => {
        fetchUserData();
    }, []);

    async function fetchUserData() {
        const response = await fetch('/api/user');
        const data = await response.json();
        setUserData(data);
    }

    return <div>{userData ? userData.name : 'Loading...'}</div>;
}

This seemed fine at first, but things didn’t end up that way. My app started showing out-of-memory errors after several updates, and it felt like a ticking time bomb. I realized the crux of my problem lay in how I managed my component's lifecycle.

The Challenge: Memory Leak Mystery

As I navigated through the sea of warnings in my console, I faced the sudden realization that my fetch operation could stay ongoing even after the component unmounted, leading to a memory leak. If the API call completed after the component was no longer present, I was trying to update an unmounted component's state. This was a classic example of state management gone wrong, resulting in a mess that I had to unravel.

I had two main problems here:

Unsuccessful cleanup of the side effect in useEffect: I hadn’t set up any mechanism to cancel the fetch request once the component unmounted.
Leaving state updates in a volatile state: If fetchUserData finished running after the component was no longer mounted, it was going to throw an error.

Breakthrough: Fixing the Leak

After reeling back slightly and analyzing the proper way to approach an asynchronous fetch operation within a functional React component, I devised a plan.

Use a flag to keep track of the component's status: This would help me commune with React's lifecycle effectively.
Incorporate a cleanup function in useEffect: This would help cancel any ongoing requests or avoid updating the state if the component was no longer active.

Here’s how I revamped my component:

import React, { useState, useEffect } from 'react';

function UserProfile() {
    const [userData, setUserData] = useState(null);
    const [isMounted, setIsMounted] = useState(false);

    useEffect(() => {
        setIsMounted(true);

        const abortController = new AbortController(); 
        fetchUserData(abortController.signal);

        return () => {
            setIsMounted(false);
            abortController.abort();
        };
    }, []);

    async function fetchUserData(signal) {
        try {
            const response = await fetch('/api/user', { signal });
            const data = await response.json();
            if (isMounted) {
                setUserData(data);
            }
        } catch (error) {
            if (error.name === 'AbortError') {
                console.log('Fetch request aborted');
            } else {
                console.error('Error fetching user data:', error);
            }
        }
    }

    return <div>{userData ? userData.name : 'Loading...'}</div>;
}

Now with the AbortController, if my fetchUserData was still going, it would get terminated if the component unmounted before it resolved. Additionally, the isMounted flag helped me ensure that only my active component’s state updated. I felt relieved to see that my application became snappier, and the error messages evaporated.

Deeper Insight: Learning from the Experience

As I reflected on how easily I stumbled into a memory leak problem, I understood that state management in React isn't just about keeping track of state; it’s equally about understanding the component lifecycle and properly handling side-effects. Diving deep into the integration of asynchronous functions and how they interact with React’s lifecycle clarified a lot for me. It’s crucial to ensure that everything appears cohesive and doesn't lead to breakage during the component transitions.

I faced implications from this experience that transcended just fixing bugs. I learned to delve deeper into component lifecycles and how each part of my code interacts.

What I'd Do Differently

In hindsight, here are a few actionable steps I would recommend for anyone working with React (or thinking about working with state management):

Always plan for cleanup: Understand that with every effect you create, consider what should happen when the component unmounts.
Use AbortController: This is vital for avoiding memory leaks when making fetch requests.
Keep track of component status with flags: Make sure your state management checks whether the component is mounted before any state updates.
Test regularly: Develop a routine for testing the application in various scenarios to catch issues early.

How do you manage state and side-effects in your React applications? Have you ever faced memory leak issues before? Let's discuss your solutions and insights!

I Tidied Up Hundreds of Open Tabs with Notion Web Clipper — Here's What I Found

Kiell Tampubolon — Tue, 05 May 2026 14:42:29 +0000

It felt overwhelming—hundreds of tabs were open across my browser, each representing a piece of information I once deemed crucial. I had become a digital hoarder, accumulating resources with no plan to revisit them. It was time to act, and that’s when I stumbled upon Notion Web Clipper.

A New Approach to Information Management

As a developer based in Batam, Indonesia, my days often blur together as I juggle coding, learning, and keeping up with tech trends. My laptop’s performance suffered with every new tab I opened. I needed a better system to organize my knowledge without the digital clutter weighing me down.

After hearing about Notion Web Clipper from a fellow developer, I decided to give it a try. It promised an easier way to clip web content and store it neatly within Notion for future reference. Little did I know, this tool would not only streamline my research but also revolutionize the way I approach learning and working.

My Tab Overload Challenge

I still remember the day I decided to tackle the mess of open tabs. I had accumulated a collection of tutorials, tool documentation, and countless articles on topics ranging from "Write Code That's Easy to Delete" to AI-driven code reviews. Each tab was a potential goldmine of information but turning into an ever-growing source of distraction.

Here’s the reality: My browser was running slowly, and I constantly found myself hunting for specific information amidst the chaos. Frustration was mounting. I realized I had a serious case of tabitus, a term I just coined for my affliction.

Finding Relief: The Breakthrough

Using the Notion Web Clipper was a game-changer. I installed the extension and, over the next few days, began clipping articles, guides, and tutorials into designated pages within Notion. I set up a few databases to categorize everything into manageable pieces:

Learning - For articles I wanted to study.
Tools - Documentation for frameworks and libraries I was exploring.
Inspiration - Blog posts that sparked an idea for a project.

Like magic, I could now search for any topic, relying on either my Notion database or even asking AI for recommendations based on my notes. It transformed my chaos into clarity and significantly improved my productivity. Every time I opened Notion, I felt like I was revisiting a well-organized library instead of a messy cafe.

Diving Deeper: The Bigger Principle

The real lesson I learned was not just about using Notion Web Clipper. It was about the importance of organization in a developer's workflow. As a programmer, we often emphasize code quality, functionality, and efficiency in our projects, but how often do we apply the same principles to our knowledge management?

Maintaining a clean workspace, both physical and digital, allows for better focus and creativity. When your environment is organized, your mind can function with much more clarity. I began to see my newfound organization not just as a method but as an essential part of my professional development.

What I'd Do Differently

Reflecting on this journey, here are some actionable steps that I would recommend for anyone looking to tackle their tab overload:

Set Time Limits on Tab Openings: Create a rule for myself to only open tabs related to current tasks. If something piques my interest, I can clip it instead.
Regular Cleanup Sessions: Schedule weekly or bi-weekly sessions to revisit tabs and decide what to keep, clip, or close.
Engage with Saved Content: Allocate specific times to explore clipped resources so they don't just sit idle.
Use Tags and Folders Wisely: Tags in Notion make retrieval a breeze. Establish a consistent system for naming and categorizing to avoid future chaos.
Connect with Others: Share your insights and systems with fellow developers—feedback can inspire improvements and new approaches to organization.

A Final Thought

Digital organization might seem trivial to some, but for developers facing a constant flow of information, it can make or break productivity. Have you ever felt overwhelmed by the sheer volume of knowledge accessible today? What systems have you found effective for maintaining clarity in your work? Let’s talk about the methods you’ve discovered in the comments!

The Surprising Power of Code Reviews: Pull Requests That Saved My Project

Kiell Tampubolon — Tue, 05 May 2026 07:59:56 +0000

Introduction

Code reviews. For many developers, they are a necessary evil — a box to check in the development process. However, I have come to appreciate them as a powerful tool for elevating code quality, fostering collaboration, and improving team dynamics. Today, I want to share my journey from viewing code reviews as a mundane task to recognizing their critical role in successful projects.

Let me take you back to a project I led a few months ago. Our team was tasked with developing a complex web application with collaborative features that would require seamless integration and robust functionalities. In the early days, I saw my role as simply overseeing the process and ensuring that the final product met user expectations. However, I soon learned that underestimating the power of code reviews could lead to colossal mistakes — not just in the code, but in team morale and project outcomes.

Here’s a detailed account of my experience, the lessons learned, and the actionable strategies that transformed my approach to code reviews.

The Early Days: Ignoring Reviews Leading to Mistakes

In the project’s inception phase, I was hyper-focused on deadlines and feature deliveries. Our codebase grew rapidly, but I neglected the importance of formal reviews. I told myself, “I’ll just go over the code later; we need to push this out.” This resulted in my team producing a few hastily written functions with bugs that were not caught early on.

This atmosphere of speed over quality led to miscommunication within the team. Some developers had differing opinions on the implementation of core features, and since we weren't catching these issues through code reviews, they propelled into the main branch. For instance, an authentication feature, which was crucial, ended up with conflicting logic due to two separate devs implementing their versions without oversight. Here’s a snippet that illustrates this moment:

// Auth function without review
function authenticateUser(username, password) {
    // Assume hashPassword is a utility function we've created
    return getUserByUsername(username).then(user => {
        return user.password === hashPassword(password);
    });
}

This snippet looks benign, but unreviewed, it ended up breaking several functionalities, leading to a user panic when they faced login issues. A thread of confusion ensued, users were locked out, and our credibility took a hit.

Lesson Learned: I realized that without code reviews, we were sacrificing not only the integrity of our code but also the trust within our team and with our users. It was a wake-up call that led to the implementation of a stricter code review process.

Transforming the Code Review Process

Once I recognized the critical importance of code reviews, I began reformulating our approach. The focus shifted from a mere task to a critical collaborative process that involved everyone. Here are the steps we took:

1. Establish Clear Guidelines

I began by drafting clear, concise guidelines on our code review process. I emphasized that reviews should not only check for bugs but also assess design choices, coding standards, and documentation. Clear expectations set the tone for how we approached reviews. We settled on using GitHub pull requests, which allowed for an easy review process. Here’s an example of our guidelines:

Purpose of Review: Ensure functionality, maintainability, and clarity.
Who Reviews: At least two team members must review before merging.
Focus Areas: Structure, readability, potential edge cases, naming conventions, and performance.

2. Educating the Team

With our framework in place, it was crucial to educate the team on effective code reviewing. I scheduled a workshop where we discussed best practices. One takeaway was to ask questions rather than impose personal preferences. For example, instead of saying, "Change this variable name to 'userId'," we encouraged feedback like, "What do you think about naming this variable 'userIdentifier' for clarity?"

This approach not only improved our code quality but also fostered a culture of respect and collaborative growth. I even modeled a review for a particularly tricky component. Here’s a sample of how I structured my feedback:

### Feedback on `authenticateUser` function

1. **Rename the function**: Consider changing to `isAuthenticated` for clarity on its purpose.
2. **Add Error Handling**: If the username is not found, currently the function would return undefined, which could lead to confusion. Consider handling this case explicitly.
3. **Utility Usage**: Instead of comparing raw passwords with hashed values in this method, why not delegate that logic to a utility function? This adds to maintainability.

Lesson Learned: A clear structure around code reviews transformed them from a task into an opportunity for everyone on the team to learn from each other’s strengths and weaknesses.

Building a Culture of Continuous Improvement

With a solid review process in place, I set out to cultivate a culture of continuous improvement. This didn’t happen overnight; it took dedication and encouragement from all team members. We began celebrating great reviews. Whenever a particularly insightful comment improved code quality, we acknowledged it during our team meetings, motivating developers to take pride in their contributions.

Encourage Pair Programming

I also introduced pair programming sessions, where team members would collaborate on challenging components. This approach not only increased engagement but also minimized the chances of oversight, as developers could hash out design decisions in real-time before code even reached the review phase. Here’s a stripped-down version of an implementation process:

// Pair-programming snippet
function registerUser(userData) {
    return hashPassword(userData.password).then(hashed => {
        return db.insert({...userData, password: hashed});
    });
} // Account for registration without review

This snippet encapsulates ideas generated during pair programming sessions where we were able to identify potential flaws before they made their way to the review process.

Lesson Learned: Investing in relationships through pair programming not only improved the quality of the code but also strengthened our team’s commitment to collaborative improvement.

Conclusion

After implementing a robust code review process, I witnessed a significant transformation not just in our code quality, but also in team morale. Challenges that previously had the power to derail us became collaborative learning opportunities. We moved from a culture of blame and speed to one of accountability and quality.

Now I see code reviews as a vital part of the software development lifecycle, a necessity for building better software and a stronger team. I’d love to hear from you: What has been your experience with code reviews? Have you faced challenges in your process or found unexpected benefits? Let's discuss in the comments below!

I Shipped My First Cloudflare Worker via GitHub Actions in 47 Minutes (3 Were Wasted on the Wrong API Token)

Kiell Tampubolon — Tue, 05 May 2026 03:36:33 +0000

My first Cloudflare Worker deployed in 47 minutes. Three of those were spent staring at this exact error in a red GitHub Actions log: Authentication error [code: 10000]. I had the API token. I had the account ID. I had copy-pasted the workflow from the official docs. It still failed.

The fix was one checkbox I never selected. That checkbox is the entire reason I'm writing this post, because every tutorial I read assumed I would not get it wrong.

What I Built

A Cloudflare Worker that returns a JSON response saying hello. Three lines of actual logic. One wrangler.toml file. One GitHub Actions workflow. Push to main, the Worker is live on the edge, end of story.

The point was never the Worker itself. The point was getting the pipeline working so the next 100 commits ship themselves.

The Setup That Actually Works

Here is the worker. It lives at src/index.js:

export default {
  async fetch(request, env, ctx) {
    return Response.json({
      message: "Hello from the edge",
      region: request.cf?.colo ?? "unknown",
    });
  },
};

The wrangler.toml:

name = "hello-edge"
main = "src/index.js"
compatibility_date = "2025-01-01"

And the GitHub Actions workflow at .github/workflows/deploy.yml:

name: Deploy Worker

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

That is the whole thing. Three files. Roughly 25 lines including blanks.

The 3 Minutes I Want Back

The first time I pushed, the Action failed in 11 seconds with Authentication error [code: 10000]. I assumed I had pasted the token wrong. I rotated it. Same error. I checked the secret name. Correct. I read the wrangler-action README twice. I started questioning the structure of reality.

What I had done: created a Cloudflare API token using the "Read All Resources" template because I was being cautious. That token can read everything and write nothing. Wrangler needs to write. The fix was to use the "Edit Cloudflare Workers" template instead, which scopes write access to exactly the Workers resource and nothing else.

The reason this isn't obvious from the error: code 10000 is Cloudflare's generic auth failure. It does not say "your token has no write permission." It says "auth bad." Three minutes of my life, gone, to a missing checkbox.

The other gotcha most posts skip: the Account ID is not a secret. It's visible in your dashboard URL. Storing it as a GitHub secret is fine, but it's not protecting anything sensitive. The API token is the actual key to the kingdom. Do not commit it. Do not log it. Rotate it if you so much as look at it sideways in a public terminal.

Why I Bothered With CI/CD on Day One

Honest answer: I almost didn't. The Cloudflare dashboard has a perfectly fine "Connect to Git" button that wires up auto-deploys without writing a single line of YAML. For a beginner shipping one Worker, that is the faster path.

I went with GitHub Actions anyway because of one thing: control. The wrangler-action approach lets me add steps I'll need later, like running tests before deploy, deploying to a staging environment first, posting to Slack on failure, gating on a manual approval. The dashboard integration gives me a black box. The Actions workflow gives me a file I can read.

The trade is more setup time now (about 15 extra minutes) for unlimited flexibility later. For a learning project, that's the right trade. For shipping a one-off marketing site, just click the button.

The First Successful Deploy

It logged this:

Total Upload: 0.42 KiB / gzip: 0.30 KiB
Uploaded hello-edge (1.15 sec)
Deployed hello-edge triggers (0.32 sec)
  https://hello-edge.<my-subdomain>.workers.dev

I clicked the URL. It loaded in 38 milliseconds from a Singapore data center. I am writing this from Batam, Indonesia, so that's roughly 60 km away. My code, on a server, 60 km from me, deployed by a GitHub Action I wrote 47 minutes ago.

The thing I was not expecting: the satisfaction came from the pipeline, not the Worker. Pushing to main and watching the green check appear on GitHub, knowing my Worker is now live globally without me touching the Cloudflare dashboard, that's the actual feature. The Worker is a hello world. The CI/CD is the real thing I built.

What This Teaches

Three things, if you're about to do this for the first time:

Use the "Edit Cloudflare Workers" API token template, not "Read All Resources" or any custom one you build yourself. The pre-baked template has the exact scopes wrangler needs. Custom tokens are how you lose 3 minutes to error code 10000.

Set up the Actions pipeline before your code is interesting. A boring Worker behind a working pipeline is worth more than a clever Worker you deploy by hand. The pipeline compounds. Your hand-deploys do not.

The Account ID is public, the API token is not. Store both as secrets if it makes your life easier, but understand which one matters. One leak is a footgun. The other leak is a key handed to a stranger.

What I'm Building Next

Next step is preview deploys per pull request, so every PR gets its own *.workers.dev URL automatically. I think the answer is a second job in the workflow keyed on pull_request, plus a comment bot that posts the preview URL on the PR.

If you've done this with Workers (not Pages, that's the easy mode), what does your workflow look like? And what's the one CI/CD mistake you wish someone had warned you about on day one?

I Connected 11 MCP Servers. 3 of Them Actually Did Anything.

Kiell Tampubolon — Mon, 04 May 2026 14:39:34 +0000

I spent a weekend connecting every MCP server that sounded useful. By Sunday night I had 11 running, a claude_desktop_config.json that scrolled off the screen, and an agent that was technically capable of doing almost anything. In practice, it was doing almost nothing useful.

What I learned had very little to do with which servers are "good."

The List Looks Better Than It Performs

The MCP ecosystem has exploded. There are directories with thousands of servers now. You can connect your agent to GitHub, Notion, Google Drive, Slack, your calendar, your email, your databases, your browser, a web search tool, a weather API, and about 40 other things I cannot remember anymore. The pitch is always the same: connect everything and your agent becomes superhuman.

What nobody tells you is what happens to your context window when you do.

Every MCP server shows up in your agent's prompt as a block of tool definitions: name, description, parameter schema. This is not free. Perplexity's CTO said publicly in March that tool descriptions alone eat 40 to 50% of available context before the agent touches a single real task. I ran my own rough test with 11 servers and came out around 35%. One third of my agent's thinking capacity, gone before the first message. The agent still technically worked. It just worked slower, cost more per turn, and occasionally picked the wrong tool because it had 80 options to reason about instead of a handful.

What I Kept

After a week of watching which tools the agent actually called, I stripped it down to three: web search, my calendar, and file system access to one specific folder.

My claude_desktop_config.json went from this kind of sprawl:

{
  "mcpServers": {
    "brave-search": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-brave-search"] },
    "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] },
    "notion": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-notion"] },
    "slack": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"] },
    "google-calendar": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-google-calendar"] },
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you"] },
    "puppeteer": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-puppeteer"] }
  }
}

To this:

{
  "mcpServers": {
    "brave-search": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-brave-search"] },
    "google-calendar": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-google-calendar"] },
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/work"] }
  }
}

Note the filesystem path change. /Users/you gave the agent access to everything on my machine. /Users/you/work gives it access to what it actually needs. Smaller scope, less noise in file lookups, faster responses.

The difference was immediate and embarrassing. I had spent a whole weekend adding capabilities, and the agent got noticeably better the moment I removed most of them.

Web search is the tool that punches farthest above its weight. An agent that can look something up in real time stops being a static oracle and becomes useful for questions whose answers change. Calendar access mattered more than I expected, not because the agent scheduled things for me, but because it could check whether I had time before suggesting I do something. "You have a 2-hour block on Thursday" as context is qualitatively different from a suggestion with no time anchor. File system access scoped to one working folder let me point the agent at my notes and drafts without handing it my entire machine.

Everything else I connected was called once or twice across a full week of actual use, then never again. GitHub: technically impressive, practically unnecessary because I just used the CLI. Notion: ran three queries, never opened it through the agent again. Slack: the agent drafted messages I never sent. Browser automation: impressive in a demo, zero practical value in my real workflow.

The Rule I Wish Someone Had Told Me Earlier

A connected MCP server costs you context whether or not you ever use it. The tool definitions sit in the prompt on every single turn. The agent reasons about whether to invoke them each time. More servers is not "free and neutral, then occasionally useful." More servers is always a cost, and only sometimes worth it. That is a fundamentally different calculation.

An MCP list that looks impressive in a screenshot will slow your agent down in production. Connect what you actually use, not what sounds good.

Before adding any server, the right question is not "could this be useful?" It is "did I actually need this in the last seven days?" If the answer is no, leave it disconnected. You can always add it back in thirty seconds.

What I Would Do Differently

Start with zero servers. Use the agent for a week on its base model alone. Write down every moment you hit a wall, something the agent could not do that you genuinely needed. Then connect exactly those servers and nothing else. Nothing else.

Most of the value in AI agents right now does not come from the size of the tool list. It comes from the agent having enough context headroom to reason clearly about the few tools it has. A focused agent with 3 servers beats a loaded one with 11. At least that is what a weekend of overengineering taught me.

If you have used MCP in a real workflow beyond demos, I want to know two things: which server do you use every single day, and which one did you connect and quietly never call again? Drop both. The most useful answers get turned into a proper teardown post with real usage data.

I Built an OSINT Aggregator That Queries 5 Threat Intel Sources in One Command

Kiell Tampubolon — Fri, 01 May 2026 11:54:36 +0000

One night. One command. Full threat intelligence picture.

The Problem

Every time I needed to check if an IP or domain was malicious, I'd end up with 5 browser tabs open:

VirusTotal
AlienVault OTX
Shodan
NVD CVE Database
GitHub Security Advisories

Copy. Paste. Wait. Repeat. Cross-reference. Then make a decision.

This workflow is fine once. But when you're triaging multiple alerts during an incident, or doing OSINT research on a list of indicators — it's a massive time sink.

So I built a tool to automate it.

Introducing SentinelScout

SentinelScout is an open-source CLI tool that queries 5 threat intelligence sources simultaneously, then uses AI to correlate the results into a single, actionable threat score.

$ sentinelscout query suspicious-domain.xyz

Query: suspicious-domain.xyz (5 sources)

Source         Status  Severity  Result
──────────────────────────────────────────────
Virustotal      [+]     HIGH     67/94 engines flagged
Alienvault      [+]     HIGH     3 pulses found, tags: [apt] [phishing]
Shodan          [+]     INFO     4 open ports detected
Cve             [-]     LOW      No known CVEs found
Github Adv      [-]     LOW      No advisories found

Threat Score: 87/100 [CRITICAL]

No browser tabs. No copy-pasting. Just answers.

How It Works

The tool is built on three pillars:

1. Async Python — Everything Runs in Parallel

All 5 sources are queried concurrently using Python's asyncio. Results come back in 2-4 seconds total, regardless of how slow any single source is.

async def _query(indicator: str, sources_filter: list[str] | None) -> AnalysisReport:
    all_sources: list[BaseSource] = [
        VirusTotalSource(),
        AlienVaultSource(),
        ShodanSource(),
        CVESource(),
        GitHubAdvSource(),
    ]
    if sources_filter:
        all_sources = [s for s in all_sources if s.source.value in sources_filter]

    tasks = [s.query(indicator) for s in all_sources]
    results = await asyncio.gather(*tasks)
    return AnalysisReport(indicator=indicator, sources=list(results))

The asyncio.gather() call fires all 5 API requests simultaneously. If one source is slow, it doesn't block the others. Total wait time = slowest source, not sum of all sources.

2. Source Adapters — Pluggable Architecture

Each threat intel source has its own adapter class that handles:

API authentication
Request/response handling
Data normalization to a standard IOCResult model

Adding a new source is just creating a new class:

class MySource(BaseSource):
    name = "mysource"
    source = Source.MYSOURCE

    async def query(self, indicator: str) -> IOCResult:
        # your scraping logic here
        return IOCResult(...)

Every adapter returns the same shape. The CLI doesn't care which source it came from — it just formats and displays it.

3. AI Correlation — Making Sense of It All

When you add an OpenAI API key, GPT-4o-mini reads all the raw results and generates:

A plain-English threat summary
A 0-100 threat score
A severity label (LOW / MEDIUM / HIGH / CRITICAL)

This is especially useful when different sources give conflicting signals — AI helps you make a judgment call instead of staring at contradictory data.

Supported Sources

Source	Type	API Required	Free Tier
VirusTotal	Domain/IP/Hash	Yes	500 req/day
AlienVault OTX	IP/Domain/Hash	Yes	10k pulses/day
Shodan	IP only	Yes	100 queries/month
NVD CVE	Vulnerabilities	No	Unlimited
GitHub Advisories	Vulnerabilities	No	Unlimited

Two sources (CVE and GitHub) work out of the box with no API key needed.

Quick Start

pip install sentinelscout

Get free API keys:

VirusTotal: virustotal.com/gui/my-apikey
AlienVault OTX: otx.alienvault.com/api
Shodan: account.shodan.io
OpenAI: platform.openai.com/api-keys (optional)

Set your keys:

export VIRUSTOTAL_API_KEY=your_key
export ALIENVAULT_API_KEY=your_key
export SHODAN_API_KEY=your_key
export OPENAI_API_KEY=your_key  # optional

Run it:

sentinelscout query suspicious-domain.xyz
sentinelscout sources   # check config status
sentinelscout --help

Project Structure

sentinelscout/
├── cli.py              # CLI entrypoint (Typer + Rich)
├── analyzer.py         # AI correlation engine (OpenAI)
├── config.py           # .env loader
├── models.py           # IOCResult, AnalysisReport dataclasses
├── sources/
│   ├── base.py         # BaseSource abstract class
│   ├── virustotal.py   # VirusTotal API client
│   ├── alienvault.py   # AlienVault OTX client
│   ├── shodan.py       # Shodan API client
│   ├── cve.py          # NVD CVE feed scraper (no key needed)
│   └── github.py       # GitHub Security Advisories (no key needed)
└── pyproject.toml      # package metadata

What I Learned

Async Python is powerful. Once you wrap your head around asyncio.gather(), you start seeing parallelism everywhere. It's the difference between a tool that takes 15 seconds and one that takes 3.

Structured data models > raw dicts. Defining IOCResult and AnalysisReport as clean dataclasses made the entire codebase simpler. Every source adapter returns the same shape. No more ad-hoc dict handling.

The best projects come from personal pain. I didn't build SentinelScout to impress anyone. I built it because I was annoyed with my own workflow. That specific irritation is what kept me going through the 3-hour build session — and it's what makes the tool actually useful, not just impressive-looking.

What's Next

Ideas on the roadmap:

🌐 Web UI (Gradio or Streamlit) for non-CLI users
📊 JSON/CSV export for SIEM integration
🤖 Telegram bot for on-the-go IOC queries
🔗 More sources: GreyNoise, AbuseIPDB, ThreatFox

Get the Code

Full source code, installation instructions, and documentation:

👉 github.com/glatinone/sentinelscout

Star it if you find it useful. Issues and PRs welcome.

Built with Python 3.10+, Typer, Rich, and httpx. No paid dependencies — runs entirely on free-tier APIs.

I Let Claude Pentest My Own Side Project for $0.43. It Found Three Things in 12 Minutes.

Kiell Tampubolon — Mon, 27 Apr 2026 16:38:31 +0000

I built ContextForge to solve my own problem: AI chats that lose memory mid-project. Last night I gave Claude the codebase and asked it to find ways to break in. Twelve minutes and forty-three cents later, I had a finding sheet I would have been embarrassed to show a senior engineer.

This post is what I did, what it found, what it missed, and how to do the same to your own side project tonight without spending more than a dollar.

What I Built

ContextForge is a small open-source app for managing AI conversation context. Next.js on the front, FastAPI on the back, SQLite for storage. Roughly 4,200 lines of TypeScript and Python at the time of the audit. Personal project, not yet shipped, but already wired up to a real LLM API and already storing real conversation data on disk.

In other words, exactly the class of side project most developers never security-review. We treat side projects like sketches and production apps like buildings. The problem is that side projects ship to production constantly, often with the same database engine and the same secret-handling habits we'd use in a real product.

The Setup

I wanted a junior pentester for one evening. Not a vendor scanner, not a SaaS audit tool. Just a smart adversary with patience. So I gave Claude three things:

A clear adversarial role. "You are a senior application security engineer. Your job is to find ways an attacker could compromise this app, exfiltrate data, or escalate privileges. Be specific. Cite line numbers. Rank findings by severity."

The repo. I dumped the relevant files (FastAPI routes, the Next.js API handlers, the SQLite schema, the .env.example, the Docker setup) into the conversation.

Scope rails. "Focus on the API surface, secret handling, input validation, and storage. Skip dependency CVEs for this pass. Skip nice-to-haves. Only flag things that would matter if this app went public tomorrow."

The whole prompt was about 200 words. The repo dump was about 18,000 tokens. Total session cost on the Anthropic API: $0.43 across two back-and-forth rounds.

What It Found

Three findings. All real. All embarrassing in different ways.

Finding 1: API key leaking through error responses

My FastAPI exception handler returned the full exception message to the client on 500 errors. One of those exceptions, raised when the LLM client failed to authenticate, included the partial API key in its message. A debug aid I forgot was there. An attacker who could trigger that specific failure path would get back a fragment of my OpenRouter key in the JSON response.

# api/routes/context.py (the bug)
@router.post("/extract")async def extract_context(payload: ExtractRequest):
    try:
        result = await llm_client.extract(payload.text)
        return {"context": result}
    except Exception as e:
        # bug: this leaks internal error text including upstream API errors
        raise HTTPException(status_code=500, detail=str(e))

The fix is one line of paranoia. Catch the exception, log the real error server-side, return a generic message to the client.

# api/routes/context.py (the fix)
@router.post("/extract")async def extract_context(payload: ExtractRequest):
    try:
        result = await llm_client.extract(payload.text)
        return {"context": result}
    except Exception as e:
        logger.exception("extract_context failed")
        raise HTTPException(status_code=500, detail="extraction failed")

I had written this exact pattern correctly in three other routes. I missed it on this one because I was tired when I added it. This is the most common shape of a real vulnerability: not a clever attack, just a tired Tuesday.

Finding 2: SQLite path traversal in the per-project save feature

ContextForge lets you save context packs per project. I was using the project name as part of the file path. No sanitization. A project named ../../../etc/passwd would happily walk out of the data directory.

Claude flagged the exact line, suggested a deny-list (which I rejected because deny-lists always lose), and on follow-up suggested a UUID-based storage scheme where the user-facing name is decoupled from the on-disk path. That is the right answer. I was using the name because it was convenient during dev. Convenient during dev is the most dangerous phrase in security.

Finding 3: CORS set to wildcard in the FastAPI config

I had allow_origins=["*"] for "local development convenience" in a config file that was also being loaded in the Docker production target. If I had pushed this to a public deployment as-is, any website on the internet could have made authenticated requests to the API from a victim's browser. This is the kind of thing that gets caught by a real code review and almost never gets caught by a unit test.

What It Missed

This is the part most "I used AI for security" posts skip, and it's the part that matters.

Claude did not catch a race condition in the project deletion endpoint, where deleting a project while a context extraction was in flight would leave orphan rows in the embeddings table. I found that one myself two days later when something broke in the UI. It's the kind of bug that requires understanding the full data flow over time, not just reading individual files.

It also did not catch the fact that my rate limiter was applied per IP and my dev environment was running everything through localhost, meaning the rate limiter was effectively disabled for all real testing. A pentester who uses the app for a day would have noticed this. A model reading the code in isolation didn't.

The lesson isn't that AI security review is bad. The lesson is that it's a good first pass. It catches the ten things I should have caught myself before I shipped. It does not replace someone who actually uses the system over time.

The Cost Math That Surprised Me

Total tokens for the session: roughly 47,000 input, 8,200 output. Total cost on the Anthropic API: $0.43. Twelve minutes of wall-clock time. For comparison, the cheapest external code review I have ever paid for cost $300 and took a week.

That is not a fair comparison, of course. A human reviewer brings context and judgment Claude does not have. But for the specific job of "find the obvious things in my own code before I ship," forty-three cents is the right ballpark and twelve minutes is the right wall-clock.

I would happily pay this every time I'm about to push a side project to a public URL. I am, in fact, going to make it a checklist item.

What This Actually Teaches You

A frontier model is a free junior pentester on your own code, with two caveats. First, you must give it adversarial scope, not "review my code." The framing matters because models default to politeness, and a polite reviewer does not find leaks in error responses. Second, you must verify the findings yourself. The cost of acting on a false-positive is wasted time. The cost of acting on a real finding is one fewer embarrassment.

The post-mortem habit matters more than the tool. Every finding above was a thing past-me knew was wrong and present-me had stopped paying attention to. The audit was not new knowledge. It was a forced re-read with a hostile lens.

If you are sitting on a side project that has crept toward something real (a small SaaS, a portfolio piece with a live URL, a tool you started selling on the side), run this audit tonight. Forty-three cents and twelve minutes is the right price for sleeping better.

The Five-Step Checklist If You Want To Run This Tonight

Pick the project. Anything with a public URL or a real database counts.

Dump the security-relevant files into a fresh chat. API routes, config, env example, schema, auth middleware.

Use the adversarial prompt: senior application security engineer, find specific vulnerabilities with line numbers, ranked by severity, scoped to API surface and secrets and storage.

Read every finding. Verify against your code. Reject the false positives.

Fix the real ones before you sleep. Otherwise tomorrow you will not.

What is the smallest, most embarrassing thing an AI security review found in your own code? And what is the one finding you are still arguing with the model about because you don't want to fix it? Drop both in the comments. The most surprising answer becomes the next post, with credit.

I Let OpenClaw Run My Mornings for 7 Days. It Stopped Acting Like a Chatbot on Day 4.

Kiell Tampubolon — Sat, 25 Apr 2026 14:30:14 +0000

This is a submission for the OpenClaw Writing Challenge

For three days I almost uninstalled OpenClaw. I had connected it to Telegram, GitHub, and Google Calendar, and every morning at 8 AM it sent me the most useless message I have ever received from a piece of software: "You have 4 open PRs. Consider reviewing them."

Thanks. I have eyes. The breakthrough came on day 4, and it had nothing to do with the model.

What I Built

A morning triage agent. Not a chatbot waiting for me to ask. An agent that wakes up at 8 AM, observes the state of my work across three tools, and tells me the one thing I should do first that day, with a reason.

The chatbot mindset stops at "summarize my morning." The agent mindset closes the loop and makes a decision.

How It Works

The skill definition is the contract. Plain English, declarative, and OpenClaw figures out the rest.

# skills/morning-triage/SKILL.md
name: morning-triage
description: |
  Every morning at 8 AM, look at my open GitHub PRs,
  unread Telegram messages, and today's calendar.
  Decide the ONE thing I should do first and tell me why.
triggers:
  - schedule: "0 8 * * *"
tools:
  - github
  - telegram
  - calendar

The runner is the observe → decide → act loop. This is what every real agent looks like underneath.

# skills/morning-triage/run.py
from openclaw import Agent

class TriageAgent(Agent):
    def observe(self):
        return {
            "prs": self.tools.github.open_prs("kiel/myrepo"),
            "msgs": self.tools.telegram.unread(hours=12),
            "events": self.tools.calendar.today(),
            "now": self.now(),
        }

    def decide(self, state):
        return self.llm.ask(
            f"Given this state: {state}\n\n"
            f"What is the SINGLE most important thing I should do "
            f"in the next 90 minutes? Name the specific PR/message/event. "
            f"One sentence. Include WHY it matters."
        )

    def act(self, decision):
        self.tools.telegram.send(f"☕ Focus today: {decision}")

TriageAgent().run()

The chatbot mindset stops at "decide" because the human is supposed to act on the answer. The agent closes the loop on its own.

What Actually Happened

Day 1. Output: "You have 4 open PRs. Consider reviewing them." Useless. I almost killed the cron.

Day 2. Same. I had given the agent enough tools to see everything but not enough instruction to choose. The model was hedging. The fault was in my prompt, not the LLM.

Day 3. I rewrote the decide step. Forced it to name a specific item. Forced it to explain why. Forced it into one sentence. Output got slightly better but still felt mechanical.

Day 4. The breakthrough. I added one extra field to observe: how long each PR had been open and how many times someone had pinged me. Suddenly the agent had real signal. The morning message read:

☕ Focus today: PR #142 has been open 9 days, blocking the v2.3 release, and Andre has pinged you twice on Telegram about it. Review it before your 10:30 standup.

I had genuinely forgotten about that PR. The agent connected three separate data sources and surfaced a thread I had dropped two weeks ago. That was the moment OpenClaw stopped being a chatbot to me.

Day 5. Different output, different decision: "Skip the deep work block, you have a 10:00 meeting that conflicts with your 10:15 review and three unread messages from your manager since last night."

Day 6. It correctly told me to do nothing urgent and protect my deep work block. That was the second moment that surprised me. A good agent has to know when not to interrupt.

Day 7. Total cost for the week was under one dollar in API spend, because the agent only fires once a day on a schedule. Chatbot usage is unbounded. Scheduled agent usage is cheap and predictable.

The Lesson Behind the Lesson

The fix was never the model. The fix was three things, in this order:

Better observation. If you do not give the agent state, it cannot make a decision. Vague input produces vague output.

Forced specificity in the prompt. "Name the specific item. Explain why. One sentence." That is the difference between a horoscope and a recommendation.

A schedule, not a conversation. The chatbot pattern bills you per question. The agent pattern bills you per outcome.

If you are typing into OpenClaw the same way you type into ChatGPT, you are using a power tool to hammer in a nail. Write one SKILL.md. Set one schedule. Close the loop. That is the unlock.

If you had to give one OpenClaw agent full control over a part of your day, what would you let it decide for you, and what would you never let it touch? I am genuinely curious where the line is for other devs. Drop it below.

What's New in GKE at Next '26: Kubernetes Just Got Smarter (and Cheaper)

Kiell Tampubolon — Thu, 23 Apr 2026 14:01:43 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Kubernetes as the OS of the AI Era

At Google Cloud Next '26, Google made one thing pretty clear: Kubernetes is no longer just a container orchestrator. It's quickly becoming the operating system of the AI era.

The numbers speak for themselves. GKE now powers AI workloads for all of Google's top 50 customers on the platform, including the biggest frontier model builders out there. In just a few months, multi-agent AI workflows surged by 327%. On top of that, 66% of organizations now rely on Kubernetes to run their generative AI apps and agents.

This isn't just an incremental update. It's a real shift. And the GKE announcements at Next '26 reflect that change well. Here's a breakdown of what's new and why it actually matters for developers.

1. GKE Agent Sandbox: Secure, Scalable Agent Infrastructure

As AI moves from chatbots to fully autonomous agents running at massive scale, the underlying infrastructure needs to keep up with hundreds, sometimes thousands, of agents collaborating at the same time.

Google's answer to this is the GKE Agent Sandbox, which they're calling the industry's most scalable and low-latency agent infrastructure. It's built on gVisor kernel isolation (the same tech that secures Gemini), so you can safely run untrusted code, tools, and entire agents without giving up performance.

Key numbers:

300 sandboxes per second at sub-second latency
Up to 30% better price-performance on Axion compared to other hyperscale clouds

One real-world example: Lovable, a platform where builders spin up 200,000+ new projects every single day, runs its AI-generated apps in GKE Agent Sandboxes. The reason? Fast startup, fast scaling, and solid secure isolation.

What this means for you: If you're building multi-agent systems or executing untrusted user-generated code, Agent Sandbox takes away the painful choice between security and speed.

2. GKE Hypercluster: One Control Plane for Everything

Let's be honest, managing hundreds of disconnected Kubernetes clusters is a nightmare at scale.

GKE Hypercluster (now in private GA) tackles this head on by letting a single, Kubernetes-conformant GKE control plane manage 1 million chips across 256,000 nodes across multiple Google Cloud regions.

What makes it stand out is the security model. It uses Google's Titanium Intelligence Enclave, a software-hardened "no-admin-access" security engine. Your proprietary model weights and prompts stay cryptographically sealed from platform admins and infrastructure layers. That's a big deal for enterprise teams.

What this means for you: If you're running large-scale AI training across regions, you no longer have to deal with fragmented clusters. Your entire distributed infrastructure becomes one unified capacity reserve.

3. Supercharged Inference Performance: No More Months of Manual Tuning

Getting to state-of-the-art (SOTA) inference used to take months of painful performance tuning. GKE is changing that with two solid updates:

ML-Driven Predictive Latency Boost

The new feature inside GKE Inference Gateway uses real-time capacity-aware routing to cut time-to-first-token (TTFT) latency by up to 70%. No manual tuning needed. It just works.

Automatic KV Cache Storage Tiering

Smart tiering across RAM, Local SSD, and GCS/Lustre helps with long-context memory bottlenecks:

Offloading to RAM: 40%+ TTFT reduction and 50% throughput gain (for 10K prompt length)
Offloading to Local SSD: around 70% throughput improvement (for 50K prompt length)

These features are built on top of llm-d, which just became an official CNCF Sandbox project. GKE also integrates with NVIDIA Dynamo for scaling large Mixture-of-Experts (MoE) models.

What this means for you: You can go from deployment to frontier-grade inference in minutes instead of months. That's a huge deal.

4. Reinforcement Learning Enhancers: Stop Wasting GPU Time

RL is one of the biggest drivers of AI compute demand right now. But the problem is that RL jobs involve a lot of sequential processing, which leaves GPUs and TPUs just sitting idle between steps.

GKE is adding new native RL capabilities (currently in preview) to fix this:

RL Scheduler solves the "straggler effect" and inter-batch tail latency, keeping throughput high with intelligent routing
RL Sandbox gives you kernel-level isolation for tool-calling and reward evaluation at millisecond-scale provisioning
RL Observability and Reliability dashboards give you deep visibility out of the box to troubleshoot and optimize the whole RL loop

What this means for you: If you're doing RL training at scale, this is directly targeting the idle-time problem. Less idle time means lower costs. Simple as that.

5. Intent-Based Autoscaling: No More "Custom Metric Tax"

Scaling AI workloads on anything beyond basic CPU or memory has always been painful. You'd need complex monitoring setups, IAM management, and a dependency on external observability stacks that could fail at the worst moment.

GKE's new Intent-Based Autoscaling brings native custom metrics support to the Horizontal Pod Autoscaler (HPA):

Agentless architecture pulls metrics directly from Pods, no external dependencies needed
5x faster reaction time, dropping from 25 seconds down to just 5 seconds
If your external observability stack goes down, your autoscaling keeps running. No more cascade failures.

What this means for you: This one flies under the radar but it's honestly one of the more impactful updates. Scaling on what actually matters for your workload, not just CPU, is now genuinely easy and reliable.

My Take: One Clear Pattern

Looking at all five of these announcements together, there's a clear theme running through all of them: Google is making GKE the go-to platform for serious AI workloads, not by piling on new features, but by removing the friction that's been slowing developers down.

Agent Sandbox removes the security-vs-performance tradeoff
Hypercluster removes the cluster fragmentation headache
Inference optimizations remove months of manual tuning
RL Enhancers remove GPU idle waste
Intent-based autoscaling removes fragile external metric dependencies

Every single update is about taking something painful away.

For anyone who's been frustrated running AI workloads on Kubernetes, the Next '26 GKE updates feel like Google finally saying: we get it, and here's the fix.

Whether you're building multi-agent pipelines, serving frontier models, or doing RL training at scale, these updates are worth paying attention to, especially if cost and performance matter to you.

What do you think about these GKE updates? Are you already using any of them or planning to? Drop a comment, I'd love to know what you're building!