DEV Community: Brad Hankee

How I Built an Evaluation Pipeline for AI Image Generation

Brad Hankee — Fri, 20 Feb 2026 19:04:10 +0000

We automated blog image generation with Imagen 4. It worked beautifully... except when it didn't.

Sometimes the AI would sneak text into images despite explicit instructions not to. Here's how we fixed it with automated evaluation.

The Problem

We're generating retro hero images for blog posts at Vets Who Code. The requirements were strict:

Bold navy/red/white color palette only
NO text or typography
Retro poster aesthetic

Imagen 4 is powerful, but non-deterministic. We'd get 8 perfect images, then 2 with random text. Manual QA doesn't scale.

The Solution: Automated Evaluation

We built a test harness using Gemini Vision to grade Imagen's outputs:

Step 1: Generate test images
Run the same prompts 10x to measure consistency

Step 2: Automated validation

Use Gemini Vision to detect text (even single letters)
Validate color palette adherence
Check style consistency

Step 3: Track metrics

Pass rate across test cases
Violation patterns (text vs colors vs style)
Save failed images for inspection

Step 4: Iterate on prompts
Based on eval data we discovered:

Moving "NO TEXT" to the top of the prompt improved adherence by 40%
Repeating constraints in multiple places reduced violations BUT only to an extent

Too many NOs equal a YES

This turned out to be much like a human interaction with children. The more you tell them 'NO' the more likely it is to fail. We found out that the amount of negative constrains (no letters, no text, no numbers etc.) turned out to be a bell curved chart in that having 0 did not work, adding a few at deliberate locations worked well, adding more turned out to fail more. WHY?

Too many of these instances turned out to flood the LLM with those words and even though we were stating NOT to include them they saw the word count to turn into these might be important to have.

The Takeaway

When using AI in production:

Assume non-determinism — what works once might fail the 10th time
Use AI to evaluate AI — Gemini Vision is great for validating image outputs
Make evals fast — automated testing lets you iterate rapidly
Track metrics over time — you want to know if model updates break your workflow

Brad
bradhankee.com

The KC-10 Was My First Codebase — I Just Didn’t Know It Yet

Brad Hankee — Mon, 08 Dec 2025 15:45:02 +0000

From KC-10 Aircraft to Codebases: How I Learned System Design Before Computer Science

Before I ever wrote software professionally, I was an electrician and pneumatics specialist on KC-10 aircraft. I didn’t call it “system design,” but that’s exactly what it was — understanding how large, interconnected systems behave, fail, and recover. When I later moved into software engineering, so many principles felt familiar that it almost seemed like I had been training for it without realizing it.

System Design: Schematics → Architecture

Working on the KC-10 meant thinking in terms of systems, not isolated parts. Electrical, pneumatics, hydraulics, avionics all felt like everything relied on something else.

That mindset maps directly to software:

Inputs/outputs in aircraft systems behave like APIs.
Dependencies and redundancy mirror service architecture and failover strategies.
Failure modes taught me to ask not just “Does this work?” but “What happens when it doesn’t?”

The wiring diagrams I used to study feel a lot like the architecture diagrams I use today. Both describe how a complex system communicates and reacts under stress.

Troubleshooting & Debugging: Multimeters → Logs

Aircraft discrepancies rarely came with clear symptoms. To fix a problem, you had to reproduce it, trace the system end-to-end, and validate the fix with zero guesswork.

That is exactly how debugging works in software:

Reproduce the issue under the right conditions
Trace the flow through each subsystem or function
Form hypotheses and test them
Confirm the solution with checks and monitoring

Whether I’m holding a multimeter or scanning logs, the approach is identical: systematic, thorough, and evidence-driven.

Oversight & Quality: 100% or It Doesn’t Fly

On an aircraft, “good enough” is unacceptable. Everything is inspected, documented, and verified. Some tasks required multiple sign-offs because real lives depended on the result.

That experience shaped how I approach engineering quality today:

Code reviews = peer inspections
Testing and CI = functional and system checks
Documentation = our modern technical orders
Monitoring = continuous post-flight inspection

If code is going to “fly” in production, it should be something I’d confidently sign my name to.

Continuous Improvement & Mentorship

On the flight line, improvement was part of the culture. We refined procedures, looked for better ways to troubleshoot, and coached junior airmen so the whole team grew stronger.

In software, that became:

Refactoring and reducing tech debt
Sharing context with junior devs
Running retros to identify process improvements
Building a culture where quality and learning compound over time

It wasn’t just about fixing today’s issues, it was about making tomorrow’s work safer, faster, and smarter.

How This Shapes Me as an Engineer

My aviation experience trained me to:

Think in systems
Debug with discipline
Treat quality as non-negotiable
Improve the team, not just the task

I learned programming later, but the foundations of engineering — systems thinking, troubleshooting, ownership, and mentorship — were already there. The aircraft just taught them to me first.

Software Fun-duh-mentals - DNS

Brad Hankee — Thu, 04 Dec 2025 19:56:12 +0000

DNS: The Underrated Backbone of Scale and Security

When most developers hear DNS, they think “the thing that turns google.com into an IP address.” And while that’s technically true, it wildly undersells what DNS actually represents in modern software engineering.

DNS (Domain Name System) is the routing layer of the internet. It’s the first service your users interact with—often before your load balancers, CDN, or backend infrastructure even get a chance. Because of that, DNS plays a much bigger role in application performance, scaling, and security than most engineers initially realize.

What DNS Actually Does

DNS is a distributed, hierarchical system that maps human-friendly names (like example.com) to machine-friendly information (like IP addresses, mail servers, or service endpoints).

When a user types your domain:

The browser asks the DNS resolver for the IP address
The resolver follows DNS hierarchy (root → TLD → authoritative)
It returns the final answer—your application’s entry point

Now that you know the basics, let’s talk about where DNS becomes a software engineering lever rather than just a lookup table.

DNS as a Scaling Tool

Scaling isn’t just about bigger servers or more containers—it’s about directing traffic intelligently. DNS is one of the first layers that lets you do that.

1. Global Load Distribution

DNS can route users to different servers based on:

Geolocation (send users to the closest region)
Latency (route to lowest-latency endpoint)
Health checks (automatically remove unhealthy endpoints)
Weighted routing (gradually shift traffic during deployments)

This is why modern SaaS companies rely on DNS providers like Cloudflare — turning DNS into a traffic control system.

If you’ve ever:

Rolled out features region-by-region
Slowly shifted from v1 to v2 of an API

DNS was likely helping orchestrate that rollout.

2. CDN Enablement

CDNs (Cloudflare, Fastly etc.) rely on DNS routing to direct clients to the nearest cache edge. Without DNS, global content acceleration doesn’t exist.

If you want to scale, really scale, DNS is the gatekeeper to distributing workloads worldwide.

3. High Availability and Failover

DNS enables infrastructure patterns like:

Active–active failover
Active–passive failover
Disaster recovery routing

When a region goes down, DNS can instantly reroute traffic to a healthy region—often without users noticing anything happened.

This turns DNS into a resilience layer in distributed software architecture.

DNS as a Security Layer

If DNS is the front door to your system, it’s also one of the best places to enforce security.

1. DNSSEC (Domain Integrity Protection)

DNS wasn’t originally built with authentication in mind, which led to vulnerabilities like:

DNS spoofing
Cache poisoning
Man-in-the-middle attacks

DNSSEC adds cryptographic signatures to DNS responses so clients can verify authenticity. It doesn’t encrypt traffic, but it makes sure attackers can’t lie about where your domain points.

2. Traffic Filtering and Threat Mitigation

Modern DNS providers offer:

DDoS absorption at the DNS layer
Bot filtering
Malicious domain blocking
Zero-trust access to internal services

Before a request ever touches your app, DNS can decide whether it’s allowed to.

As traffic increases—or becomes more hostile—this becomes essential.

3. Reducing Attack Surface

DNS lets you:

Hide internal services behind private or split-horizon DNS
Remove unused records that expose infrastructure
Rotate underlying infrastructure without changing public endpoints

Your DNS layer becomes a shield—not just a switchboard.

Why DNS Belongs in Every Engineer’s Toolkit

DNS is often treated as something DevOps handles, but in reality:

Frontend engineers rely on fast DNS for low TTFB
Backend engineers rely on DNS for service discovery
AI engineers rely on reliable endpoints for model inference calls
Ops/SRE teams rely on DNS for routing and resilience
Security teams rely on DNS for domain integrity

Understanding DNS makes you a better architect, not just someone who knows how domains work.

Brad Hankee

How I Built an AI That Can Make Developers Cry (And Learn)

Brad Hankee — Thu, 20 Nov 2025 15:58:10 +0000

🔥 You think you can handle AI roasting your web dev portfolio? Give it a shot while also getting lighthouse performance metrics and design feedback based on your actual site design.

As a AI engineer and web developer, I wanted to build a product that would be both technically challenging and fun. So I built Roast My Portfolio — an AI-powered web app that analyzes developer portfolio websites and (depending on the mode) either gives professional, actionable UX feedback, or completely roasts it with brutal honesty and sarcasm.

It’s deployed live here if you think you can handle the feedback!

🧠 Tech at a Glance

Feature	Stack
Frontend	React + Next.js + TypeScript (Vercel)
Backend API	FastAPI (Python), deployed on Railway
AI Models	LLM multi-mode via Groq (Llama 3.3 70B)
Automation	Lighthouse CLI for web performance
Screenshot Capture	Browserless
Auth & DB	Supabase
Deployment	Vercel (FE), Railway (Dockerized BE)

🚀 How It Works

User enters a portfolio URL and chooses “Roast” or “Serious” mode.
The backend scrapes the site, gathers content, captures a screenshot, and generates a Lighthouse performance report.
All of that gets bundled into a prompt (plus persona-based styling) and sent to the AI model (Groq).
The AI returns structured JSON:

{
  "score": 7,
  "feedback": "...",
  "visual_design_feedback": "...",
  "suggestions": [...]
}

The frontend displays the results using a custom UI with animated score graphics and metric visualizations.

🤖 AI Prompt Strategy

I built two prompts using LangChain templates:

🔥 Roast Mode – sarcastic, witty, comedic tone using the Groq API.

💼 Serious Mode – professional UX & design critique using Groq as well.

A key setup was enforcing consistent JSON responses to keep parsing stable:

Return ONLY valid JSON, no markdown or additional commentary.

This allowed reliable extraction of feedback, score, and suggestions.

💡 Challenges Solved

CORS & domain routing issues between Vercel and Railway.
Getting Docker builds to work with FastAPI and managing .env variables.
Handling AI output consistency (LLMs love adding extra flourish).
Making Lighthouse work without blocking performance.
Avoiding token overflow with prompt truncation.

📈 What’s Next

PDF export of roast results for sharing.

“Before/After portfolio improvements” tracker.

User accounts with analysis history.

If you're exploring AI-powered tooling or want feedback on your portfolio (painful or professional), give it a try.

👉 [Live Demo Link Here]
🎯 Would love to hear your feedback and roast suggestions!

📝 Final Thoughts

This project helped me bridge my front-end experience with backend AI engineering, and taught me a lot about:

AI model prompting strategies
LLM Structured outputs
Integrating custom datasets (screenshot + Lighthouse + scraped content)

If you’re trying to make the jump into AI engineering — build something weird, something useful, or something hilarious. You’ll learn way faster.

Function Calling in LangChain: Turning Chatbots into Enterprise Copilots

Brad Hankee — Thu, 30 Oct 2025 00:08:29 +0000

Understanding Function Calling and Tool Calling in LangChain

If you’ve been diving into LangChain, you’ve probably noticed that it has a pretty elegant way of standardizing how LLMs interact with external tools — whether those are APIs, databases, or your own custom functions.

At the heart of this design are function calling and tool calling — mechanisms that give the LLM structured ways to perform actions beyond text generation. In this post, I’ll walk through what they are, how they work, and why they’re so powerful.

🧠 What Function Calling Actually Does

Function calling lets an LLM decide when and how to use a function (or “tool”) you’ve defined. Instead of hard-coding logic for every possible task, you provide the LLM with a list of available tools and their schemas — and it figures out which one to call, if any.

Here’s the magic part:

When the model determines a tool is needed, it returns a structured JSON object specifying the tool name and the arguments it wants to use. LangChain handles the plumbing for you — executing the tool, appending its result back into the conversation history, and letting the LLM continue reasoning from there.

This process looks like:

The model receives a user query.
It decides whether a tool is needed.
If yes, it outputs the tool name + JSON arguments.
LangChain executes that tool.
The result is appended to the message list and sent back to the LLM.
The LLM continues, now with that new context.

⚙️ Core Functions for Tool Handling in LangChain

LangChain has made this pattern remarkably clean through a few key methods:

.bind_tools() – attaches your tool definitions (schemas, descriptions, etc.) directly to a model call.
.tool_calls() – retrieves or inspects the tools the model actually invoked.
create_tool_calling_agent() – builds an agent that can manage multiple tools and handle parallel tool calls automatically.

These functions help standardize how you define, attach, and inspect tools — and make it easy to scale from a single function call to a multi-tool agent setup.

🧩 Example: Using `bind_tools()` for Function Calling

Let’s make this concrete with a simple example.

Say you want your model to have access to a weather tool.

The tool will take a city name and return fake weather data — just enough to illustrate how tool schemas and calls work.

from langchain_openai import ChatOpenAI
from langchain.tools import tool

# Step 1: Define your tool
@tool
def get_weather(city: str) -> str:
    """Returns current weather for a given city."""
    fake_weather = {
        "Portland": "Rainy and 55°F",
        "Austin": "Sunny and 82°F",
        "New York": "Cloudy and 64°F",
    }
    return fake_weather.get(city, "Weather data unavailable")

# Step 2: Initialize your model
llm = ChatOpenAI(model="gpt-4o-mini")

# Step 3: Bind your tool to the model
model_with_tools = llm.bind_tools([get_weather])

# Step 4: Ask the model a question that may trigger a tool call
response = model_with_tools.invoke("What's the weather like in Portland today?")
print(response)

When you run this, the LLM may decide it needs to call the get_weather tool — and LangChain will automatically:

Generate the structured JSON call with the correct arguments,
Execute the function,
Append the result to the message history,
And return the combined final response.

If you inspect the model’s internal state (for debugging), you can see what tools it used:

response.tool_calls  # See what tools were invoked

🔄 Switching Between Models Is Easy

One of the best aspects of LangChain’s function calling setup is how model-agnostic it is. You can swap between OpenAI, Anthropic, or local models that support the same structured-function-calling interface with minimal changes. The schema for your tools stays the same — it’s the LLM that decides how to interpret and use them.

That means once you’ve defined your tools, you can experiment with different providers or even run them in parallel to compare behavior.

⚡ Parallel Tool Calls

LangChain’s architecture also allows the LLM to run multiple tool calls in parallel. This can make certain workflows dramatically faster — for example, fetching data from multiple APIs at once or running several analysis functions simultaneously.

You still define your tools declaratively, but LangChain’s internal orchestration ensures that execution happens efficiently under the hood.

🔗 Common Tool Use Cases

Some classic examples of tools you might expose include:

API calls – such as fetching weather, stock prices, or data from your own backend.
Database queries – using SQL or vector search for retrieval-augmented generation.
Computation utilities – small functions like calculating dates, formatting text, or summarizing results.

Each of these tools has a schema that tells the LLM what inputs it expects — and that schema is what allows the model to call it correctly using structured JSON.

🧠 The Responsibility of Description

With great power comes… well, a bit of responsibility.
The better you describe your tools, the better the LLM performs.

Each tool’s description should clearly explain what it does and when to use it. That’s how the model learns to make accurate choices about when to call (or not call) a tool.

The LLM isn’t just executing code blindly — it’s reasoning about when calling a tool makes sense. As AI engineers, our job is to give it the right context and structure to make those decisions intelligently.

🏢 How Function Calling Impacts Enterprise and Business

For enterprises, function calling changes the game in how AI integrates with existing systems.

Instead of siloed AI chatbots, organizations can now build intelligent orchestration layers that sit on top of internal APIs, CRMs, databases, and analytics platforms.
Here’s how it plays out in real business terms:

1. Seamless System Integration

Function calling lets an LLM act as the “brain” across multiple business tools — Salesforce, HubSpot, internal APIs, SQL databases, etc. It allows conversational interfaces that don’t just talk but actually act — fetching reports, creating tickets, or running queries in real time.

2. Governance and Standardization

Because tool schemas are explicitly defined, enterprises gain control and auditability. You know exactly what the model can and can’t do, which functions it’s allowed to call, and how it’s supposed to format outputs (structured JSON).
That’s critical for compliance, security, and scaling AI workflows safely.

3. Improved Efficiency and ROI

Function calling cuts down on manual steps. Imagine a customer service model that calls a refund API, updates a database, and emails the customer — all within one reasoning loop.
That’s time saved, fewer context switches, and measurable impact on team productivity.

4. Vendor Flexibility

Since LangChain’s tool calling is model-agnostic, businesses can swap or mix LLM providers (OpenAI, Anthropic, Mistral, etc.) without rewriting their integration layer.
The function schemas remain constant — the intelligence layer becomes modular and future-proof.

In short, function calling turns LLMs from “smart typists” into operational copilots that can take action within enterprise systems safely and predictably.

Final Thoughts

Function calling and tool calling in LangChain unlock a whole new level of composability. Instead of coding static flows, you’re building dynamic reasoning systems that can use external knowledge and computation whenever needed.

“Don’t Chain Yourself Down — Graph It Out! 🔗 (LangGraph, Memory, and the Future of AI Workflows)”

Brad Hankee — Wed, 22 Oct 2025 15:07:58 +0000

Understanding LangGraph: Building Smarter, Stateful AI Workflows

LangGraph has recently become one of my favorite tools from the LangChain ecosystem — and for good reason. If you’ve ever found yourself struggling to manage multi-step AI reasoning, dynamic state, or complex tool orchestration, LangGraph feels like that missing link in the chain(insert pun here).

So what is LangGraph and when you should use it instead of standard LangChain, and some of its most exciting features like reducers, super-steps, memory checkpointing, and even a bit of time travel.

What is LangGraph?

LangGraph is an extension of LangChain designed for stateful, graph-based AI applications.

Think of it like this: LangChain lets you build chains (step-by-step sequences).
LangGraph lets you build graphs — dynamic, branching workflows where each node can make decisions and carry forward memory and state.

If LangChain is a pipeline, LangGraph is the traffic control system for multiple pipelines that can interact, merge, and loop intelligently.

This means it’s perfect for cases like:

Multi-agent reasoning (AI agents collaborating or debating)
Conversational memory over long sessions
Stateful apps like chatbots, assistants, and copilots
Complex data processing pipelines

When to Use LangGraph Over LangChain

LangChain is amazing for linear workflows — when you know the exact steps your model will take.
But when you start needing adaptive logic, where each step might depend on multiple previous results or user states, that’s when LangGraph shines.

To simplify:

✅ Use LangChain for predictable, short, single-pass reasoning.
🚀 Use LangGraph when you need looping, branching, memory, or dynamic control flow.

State Management: Reducers and Super-Steps

LangGraph utilizes the concept of state, and it’s managed using what’s called a reducer.

If you come from the React or Redux world — this should feel like your jam.
Reducers take the previous state and the new input, and return the next state.

This makes the graph deterministic and inspectable — every node and edge mutation is explicit. No more guessing what happened mid-run.

And then there’s the concept of a super-step — essentially a full pass over all active nodes in your graph.
Each super-step updates state across nodes, synchronously, so you can reason about your app in cycles rather than chaos.

Memory and Checkpointing

This is where LangGraph really flexes.

It includes built-in checkpointing, which means you can save, reload, and “time travel” through the states of your graph.
This is huge for debugging, long-running conversations, or AI workflows that evolve over time.

Think of it like version control for your agent’s brain.

You can inspect how your graph reasoned at step 5 vs. step 50, and even branch from a checkpoint to explore a new direction.

This persistent memory layer integrates tightly with LangSmith, LangChain’s observability platform.

Visualizing It: Nodes, Memory, and Checkpoints

Here’s a quick visualization of how LangGraph keeps track of memory and checkpoints between nodes:

graph TD
    A[Start Node] -->|Adds user message| B[Model Node]
    B -->|Generates response| C[Memory Checkpoint]
    C -->|Saves to SQLite or LangSmith| D[Checkpoint Store]
    D -->|Reload / Time Travel| B

🧠 Each run through the graph:

The Start Node initializes or updates the state.
The Model Node processes and updates that state.
The Checkpoint stores that state snapshot.
You can restore from any checkpoint and continue reasoning.

It’s simple, powerful, and makes debugging or branching your agent’s memory trivial.

LangSmith Integration

LangSmith is your AI debugger and performance tracker.
When you run LangGraph with LangSmith, every node, state update, and tool call is logged automatically. You can replay runs, visualize reasoning chains, and monitor metrics in real time.

In short — it’s not just a dev tool, it’s your AI workflow observatory.

Built-in Serper Wrapper

LangGraph and LangChain come with handy tool integrations — one of the most useful being the Google Serper API wrapper.
It’s a quick way to give your agents access to live search results.

Here’s how you can run a quick query using Python:

from langchain_community.utilities import GoogleSerperAPIWrapper

serper = GoogleSerperAPIWrapper()
serper.run("What is the capital of France?")

And you guessed it — the model would return:

"Paris"

This can easily be integrated into a LangGraph node as one of your tools, letting your agents pull in real-time context dynamically.

Time Travel with Checkpoint IDs

Remember those checkpoints we talked about earlier?
You can actually use them to time travel in LangGraph.

Each checkpoint gets a unique ID, and you can restore or fork from that point in the graph.
This allows you to explore “what-if” scenarios without rerunning everything from scratch — perfect for research, testing, or debugging reasoning drift in long sessions.

Imagine jumping back to the moment before your AI made a bad decision… and sending it down a smarter path. 🕰️

Wrap Up

LangGraph feels like the evolution of LangChain — not a replacement, but a level-up for developers building persistent, intelligent, multi-agent systems.

If you’ve hit the limits of simple chains, give graphs a try.
The ability to reason over state, checkpoint memory, and visualize logic flows will make your AI apps not only smarter but also far more maintainable.

– Brad
Brad Hankee
Building the bridge between web-dev and AI systems.

Stop Waiting Around: Async & Await in Python Explained

Brad Hankee — Thu, 02 Oct 2025 13:30:11 +0000

Hey JavaScript… Python’s got async too!

So what exactly is async, and why should you care about it in Python?

Since Python has become the go-to language for AI, data, and backend services, understanding asynchronous programming is more important than ever. If you’re making calls to LLMs, APIs, or any external service, async gives you a powerful way to manage those operations without your program sitting idle and wasting time.

What Async Actually Is

Think of async as lightweight concurrency. It’s similar to threading or multiprocessing, but much simpler to write and more efficient in many cases.

When you define a function with:

async def my_function():
    ...

you’re not just making a normal function. Technically, you’re creating a coroutine — a special kind of function that can be paused and resumed.

What Happens When You Call a Coroutine?

Here’s the gotcha: if you just call it, you don’t actually run it. You get back a coroutine object. To execute it, you need the await keyword:

result = await my_function()

That await tells Python: “Pause here until the coroutine is done, then give me the result.”

So while the word “async” sounds non-blocking, the await line itself is blocking for that specific call.

Enter the Event Loop

The real magic comes from Python’s built-in event loop (provided by asyncio). The event loop is like a conductor for your coroutines. While one coroutine is waiting — say, for an API call — the loop can run another one in the meantime.

This gives you concurrency without the complexity of threads.

Running Multiple Coroutines

One of the coolest features is asyncio.gather(). With it, you can schedule multiple coroutines to run “at once” (really, managed by the event loop):

import asyncio

async def first_run():
    await asyncio.sleep(1)
    return "First done"

async def second_run():
    await asyncio.sleep(2)
    return "Second done"

async def third_run():
    await asyncio.sleep(1)
    return "Third done"

async def main():
    output = await asyncio.gather(
        first_run(),
        second_run(),
        third_run()
    )
    print(output)

asyncio.run(main())


Output:

['First done', 'Second done', 'Third done']

Even though second_run() takes longer, the others don’t wait around — the event loop keeps everything moving efficiently.

Takeaway

async and await give Python developers an elegant way to write concurrent code. Whether you’re working with LLMs, APIs, or just want your app to be more responsive, it’s a tool worth learning.

So next time someone drops “coroutine” in your Slack thread, you’ll know what’s up. 😉

AI is now my Health Coach ... and it's working 🏋️

Brad Hankee — Fri, 19 Sep 2025 18:21:34 +0000

Connecting My Smart Scale to Gemini LLM for Custom Daily Meal Plans

Recently, I built a local app that connects my withings smart scale to Google's Gemini LLM and uses my real-time daily weight data to generate custom daily meal plans. The goal: hit my target body weight while preserving as much lean mass as possible.

This article breaks down the idea, the tech stack, and some key learnings — including how temperature values in LLMs can drastically affect the type of outputs you get.

Why I Built This

I wanted a way to:

Automatically collect my weight data every morning.
Feed that into an LLM with a dynamic and customized prompt.
Get back a set of meals tailored to my caloric needs for that day — with a focus on protein intake to preserve muscle.

Instead of manually calculating macros and searching for recipes, the LLM now does all of this for me.

The Tech Stack

Here's the setup:

Withings Smart Scale – Syncs weight data daily (total, lean mass, fat mass).
Python – language built with to get data and hook into LLM.
Gemini LLM – Takes weight, target weight, and some user preferences as input.

NOTE: Withings API is lets say... not great to use. After seeing this opinion all over I decided to make my life easy and use an applet from IFTTT to get my data into a google sheet. This made sense since this is a local app since it uses a very specific scale.

Sample of Output

The only thing I give the LLM everyday are the proteins I have and plan to eat. In this case you can see if told it 85/15 ground beef and chicken thighs.

Progress so Far

So far it's been great and I am down about 3 pounds. I added into the prompt to give me 2 options per meal so it would be somewhat flexible. I added history so that if it gives me a menu or item I do not have I can tell it and it will give me a better option such as this...

Working With LLM Temperature

One of the most interesting discoveries was how temperature affects the LLM's output.

Low temperature (0.0–0.3) → Very consistent results. The LLM mostly gives the same meal plan with minor variations. Good for keeping macros stable.
Medium temperature (0.5–0.7) → Adds more variety to meals. You get different recipes day to day, but they still hit macro targets.
High temperature (0.8–1.0) → Very creative. Sometimes too creative — you get exotic meals or unusual combinations that technically hit macros but might not be practical.

I found that 0.5 was the sweet spot: balanced creativity without going off the rails.

Here is a good example of the differences in the temperature. The first image is at .9 and the second at .1. You can see in the .1 the numbers are more consistent with almost always referencing 5oz for the portion sizes.

Temp @ .9

Temp @ .1

Key Challenges

Consistency: Sometimes the LLM would under- or over-estimate calories. I had to add a check to ensure the total calories matched my target before saving the plan.
Variety vs. Adherence: Too much meal variety made grocery shopping harder. I added an option to limit variety to a weekly rotation.

Takeaways

LLM temperature tuning matters a lot — find the right level for your use case.
Automating meal plans saves mental energy and reduces decision fatigue.
Preserving history enables deeper personalization and makes it easier to see what works over time.

You can check out the code in this Repo if you would like. Thanks for reading!

TypeScript Primer ( Intro -> Kinda Advanced)

Brad Hankee — Mon, 12 Apr 2021 12:38:17 +0000

Why TypeScript? I mean do we really want to write more code when the whole talk over the last decade has been about being more concise.
YES!
Yes, because writing a little more up front will help prevent all those production bugs that no one can afford. This can prevent you or others from drilling down call stacks in the browser dev tools as well.

Another, and maybe the best reason, is the integrated documentation and IntelliSense that will make your life as a developer great since it feels like your coding with a rubber duck always looking over your shoulder screaming in your ear what you can and cannot do.

How does TypeScript work?
TypeScript is written in .ts extension files. This allows the typescript compiler, which the user installs, to see these files and compile them into the vanilla JS files.

TypeScript Basics

Type Inference(Implicit)- Typescript guesses the type for us

let firstTS = 36
// This will show as: let firstTS: number

Type Annotations(Explicit) - We (devs) tell TypeScript the type

let firstTSAgain: number = 36
// This will show as: let firstTS: number

As you can see both have same result as TypeScript will apply type number when variable is declared with a value as number. In this case there's no need to specify and be redundant. But if you are declaring a variable with out a value this is necessary.

let missingVal: number

// You can also extend to have multiple types such as:
let moreOptions: (number | string)

Types and Interfaces

One of the best parts of TypeScript is creating your own types which really allows you to control the structure of your code to a precise level. In this example we're making a type that can only be a certain string in a set of strings that we specify.

type FavBand = "Weezer" | "Tool" | "GreenDay" | "Dropkick Murphys"

let coolBand: FavBand = "Tool"

Interfaces are very much like types but more specific to data shapes such as objects like we see here. Notice in the property for drinksCoffee the ?. This is to set this property to be optional and not mandatory.

interface PathToSenJSDev {
    language: string,
    drinksCoffee?: boolean
}

let dev: PathToSenJSDev = { 
    language: 'JS',   
    drinksCoffee: true   
}

Functions

A basic version of a function is shown here where the parameters are set as a type and then after the parentheses the return value of the function is also specified. If a string were to be passed in the function call TypeScript would show an error on the spot.


function doubleMe(num: number): number {
    return num * 2
}

doubleMe(2)

Mapped Types

My favorite part of TypeScript so far. Think of mapped types as being able to apply specific functionality over another type.

In this example we're going to use food to learn about mapped types by setting a recipe interface and then learning how to map over the interface and make the properties readonly and optional.


type range = 1|2|3|4|5|6|7|8|9|10

// Main Interface
 interface Recipe {
     numIngred: number;
     cookMethod: string;
     score: range
 }

 let BeefBourguignon: Recipe = {
    numIngred: 8,
    cookMethod: "Simmer",
    score: 9
 }

// Here we can modify 
 BeefBourguignon.numIngred = 2;


// Create a readonly version that can map over a type 
// Syntax [P in keyof T] is depicting "Property in keyof Type"

 type ReadOnlyRecipe<T> = {
     readonly [P in keyof T]: T[P]
 }

 let readOnlyBeefBourguignon: ReadOnlyRecipe<Recipe> = {
    numIngred: 8,
    cookMethod: "Simmer",
    score: 9
 }
// Will not allow since this is now readonly
//  readOnlyBeefBourguignon.numIngred = 4


//Different version for adding optional to each property
 type OptionalProps<T> = {
     [P in keyof T]? : T[P]
 }

Wrap Up

This is just a primer that includes a small small set of features for TypeScript but I hope I picked some good use cases where it would be easy to see how simple it is to start using as well as the power of the extendability it can have on a codebase. I think it is safe to say if you are planning on being a JavaScript dev at least for the next few years you should have this in your toolset.

-- Brad
PathToSeniorJS

JS Promises.bonus(useCases)

Brad Hankee — Sun, 07 Mar 2021 17:58:25 +0000

This post will QUICKLY cover the basics of promises then go into the other side of promises rarely talked about(Promise.all(),Promise.allSettled(), Promise.race(), Promise.any()). Great way to discover more uses for promises and impress that interviewer at some point. If you prefer a video version please check out...

JUNIOR DEV LEVEL
Ok so if this isn't the first time you seen Promises feel free to skip to next section. Here is the summary of what a promise is in JS. Promises give us a better way to handle callbacks and more notably the callback hell that many talk about.
Simplified: With more then one callback a pattern that made it difficult to read and maintain JS such as this beauty...

Call Back Hell Example

callOne(args, () => {
  // Wait for One then call Two
  callTwo(args, () => {
    // Wait for Two then call Three
    callThreeRejected(args, () => {    
    })
  })
})

Functions used in examples

 let callOne = new Promise((res, rej) => {
   return setTimeout(res, 3000, "Call One Returned")
 })  

let callTwo = new Promise((res, rej) => {
   return setTimeout(res, 2000, "Call Two Returned")
 })  

let callThreeRejected = new Promise((res, rej) => {
   return setTimeout(rej, 1000, "Call Three REJECTED")
 })

Common usage chaining promises in sequence



callOne
.then(data => {console.log(data); return callTwo})
.then(data => {console.log(data); return callThreeRejected})
.then(data => {console.log(data)})
.catch(err => console.error(err))

//With Async / Await
async function useAsync(){
  const dataOne = await callOne
  console.log(dataOne)

  const dataTwo = await callTwo
  console.log(dataTwo)

  const dataThree = await callThreeRejected.catch((e) => { 
    console.error(e)})
  console.log(dataThree)
}

useAsync()

console.log
"Call One Returned"
"Call Two Returned"
"Call Three REJECTED"

SENIOR DEV LEVEL
Promise.all([getDataOne, getDataTwo, getDataThree])
Summary:Returns array of all promise data UNLESS one is rejected. Should be named to Promise.allOrNothing()
USE CASE: When results from more then one API call are needed to do something with(display in a ChartJS graph). This makes sense since if one call is rejected the chart cannot be built correctly.


let consumeParallel = async () => {

  let [resultsOne, resultsTwo] = await Promise.all([callOne, callTwo])


  // Use for error handling and comment out prev 7 lines
  // let [resultsOne, resultsTwo, resultsThree] = await Promise.all([callOne, callTwo, callThreeRejected]).catch(err => console.error(err))

  console.log(`All Promises: ${resultsOne} && ${resultsTwo}`) 

}

consumeParallel()

console.log
"All Promises: Call One Returned Call Two Returned"

Promise.allSettled([getDataOne, getDataTwo, getDataThree])
Summary:Wait for no more pending promises (all settled) meaning each either resolved or rejected.
USE CASE: Seemingly few use cases for this (if you have others put in comments please). One that is consistent is using this for indicating when a displayed loader/spinner should be removed from screen.

let consumeSettled = () => {  
  Promise.allSettled([callOne, callTwo, callThreeRejected])
    .then(promiseResults => console.log(promiseResults))
    .catch(e => console.error(e))  
}

consumeSettled()

console.log
[
 {status:"fulfilled", value:"call one returned"},
 {status:"fulfilled", value:"call two returned"},
 {status:"rejected", reason:"call three REJECTED"}
]

Promise.race()
Summary: Takes in iterable such as an array and returns data for the first settled (resolved or rejected) promise.
USE CASE:An interesting use case for .race() is having one promise along with another that resolves with a certain time period in ms and if that one resolves first show a loader/spinner.

let racePromises = async () => {  
  let firstDone = await Promise.race([callOne, callTwo])

  console.log(`First Promise Settled: ${firstDone}`) 
}

racePromises()

console.log
First Promise Settled: Call Two Returned

Promise.any()
Summary: Takes in iterable such as an array and returns data for the first resolved promise.
USE CASE:For a performance use case a developer can use .any() to set up an array of promises if the users are worldwide and more than one server is available. This would allow for the fastest response time from a server.

let anyPromise = async () => {  

  let firstDone = await Promise.any([callOne, callTwo]) 
  console.log(`First Resolved: ${firstDone}`)


}

anyPromise()

console.log
"First Resolved: Call Two Returned"

There you go. Hope this helps at least one person see the potential of using promises and the built in methods it allows.

Share More JS / Avoid More BS

Brad Hankee — Mon, 20 Jan 2020 02:33:50 +0000

The greatest appeal for me becoming a JavaScript developer was the community. But more specifically the ability to, at any level, spread knowledge learned and also learn from others everyday. One thing that I find that correlates very strongly with imposter syndrome is ego. Just like going to the gym if you let your ego get the best of you it will slow your progress and hurt you fast usually in the form of a pulled muscle. This is no different in programming and gaining knowledge from your peers around you.

Lately after two years of being a JS Dev I've been trying to get rid of all imposter syndrome and as I learn things, big or small, share those things. In my job we pretty much rely on vanilla JS for most of our App. I have known about IIFE's and pretty much how they function but never came across this particular use case until this week and had to share it. Just for a quick summary of IIFE's:

IIFE:Immediately Invoked Function Expression

Example: (function runNow(){
console.log("Hello IIFE!")
})()

So the basics are that this function will be declared and ran one time right after it is declared. When you start incorporating closure this gets really exciting. Here is the pattern I saw this week and went down a rabbit hole exploring.

let counter = (function() {

    let current = 0;

    return () => current += 1  

}());

console.log(counter()) //1
console.log(counter()) //2
console.log(counter()) //3

As you can see counter holds the value and doesn't reset but almost acts like state in a stateful component in React. This is the perfect example to show how closure works in JS.

At first it wasn't obvious what was happening until I really inspected the code. Here is a more explicit version of the above code that should make a little more sense.

let counter = (function() {

    let current = 0;

    return {
        getNext: () => current = current + 1

    };

}());

console.log(counter.getNext()); // 1
console.log(counter.getNext()); // 2
console.log(counter.getNext()); // 3

So what's really happening here, going back to the first more concise version, is the first time the IIFE runs it is declaring the counter but since the variable now has the return function on it it will run that return function (which has access to the variable due to closure) and will not reset the counter to 0 each time.

After seeing how this code functioned I had a ah-hah moment and starting to defaulting to my oh cool I want to show this to someone but then the imposter syndrome started creeping in. If you're honest with yourself you know what I mean. The "I'm going to show someone and their going to make that condescending face and be like yeah that has been around a while now." But then I thought what the hell is the point of working with a team and actually having a job with peers if we cannot share information and show each other cool things.

The approach I use for this is to show my enthusiasm while showing someone the code. Think about it. If you pull a senior dev over and be like "Hey check this out this is pretty cool" and continue showing them how the IIFE creates a closure and seems to keep state, even if they know it, they will see your enthusiasm for learning something new. So I did just that and the senior dev hasn't seen that exact use case before. This is one of the scenarios that's a win-win and should always be sought out in our profession in my opinion.

On top of that for VetsWhoCode we have a member that slacks out a code challenge daily so I hit him up about possibly using this in a challenge and his reply back was...

He was cool enough to reply back with a great resource that I actually started reading when I first got my first JS job but at the time it didn't really make sense for me since my Javascript experience was more narrow at that time. Like many books and other resources timing is key and now after having worked in a large JS codebase for a few years I am going through it again and getting much more out of it.

When you learn something or something finally clicks share that with anyone and everyone.

--Brad

My Journey: Launching Jets to Helping Businesses Take Off

Brad Hankee — Thu, 13 Jun 2019 23:54:34 +0000

My Journey: Launching Jets to Helping Businesses Take Off

Often I am asked about my transition from active duty Air Force to front-end developer. Today I will tie this in with another question I am frequently asked as why do we need programming bootcamps since there is so much free and cheap educational content available today.

My journey started while being stationed in Germany. I started tinkering with some HTML and CSS files and quickly showed off my red box and blue circle I was able to display in the browser to my wife. She was really excited to say the least 😆.

With the complexity seen in modern web sites and web applications today I knew I needed to learn an actual programming language to add functionality to websites. So I ran a Google search thinking a clear answer would be right there at the top on the results… but no 🤷‍♂. Every developer, every person that knew what code is seemed to have a very strong opinion how to get started. Python sounded good to me and within a few weeks I had worked my way through Learn Python the Hard Way and felt pretty good about where my skills were going. After I was done I knew some basics and made some cool games but still had questions like …

"How do I take this language and tie it into a website?".

Having some cool skills but the inability to tie them together to actually create anything I took a break until I moved back to the States about 6 months later. Being a fan of podcasts I stumbled onto one about programming and learned about this bootcamp for vets, VetsWhoCode, that sounded promising.

This is where my real development journey began. VetsWhoCode gave me a roadmap to transition into my new career. They didn't only provide the quality instruction and direct me to the resources that the top performers in our profession are utilizing, but they also bring you into an ecosystem of real working developers who make sure they communicate the tools and skills needed to break into the development world with more then just knowing the basic coding skills.

It's one thing to know how to code in JavaScript or connect to a database to store secure data but the professionals also depend on more essentials such as tooling, build processes and how to effectively work with seasoned developers so a effective workflow is maintained in a company. Often overlooked in some bootcamps, this is front and center as a VetsWhoCode student giving a much needed edge 🔪 while interviewing for that first job.

So by now you may be thinking it must be nice to have the time to do this and learn a valuable skill without life getting in the way right? Even though I transitioned out my wife is still active duty which means me, as the spouse, is expected to pick up pretty much everything family related if and when my wife has training, deploys or whatever the military can throw our way. Add to that an amazing 4 year old son who, as normal boy, gets into trouble every 5 minutes.

We end up getting our base of choice in Virginia and get excited to purchase our first home. We drive up to VA and find a home and return to Florida excited with all cylinders firing and life is great when… we find out my wife has cancer. To say this stopped us in our tracks and caught us off guard is an understatement.

Still moving to VA? No one knows.

Have support for medical appointments etc? Closest family is 1500 miles away.

But the military can show it's true colors and shine when adversity hits home and we had officers from various branches communicating and making sure my wife was getting the best medical care while still making sure our base of choice was secured for our future.

Prioritizing being a caregiver, making sure to transfer my son into a new school while at the same networking to find my first development job proved to be a full-time job. Having an amazing wife who made sure I would not back away from this because of this challenge proves that having a support system in place and not having an option to give up is for sure the secret sauce for anything in life.

As a fresh VetsWhoCode grad I proved myself to be able to tutor other bootcamp students at other bootcamps and honed my instructional skills with over 500 hours.

Wanting a job that I could help build user facing products I went to a company that builds software utilized by multi-national companies.
It was an easy answer when I was given the opportunity to give back and devote personal time instructing students with VetsWhoCode. After all sharing quality information and growing each others skills is the best way to stay ahead in the technology and make companies that change the world 🌎.

Brad Hankee

DEV Community: Brad Hankee

How I Built an Evaluation Pipeline for AI Image Generation

We automated blog image generation with Imagen 4. It worked beautifully... except when it didn't.

The Problem

The Solution: Automated Evaluation

Too many NOs equal a YES

The Takeaway

The KC-10 Was My First Codebase — I Just Didn’t Know It Yet

From KC-10 Aircraft to Codebases: How I Learned System Design Before Computer Science

System Design: Schematics → Architecture

Troubleshooting & Debugging: Multimeters → Logs

Oversight & Quality: 100% or It Doesn’t Fly

Continuous Improvement & Mentorship

How This Shapes Me as an Engineer

Software Fun-duh-mentals - DNS

DNS: The Underrated Backbone of Scale and Security

What DNS Actually Does

DNS as a Scaling Tool

1. Global Load Distribution

2. CDN Enablement

3. High Availability and Failover

DNS as a Security Layer

1. DNSSEC (Domain Integrity Protection)

2. Traffic Filtering and Threat Mitigation

3. Reducing Attack Surface

Why DNS Belongs in Every Engineer’s Toolkit

How I Built an AI That Can Make Developers Cry (And Learn)

🧠 Tech at a Glance

🚀 How It Works

🤖 AI Prompt Strategy

💡 Challenges Solved

📈 What’s Next

📝 Final Thoughts

Function Calling in LangChain: Turning Chatbots into Enterprise Copilots

Understanding Function Calling and Tool Calling in LangChain

🧠 What Function Calling Actually Does

⚙️ Core Functions for Tool Handling in LangChain

🧩 Example: Using bind_tools() for Function Calling

🔄 Switching Between Models Is Easy

⚡ Parallel Tool Calls

🔗 Common Tool Use Cases

🧠 The Responsibility of Description

🏢 How Function Calling Impacts Enterprise and Business

1. Seamless System Integration

2. Governance and Standardization

3. Improved Efficiency and ROI

4. Vendor Flexibility

Final Thoughts

“Don’t Chain Yourself Down — Graph It Out! 🔗 (LangGraph, Memory, and the Future of AI Workflows)”

Understanding LangGraph: Building Smarter, Stateful AI Workflows

What is LangGraph?

When to Use LangGraph Over LangChain

State Management: Reducers and Super-Steps

Memory and Checkpointing

Visualizing It: Nodes, Memory, and Checkpoints

LangSmith Integration

Built-in Serper Wrapper

Time Travel with Checkpoint IDs

Wrap Up

Stop Waiting Around: Async & Await in Python Explained

AI is now my Health Coach ... and it's working 🏋️

Connecting My Smart Scale to Gemini LLM for Custom Daily Meal Plans

Why I Built This

The Tech Stack

Sample of Output

Progress so Far

Working With LLM Temperature

Key Challenges

Takeaways

TypeScript Primer ( Intro -> Kinda Advanced)

TypeScript Basics

Types and Interfaces

Functions

Mapped Types

Wrap Up

JS Promises.bonus(useCases)

Call Back Hell Example

Functions used in examples

Common usage chaining promises in sequence

Share More JS / Avoid More BS

🧩 Example: Using `bind_tools()` for Function Calling