DEV Community: Daniel Akudbilla

I Built an AI Agent to Check the Weather. It Was Gloriously Unnecessary.

Daniel Akudbilla — Sat, 04 Jul 2026 18:41:37 +0000

Let me get the confession out of the way early: I built an AI agent that, given a city name, tells you about the place and then checks the weather.

You know what already checks the weather? A weather API. One fetch. No model, no tokens, no monthly bill with the word "usage" in it. I knew this the whole time I was building. Built the agent anyway.

Here's the story of that, and a small argument for why doing the unnecessary thing was actually the point.

What the thing does

It's called the Travel & Weather Guide. You type in a city Lisbon, Kyoto, wherever and it gives you back four things: a couple of sentences on what the place is known for, the live weather right now, what people tend to do there this time of year, and a straight verdict on whether now is a good time to visit.

It runs two ways. A web page with a search box:

The Travel & Weather Guide web UI:

And a terminal version, for when you want to feel like a hacker while asking about the weather in Bali:

The CLI starting up, printing "Travel & Weather Guide (type exit to quit)" and prompting for a city name]

Both talk to the same agent underneath. The weather itself comes from Open-Meteo, which is free and needs no key. The "thinking" comes from a model via the OpenAI Agents SDK.

How it actually works (spoiler: not MCP)

The interesting part is how the model gets the weather, because it doesn't. The model can't make an HTTP request or run code, it can only generate text. So instead of fetching anything itself, it asks an internal tool to do it, and waits for the answer.
In the SDK that looks like this:

export const getWeather = tool({
  name: 'get_weather',
  description: 'Fetch current weather for a given city using Open-Meteo.',
  parameters: z.object({
    city: z.string().describe('The city or town name to check weather for'),
  }),
  execute: async ({ city }) => {
    // geocode the city, then hit the forecast endpoint
    // ...return "Lisbon, Portugal: 24°C, wind 12 km/h"
  },
});

That tool() wrapper turns my Zod schema into a description the model can read. So now the model knows a get_weather(city) function exists — but it can't run it. It can only ask.

The loop goes like this:

You ask about Lisbon.
The model thinks, "I need weather data," and emits a structured tool call: get_weather({ city: "Lisbon" }). No code has run yet. That's just the model raising its hand.
The SDK's runner sees the request, runs my actual JavaScript function locally, and that function makes the plain fetch to Open-Meteo.
The result gets handed back to the model.
The model writes the final answer using that data.

People sometimes assume this is MCP. It isn't. MCP is for tools that live in a separate server you connect to over a protocol. This tool is just a function in my own process. The model requests, my code runs, the result goes back. All in-memory, one repo, no protocol.

The uncomfortable part

Look at that loop again. To tell you it's 24°C in Lisbon, the system:

sends the full conversation and tool definitions to a model,
waits for the model to decide it wants the weather,
runs the fetch I could have run in the first place,
sends everything back to the model,
waits again while it writes a paragraph.

Two model round-trips and a pile of tokens, wrapped around a single HTTP call that a first-week bootcamp student could write. The fetch was always the easy part. I built a very expensive middle manager to decide when to make it.

And here's the thing: this isn't just my weird little project. It's the whole moment we're in.

Everything is becoming an agent now

There's a quiet shift happening. A lot of things that used to be a function call, a cron job, or an if statement are being rebuilt as agents. Not because the old way stopped working. The old way is fast and basically free. It's just that "agent" is the shape everything wants to be right now.

Some of that is genuinely good. When a task is fuzzy, open-ended, needs judgment, or strings together tools in ways you can't predict up front, an agent earns its tokens. That's the real use case, and it's legitimately new.

But a lot of it is us wrapping perfectly deterministic problems in a probabilistic, token-metered layer because it feels like the future. We took things that were already solved and made them "smart," which mostly means slower, pricier, and occasionally confidently wrong about the weather. The wins are real. So is the tax. Both things are true at the same time, and nobody wants to say the second one out loud.

My weather agent is a tiny, honest monument to that tax. It is a fetch cosplaying as artificial intelligence.

So why did I build it?

Not to solve a world problem. Let's be very clear. Nobody was out there suffering from a lack of AI-narrated weather. Climate change did not get one degree cooler because my agent can tell you it's warm in Lisbon.

I built it because I did not want to be the guy who talks about agents at parties without having actually built one. You know that guy. I refuse to become that guy.

The agentic era is happening whether I have opinions about tokens or not.

Turns out the best way to understand the expensive absurdity of the agentic era is to commit a small, cheerful act of it yourself.

So no, you should not build an agent to check the weather. You should just call the API.

I, however, have now called the API. Through an agent. On purpose. And I regret nothing, except slightly the tokens. Cheers

Try it yourself

The code is on GitHub: Dakudbilla/openai-travel-weather-agent.

# clone and install
git clone https://github.com/Dakudbilla/openai-travel-weather-agent.git
cd openai-travel-weather-agent
npm install

# add your OpenAI key
cp .env.example .env      # then paste your key into .env: OPENAI_API_KEY=sk-...

npm start                 # web app → http://localhost:3000
npm run cli               # or the terminal version

The weather data is free (Open-Meteo, no key), so the only thing you'll pay for is the tokens.You can get a free openai account generate the API key for it.

Happy Coding

How to Push to a Private GitHub Repository Using a Fine-Grained Personal Access Token

Daniel Akudbilla — Sat, 29 Mar 2025 12:39:25 +0000

If you have an existing local Git repository and need to push it to a private GitHub repository, but GitHub is rejecting your credentials, you may need to use a fine-grained personal access token (PAT). This guide will walk you through the process step by step.

Step 1: Generate a Fine-Grained Personal Access Token (PAT)

GitHub has moved away from password authentication for Git operations, so you must use a personal access token (PAT) instead.

1.1 Navigate to GitHub Settings

Go to GitHub Personal Access Tokens.
Click on "Generate new token (fine-grained)".

1.2 Configure Token Permissions

Repository Access: Select the specific repository you want to push to.
Permissions:
- Under "Repository permissions," set "Read and Write" access for "Contents."
Expiration: Choose an expiration date or select "No expiration" (not recommended for security reasons).
Click "Generate token" and copy the token immediately (you won’t see it again).

Step 2: Set the Remote URL with the PAT

Now, update your Git remote URL to authenticate using the token.

2.1 Navigate to Your Local Repository

Open a terminal and move to your project directory:

cd /path/to/your/local/repository

2.2 Update the Remote URL

Run the following command, replacing {your-personal-token}, {github_username}, and {private-repo-name} accordingly:

git remote set-url origin https://{your-personal-token}@github.com/{github_username}/{private-repo-name}.git

Note: The token will be stored in your Git configuration. For security reasons, it’s best to use a Git credential manager instead of embedding it in the URL.

Step 3: Push Your Code to GitHub

3.1 Add and Commit Changes

If you haven’t already committed your changes, do so:

git add .
git commit -m "Initial commit"

3.2 Push to the Private Repository

Now, push your code to GitHub:

git push -u origin main

If everything is set up correctly, your repository should now be updated on GitHub.

Step 4: Verify Your Push

Go to your GitHub repository and refresh the page. You should see your files successfully pushed.

Optional: Use a Credential Manager for Better Security

Instead of storing your token in the remote URL, you can configure a credential manager to securely store and automatically use your token when needed.

For macOS:

git credential-osxkeychain

For Windows:

git credential-manager-core

For Linux:

git credential-store

Then, configure Git to use the credential manager:

git config --global credential.helper store

This way, you won’t need to include your token in the remote URL manually.

Conclusion

By following these steps, you should be able to push to a private GitHub repository using a fine-grained personal access token. This method ensures secure authentication without exposing your GitHub password. Always remember to keep your access tokens safe and use GitHub's credential storage features for added security.

Cloning a Private GitHub Repository Using HTTPS

Daniel Akudbilla — Mon, 03 Mar 2025 20:52:56 +0000

If you're here, you're either struggling to clone a private GitHub repository or simply trying to learn how. Let's dive straight into the solution.
You have encountered this error
Cloning into 'repo_name'... remote: Write access to repository not granted. fatal: unable to access 'https://github.com/username/repo_name.git/': The requested URL returned error: 403

Step 1: Generate a Personal Access Token (PAT)

To clone a private repository using HTTPS, you need a Personal Access Token (PAT) instead of a password. Follow these steps to generate one:

1. Log in to GitHub

Go to GitHub and sign in to your account.
Click on your profile picture in the top-right corner.
Select Settings.

2. Navigate to Developer Settings

Scroll down and click on Developer settings (found in the left sidebar).
Under Personal access tokens, select Fine-grained tokens.
Click Generate new token.

3. Configure the Token

Name the token (e.g., GitHub Repo Access).
Select the resource owner: Choose your GitHub username (or your organization if cloning an organization repo).
Set an expiration date: Choose an appropriate duration for security purposes.
Repository access:
- Select All repositories (if you want access to all your repos).
- Recommended: Select only the specific repositories you need access to.
Permissions:
- Under Repository permissions, find Contents and set it to Read and Write.
- Find Administration and set it to Read and Write.
- Grant additional permissions as needed.

4. Generate and Copy the Token

Click Generate Token.
Important: Copy the generated token and store it securely, as it will not be shown again.

Step 2: Clone the Private Repository

With your Personal Access Token (PAT) ready, follow these steps to clone your private repository:

1. Open Your Terminal

On Windows, use Git Bash or Command Prompt.
On Mac/Linux, use the Terminal.

2. Run the Clone Command

Use the following command to clone your repository:

git clone https://USERNAME:TOKEN@github.com/USERNAME/REPOSITORY_NAME.git

Replace:

USERNAME → Your GitHub username
TOKEN → Your generated Personal Access Token
REPOSITORY_NAME → The name of your repository

Example:

git clone https://johnDoe:ghp_ABC123xyz@github.com/johnDoe/my-private-repo.git

If everything is correct, your repository should start cloning successfully.

Final Thoughts

I personally struggled with this issue for a while and decided to share my findings after thorough research. I hope this guide helps you avoid the same frustration. If you found this useful, share it with others who might need it!

🚀 Happy coding!