How I Became Bullish on AI

Ironically, I wasn't initially keen on using AI in my day-to-day work. That changed after a workshop with Google's team at their Bengaluru HQ. We got hands-on with Gemini 2.5 agents and sub-agents, building end-to-end workflows and seeing how these systems actually operate in practice.

Watching an LLM work and then hallucinate, self-correct, and still produce usable output, felt genuinely magical. (Maybe that's why AI icons are always the ✨ emoji.)

That experience flipped a switch. I went from being skeptical to genuinely excited, enough to later run a workshop within my team on writing tests with AI.

How AI Entered My Workflow

I started this journey back when neither ChatGPT nor Gemini had the strongest coding agents. Claude was the go-to, though it certainly made mistakes. My manager, gauging my potential to pick things up quickly, gave me the opportunity to take on a few backend tasks.

AI helped me:

• Grasp existing coding practices
• Navigate domain architecture
• Build context around the business logic of the repository

For my first task, I tried to one-shot the feature using Claude. And it worked! The feature ran, passed tests, and I raised a PR.

That's when reality hit.

A senior backend engineer reviewed the PR and flagged multiple issues: design flaws, optimizations, and edge cases that Claude (and I) had missed.

That's when it clicked:

Vibe-coded code is only as good as the reviewer promoting it.

Learning the Hard Way (and the Right Way)

Back to the drawing board.

Over the next few PRs, I went through heavy reviews: long comment threads, deep discussions, and constant back-and-forth. Painful, but invaluable. It forced me to understand not just what the AI suggested, but where its limits were.

What AI did exceptionally well was reduce the learning barrier.
What it didn't do was replace judgment.

As I absorbed feedback and improved, I started shipping faster, not because AI wrote more code, but because I understood the system better.

The Bigger Shift

AI is quietly making programmers multi-stack.

With my frontend background and my growing backend understanding, I can now own features end to end, from UI to API to data flow. AI blurred the boundaries between stacks just enough to make that possible.

But one thing hasn't changed.

AI can review syntax.
AI can suggest patterns.
AI can even refactor.

What it cannot do (yet) is develop intuition:

• How systems behave at scale
• Which trade-offs protect uptime
• What decisions will hurt six months later

That's still human territory.

And that's where seniors... at least for now... still have the upper hand. 😄

Takeaways

• AI reduces the learning barrier across stacks, but doesn't replace engineering judgment
• Code reviews on AI-generated code are where the real learning happens
• Multi-stack fluency comes from understanding systems, not from generating more code

Why are we using nextJS’s API route to fetch our data?

Why use Next.js API routes?

• Server-Side Security: Sensitive credentials like client_id, client_secret, and refresh_token stay server-side, never exposed to the browser
• Token Management: Token refreshing logic is handled securely and transparently without involving the client
• Caching and Optimizations: Server-side requests enable s-maxage and stale-while-revalidate for better performance
• Centralized Data Fetching: All client requests go through a central point, allowing better control over logging

Service Architecture

Step One: Sign up as a Spotify Developer

To access your Spotify data and communicate with Spotify’s servers, you’ll need some tokens. Here’s how you can generate them:

1. Head over to Spotify for Developers and sign in with your Spotify account to register as a developer.

2. Click the Create App button and fill in the required details. Here’s an example to guide you.

   

3. Now, go to the project you just created and make sure to note down the Client ID and Client Secret. You'll need these for authentication.

   

4. You should now have the following::

SPOTIFY_CLIENT_ID=<Client ID>
SPOTIFY_CLIENT_SECRET=<Client secret>

StepTwo: Generating a Refresh Token for the Spotify API

We'll need to generate a refresh token for our API so that each time a user visits the site, a new access token is created to access our Spotify data. Spotify uses the OAuth 2.0 authorization framework for this process. You can dive deeper into the details here: OAuth 2.0 Documentation.

1. To generate the authorization code with permissions to access your now-playing and top-songs data, open the following URL in your browser after replacing <SPOTIFY_CLIENT_ID> with your actual client ID:

   https://accounts.spotify.com/authorize?client_id=<SPOTIFY_CLIENT_ID>&response_type=code&redirect_uri=http%3A%2F%2Flocalhost:3000&scope=user-read-currently-playing%20user-top-read
   
   Note: Keep the same redirect_uri as the one in your spotify dashboard.
   

2. You’ll be redirected to the redirect_uri you configured, and the query parameter code will be attached to the URL. This code is what we’ll need to generate your SPOTIFY_REFRESH_TOKEN.

   Example:
   http://localhost:3000/?code=AQCU5snB4rmSCKyvhWOQOEcvqsYFy17n_PcDOdoMwDVPJs
   

3. Head over to Base64 Encode to generate your encoded base64 string. You'll need to encode your <SPOTIFY_CLIENT_ID>:<SPOTIFY_CLIENT_SECRET> in this format.

   Encode your string in the format:
   SPOTIFY_CLIENT_ID:SPOTIFY_CLIENT_SECRET
   
   Note: Don't forget the ":" in between the values!
   

4. Final Step: Open Postman or Insomnia and paste the following cURL command. Make sure that the redirect_uri and code match the ones from the previous steps

   curl --request POST \
     --url https://accounts.spotify.com/api/token \
     --header 'Authorization: Basic <YOUR_BASE64_STRING>' \
     --header 'Content-Type: application/x-www-form-urlencoded' \
     --data redirect_uri=http%3A%2F%2Flocalhost:3000 \
     --data grant_type=authorization_code \
     --data code=<YOUR_AUTHORIZATION_CODE>
   

5. And, now you’ll have the SPOTIFY_REFRESH_TOKEN with the response JSON:

   {
     "access_token": "BQCE8nQzic.....rHNr",
     "token_type": "Bearer",
     "expires_in": 3600,
     "refresh_token": "AQC....c5UgIxSpl8EA",
     "scope": "user-read-currently-playing user-top-read"
   }
   

StepThree: Writing our fetcher functions

Now let's write our fetcher functions that will handle the Spotify API requests, using the SPOTIFY_REFRESH_TOKEN to generate an access token and fetch the necessary data.

1. Store the Spotify Tokens in the .env file of your nextJS project:

   SPOTIFY_CLIENT_ID=<Client ID>
   SPOTIFY_CLIENT_SECRET=<Client secret>
   SPOTIFY_REFRESH_TOKEN=<refresh_token>
   

Never commit your .env file. Make sure it's in your .gitignore.

2. Create a spotify.ts file inside of your nextJS project, I prefer the path to be /src/lib and we’ll define our Spotify data-fetching functions here:
   1. getAccessToken ⇒ Retrieves a new access token using the refresh token.
   2. fetchFromSpotify ⇒ Utilizes the access token to fetch data from Spotify.

import querystring from 'querystring'

const client_id = process.env.SPOTIFY_CLIENT_ID
const client_secret = process.env.SPOTIFY_CLIENT_SECRET
const refresh_token = process.env.SPOTIFY_REFRESH_TOKEN

const basic = Buffer.from(`${client_id}:${client_secret}`).toString('base64')
const TOKEN_ENDPOINT = 'https://accounts.spotify.com/api/token'

const ENDPOINTS = {
  nowPlaying: 'https://api.spotify.com/v1/me/player/currently-playing',
  topTracks: 'https://api.spotify.com/v1/me/top/tracks',
  topArtists: 'https://api.spotify.com/v1/me/top/artists',
}

const getAccessToken = async () => {
  const response = await fetch(TOKEN_ENDPOINT, {
    method: 'POST',
    headers: {
      Authorization: `Basic ${basic}`,
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: querystring.stringify({
      grant_type: 'refresh_token',
      refresh_token,
    }),
  })

  const data = await response.json()
  return data.access_token
}

const fetchFromSpotify = async (endpoint: string) => {
  const access_token = await getAccessToken()
  return fetch(endpoint, {
    headers: {
      Authorization: `Bearer ${access_token}`,
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=30',
    },
  })
}

export const getNowPlaying = async () => fetchFromSpotify(ENDPOINTS.nowPlaying)
export const getTopTracks = async () => fetchFromSpotify(ENDPOINTS.topTracks)
export const getTopArtists = async () => fetchFromSpotify(ENDPOINTS.topArtists)

StepFour: Serving the Data Using Next.js API Routes

Now we’ll use Next.js API routes to serve the Spotify data. This allows you to securely fetch the data on the server-side and return it to your frontend.

Now Playing - /api/playing

Create a file at /src/app/api/playing/route.ts, which will generate an endpoint at /api/playing. We'll set the revalidation interval to 120 seconds, which is more than enough to keep the currently playing song updated.

import { getNowPlaying } from '@/lib/spotify'

type Artist = { name: string }

export const revalidate = 120

export async function GET() {
  const response = await getNowPlaying()

  if (!response.ok || response.status === 204) {
    return Response.json({ isPlaying: false })
  }

  const song = await response.json()
  const item = song.item

  if (!item) {
    return Response.json({ isPlaying: false })
  }

  const { is_playing: isPlaying } = song
  const { name: title, album, artists, external_urls } = item
  const artist = artists.map((artist: Artist) => artist.name).join(', ')
  const albumImageUrl = album.images[0]?.url
  const songUrl = external_urls.spotify

  return Response.json({
    album: album.name,
    albumImageUrl,
    artist,
    isPlaying,
    songUrl,
    title,
  })
}

Spotify Documentation for the API: https://developer.spotify.com/documentation/web-api/reference/get-the-users-currently-playing-track

Top Tracks - /api/tracks

Create a file at /src/app/api/tracks/route.ts, which will provide an endpoint at /api/tracks. We'll configure the revalidation interval to 86,400 seconds (1 day), since this data doesn't need frequent updates.

import { getTopTracks } from '@/lib/spotify'

type Artist = { name: string }

type Track = {
  artists: Artist[]
  external_urls: { spotify: string }
  name: string
}

export const revalidate = 86400

export async function GET() {
  const response = await getTopTracks()
  const { items } = await response.json()

  const tracks = items
    .slice(0, 10)
    .map(({ artists, external_urls, name }: Track) => ({
      artist: artists.map((artist) => artist.name).join(', '),
      songUrl: external_urls.spotify,
      title: name,
    }))

  return Response.json({ tracks })
}

Spotify Documentation for the API: https://developer.spotify.com/documentation/web-api/reference/get-users-top-artists-and-tracks

StepFive: Consuming the data on the Frontend

On any page where you want to use this API, you can call the endpoint as shown in the following example:

import { SimpleLayout } from '@/components/SimpleLayout'

export const revalidate = 60 * 60 * 24

export default async function Stats() {
  const response = await fetch(`${process.env.NEXT_PUBLIC_SITE_URL}/api/tracks`)
  const data: TopTracks = await response.json()

  return (
    <SimpleLayout
      title="Music"
      intro="My current jam? Got it listed right here!"
    >
      // Your components here
    </SimpleLayout>
  )
}

Also, don’t miss the footer for a live update of what I’m currently listening to!

Enter Github Actions

Well I did know about Github Actions, because every repo has a tab called Actions and I did my basic research for it. At this point I was intrigued, I grabbed my coffee at 2pm and started reading the docs and a few blogs on how I can approach the problem.

4 hours in, I had come across a solution via youtube, but it didn't work. It was a sign I was going to struggle with Github Actions for a long time, and I liked the challenge. I started hot-swapping code to see if I was missing something, rechecked my .env variables and still no success.

I pulled myself back at night, it was time to slow down and think over the problem instead of trying my luck. I watched a couple of youtube videos to better grasp at the concept. Here's the summary for you!

Wind down and think about a problem when you can't fix it!

What is Github Actions?

In a sentence, Github Action is a tool which will automate your development process. It lets you build, test, and deploy your code right from GitHub. You can also assign code reviews, manage branches, and place issues the way you want with actions.

Why do we need it?

Well, to save time. Get freedom from doing repetitive tasks. One such use-case I read about was about onboarding a new member to an open source project. Say a new member joins your open source project. Using Github actions, we can greet him, send him the contributing guidelines and resources based on the project. Another such use case is setting up your custom solution for CI/CD or testing the latest commit.

Github Actions is super flexible to your needs.

How does it work?

Github actions are stored inside the /.github/workflows and are written in .yaml format. Here are the three pillars of Github Actions, collectively, these three pillars would make up most of the workflow.

1. Name

   You can set the display name for your workflow by using name syntax. If you don't set any name, the default name would be the file's name.

   name: Test-Actions
   

2. On (Trigger)

   on is a trigger for the Github Action to run. You can set your action to run on specific events like push to a branch, a new issue being created or a new pull request has just come in!

   on: push
   

   on: issues
   

   on: pull_request
   

3. Jobs

   Now we know what triggers a Github Action, how do we tell it to process something? We use the jobs keyword. There can be multiple 'Mini Jobs' under a job. Each job definition runs-on and steps are required.

   jobs:
     first-job:
       name: This job will run first
       runs-on: ubuntu-latest
       steps:
         - name: Prints a greeting
           run: |
             echo Hello World - ❤ Github Actions
   

How I Implemented it for my portfolio website!

Google, Docs, Open Source, Youtube to the rescue!

Declaration of Action

name: github pages

on:
    push:
		branches:
		- development

I declared my Github Action with the name "github pages". And I added a trigger to run this action whenever I commit to the development branch of my repo.

Setting up the job

jobs:
  deploy:
    runs-on: ubuntu-18.04

I gave the name deploy to the job and then set it to run of v18.04 of Ubuntu on Github's Servers. After that, came to write the steps for the actions.

steps:
	- uses: actions/checkout@v2

	- name: Setup Node
	uses: actions/setup-node@v2.1.2
	with:
		node-version: "14.x"

	- name: Cache dependencies
	uses: actions/cache@v2
	with:
		path: ~/.npm
		key: ${{ runner.os }}-node-${{ hashFiles('\*\*/package-lock.json') }}
	restore-keys: |
		${{ runner.os }}-node-

	- run: npm install
	- run: npm run build

	- name: Deploy
	uses: peaceiris/actions-gh-pages@v3
	with:
		github\_token: ${{ secrets.GITHUB\_TOKEN }}
		publish\_branch: master

Let's break down the code,

1. actions/checkout@v2

actions/checkout is an open-source code by github where it checks out your current repo so that the workflow is able to access it. Basically, it fetches all the branches and commits which are present in your repo, and allows you to perform tasks on them.

2. actions/setup-node@v2 With this mini job, I've specified a node version on which the upcoming npm commands would take place on Github's Server.

   • node-version - is used to set the version of node to be used.

3. actions/cache@v2 This action allows caching dependencies and build outputs to improve workflow execution time.

   • path - A list of files, directories, and wildcard patterns to cache and restore.
   • key - An explicit key for restoring and saving the cache.
   • restore-keys - An ordered list of keys to use for restoring the cache if no cache hit occurred for key
   • Via the docs

4. npm install This command installs on the dependencies required for the codebase to run.

5. npm run build This command builds the project and makes it ready for deployment.

6. peaceiris/actions-gh-pages@v3 It's the Github Action I'm using to deploy the files generated in the previous step to the master branch in my repo. (Power of Open Source + Abstraction!)

   • github_token - Shh it's a secret token which grants access to the repo.
   • publish_branch - It's the target branch for the built files to be pushed.

Conclusion

After a day since I took up the challenge, I was able to automate my deployment process! With the time I spent learning github actions, I'm sure I've become pretty good at making up my own Github Actions. If you have found this useful, please consider recommending and sharing it with other fellow developers!

You can check the gh-pages.yml file mentioned in the blog here.