DEV Community: G Ghuman

New advancements in Generative AI

G Ghuman — Thu, 03 Sep 2026 11:11:41 +0000

New advancements in Generative AI

If you spent last year fine-tuning massive language models just to get decent JSON output, you already know how exhausting the state of the art was. Every project felt like you were wrestling a very smart, very expensive toddler.

Things have shifted. The narrative around generative AI has moved away from "look how big this model is" to "how do we make this thing actually reliable in production?" We aren't just prompting text boxes anymore. We're chaining agents, running smaller models locally, and dealing with structured outputs that don't randomly break at 3 AM because the LLM decided to get creative.

Here is what actually matters right now if you are building software with these tools.

1. Native Structured Outputs

For a long time, forcing an LLM to return valid JSON meant writing elaborate system prompts, crossing your fingers, and wrapping your parser in a brutal try/catch block. Even then, you'd eventually hit a day where the model felt like dropping a trailing comma or throwing a markdown code block inside your raw data.

Most major providers now support native structured outputs via JSON schema enforcement at the API level. The model literally cannot sample tokens that violate your schema.

Here is how you actually use this with the OpenAI Python SDK now, without praying to the probabilistic gods:

import os
from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))


class CodeReview(BaseModel):
    summary: str = Field(description="One sentence summary of the code quality")
    bugs_found: list[str] = Field(
        description="List of potential bugs or security flaws"
    )
    rating: int = Field(description="Rating from 1 to 10")


completion = client.beta.chat.completions.parse(
    model="gpt-4o-mini",
    messages=[
        {
            "role": "system",
            "content": "You are a senior code reviewer. Analyze the provided snippet.",
        },
        {"role": "user", "content": "print('Hello World') # TODO: add database"},
    ],
    response_format=CodeReview,
)

review = completion.choices[0].message.parsed
print(f"Rating: {review.rating}/10")
print(f"Bugs: {review.bugs_found}")

This saves you from writing custom validation loops. If the model's generation drifts, the API handles the rejection loop on their end.

2. Small Language Models (SLMs) Are Eating the World

Stop reaching for GPT-4 to classify support tickets. Seriously.

The biggest operational shift in the past six months isn't a new breakthrough in reasoning; it's that 8B and 7B parameter models (like Llama 3 or Mistral) got uncomfortably good. Running an 8-billion parameter model locally via Ollama or vLLM gives you sub-second latency, zero data privacy headaches, and a hosting bill that doesn't terrify your CFO.

I spent a weekend trying to migrate a simple text-categorization pipeline from a hosted API to a local Llama 3 instance. The setup looks something like this:

import json
import urllib.request

# Assuming you have Ollama running locally: ollama run llama3
url = "http://localhost:11434/api/generate"

payload = {
    "model": "llama3",
    "prompt": "Classify this support ticket as 'Billing', 'Tech', or 'General': 'My credit card was charged twice.'",
    "stream": False,
    "format": "json",
}

req = urllib.request.Request(
    url,
    data=json.dumps(payload).encode("utf-8"),
    headers={"Content-Type": "application/json"},
)

with urllib.request.urlopen(req) as response:
    result = json.loads(response.read().decode("utf-8"))
    print(result["response"])

The gotcha here? Context windows and prompt sensitivity. Smaller models are like brilliant interns. They are fast and cheap, but if you don't give them exact instructions with clear boundaries, they will wander off into the weeds much faster than a 400B parameter model. You have to prompt them tighter.

3. Tool Use and Function Calling Got Boring (In a Good Way)

Function calling used to feel like a fragile science experiment. You'd define a bunch of JSON schemas, parse the tool call response, execute your local database query, and feed the result back into the chat. Half the time, the model would hallucinate arguments that didn't exist in your schema.

Frameworks have matured, but more importantly, the base models learned how to use tools natively without needing giant orchestration frameworks holding their hands.

The biggest trap I fell into when learning this? Over-engineering agent loops. I tried building complex multi-agent setups using heavy orchestration libraries before I had a single stable tool call working. It was a debugging nightmare. Circular loops, infinite token burns, and zero visibility into why the agent decided to call the weather API three times in a row.

Start simple. Write a single function, bind it to the model, and handle the execution loop yourself in plain code before you introduce any agent frameworks.

# The mental model: handle tool execution explicitly
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_user_timezone",
            "description": "Get the timezone for a given user ID",
            "parameters": {
                "type": "object",
                "properties": {
                    "user_id": {"type": "string"},
                },
                "required": ["user_id"],
            },
        },
    }
]

# When the model responds with a tool_call, you run your standard Python function
# and send the result back in a follow-up message. No magic required.

When you write the execution loop yourself, you realize that "agents" are really just while loops with good marketing. Demystifying that changes how you architecture your apps.

Where to go from here

Don't try to master all of this at once. Pick a small, annoying utility script in your current codebase—something where you're currently regex-parsing messy text or writing brittle validation logic.

Spin up a local SLM using Ollama, or rewrite one of your API calls to use native Pydantic schema validation. See how much code you can delete.

New advancements in Generative AI

G Ghuman — Mon, 24 Aug 2026 12:02:52 +0000

New advancements in Generative AI

Most AI tutorials start with a 500-word essay about how Alan Turing would be so proud of our current chat bots. Let's skip that.

If you've spent any time building with LLMs over the last year, you already know the core frustration: models are great at generating text tokens in a vacuum, but the second you ask them to interact with a real system, they hallucinate function arguments, forget state, or run out of context window right when things get interesting.

The landscape has shifted past basic prompt engineering. We're moving away from giant, monolithic prompts toward structured reasoning loops, native tool use, and smaller models that punch way above their weight. Here is what actually matters right now if you're building software with AI.

Structured Outputs Without Losing Your Mind

For a long time, getting JSON back from an LLM meant writing a desperate system prompt ("YOU MUST RETURN ONLY VALID JSON OR ELSE") and praying the model didn't add a conversational markdown wrapper at the end anyway. Your parser would inevitably crash at 3:00 AM on a Saturday because the model decided to include a friendly trailing comma.

Major providers finally fixed this at the API level. Instead of hoping the model formats text correctly, you can now enforce a JSON schema directly at the decoding step. The model physically cannot generate tokens that violate your schema.

Here is how you actually do it using the official OpenAI client in Python. No regex hacks required.

import os
from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

# Define what you actually want back using Pydantic
class CodeReview(BaseModel):
    summary: str = Field(description="One sentence summary of the code quality")
    severity_score: int = Field(description="Score from 1 to 10 on how broken this is")
    refactored_code: str = Field(description="The fixed version of the code")

completion = client.beta.chat.completions.parse(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "You are a ruthless senior code reviewer."},
        {"role": "user", "content": "Review this: `print(x)` where x is undefined."}
    ],
    response_format=CodeReview,
)

# This is a Pydantic object, not a raw string you have to json.loads()
result = completion.choices[0].message.parsed

print(f"Severity: {result.severity_score}/10")
print(f"Fix:\n{result.refactored_code}")

The gotcha here: structured outputs take more compute on the provider's end. Your latency will go up slightly, and if your Pydantic schema is unnecessarily nested with ten levels of optional fields, the API will occasionally throw a 400 error because the constrained decoding path got too complex. Keep your schemas flat.

Local Models Are Actually Usable Now

A year ago, running an open-weight model locally on your laptop felt like watching a slideshow rendered on a Game Boy. Llama 3 and its successors changed that. You can now run a 7B or 8B parameter model locally via Ollama that handles basic classification, entity extraction, and simple code generation fast enough to use in a local development loop without burning through API credits.

This matters for data privacy, obviously, but it also matters for cost and latency when you're processing high-volume, low-complexity tasks.

Here is a quick script to hit a local Ollama instance using the standard OpenAI-compatible endpoint. You don't even need a new SDK.

from openai import OpenAI

# Point the client at your local Ollama instance
client = OpenAI(
    base_url='http://localhost:11434/v1',
    api_key='ollama', # required, but can be anything
)

response = client.chat.completions.create(
    model="llama3",
    messages=[
        {"role": "system", "content": "Extract all email addresses from the text. Return a comma-separated list."},
        {"role": "user", "content": "Reach out to support@example.com or admin@test.org for help with the migration."}
    ],
    temperature=0.0
)

print(response.choices[0].message.content)

The reality check: don't expect an 8B local model to write a full microservice architecture from scratch. It will hallucinate imports, forget context after a few thousand tokens, and occasionally get stuck in loops if you set the temperature too high. Use local models for narrow, bounded tasks where failure is cheap and easy to catch.

Agentic Loops and Tool Use

The biggest shift in how we architect AI applications isn't about the model getting smarter—it's about the scaffolding we build around it. Instead of a single prompt-response cycle, modern architectures use loops where the model can inspect its own output, call external tools, and iterate until a condition is met.

Frameworks like LangChain tried to abstract all of this away, and honestly, they created more abstraction layers than most codebases needed. I spent three days debugging a LangChain agent before throwing it out and writing 50 lines of plain Python using native tool calling.

When you write the loop yourself, you can actually see what the model is doing:

import json
import requests
from openai import OpenAI

client = OpenAI()

def get_current_weather(location):
    """Get the current weather for a given city."""
    # Dummy implementation for illustration
    return json.dumps({"location": location, "temperature": "72F", "condition": "Partly Cloudy"})

# Map available tools to their Python functions
available_tools = {
    "get_current_weather": get_current_weather
}

tools = [{
    "type": "function",
    "function": {
        "name": "get_current_weather",
        "description": "Get the current weather for a given city",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {"type": "string", "description": "The city and state, e.g. San Francisco, CA"}
            },
            "required": ["location"]
        }
    }
}]

def run_conversation():
    messages = [{"role": "user", "content": "What's the weather like in Seattle right now?"}]

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=tools,
        tool_choice="auto",
    )

    response_message = response.choices[0].message

    # Check if the model wants to call a tool
    if response_message.tool_calls:
        messages.append(response_message)

        for tool_call in response_message.tool_calls:
            function_name = tool_call.function.name
            function_to_call = available_tools[function_name]
            function_args = json.loads(tool_call.function.arguments)

            # Execute our local function
            tool_output = function_to_call(**function_args)

            messages.append({
                "tool_call_id": tool_call.id,
                "role": "tool",
                "name": function_name,
                "content": tool_output,
            })

        # Second round: Send the tool output back to the model so it can answer the user
        second_response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages
        )
        return second_response.choices[0].message.content

print(run_conversation())

The hard part here isn't the code. The hard part is managing infinite loops when the model decides it needs to call the same tool four times in a row because it didn't parse the output correctly. Always set a hard iteration limit (max_loops = 5) on any agentic workflow you write.

Context Windows Are Great, But Watch Your Costs

We now have models that accept millions of tokens of context. You can drop an entire codebase into a prompt and ask questions about it. It feels like magic the first time you do it.

Just remember that with most API providers, you pay for the entire context window on every single request in a conversation thread if you're passing history back and forth. If your context balloons to 100k tokens and you chat back and forth ten times, you are burning through budget fast for simple queries.

Use large context windows for specific ingestion tasks—like summarizing a massive PDF or analyzing a dump of logs—and prune your message histories ruthlessly for standard chat interfaces.

Next Steps

Don't try to build a complex autonomous agent right away. Download Ollama, pull llama3, and write a simple script that uses Pydantic structured outputs to parse messy text input into a clean database record. See where the model fails, adjust your schema, and go from there.

New advancements in Generative AI

G Ghuman — Mon, 24 Aug 2026 11:35:40 +0000

New advancements in Generative AI

Most AI tutorials start with a ten-paragraph philosophical essay on whether machines can think. Let's skip that. If you are a developer trying to build something useful, you already know the limitations of what we had six months ago: models that hallucinate database schemas, context windows that drop your system prompt the moment things get interesting, and orchestration frameworks that feel like Rube Goldberg machines written in Python.

Things have shifted. Not in a "singularity is near" way, but in a "you can actually build reliable features with this now" way.

Here is what is actually worth paying attention to right now, minus the marketing hype.

1. Native Structured Outputs (Because JSON mode was a lie)

Remember trying to get an LLM to return valid JSON six months ago? You would wrap your prompt in desperate markdown: “Return ONLY valid JSON, no markdown blocks, no conversational filler, or the kittens get it.”

And then it would return

```json followed by a trailing comma on the last key-value pair, crashing your parser in production at 2 AM.

We finally moved past hoping for the best. Modern APIs now support native constrained decoding. You pass a JSON schema (or a Pydantic model in Python), and the model's token sampling mask is physically restricted at the logit level to only output tokens that conform to that schema. It literally cannot hallucinate an invalid structure because the illegal tokens don't exist in its vocabulary at that step.

Here is what that looks like using the standard OpenAI client with Pydantic:


python
import os
from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

class CodeReview(BaseModel):
    summary: str = Field(description="One sentence summary of the code quality")
    bugs_found: list[str] = Field(description="List of potential bugs or edge cases")
    rating: int = Field(description="Score from 1 to 10", ge=1, le=10)

completion = client.beta.chat.completions.parse(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "You are a code reviewer."},
        {"role": "user", "content": "Review this: `x = [i for i in range(10)]`"}
    ],
    response_format=CodeReview,
)

review = completion.choices.message.parsed

# This is a real Python object, not a string you have to json.loads()
print(f"Rating: {review.rating}/10")
print(f"Bugs: {review.bugs_found}")

The gotcha here? It is still slow compared to raw text generation because the API has to validate the state machine transitions for every single token. If you're building a real-time UI, set your expectations (and loading spinners) accordingly.

2. Local Function Calling That Doesn't Require a PhD

For a long time, running function calling locally meant wrestling with LlamaCpp grammar files or writing hundreds of lines of regex glue code to parse model output into actual function arguments.

Open-weight models like Llama 3 and Mistral have baked tool-calling syntax directly into their chat templates. If you are running models locally via Ollama, you can hand off a JSON schema of your local functions, and the model will spit back a structured tool call payload.

Here is a quick Node.js snippet using the official Ollama library to fetch local weather:


javascript
import ollama from 'ollama';

const tools = [{
  type: 'function',
  function: {
    name: 'get_current_weather',
    description: 'Get the current weather for a city',
    parameters: {
      type: 'object',
      properties: {
        location: { type: 'string', description: 'City and state, e.g. San Francisco, CA' },
      },
      required: ['location'],
    },
  },
}];

async function run() {
  const response = await ollama.chat({
    model: 'llama3',
    messages: [{ role: 'user', content: 'What is it like outside in Tokyo right now?' }],
    tools: tools,
  });

  if (response.message.tool_calls) {
    for (const tool of response.message.tool_calls) {
      console.log(`Model wants to call function: ${tool.function.name}`);
      console.log(`With arguments:`, tool.function.arguments);
      // Here is where you actually execute your local function
    }
  } else {
    console.log(response.message.content);
  }
}

run();

What tripped me up the first time I set this up: local models are notoriously bad at knowing when to use a tool versus when to just answer the question. If your prompt isn't explicit, Llama 3 might try to invent weather data on its own instead of triggering the tool call. Write strict system prompts.

3. The Death of the Massive Vector DB (For 90% of Use Cases)

A year ago, every tutorial on earth insisted you needed to spin up Pinecone, Milvus, or Qdrant just to search through a PDF. We over-engineered ourselves into a corner with embeddings, chunking strategies, and hybrid search pipelines.

For most day-to-day developer tasks—searching a codebase, querying a few dozen documentation pages, summarizing meeting notes—vector databases are massive overkill.

Context windows have expanded to 128k tokens and beyond. Do you know how much text 128k tokens is? It's roughly 300 pages of standard documentation.

Instead of embedding your markdown files, splitting them into 500-token chunks, storing them in a vector store, writing a cosine similarity search, and praying your retrieval step grabs the right chunk, you can literally just read the files into memory and dump them directly into the context window.


python
import glob

# Read all markdown files in a docs directory
docs = []
for filepath in glob.glob("./docs/**/*.md", recursive=True):
    with open(filepath, "r") as f:
        docs.append(f"--- FILE: {filepath} ---\n" + f.read())

full_context = "\n\n".join(docs)

# Pass the whole damn thing to the model
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "Answer questions based only on the provided documentation."},
        {"role": "user", "content": f"Here is the documentation:\n{full_context}\n\nQuestion: How do I configure auth?"}
    ]
)

print(response.choices[0].message.content)

Is this inefficient from a token cost perspective? Slightly. Is it faster to build, easier to debug, and immune to bad chunking algorithms? Absolutely. Save the vector database for your multi-gigabyte enterprise data lakes.

Where to go from here

Pick one script you currently have that relies on string parsing or messy regex to extract data from an LLM response. Rewrite it using native structured outputs (Pydantic or JSON schema mode). Run it ten times and watch it pass every single time. That is the baseline utility we should have had two years ago, and it's finally stable enough to ship.

New advancements in Generative AI

G Ghuman — Mon, 24 Aug 2026 11:25:42 +0000

New advancements in Generative AI

Most AI tutorials start with a ten-paragraph philosophical debate about whether machines can think. Let's skip that. If you're building software today, you already know the raw text-in, text-out wrapper phase is mostly over. Everyone has a basic chatbot.

The actual shift happening right now isn't about models getting marginally better at writing poetry. It’s about architectures moving from passive autocomplete engines to active, structured systems. We are finally getting the tooling to build software that can reason through multi-step tasks without hallucinating right off a cliff.

Here is what actually matters in the current landscape, stripped of the vendor hype, and how to use it without losing your mind.

1. Structured Outputs (Stop Parsing Markdown Regexes)

For the last two years, getting reliable JSON out of a language model felt like convincing a toddler to assemble IKEA furniture using only verbal instructions. You'd prompt it to return JSON, it would wrap it in a markdown block, throw in a conversational "Sure, here is your data!", and occasionally escape a quote incorrectly just to ruin your 3 AM deployment.

Now, major providers support constrained decoding at the API level. You pass a schema (using JSON Schema or Pydantic), and the model's token sampling literally masks out any token that doesn't conform to your rules. It physically cannot generate invalid output.

Here is what that looks like in Python using Pydantic and the modern OpenAI client:

import os
from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

class BugReportAnalysis(BaseModel):
    component: str = Field(description="The UI component or backend service failing")
    severity: int = Field(ge=1, le=5, description="1 is a typo, 5 is total outage")
    reproduction_steps: list[str]
    is_actionable: bool

completion = client.beta.chat.completions.parse(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Analyze the user bug report."},
        {"role": "user", "content": "The checkout button crashes the app whenever a user enters a postal code with a space in it."}
    ],
    response_format=BugReportAnalysis,
)

analysis = completion.choices[0].message.parsed

# This is a real Python object, not a string you have to json.loads()
print(f"Component: {analysis.component}")
print(f"Severity: {analysis.severity}")
print(f"Steps: {analysis.reproduction_steps}")

The gotcha here? Strict mode comes with constraints. If you use Pydantic models, every field description helps, but optional fields can sometimes confuse the schema compiler if you aren't careful with default values. Keep your schemas flat and explicit. Nested objects work, but deep hierarchies will occasionally trigger API validation errors on the provider side.

2. Local Function Calling and Tool Use

Function calling used to mean sending a massive JSON payload of tool definitions and crossing your fingers that the model wouldn't hallucinate a function name that didn't exist.

The newer wave of models—both proprietary and open-weight models like Llama 3.1 running locally via Ollama—handle tool selection with actual competence. More importantly, we've stopped trying to build "autonomous agents" that run in infinite loops until they spend your entire cloud budget. Instead, we are building deterministic orchestrators with non-deterministic copilots.

Here is a minimal pattern for executing a local tool loop safely:

import json
import ollama

def get_current_weather(location: str):
    # Pretend this hits an external API
    return json.dumps({"location": location, "temperature": "72", "condition": "partly cloudy"})

available_tools = {
    'get_current_weather': get_current_weather,
}

def run_conversation():
    messages = [{'role': 'user', 'content': 'What is the weather like in Seattle?'}]

    response = ollama.chat(
        model='llama3.1',
        messages=messages,
        tools=[{
            'type': 'function',
            'function': {
                'name': 'get_current_weather',
                'description': 'Get the current weather for a given location',
                'parameters': {
                    'type': 'object',
                    'properties': {
                        'location': {'type': 'string', 'city and state'}
                    },
                    'required': ['location']
                }
            }
        }]
    )

    if response.get('message', {}).get('tool_calls'):
        for tool in response['message']['tool_calls']:
            func_name = tool['function']['name']
            func_args = tool['function']['arguments']

            if func_name in available_tools:
                result = available_tools[func_name](**func_args)
                print(f"Tool executed. Result: {result}")

run_conversation()

The trap I fell into when learning this: trusting the model to format tool arguments correctly on the first try. Always wrap your tool execution blocks in try/except blocks. If the model passes a string instead of an integer to your function, your entire process shouldn't crash because you didn't validate the payload coming out of the generation step.

3. Multimodal Context by Default

For a long time, processing images meant spinning up a separate OCR pipeline, feeding that text to an embedding model, and hoping context wasn't lost in translation. Now, models process visual layouts natively alongside text.

This changes how we handle messy input data. You aren't just writing scrapers for web pages anymore; you can feed UI mockups directly into a vision-enabled model and ask it to output component trees or Tailwind markup.

The practical reality is that inference costs for vision tokens have dropped significantly, making it viable for background processing tasks like invoice parsing or automated UI regression testing. You drop a screenshot of a broken page and a screenshot of the design file into the context window and let the model pinpoint the CSS mismatch.

Where to go from here

Don't try to build a massive RAG pipeline or a complex multi-agent framework on your first weekend. Pick a single, annoying data-cleaning or parsing task in your current codebase that currently relies on fragile regex or manual entry. Rewrite that one small script using structured outputs.

See how it feels when you stop fighting the output format and start treating the model like a slightly eccentric, extremely fast microservice.

New advancements in Generative AI

G Ghuman — Mon, 24 Aug 2026 10:33:33 +0000

New advancements in Generative AI

If you spent last year fine-tuning LLMs just to get a JSON payload back without markdown backticks wrapping the entire thing, you probably noticed the goalposts moved.

We are past the era where generative AI is just a chatbot API you paste into a React app. The tooling has shifted toward agentic workflows, local execution, and structured inputs that actually respect your schemas. If you haven't looked at the ecosystem in the last six months, your mental model is likely outdated.

Here is what actually matters right now for a working developer, minus the hype cycle.

Structured Outputs Are Finally Solved

Remember writing regex to scrape a markdown block out of a gpt-3.5 response because the model ignored your system prompt about raw JSON? That was exhausting.

The biggest quiet win in recent tooling is native structured outputs. Major providers and open-source runtimes now let you pass a JSON schema directly to the inference endpoint. The model's token selection is constrained at the logit level so it literally cannot output invalid data.

Here is what this looks like using the modern OpenAI SDK with Pydantic. If the model tries to return a string where an integer belongs, the API errors out before it even hits your network layer.

import os
from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

class CodeReview(BaseModel):
    summary: str = Field(description="One sentence summary of the code quality")
    bug_count: int = Field(description="Number of bugs found")
    refactor_suggestions: list[str] = Field(description="List of specific improvements")

completion = client.beta.chat.completions.parse(
    model="gpt-4o-2024-08-06",
    messages=[
        {"role": "system", "content": "You are a senior code reviewer."},
        {"role": "user", "content": "Review this: `const x = eval(userInput);`"}
    ],
    response_format=CodeReview,
)

review = completion.choices.message.parsed
print(f"Bugs found: {review.bug_count}")
print(review.refactor_suggestions)

The trip-up here: if you're using older open-source models via Ollama or vLLM, you still have to pass grammar files (like GBNF) or rely on library-level constraints like Instructor. Don't assume response_format={"type": "json_object"} guarantees your schema fields exist. It just guarantees valid JSON. Always use the Pydantic parsing features if you want actual schema compliance.

Local Models Are Viable for Production (Sometimes)

Running models locally used to mean watching your fans spin at maximum velocity while a 7B parameter model took forty seconds to explain a stack trace.

That has changed. With the proliferation of quantized formats like GGUF and engines like Ollama and llama.cpp, running models like Llama 3.1 8B or Mistral 7B on an Apple Silicon Mac or a decent consumer GPU is genuinely fast. For many CRUD-adjacent tasks—classification, text extraction, simple entity recognition—you don't need to ship user data to a third-party API anymore.

Here is a quick Node.js script using the standard fetch API to hit a local Ollama instance running Llama 3.1:

async function summarizeLocally(text) {
  const response = await fetch('http://localhost:11434/api/generate', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      model: 'llama3.1',
      prompt: `Summarize this error log in one sentence: ${text}`,
      stream: false
    })
  });

  if (!response.ok) {
    throw new Error(`Local inference failed: ${response.statusText}`);
  }

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

summarizeLocally("TypeError: Cannot read properties of undefined (reading 'map') at UserList.jsx:42")
  .then(console.log)
  .catch(console.error);

The catch: Context windows and instruction following on smaller local models are still brittle. If your prompt relies on complex multi-step reasoning, an 8B model will hallucinate steps that a larger frontier model handles effortlessly. Match the model size to the actual complexity of the task, not your desire to keep everything on your local machine.

Agentic Loops Without the Heavy Frameworks

Six months ago, people were building agents using massive, opinionated frameworks that abstracted everything away behind twelve layers of classes. Half the time, you spent more time debugging the framework's state machine than getting the AI to do anything useful.

The trend now is raw, simple agentic loops. An agent is essentially just a while loop that calls an LLM, checks if the model wants to call a tool, executes that tool, and feeds the result back into the context.

You don't need a heavy abstraction for this. You just need function calling and basic control flow.

import json
import requests

def get_current_weather(location: str):
    # Stub for an actual weather API call
    return json.dumps({"location": location, "temperature": "72", "unit": "fahrenheit"})

available_tools = {
    "get_current_weather": get_current_weather
}

# The actual agent loop is remarkably dumb and simple
def run_agent_loop(initial_prompt):
    messages = [{"role": "user", "content": initial_prompt}]

    for _ in range(5): # Hard limit to prevent infinite loops
        response = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=messages,
            tools=[{
                "type": "function",
                "function": {
                    "name": "get_current_weather",
                    "parameters": {
                        "type": "object",
                        "properties": {"location": {"type": "string"}},
                        "required": ["location"]
                    }
                }
            }]
        )

        response_message = response.choices[0].message
        messages.append(response_message)

        if not response_message.tool_calls:
            return response_message.content

        for tool_call in response_message.tool_calls:
            function_name = tool_call.function.name
            function_to_call = available_tools[function_name]
            function_args = json.loads(tool_call.function.arguments)

            tool_output = function_to_call(**function_args)

            messages.append({
                "tool_call_id": tool_call.id,
                "role": "tool",
                "name": function_name,
                "content": tool_output,
            })

The classic gotcha here is token bloat. As the loop iterates, the history grows. If your tool returns a massive JSON payload or a 500-line log file, your context window fills up instantly, your API costs spike, and the model starts losing the plot. Always truncate or summarize tool outputs before shoving them back into the message array.

Where to go from here

Pick one part of your current stack that involves messy text parsing, manual categorization, or repetitive data extraction. Spin up a local Ollama instance or grab an API key, write a 30-line script using structured outputs to solve it, and see where the model actually fails.

New advancements in Generative AI

G Ghuman — Mon, 24 Aug 2026 10:25:18 +0000

New advancements in Generative AI

Most AI tutorials start with a 500-word essay about how generative models are changing the world. You already know that, or you wouldn't be here. You probably have an API key, you've pasted some prompts into a chat window, and now you want to know what actually changed in the last six months beyond the marketing hype.

We aren't talking about better chatbots today. Let's look at the architectural shifts that actually matter for building software: structured outputs that don't break, local models you can run on a MacBook without setting your fan on fire, and function calling that behaves deterministically enough to put in production.

Here is what is actually useful right now.

1. Structured JSON output without the regex hacks

If you've ever tried to get an LLM to return a clean JSON object for a database insert, you know the pain. You write a prompt saying "ONLY RETURN JSON," and the model happily returns:

Sure! Here is the data you requested:

json
{
"name": "test"
}

python

Your parser crashes, your CI pipeline turns red, and you spend your afternoon writing brittle regex to strip out conversational filler.

That era is mostly over. Major providers and local runtimes now support JSON mode and strict schema enforcement at the token generation level. Instead of hoping the model behaves, you pass a JSON schema directly to the API parameters. The tokenizer literally masks out any token that doesn't fit the schema.

Here is what that looks like using the OpenAI client in Python:

import os
from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

# Define the exact shape you want using Pydantic
class CodeReview(BaseModel):
    summary: str = Field(description="One sentence summary of the code quality")
    severity: str = Field(description="Must be 'low', 'medium', or 'high'")
    bug_found: bool

response = client.beta.chat.completions.parse(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a senior code reviewer."},
        {"role": "user", "content": "Review this: `print(eval(user_input))`"}
    ],
    response_format=CodeReview,
)

# The result is already a validated Pydantic object
review = response.choices[0].message.parsed
print(f"Severity: {review.severity}")
print(f"Bug? {review.bug_found}")

The gotcha here: strict mode is great, but it requires your schema to be relatively rigid. If you try to use optional fields everywhere or nested arrays three levels deep, latency goes up, and sometimes the API will just throw a 400 error telling you your schema is too complex for structured generation. Keep it flat when you can.

2. Local models that don't require a cluster

A year ago, running a decent open-weights model locally meant renting a cloud GPU instance with 80GB of VRAM or waiting ten minutes for your laptop to generate a single paragraph.

Quantization changed this. By compressing weights from 16-bit floats down to 4-bit integers (via methods like GGUF), models like Llama 3 and Mistral can run locally on consumer hardware with minimal loss in capability.

If you haven't tried Ollama yet, install it. It handles the messy C++ binding compilation and model management behind a simple CLI.

# Pull and run a 8B parameter model
ollama run llama3:8b

More importantly, you can talk to these local models via standard HTTP endpoints that mimic the OpenAI API format. Here is how you wire up a local endpoint in Node.js without changing your architecture:

import OpenAI from 'openai';

// Point the SDK to your local Ollama instance
const openai = new OpenAI({
  baseURL: 'http://localhost:11434/v1',
  apiKey: 'ollama', // API key is required by the SDK, but ignored by Ollama
});

async function localCompletion() {
  try {
    const completion = await openai.chat.completions.create({
      model: 'llama3:8b',
      messages: [{ role: 'user', content: 'Explain CORS in one sentence.' }],
      temperature: 0.1
    });

    console.log(completion.choices[0].message.content);
  } catch (err) {
    console.error("Is Ollama running?", err.message);
  }
}

localCompletion();

The trade-off: local models are fast and free, but an 8B model will still hallucinate edge cases faster than GPT-4. Use local models for classification, formatting, or drafting, but keep critical reasoning tasks on larger models (or write deterministic code instead).

3. Tool use that actually works

Function calling used to be an expensive game of chance. You'd define three tools, the model would invent a fourth one, or it would pass arguments as strings instead of integers, completely breaking your database queries.

The current generation of models treats tool use as a first-class citizen. When you pass a JSON schema of available functions, the model generates a structured tool call token stream instead of plain text.

The pattern looks like this:

You send a user prompt and a list of available functions to the model.
The model stops generating text and returns a JSON payload containing the function name and extracted arguments.
Your code executes the actual function locally.
You send the result back to the model so it can formulate a human-readable response.

I tried writing manual prompt-parsers for this back in 2023. It was endless pain. Handling edge cases where the user asks a question that requires two sequential tool calls used to break the loop entirely. Now, most SDKs have built-in agent loops that handle multi-turn tool execution automatically.

The one thing that still trips people up: timeouts. If your local database query inside a tool execution takes five seconds, your API connection might drop. Always decouple your tool execution from your HTTP request lifecycle if you're building background agents.

Where to go from here

Stop reading about AI architectures and pick one concrete problem in your current codebase.

Take a messy internal script—maybe something that parses error logs or formats user input—and rewrite it using structured outputs with Pydantic or Zod. See where the model fails, adjust your schema, and handle the errors explicitly in code. That will teach you more about the current state of generative AI than a dozen benchmark charts.

New advancements in Generative AI

G Ghuman — Mon, 24 Aug 2026 10:20:09 +0000

New advancements in Generative AI

If you’ve tried to build anything deterministic with an LLM lately, you know the pain. You write a prompt, cross your fingers, and hope the model doesn’t hallucinate a python method that hasn't existed since 2018. For a long time, building software around generative AI felt less like engineering and more like whispering to a moody psychic.

That is slowly changing.

The conversation around gen AI has shifted away from raw parameter counts and toward reliability, local execution, and structural control. If you've been heads-down writing CRUD apps for the last year and haven't looked up, here is what actually matters right now.

Structured Outputs Are Finally Usable

The biggest bottleneck in AI development used to be parsing the response. You'd ask an LLM for JSON, it would happily wrap it in markdown code blocks, occasionally append "Sure, here is your JSON!", and sometimes casually drop a trailing comma that broke JSON.parse().

We used to spend half our Python files writing regex band-aids to clean up model output.

Now, major providers and local runtimes support constrained generation. Instead of hoping the model formats things correctly, you enforce a schema at the token level. The model literally cannot generate a token that violates your JSON schema or Pydantic model.

Here is what this looks like using the OpenAI client with Pydantic. If you aren't using this yet, stop doing string parsing immediately.

import os
from pydantic import BaseModel, Field
from openai import OpenAI

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

class CodeReview(BaseModel):
    summary: str = Field(description="One sentence summary of the code quality")
    severity_score: int = Field(description="Scale of 1 to 10, where 10 is catastrophic")
    suggested_fix: str = Field(description="The corrected code snippet")

completion = client.beta.chat.completions.parse(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a harsh code reviewer."},
        {"role": "user", "content": "print('hello world')"}
    ],
    response_format=CodeReview,
)

review = completion.choices.message.parsed

# This is a real Python object, not a string you have to clean
print(f"Severity: {review.severity_score}")
print(f"Fix: {review.suggested_fix}")

The gotcha here: structured outputs take longer to initialize on the first request because the provider has to compile the grammar mask. Don't panic if your first request takes an extra second or two. Subsequent requests are fine.

Local Models Grew Up

Sixteen-gigabyte M-series Macs changed local development, but until recently, running open-weights models felt like a compromise. Llama 3 and its variants changed that. You can now run a model locally that actually understands system prompts, handles tool use reasonably well, and doesn't completely lose the plot if your prompt goes over 500 tokens.

Tools like Ollama made this a single-command setup. You pull a model, and it exposes an OpenAI-compatible API on localhost:11434.

Here is how you swap your production client for a local instance without changing your business logic:

import OpenAI from 'openai';

// Point the standard SDK at your local Ollama instance
const openai = new OpenAI({
  baseURL: 'http://localhost:11434/v1',
  apiKey: 'ollama', // Ollama doesn't care what this is, but the SDK requires it
});

async function runLocal() {
  const response = await openai.chat.completions.create({
    model: 'llama3.2',
    messages: [{ role: 'user', content: 'Why is my database connection dropping?' }],
    temperature: 0.1,
  });

  console.log(response.choices.message.content);
}

runLocal();

The trade-off? Local models are still resource hogs. If you try to run a 70B parameter model on a laptop with 16GB of RAM, your fan is going to sound like a jet engine and generation speed will drop to one word every three seconds. Stick to the 3B to 8B parameter range for local development unless you've got a dedicated GPU rig sitting under your desk.

Context Windows Are Huge, But Mostly Noise

Models now claim context windows of 128k, 200k, or even millions of tokens. The pitch is simple: dump your entire codebase into the prompt and let the model figure it out.

I tried this. I took an entire mid-sized backend repo, concatenated the files, and shoved it into a context window to ask about a routing bug.

It didn't work very well.

While the models technically can read all those tokens, "needle in a haystack" retrieval degrades the further into the context window the important information sits. If your crucial database config is buried on page 40 of a massive prompt, the model is entirely capable of hallucinating an answer based on generic patterns it saw earlier instead of actually reading your code.

RAG (Retrieval-Augmented Generation) isn't dead. Chunking your code into a vector database and pulling relevant snippets is still significantly more reliable and cheaper than dumping an entire repository into a single massive prompt. Treat massive context windows as a nice-to-have for specific documents, not an excuse to stop writing clean code architecture.

Moving Past the Hype

The generative AI landscape is settling into a normal engineering toolset. It's no longer just magic chat interfaces in a browser wrapper. We have better syntax enforcement, faster local execution, and more predictable APIs.

If you want to actually build something with this stuff this weekend, skip the wrapper apps and the complex multi-agent frameworks.

Pick one boring, repetitive task in your daily workflow—like generating test cases for a specific utility function or parsing messy CSV headers—and write a script using Pydantic structured outputs and a local model.

Understanding OAuth2 the Simple Way

G Ghuman — Sat, 22 Aug 2026 05:19:48 +0000

Understanding OAuth2 the Simple Way

You are building a side project and want users to log in with their Google accounts instead of making up yet another password they'll forget. So you open the OAuth2 spec. Ten minutes later, you are staring blankly at a wall of terminology involving "Resource Owners," "Authorization Servers," and "Grant Types," wondering if you actually need to learn cryptography just to let someone sign in with Google.

Most explanations of OAuth2 are written by security architects for other security architects. They read like legal contracts disguised as technical docs.

Let's skip the academic definitions. Here is how OAuth2 actually works when you're building a web app, without the enterprise fluff.

The Valet Key Analogy

Forget the RFC for a minute. Think about how you give your car to a valet.

You don't hand the valet the master key that opens your glove compartment, your trunk, and your house front door (which uses the same key, because your life is messy). You hand them a specific, restricted valet key that only starts the engine and moves the car forward and backward.

OAuth2 is just a digital valet key.

Your app wants to do something on behalf of a user—like read their GitHub repositories or post a tweet—without ever seeing their password. You don't want their password. If your database gets compromised, you don't want plain-text or hashed Google passwords sitting on your server. You want a token that says, "Hey, this specific app has permission to read user X's public profile for the next hour."

That token is your valet key.

The Authorization Code Flow (Or: The Dance You Actually Have To Code)

There are several ways OAuth2 can hand over this token (called "Grant Types"). Ignore almost all of them. For 95% of web apps, you only need the Authorization Code Flow.

It’s a four-step handoff between your frontend, your backend, the user, and the identity provider (like Google or GitHub). Here is what actually happens behind the scenes:

The Redirect: Your app tells the user's browser, "Go ask Google if it's okay for us to access their profile." You include your Client ID and a redirect URL.
The Consent Screen: Google asks the user, "Hey, this random app wants to read your profile. Cool?" The user clicks "Allow."
The Code: Google redirects the user back to your site with a temporary string attached to the URL called an authorization_code. This is not the access token yet. It's a single-use receipt.
The Trade: Your backend takes that code, secretly packages it up with your app's client_secret, and sends a direct server-to-server request back to Google. Google verifies it and hands over the actual Access Token.

Why the extra step with the code? Because steps 1 through 3 happen in the user's browser, which is a hostile environment where query params can be logged or intercepted. Step 4 happens entirely on your backend, safely hidden from prying eyes.

Here is what step 4 looks like in Node.js using fetch once you've received that code in your callback route:

async function exchangeCodeForToken(authCode) {
  const response = ares = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: new URLSearchParams({
      code: authCode,
      client_id: process.env.GOOGLE_CLIENT_ID,
      client_secret: process.env.GOOGLE_CLIENT_SECRET,
      redirect_uri: 'https://myapp.com/auth/callback',
      grant_type: 'authorization_code',
    }),
  });

  if (!response.ok) {
    const errorBody = await response.text();
    throw new Error(`Failed to exchange token: ${errorBody}`);
  }

  const data = await response.json();
  // data.access_token is what you actually save or use
  return data.access_token;
}

Making the Actual Request

Once you have that access_token, using it is straightforward. You slap it into the Authorization header of an HTTP request.

Let's say you want to fetch the user's profile info from GitHub using the token you just got.

async function fetchGitHubUser(accessToken) {
  const response = await fetch('https://api.github.com/user', {
    headers: {
      Authorization: `Bearer ${accessToken}`,
      // GitHub requires a User-Agent header, or it rejects the request
      'User-Agent': 'my-oauth-learning-app',
    },
  });

  if (!response.ok) {
    throw new Error(`GitHub API returned ${response.status}`);
  }

  const profile = await response.json();
  console.log(`Hello, ${profile.login}!`);
  return profile;
}

That’s it. You don't need to sign the request cryptographically or jump through hoops. You just present the token like a backstage pass.

The Gotchas That Will Trip You Up

When I first built this, I spent two hours debugging an opaque 400 Bad Request error. It turned out to be a mismatch in the trailing slash of my redirect URL. OAuth2 is notoriously unforgiving about string matching.

Here are the mistakes you are likely to make:

Exposing the Client Secret: Never, ever put your client_secret in frontend JavaScript, a single-page app running in a browser, or a mobile app binary. Anyone can decompile an app or inspect network requests to steal it. If your app is a pure SPA or mobile app, you should be using PKCE (Proof Key for Code Exchange) instead of a traditional client secret.
Redirect URI Mismatch: The URL you send in Step 1 must match the URL you send in Step 4 down to the exact character. If Google expects http://localhost:3000/callback and you send http://127.0.0.1:3000/callback, it will fail silently or throw a cryptic error.
Confusing Authentication with Authorization: This is the classic trap. OAuth2 is for authorization (granting permissions). OpenID Connect (OIDC) is built on top of OAuth2 and handles authentication (proving who the user is). When you use "Sign in with Google," you are usually using OIDC, which hands back an id_token (a JWT containing user info) alongside your access token.

Next Steps

Don't try to write an OAuth2 client from scratch for production. Use a well-tested library like Passport.js for Node, Authlib for Python, or let a managed service like Auth0, Supabase, or Firebase handle the edge cases.

To lock this concept in your head today, open up your code editor, pick one provider (GitHub is usually the friendliest for developers), and write a tiny script that successfully logs you into your own local terminal using the Authorization Code Flow.

Understanding OAuth2 the Simple Way

G Ghuman — Wed, 19 Aug 2026 06:45:55 +0000

Understanding OAuth2 the Simple Way

You are building a side project. It needs to let users save their data, but you really do not want to manage passwords, salt hashes, password resets, or brute-force rate limiting. So you slap a "Sign in with Google" button on your frontend.

Suddenly, a user clicks it, a popup appears, Google asks if they trust your app, and when they say yes, your backend somehow knows who they are without ever seeing their Google password.

That magic trick is OAuth2. And if you read the official RFC specifications first, you will quickly wish you had chosen a simpler hobby like woodworking. The spec reads like a legal document written by enterprise architects who hate you.

Let's strip away the enterprise jargon and look at what is actually happening.

The Valet Key Analogy

Forget tokens, scopes, and grant types for a second. Think about a valet key for a car.

When you hand your car to a hotel valet, you don't give them your master house key, your wallet, and permanent ownership of the vehicle. You give them a special, restricted key that only starts the engine and moves the car a short distance. If they try to open the glove box or the trunk, that key doesn't work. And when you get back, you take the key back.

OAuth2 is just a digital valet key.

Instead of asking users for their username and password—which requires them to blindly trust you won't get hacked and leak their credentials—your application asks an authorization server (like Google, GitHub, or Auth0) for a temporary badge. That badge says: "Hey, user X has allowed this app to read their basic profile, but nothing else."

Your app uses that badge (the access token) to fetch data, and the identity provider handles the scary part of verifying who the user actually is.

The Authorization Code Flow (The One You'll Actually Use)

There are several ways to do OAuth2, known in the spec as "grant types." Ignore the implicit grant (it's dead and insecure anyway), ignore the password grant, and just learn the Authorization Code Flow. It's the standard for web apps.

Here is the exact sequence of events when a user clicks "Log in with GitHub":

The Redirect: Your app sends the user's browser to GitHub with a URL parameter saying, "Hey, I'm app X, and I need read access to user profiles."
The Consent: GitHub shows the user a scary permission screen. The user clicks "Authorize."
The Callback: GitHub redirects the user back to your server (/auth/callback) with a temporary, single-use code in the URL query string. This is not the access token. It's just a receipt.
The Exchange: Your backend takes that temporary code and makes a server-to-server HTTP POST request directly to GitHub, trading the code for the actual Access Token. Because this happens on your backend, your client secret stays hidden from the browser.

Here is what step 4 looks like in Node.js using Express and axios. This assumes you've already received the code query parameter from the callback.

const express = require('express');
const axios = require('axios');
const app = express();

app.get('/auth/callback', async (req, res) => {
  const { code } = req.query;

  if (!code) {
    return res.status(400).send('No code provided from provider.');
  }

  try {
    // Step 4: Exchange the temporary code for an access token
    const tokenResponse = await axios.post('https://github.com/login/oauth/access_token', {
      client_id: process.env.GITHUB_CLIENT_ID,
      client_secret: process.env.GITHUB_CLIENT_SECRET,
      code: code
    }, {
      headers: {
        accept: 'json' // GitHub is quirky, it returns query params by default unless you ask for JSON
      }
    });

    const accessToken = tokenResponse.data.access_token;

    // Now use the access token to fetch the user's profile
    const userResponse = await axios.get('https://api.github.com/user', {
      headers: {
        Authorization: `Bearer ${accessToken}`
      }
    });

    console.log("Logged in user:", userResponse.data.login);
    res.send(`Welcome, ${userResponse.data.login}!`);

  } catch (err) {
    console.error('OAuth failed:', err.response?.data || err.message);
    res.status(500).send('Authentication failed.');
  }
});

app.listen(3000, () => console.log('Server running on port 3000'));

The Gotchas (Or: What Tripped Me Up)

When I first built this, I made a few assumptions that blew up in my face. Save yourself the debugging hours.

1. Confusing Authentication with Authorization
OAuth2 is technically an authorization framework, not an authentication framework. It answers the question: "Is this app allowed to read this user's data?" It doesn't strictly guarantee who the user is.
Because of this, people started abusing OAuth2 to handle logins. To fix that, the industry created OpenID Connect (OIDC), which sits on top of OAuth2 and standardizes identity tokens. If you are using Google or Auth0, you are usually using OIDC under the hood of your OAuth flow. Don't sweat the distinction too much early on, but know why people keep throwing terms like JWT and OIDC into the conversation.

2. State Parameter CSRF
Look at the code snippet above. Notice I didn't include the state parameter? That was lazy and insecure.
An attacker could theoretically intercept your user's auth flow and inject their own authorization code, logging the victim into the attacker's account. To prevent this, you should generate a random cryptographic string (state), send it to the provider, and verify that the state coming back in the callback matches what you stored in the user's session. If it doesn't match, drop the request.

3. Token Expiration
Access tokens expire. Sometimes in an hour, sometimes in days. If your app assumes an access token lasts forever, your users are going to experience random mysterious logouts. You either need to gracefully prompt them to re-authenticate or implement Refresh Tokens, which let your server ask for a new access token without bothering the user again.

Making API Requests with the Token

Once you have that access token safely stored (in an HTTP-only cookie or a secure session, never in localStorage if you want to avoid XSS nightmares), making requests on behalf of the user is straightforward.

You just attach it to the Authorization header. Here is a quick example of fetching a user's repositories from GitHub using that token:

async function getUserRepos(accessToken) {
  try {
    const response = await axios.get('https://api.github.com/user/repos', {
      headers: {
        Authorization: `Bearer ${accessToken}`,
        'User-Agent': 'My-Awesome-App' // GitHub requires a User-Agent header or it blocks you
      },
      params: {
        visibility: 'private',
        sort: 'updated'
      }
    });

    return response.data;
  } catch (error) {
    if (error.response && error.response.status === 401) {
      console.log('Token expired or revoked. Time to refresh or re-auth.');
    }
    throw error;
  }
}

Notice how clean that is once the initial setup is done. Your app doesn't know or care about passwords; it just passes the token along like a VIP wristband at a concert.

Next Steps

Stop reading theory. Open up GitHub, Google Cloud Console, or Auth0, and create a dummy developer application. Write a tiny local Express or Flask server, wire up the redirect and callback routes shown above, and log your own username to the console. Seeing the data come back live makes the whole loop click into place faster than reading ten more articles.

Understanding OAuth2 the Simple Way

G Ghuman — Fri, 14 Aug 2026 11:32:49 +0000

Understanding OAuth2 the Simple Way

You are building a side project and want users to log in with their Google accounts instead of making up yet another password they'll forget. So you open the OAuth2 spec. Ten minutes later, you are staring blankly at a wall of terminology about "Resource Owners," "Authorization Grants," and "Bearer Tokens," wondering if you should just use a plaintext database table and call it a day.

Every tutorial on the internet tries to explain OAuth2 with an analogy about valet keys at a restaurant. I don't want a valet key. I want to know why my redirect URI is returning a 400 Bad Request and how to get an access token without losing my sanity.

Let's skip the car analogies and look at how this actually works.

The Core Concept: Delegation, Not Authentication

Here is the first trap everyone falls into: treating OAuth2 as a login system.

It isn't one. OAuth2 is an authorization framework. It is designed to answer one question: Can application X access resource Y on behalf of user Z?

Authentication answers "Who are you?" (That's OpenID Connect, which is built on top of OAuth2, but we'll ignore that for a second). OAuth2 answers "What are you allowed to do?"

Imagine you built a little CLI tool that automatically backs up your GitHub repositories to a local drive. Your script needs access to your private repos, but you definitely don't want to hardcode your GitHub password into a Python file.

Instead, you want to go to GitHub, log in yourself, look at a scary warning screen that says "This app wants read access to your repositories," and click "Authorize." GitHub then hands your script a temporary backstage pass (an access token). Your script uses that pass to grab your code.

That handshake is OAuth2.

The Authorization Code Flow (The One You'll Actually Use)

There are several "grant types" in the OAuth2 spec. Ignore all of them except the Authorization Code Flow.

If you are building a traditional web app with a backend server, this is the flow you need. It keeps your app's secret key safe on the server where users can't see it in their browser dev tools.

Here is how the dance goes step by step:

The Redirect: Your app sends the user to the identity provider (like Google or GitHub) with a URL that says, "Hey, send this user back to /callback when they log in, and tell them I need read:user permissions."
The Consent: The user logs into Google, sees the consent screen, and clicks "Allow."
The Code: Google redirects the user back to your app's /callback route with a temporary code stuck in the query string. This code is not the access token. It's a single-use receipt.
The Exchange: Your backend takes that receipt, walks up to Google's token endpoint behind the scenes (along with your client secret), and trades it for the actual Access Token.

Let's look at what that token exchange looks like in practice. Here is a quick Node.js snippet using axios hitting a mock provider:

const axios = require('axios');

async function exchangeCodeForToken(authCode) {
  try {
    const response = await axios.post('https://oauth.example.com/oauth/token', {
      client_id: process.env.CLIENT_ID,
      client_secret: process.env.CLIENT_SECRET,
      code: authCode,
      grant_type: 'authorization_code',
      redirect_uri: 'http://localhost:3000/callback'
    }, {
      headers: { 'Content-Type': 'application/json' }
    });

    // This is what you actually care about
    const { access_token, refresh_token, expires_in } = response.data;

    return access_token;
  } catch (error) {
    // Spoiler: You will hit this catch block a lot at first
    console.error('Token exchange failed:', error.response.data);
    throw new Error('OAuth dance failed');
  }
}

Making the Authenticated Request

Once you have that access_token safely stored in a secure, HTTP-only cookie or a session, using it is anti-climactic. You just slap it into the HTTP headers of your API requests.

import requests

def get_user_profile(access_token):
    url = "https://api.example.com/v1/user/profile"

    headers = {
        "Authorization": f"Bearer {access_token}",
        "Accept": "application/json"
    }

    response = requests.get(url, headers=headers)

    if response.status_code == 401:
        print("Token expired or invalid. Time to use that refresh token.")
        return None

    return response.json()

That Bearer prefix trips people up. It literally means "Hand this token to whoever is bearing it." If someone steals your access token, they can impersonate the user until it expires. That is why keeping tokens out of localStorage in single-page apps matters so much—any rogue XSS script can read localStorage and steal your bearer tokens.

The Gotchas That Will Waste Your Afternoon

When I first wired this up, I spent three hours debugging a redirect_uri_mismatch error from Google. Everything looked identical. The string in my code matched the string in the Google Cloud Console down to the last slash.

Except it didn't. I had http://localhost:3000/callback in my code, but http://localhost:3000/callback/ (with a trailing slash) registered in the dashboard. OAuth implementations are aggressively literal. If a single character is off, they lock the door and give you zero helpful context.

Another common pitfall is ignoring token expiration. Access tokens are designed to be short-lived—sometimes expiring in 15 minutes. If your app crashes because a user's token expired while they were filling out a form, your UX is broken. You have to implement the refresh token cycle, which means storing that second token securely and asking the auth server for a fresh access token behind the scenes when the first one dies.

Finally, don't write your own OAuth2 server unless you are doing it purely for fun on a weekend. Use Auth0, Keycloak, Supabase, or Firebase Auth. Implementing the spec securely—handling state parameters to prevent CSRF, managing PKCE for mobile apps, handling token rotation—is tedious security plumbing that has already been solved a thousand times.

Next Steps

Open up your terminal, pick an API you use daily (GitHub or Spotify have great, developer-friendly docs), and register a new developer application in their dashboard. Don't write any code yet—just use Postman or curl to manually trigger the authorization URL in your browser, grab the code from the redirect, and paste it into a manual POST request to get your first token.

Once you trace the round-trip manually with your own eyes, the magic trick loses its mystery.

Step-by-Step: Setting Up a Mobile App Development Environment

G Ghuman — Fri, 14 Aug 2026 08:31:05 +0000

Step-by-Step: Setting Up a Mobile App Development Environment

Getting a mobile development environment running on your machine is a rite of passage, mostly because it usually takes three hours and involves downloading about fifteen gigabytes of software you didn't know existed.

If you're coming from web development, the shift is jarring. In web dev, you save a file and your browser refreshes. In mobile dev, you're compiling native binaries, managing virtual devices that eat your RAM for breakfast, and dealing with two completely different ecosystems that actively try not to get along.

I recently had to set up a fresh MacBook for React Native and Flutter work. Here is the exact path through the setup swamp, minus the dead ends I hit along the way.

1. The Command Line Foundation (Homebrew and Node)

Don't download installers from random websites if you can avoid it. You want a package manager so you can actually update your tools next year without crying.

On macOS, Homebrew is non-negotiable. If you're on Linux, your native package manager handles most of this, and if you're on Windows, you should probably be using WSL2, though that's a whole separate therapy session.

Open your terminal and install Homebrew if you haven't already:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once that finishes, the installer usually prints a couple of "Next steps" lines to add Brew to your PATH. Do not ignore them, or your terminal will pretend it has no idea what brew is the second you close the window.

Next, grab Node.js. Even if you aren't building a React Native app, almost every mobile toolchain relies on Node somewhere under the hood for build scripts or CLI runners.

brew install node

Verify it worked. If node -v spits out a version number, you're ready for the heavy machinery.

2. Android Studio and the SDK Monster

You need Android Studio even if you plan to build iOS apps later. Why? Because you need the Android SDK, the build tools, and the emulator manager. You don't actually have to write code in Android Studio—you can use VS Code or whatever editor you prefer—but you cannot escape installing it.

Download Android Studio from the official site and run the installer. When you get to the setup wizard, choose Custom setup. Do not just click Next on everything. You want to make sure the following components are checked:

Android SDK
Android SDK Platform
Performance (Intel HAXM or AMD equivalent, depending on your chip)
Android Virtual Device

Once it installs, open the SDK Manager (it's hidden in the settings menus). Go to the SDK Platforms tab and make sure you have at least one recent version installed—Android 14 (API 34) is a safe bet right now.

Then switch to the SDK Tools tab and check these boxes:

Android SDK Build-Tools
Android Emulator
Android SDK Platform-Tools

Here is the gotcha that wasted an hour of my life: your terminal doesn't know where any of this lives by default. You have to wire up your environment variables.

Open your shell configuration file (~/.zshrc or ~/.bash_profile) in your text editor and paste these lines at the bottom:

export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin

Save the file, then run source ~/.zshrc to apply the changes. If you type adb into your terminal now, it should print a list of commands instead of saying "command not found."

3. Xcode (Mac Only) and iOS Simulator Quirks

If you're on a Mac and want to build for iOS, you have to deal with Xcode. Head over to the Mac App Store and download it.

Fair warning: Xcode is massive—well over 30GB depending on what components it decides to pull down. Start the download, go make a sandwich, watch an episode of something, and come back. It takes a while.

Once Xcode is installed, open it at least once. It needs to prompt you to install additional required components and agree to the license agreement. If you skip this and try to run a build from the command line, Xcode will fail silently or throw an obscure exit code that means nothing.

Next, install the command-line tools:

sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -runFirstLaunch

You'll also want to install CocoaPods, which is the dependency manager for iOS. Don't use sudo gem install cocoapods if you can avoid it—it messes with system ruby permissions. Use homebrew instead:

brew install cocoapods

To test if your iOS simulator is working without spinning up a whole project yet, you can boot one directly from the terminal:

xcrun simctl boot "iPhone 15"
open -a Simulator

If a shiny virtual iPhone pops up on your screen, you're in business.

4. Creating and Running Your First Test Project

Let's verify everything actually talks to each other. We'll use React Native's CLI for this test because it touches both Android and iOS toolchains.

Create a blank sandbox project:

npx @react-native-community/cli init TestEnvironmentApp
cd TestEnvironmentApp

Now, open two separate terminal tabs.

In tab one, start the Metro bundler:

npm start

In tab two, try launching the Android build:

npm run android

If your Android emulator spins up, builds the app, and displays the default React Native welcome screen without throwing a Gradle build error, your environment is solid.

If it fails with a Gradle error about Java versions, don't panic. Mobile tools are notoriously picky about Java Development Kit (JDK) versions. Android Studio installs its own JDK, but sometimes your system points to an older global version. You can check your Java version with java -version. Most modern mobile frameworks expect JDK 17.

To test iOS (assuming you're on a Mac), run:

cd ios && pod install && cd ..
npm run ios

The simulator should automatically compile the native iOS binary and load the app.

Next Step

Open your terminal right now, type adb devices or spin up an iOS simulator to verify your paths are still working after closing your terminal window. Once you confirm a virtual device boots up cleanly, pick a framework—React Native, Flutter, or native Swift/Kotlin—and run their official "Hello World" tutorial while your environment is still fresh.