DEV Community: Austin Vance

Everybody Tests

Austin Vance — Tue, 03 Feb 2026 19:43:37 +0000

Everybody Tests

Everybody tests. Every developer. Every team. The debate isn't about whether you test. It's about whether you automate it.

I hear the pushback all the time. "We don't do TDD." "We don't have time for tests." "Tests slow us down." Fine. But watch what happens when that same developer finishes a feature. They open the browser. They click around. They fill out a form. They check the button. They verify the data.

That's a test.

When QA maintains a spreadsheet of scenarios to run before each release... that's a test suite. When you demo to stakeholders and walk through the happy path... that's acceptance testing. When you "just quickly check" that your refactor didn't break anything... that's regression testing.

The tests exist. They always have. They're just manual. Trapped in someone's head.

You already think test-first

Most developers already think test-first. They just don't write it down.

Before you write a function, what do you do? You think about what it should do. You imagine calling it with some input. You picture what comes out. You might even sketch a few edge cases in your head, on a post-it, on a whiteboard. What if the list is empty? What if the user isn't authenticated?

That's the test. You've written it. It exists. It's just in your brain instead of in code.

Then you implement. Then you verify it does what you imagined.

Congratulations, you already did the hardest part of test-first development.

The cost nobody talks about

Manual testing isn't free. It's a subscription.

Every time you click through your app to verify a change, you're paying. Every time someone else on your team does the same verification, that's another payment. Before every release. After every refactor. When something breaks in production. When a new hire needs to understand what the system does.

That 30-second click-through? You'll do it a hundred times. So will everyone else. Multiply by every feature, every edge case, every browser.

The math is brutal. An automated test takes minutes to write and milliseconds to run. A manual test takes seconds to run, but you'll run it thousands of times.

The teams that say they don't have time

I've seen teams who are adamant they "don't do TDD" spend entire days before a release running through test scripts. They hire QA teams whose job, their actual full-time job, is clicking the same buttons over and over.

And then they tell me they don't have time to write tests.

What they mean is this: they don't have time to write the test once. But they have infinite time to run it manually forever.

The same satisfying satisfying, all over again

We're about to make the exact same mistake with AI.

Watch what happens when someone builds an agent. They tweak a prompt. They run it. They look at the output. They squint. They decide if it's good enough. They tweak again. They run it again. They squint harder.

That's an eval. That's literally an eval. You're evaluating the output of your system against some criteria in your head.

Everybody evals. The question is whether you automate it.

Eval Driven Development

The parallel to TDD is exact. Before you write an agent, you think about what it should do. You imagine the inputs. You picture what a good output looks like. You might even think through some edge cases, what if the context is empty? What if the user asks something adversarial?

That's the eval. You've already written it. It's in your brain. Write it down.

Define what good looks like before you start prompting. Capture the examples. Capture the edge cases. Automate the judgment, whether that's exact match, semantic similarity, or LLM-as-judge.

Then iterate. Change the prompt, run the evals, see what breaks. Change the model, run the evals, see what improves. Swap in a new retriever, run the evals, know immediately if you're moving forward or backward.

This is Eval Driven Development. It's just TDD for the age of AI.

Vibes don't ship

With traditional software, at least the output is deterministic. You click the button, you get the same result.

With agents? The output is stochastic. You run the same prompt twice, you get different results. Manual review is useful for exploration. It’s useless as a measurement system. You can't trust your own squinting because you're sampling a distribution. That one good output you saw could happen 90% of the time. Or maybe 20% of the time. You have no idea.

This is why the teams building AI systems have eval suites, they have regression sets, they run benchmarks on every commit. They know their success rates because they measure them.

The teams that don't? They're shipping on vibes. And I've seen where that ends. It ends with an agent in production that works great in the demo and fails catastrophically on real traffic. It ends with prompt changes that "seemed fine" but tanked accuracy by 15%. It ends with executives asking why the AI feature is so unreliable, and engineers shrugging because they never actually knew how reliable it was in the first place.

The choice is the same as it always was

Twenty years ago, the industry had to learn that manual QA doesn't scale. That you can't hire enough people to click through every scenario before every release. That automated tests aren't a luxury.

Some teams learned that lesson. Some are still running through spreadsheets the night before launch.

Now we get to make the same choice again. You can build agents by squinting at outputs and hoping for the best. Or you can write down what good looks like, automate the evaluation, and actually know whether your system works.

Everybody tests. Everybody evals. The only question is whether you're going to keep doing it by hand, or whether you're finally going to let the computer do its job.

If your team is building agents without evals—or still stuck in manual testing on the traditional side—drop me a note or check out focused.io. We've helped teams escape the spreadsheet and the squint.

Context Will Replace Your Design

Austin Vance — Tue, 27 Jan 2026 03:34:12 +0000

There's a particular irony in typing a Slack DM to an AI assistant that will help me write about why interfaces don't matter anymore... There’s just words in a box (or in this case,a series of manic voice notes), and a system that understands what I need.

I've been running Clawdbot, a persistent AI assistant, for a few days (yeah only days) now. It reads my email, manages my calendar, browses the web on my behalf, and remembers conversations across sessions. It does everything my current VA does. It's changed how I think about software design. Clawd has no interface, no web page for interaction, nothing... and the absence of a traditional interface hasn't diminished the experience. If anything, it's clarified something we've been dancing around since agents have started to take shape: most interface design exists to compensate for computers not understanding what users want.

The Translation Layer We Built

For fifty years, interface design has solved a specific problem: we humans think in fuzzy concepts and intentions, while computers operate on instructions and data. Going from "I want to book a flight to Chicago next Tuesday" to the seventeen form fields, dropdowns, and confirmation screens required to book a flight is what interface designers do.

There are disciplines around this translation work. Information architecture. Visual hierarchy. Affordances and signifiers. Progressive disclosure. All this design exists to help people navigate the rigid structures that computers require. Click here, not there. Fill this field before that one. Read the error message, understand what went wrong, try again.

Design makes speaking “computer” effortless, drawing on the premise that humans adapt to the system.

When the System Adapts to You

Over the weekend, I sent a voice memo to my assistant while skiing that says, "draft a 2,000-word essay about the future of design in a post-agentic world, use Clawdbot as a case study, make it sound like my writing style," and... it did a pretty mediocre job on the essay… but the interaction was perfect. I used WhatsApp and Slack, used voice notes while driving and skiing, it read my other articles on focused.io and austinbv.com. It blew me away. It's a new paradigm for design.

The agent, clawdbot, did all the input work for me. It didn't need maliciously designed input fields, instead the LLM can parse my natural language, and it doesn’t want visual hierarchy to guide attention because it just asks clarifying questions. There’s no more progressive disclosure because it can handle complexity directly.

So, what does design become when the translation layer is the system itself?

The Clawdbot Case Study

My current setup involves an AI assistant (clawdbot) that:

Lives in WhatsApp and Slack (messaging interfaces I already use)
Maintains persistent memory across conversations
Has access to my email, calendar, and files
Can browse the web and interact with services
Runs scheduled tasks and proactive check-ins

The "interface" is the chat apps, but the beauty is the tools. Clawdbot connects to other APIs and handles tasks that would require dedicated applications and logins and passwords and and 2fa and have websites with carefully designed interfaces: email clients, calendar apps, travel booking sites, task managers, note-taking tools.

It feels like noise now that I think about it... Designers in an agentic world should be thinking as the Agent, as the user, not a person. You can then frame it as:

Context structures - What information does the AI need to understand my preferences, constraints, and goals?
Memory systems - How does the assistant maintain continuity across sessions without drowning in irrelevant history?
Tool interfaces - How do we expose capabilities (email, calendar, web browsing) in ways that AI can reliably invoke?
Failure modes - What happens when the AI misunderstands? How do we make correction natural?

The design becomes decoupled from the interface and more about “How it works” rather than “how it looks.” Isn’t that what designers wanted all along?

Context Engineering: The New Discipline

There’s a new term for what's emerging: context engineering. It's the discipline of designing the information environments in which AI agents operate.

Traditional interface design asks: "How do we present information so humans can find and act on it?"

Context engineering asks: "How do we structure information so AI can understand and act on it appropriately?"

Sound similar? They are, but lead to radically different practices. Visual hierarchy doesn't matter to an AI, it can process information in any order. Color and iconography don't matter. Animation and micro-interactions don't matter.

What matters:

Information completeness - Does the AI have everything it needs to make good decisions?
Semantic clarity - Is the information structured in ways the AI can reliably parse?
Constraint specification - Are the boundaries of acceptable action clearly defined?
Context efficiency - Can we convey what's needed without wasting tokens (and money, and latency)?

That last point deserves emphasis. In the current paradigm, loading a webpage or json or whatever costs the user attention and costs the provider bandwidth, both relatively cheap. In an agentic paradigm, loading context costs tokens, which cost real money at scale, add latency that compounds, and confuse agents across multi-step tasks.

The entire economics of information presentation flips. Dense, structured, machine-readable information beats sparse, visual, human-readable information.

What Agents Need

When I watch Clawdbot browse the web on my behalf, it’s painful. It loads pages designed for humans, rich with images, navigation, whitespace, branding, and extracts the tiny fraction of information it needs. A flight search that a human might complete in five minutes of visual scanning takes the AI multiple page loads, screenshots, and navigation of UIs designed to be intuitive for people who look rather than read.

This is obviously transitional. As agents become more prevalent, services will increasingly expose information in agent-friendly formats. I don’t think this is traditional APIs (they are too noisy), but something more flexible, semantic interfaces that can adapt to varied requests while remaining token-efficient.

And a new design challenge emerges, going from "how do we make this look good to humans" to "how do we make this legible to agents while remaining interpretable by humans for oversight?" Yup, with oversight.

It’s harder than it sounds. Pure API endpoints are good for agents but opaque to human oversight. Visual interfaces are easy for humans to monitor but wasteful for agents. The emerging discipline will be the middle ground: interfaces that are simultaneously agent-efficient and human-auditable. Until the agent just gets what it needs and builds the interface on the fly.

The Skills That Transfer

If you're a designer reading this with anxiety about obsolescence. I think your core skills transfer, building APIs had users, the systems were users, the developers were users. Now the Agents are users.

Understanding user intent remains crucial. You're solving for what people want, even when the interface between the user and the system is an agent.

Information architecture evolves. Structuring information so an agent can navigate it requires the same thinking about relationships, hierarchies, and access patterns.

Systems thinking becomes more important. Agent-based systems involve more moving pieces, more failure modes, more need for coherent components.

What won’t transfer is the visual craft, the micro-interactions, the animation choreography.

Design Becomes Invisible

There's a Marshall McLuhan quality to what's happening. The interfaces that are everywhere in our visual landscape, the screens, buttons, forms, and menus, they aren’t the point. They are necessary infrastructure for the pre-AI era when computers couldn't understand intent and humans had to translate, or the interface had to force it.

As that scaffolding comes down, design becomes the structure of context and the shape of information. It’s the logic of systems that we interact with but no longer see.

So, the best interface is no interface, as the cliché goes. And we're about to find out if we meant it.

My AI assistant doesn't have a color scheme. It doesn't have a logo animation or a distinctive illustrative style. It lives in generic chat windows with access to multiple platforms. And it's the most thoughtfully designed software I’ve interacted with, because the design is in what it knows, how it reasons, and how it adapts to what I need.

That's the future of design in an agentic world.

If you like this and are thinking about design and agents check out Focused we build AI agents that actually work. We're a LangChain consulting partner and help teams move from prototypes to production... context engineering included.

Customizing Memory in LangGraph Agents for Better Conversations

Austin Vance — Wed, 16 Jul 2025 17:24:47 +0000

Right now everyone is building conversational agents and having them remember past interactions is crucial for creating natural, engaging user experiences. LangChain, a powerful framework for developing LLM-based applications, has evolved its memory management. Recently, in v0.3.x they deprecated indivdual memory management classes, the recommended approach for memory in agents is to use LangGraph persistence. This tutorial dives into customizing memory using LangGraph, addressing common challenges like maintaining persistent chat history and optimizing for better conversations. Whether you're building chatbots or intelligent assistants, mastering LangGraph memory will enhance your agent's intelligence and make the UX feel more seamless across interactions.

Overview of Memory Types in LangChain

As of LangChain v0.3.1, several legacy memory types have been deprecated in favor of more robust persistence via LangGraph. Here's a quick overview of the deprecated types and the migration path:

ConversationBufferMemory: Deprecated. Previously stored entire conversation history.
ConversationBufferWindowMemory: Deprecated. Limited to recent messages.
ConversationSummaryMemory: Deprecated. Summarized interactions.
ConversationEntityMemory: Deprecated. Extracted and stored entities.

All of these have been replaced by LangGraph's checkpointing system, which provides built-in persistence, support for multiple threads, and advanced features like time travel. LangGraph uses checkpointers (e.g., InMemorySaver for in-memory, SqliteSaver for persistent storage) to manage state across conversations.

For more on the migration, refer to the official migration guide.

In this langchain memory tutorial, we'll start with simple setups using LangGraph and progress to custom persistent implementations.

Setting Up Simple Memory Buffers

Let's begin by setting up a basic conversational agent with memory using LangGraph and InMemorySaver. This provides simple, in-memory persistence across interactions within the same thread.

First, ensure you have the necessary dependencies installed. We'll use LangChain version 0.3.26 (the latest as of July 2025), LangGraph, and OpenAI for the LLM.

uv add langchain langchain-openai langgraph langchain-community --bounds lower

Now, here's a Python example to create an agent with simple memory:

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import MemorySaver

# Initialize LLM (replace with your API key)
llm = ChatOpenAI(model="gpt-4o", temperature=0)

# Define a simple tool (e.g., for math calculations)
@tool
def multiply(a: int, b: int) -> int:
   """Multiplies two numbers."""
   return a * b

tools = [multiply]

# Set up memory with MemorySaver
memory = MemorySaver()

# Create the agent
agent_executor = create_react_agent(llm, tools, checkpointer=memory)

# Interact with the agent using a thread_id for memory
config = {"configurable": {"thread_id": "chat1"}}

response1 = agent_executor.invoke({"messages": [{"role": "user", "content": "What is 3 times 4?"}]}, config)
print(response1["messages"][-1].content)  # Output: 12

response2 = agent_executor.invoke({"messages": [{"role": "user", "content": "What was the result of the previous calculation?"}]}, config)
print(response2["messages"][-1].content)  # Output: The previous calculation result

This setup uses MemorySaver to store and recall chat history within the same thread, making your langchain agents more context-aware.

Custom Memory Implementation

For more advanced scenarios, such as persistent storage across restarts, use a persistent checkpointer like SqliteSaver. First, install the required package:

uv add langgraph-checkpoint-sqlite --bounds lower

Here's how to create a persistent memory using SqliteSaver, ensuring conversations survive restarts—perfect for production chat apps.

import sqlite3
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.sqlite import SqliteSaver

# Initialize LLM (replace with your API key)
llm = ChatOpenAI(model="gpt-4o", temperature=0)

# Define a simple tool
@tool
def multiply(a: int, b: int) -> int:
   """Multiplies two numbers."""
   return a * b

tools = [multiply]

# Set up persistent memory with SqliteSaver
conn = sqlite3.connect("checkpoints.db", check_same_thread=False)
memory = SqliteSaver(conn)

# Create the agent
agent_executor = create_react_agent(llm, tools, checkpointer=memory)

# Interact with the agent using a thread_id for memory
config = {"configurable": {"thread_id": "chat1"}}

response1 = agent_executor.invoke({"messages": [{"role": "user", "content": "What is 3 times 4?"}]}, config)
print(response1["messages"][-1].content)  # Output: 12

response2 = agent_executor.invoke({"messages": [{"role": "user", "content": "What was the result of the previous calculation?"}]}, config)
print(response2["messages"][-1].content) # Output: The previous calculation result

This implementation uses SqliteSaver for file-based persistence (in "checkpoints.db"), providing true long-term conversation memory in LangGraph.

For fully custom behavior, you can subclass BaseCheckpointSaver to create your own checkpointer, tailoring persistence (e.g., to JSON files or other databases).

Example: Persistent Chat History

Building on the persistent memory above, let's apply it to a real-world example: a persistent chatbot for customer support. The agent remembers user details across sessions and restarts, improving personalization.

In the code snippet provided, after invoking with "Hi, I'm Bob.", stopping and restarting the script, then asking "Who am I?" should recall the name due to the SQLite storage. This addresses pain points in custom memory LangChain agents, ensuring seamless experiences across many sessions.

Optimization Techniques

To make your memory-efficient in LangGraph:

Limit History Length: Use message trimming functions like trim_messages to avoid token limits.
Summarization: Implement summary nodes in your graph to condense long histories.
Entity Extraction: Add tools for entity extraction and store in a separate memory store for focused recall.
Async Persistence: Use async checkpointers like AsyncSqliteSaver for high-traffic apps to prevent bottlenecks.
Monitoring: Leverage LangSmith to trace memory usage and optimize graphs.

These techniques optimize LLM agents memory, preventing issues like context overflow in extended conversations.

Conclusion: Enhancing Agent Intelligence

Customizing memory with LangGraph transforms basic chatbots into intelligent, context-aware systems. By leveraging checkpointers for persistence, you can build robust applications that remember and adapt across sessions. This not only improves user engagement but also positions your projects for scalability.

Ready to implement advanced conversation memory in LangGraph? If you need help with custom LangChain agents or optimizations, contact us at Focused.io, we're here to help you build agents that work!

Migrating Classic LangChain Agents to LangGraph a How To

Austin Vance — Wed, 16 Jul 2025 15:46:31 +0000

Takeaway: You can swap a legacy AgentExecutor for a LangGraph node in a single commit. The payoff is lower overhead, deterministic routing, and native persistence.

WHY MIGRATE NOW?

LangChain announced that with LangChain 0.2 the original agent helpers (initialize_agent, AgentExecutor) are deprecated and will only receive critical fixes. LangChain recommends moving to LangGraph’s node‑based approach for better control flow, built‑in persistence, and the ability to use multi‑actor workflows.

WHAT CHANGED IN LANGCHAIN 0.2 AND LATER?

Legacy pattern (langchain < 0.2) versus current pattern (langchain 0.2 or newer):

• Agent entry point – legacy: initialize_agent; current: graph node created with LangGraph helpers.
• Configuration – legacy: many function kwargs that are hard to extend; current: typed graph state and composable nodes.
• Persistence – legacy: DIY pickling or a custom DB; current: checkpoint helpers built into LangGraph.
• Deprecation status – legacy helpers are deprecated; the LangGraph approach is the long‑term, fully supported path.

CODE DIFF: FROM `initialize_agent` TO A LANGGRAPH NODE

Below is a minimal ReAct agent that calls a calculator tool—first the legacy way, then the LangGraph way.

Before (legacy agent)

from langchain.agents import AgentExecutor, AgentType, initialize_agent, load_tools
from langchain.chat_models import ChatOpenAI

from langchain_core.tools import tool


@tool
def capitalize(text: str) -> str:
    """Capitalize the text."""
    return text.upper()

llm = ChatOpenAI(model="gpt-4o-mini")

agent = initialize_agent(
    [capitalize],
    llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True,
)

response = agent.run("can you capitalize this text: hello world")
print(response)

After (LangGraph)

from langgraph.prebuilt import create_react_agent
from langgraph.graph import END, StateGraph
from langchain_openai import ChatOpenAI
from langchain.tools import Calculator

class State(TypedDict):
    messages: Annotated[list, add_messages]

@tool
def capitalize(text: str) -> str:
    """Capitalize the text."""
    print(f"Capitalizing text: {text}")
    return text.upper()

llm = ChatOpenAI(model="gpt-4o-mini")
tools = [capitalize]

Create the ReAct agent node

agent_node = create_react_agent(llm, tools)

Build a simple single‑node graph

graph = StateGraph(State)
graph.add_node("react_agent", agent_node)
graph.set_entry_point("react_agent")
graph.add_edge("react_agent", END)

agent_executor = graph.compile()

response = agent_executor.invoke({"messages": [{"role": "user", "content": "can you capitalize this text: hello world"}]})
print(response["messages"][-1].content)

The functional behavior is identical, but you gain an explicit state object, the ability to add router or guardrail nodes later without refactoring the agent itself, and full compatibility with LangGraph’s checkpoint and observability APIs.

UPDATING TESTS AND CALLBACKS

Unit tests with Pytest and LangSmith

rom graph import agent_executor

def test_capitalize_text():
    result = agent_executor.invoke({
        "messages": [{"role": "user", "content": "can you capitalize this text: hello world"}]
    })

    assert "HELLO WORLD" in result["messages"][-1].content

For richer coverage, use LangSmith’s pytest plugin to log run trees and score outputs with metrics instead of brittle string matches.

Callbacks
If you previously passed callbacks into initialize_agent(..., callbacks=[StdOutCallbackHandler()]), move them to the graph compile step (or to individual nodes for fine‑grained tracing):

from langchain_core.callbacks.base import BaseCallbackHandler
class PrintCallbackHandler(BaseCallbackHandler):
    def on_llm_start(self, serialized: dict[str, any], prompts: list[str], **kwargs: any) -> None:
        print(f"LLM start: {prompts}")

response = agent_executor.invoke({"messages": [{"role": "user", "content": "can you capitalize this text: hello world"}]}, {"callbacks": [PrintCallbackHandler()]})

PRODUCTION ROLLOUT CHECKLIST

Freeze versions: pin langchain>=0.2,<0.3, then move to 0.3 and the latest stable langgraph.
Refactor imports: search‑and‑replace initialize_agent( with create_react_agent(.
Compile once: cache the compiled graph (agent_executor) at application start to avoid cold‑start overhead.
State schema: define a TypedDict or Pydantic model for your graph state to catch breaking changes early.
Health probes: invoke the graph with {“message”: {role: {“user”: “ping”}}} and expect "pong" so orchestration platforms detect failures.
Checkpoint storage: configure S3, Redis, or SQLite persistence before rolling to production if your flows exceed a single request.
Observability: enable LANGCHAIN_TRACING_V2=true and send traces to LangSmith.
Canary deploy: route a slice of traffic to the new executor and compare latency and error rate against the legacy path.
Retire legacy code: delete deprecated agent imports when metrics hit parity.
Document the graph: export a GraphViz diagram and commit it so new teammates can visualize the flow.

FINAL WORD

Upgrading to LangGraph is not a risky rewrite; it is a surgical swap that positions your agent for reliable scale, granular observability, and future multi‑actor magic. Make the jump today and own the graph—before the graph owns you.

Why Big Classes Get Bigger: Understanding Preferential Attachment in Your Code

Austin Vance — Thu, 19 Dec 2024 16:15:53 +0000

The Law of Preferential attachment: Why your User class keeps growing

Software often models the natural world. One pattern I have been thinking about is why our biggest components continue to grow. In natural systems there is a phenomenon known as preferential attachment, which describes how new elements in a system tend to collect at the most connected nodes in the network. Zoologists observed this phenomenon in taxonomy where the largest class, order, family, etc collect newly named organisms.

The pull of the common class

This is exactly what happens in our codebases. Someone once said there are two hard things in computer science: “Naming things, cache-invalidation, and off by one errors.” I love the joke, but it hurts every time. Poorly named components create a gravitational pull forcing the next developer between a rock and a hard place: either comb through the component to understand what its purpose is and then refactor the name to be more specific, or take the path of least resistance and add new functionality further expanding the responsibility of the component. This decision creates a feedback loop attracting more and more “like” functionality.

Consider a component named UserHandler. The original intent could be to manage a user's authentication, but because of the vague name, the component could also logically handle anything user related. The UserHandler soon contains preferences, notifications, and social connections along with the original intention, authentication. Each addition makes new complexity even easier to add, moving it closer and closer to the “god class”.

Yes there’s math

There’s actually some math to back this up. Preferential attachment follows a power law distribution where the probability of new functionality being added to a component is proportional to the existing functionality of the component. We can express this mathematically if F(c) represents the functionality in component c, then the probability P of adding complexity to that component is:

\frac{F(c)^\alpha}{\sum_{i} F(i)^\alpha}

Where $α\alpha$ represents the strength of the preferential attachment.

Imagine a system where we have three components

* A - 100 lines of code
* B - 200 lines of code
* C - 1000 lines of code

And the strength of preferential attachment is 2 (which is a pretty common value in the power law) then we end up with

\frac{100^2}{(100+200+1000)^2}

\frac{1000^2}{(100+200+1000)^2}

The probability of adding to C is not 10x but 100x more likely. Which makes it more clear why some classes continue to grow while most remain small.

There is no strength in numbers

If it is not painfully obvious, the larger the component the more impact that that component has on the efficiency of future development. Large components become immovable objects in architectures shaping the systems evolution. This shape has a significant cost on the ability of a system to evolve.

Consider testing. As a component attracts more and more functionality its dependencies grow as well creating more and more potential interactions that must be validated every time the component changes. Changing one part of a system will eventually cascade to the “God Component” and then the changes to that component will require testing and updates to other seemingly unrelated parts of the code.

The answer to preferential attachment is more simply said than done, just name things better. It’s always easier to bring components together than it is to untangle them and refactor them apart.

Using the UserHandler example above

interface UserHandler {
    authenticate(credentials: Credentials): User;
    validateSession(token: string): boolean;
    revokeAccess(userId: string): boolean;
    authenticate(credentials: Credentials): User;
    validateSession(token: string): boolean;
    revokeAccess(userId: string): boolean;
    fetchPreferences(userId: string): UserPreferences;
    updatePreferences(userId: string, preferences: UserPreferences): UserPreferences;
    getDefaultPreferences(): UserPreferences;
    getNotificationSettings(userId: string): NotificationSettings;
    updateNotificationSettings(userId: string, settings: NotificationSettings): NotificationSettings;
    addSocial(userId: string, connectionId: string): string;
    removeSocial(userId: string, connectionId: string): string;
    listSocial(userId: string): string[];
}

This component clearly does a lot and if each method is implemented it could be hundreds of lines long with dependencies on databases, caches, and other whole components

The only constant is change

There are four clear concerns here that each could have their own class or component, creating more clear naming and a more clear place for new functionality to go

interface AuthenticationService {
  authenticate(credentials: Credentials): User;
  validateSession(token: string): boolean;
  revokeAccess(userId: string): boolean;
}

interface PreferenceService {
  fetch(userId: string): UserPreferences;
  update(userId: string, preferences: UserPreferences): UserPreferences;
  getDefaults(): UserPreferences;
}

interface NotificationService {
  getSettings(userId: string): NotificationSettings;
  updateSettings(userId: string, settings: NotificationSettings): NotificationSettings;
}

interface SocialService {
  addSocial(userId: string, connectionId: string): string;
  removeSocial(userId: string, connectionId: string): string;
  listSocial(userId: string): string[];
}

This form is more clear and gives clear indication of the behavior for each component and makes it easy to test and easy for developers to grok the context.

Build for change

Our job as developers is to build code that enables change in a system and by creating clear boundaries with naming we avoid the pull of preferential attachment making new components easier to build an new functionality easier to change old.

Just as natural systems tend toward entropy, software systems tend toward complexity, and the science supports it. Our role is to manage that complexity by introducing patterns and constraints ensuring sustainable and predictable growth of the system over time.

Shameless plug
If you've got a "god class" or "god service" and need help decomposing and untangling your largest components or systems drop me a note or check out focused.io. We love working with legacy code and helping it welcome the future!

Unlock the Power of LangChain: Deploying to Production Made Easy

Austin Vance — Wed, 14 Feb 2024 20:33:45 +0000

In this tutorial, Austin Vance, CEO and co-founder of Focused Labs, will guide you through deploying a PDF RAG with LangChain to production!

In this captivating video, we will dive deep into the process of deploying a rag to production, taking you on an informative and engaging step-by-step journey. Throughout this tutorial, we will explore the intricacies of transforming a local rag into a powerful and accessible resource on the digital ocean app platform. Don't miss out on this highly informative and exciting adventure - make sure to subscribe now to stay updated with all the latest content!
Don't forget to subscribe for more tutorials like this.

Just to remember what happened so far:

In Part One You will Learned:

Create a new app using LangChain's LangServe
ingestion of PDFs using unstructuredio
Chunking of documents via LangChain's SemanticChunker
Embedding chunks using OpenAI's embeddings API
Storing embedded chunks into a PGVector a vector database
Build a LCEL Chain for LangServe that uses PGVector as a retriever
Use the LangServe playground as a way to test our RAG
Stream output including document sources to a future front end.

In Part 2 we will focus on:

Creating a front end with Typescript, React, and Tailwind
Display sources of information along with the LLM output
Stream to the frontend with Server Sent Events

In Part 3 we will focus on:

Deploying the Backend application to @DigitalOcean
Deploying the frontend to @digitalocean_staff App Platform
Use a managed Postgres Database

In Part 4 we will focus on:

Adding Memory to the @LangChain Chain with PostgreSQL
Add Multiquery to the chain for better breadth of search
Add sessions to the Chat History

Github repo

https://github.com/focused-labs/pdf_rag

Chat With Your PDFs: Part 2 - Frontend - An End to End LangChain Tutorial. Build A RAG with OpenAI.

Austin Vance — Mon, 29 Jan 2024 23:35:58 +0000

In this video we are going to dive into part two of building and deploying a fully custom RAG with @LangChain and @OpenAI. In this tutorial, code with me, video we will take the LangServe pipeline we developed in Part 1 and build out a fully functioning React & Typescript frontend using TailwindCSS.

The video did end up getting pretty long so we will deploy the app to @digitalocean_staff and to @LangChain in Part 3!

Just to remember what happened so far:

In Part One You will Learned:

Create a new app using @LangChain's LangServe
ingestion of PDFs using @unstructuredio
Chunking of documents via @LangChain's SemanticChunker
Embedding chunks using @OpenAI's embeddings API
Storing embedded chunks into a PGVector a vector database
Build a LCEL Chain for LangServe that uses PGVector as a retriever
Use the LangServe playground as a way to test our RAG
Stream output including document sources to a future front end.

In Part 2 we will focus on:

Creating a front end with Typescript, React, and Tailwind
Display sources of information along with the LLM output
Stream to the frontend with Server Sent Events

In Part 3 we will focus on:

Deploying the Backend application to @DigitalOcean & @LangChain's LangServe hosted platform to compare
Add LangSmith Integrations
Deploying the frontend to @digitalocean_staff's App Platform
Use a managed Postgres Database

In Part 4 we will focus on:

Adding Memory to the @LangChain Chain with PostgreSQL
Add Multiquery to the chain for better breadth of search
Add sessions to the Chat History

Github repo

https://github.com/focused-labs/pdf_rag

Chat With Your PDFs: Part 1 - An End to End LangChain Tutorial For Building A Custom RAG with OpenAI.

Austin Vance — Wed, 24 Jan 2024 17:48:57 +0000

A common use case for developing AI chat bots is ingesting PDF documents and allowing users to ask questions, inspect the documents, and learn from them. In this tutorial we will start with a 100% blank project and build an end to end chat application that allows users to chat about the Epic Games vs Apple Lawsuit.

There's a lot of content packed into this one video so please ask questions in the comments and I will do my best to help you get past any hurdles.

In Part One You will Learn:

Create a new app using @LangChain 's LangServe
ingestion of PDFs using @unstructuredio
Chunking of documents via @LangChain 's SemanticChunker
Embedding chunks using @OpenAI 's embeddings API
Storing embedded chunks into a PGVector a vector database
Build a LCEL Chain for LangServe that uses PGVector as a retriever
Use the LangServe playground as a way to test our RAG
Stream output including document sources to a future front end.

In Part 2 we will focus on:

Creating a front end with Typescript, React, and Tailwind
Display sources of information along with the LLM output
Stream to the frontend with Server Sent Events
Deploying the Backend application to @DigitalOcean & @LangChain 's LangServe hosted platform to compare
Deploying the frontend to @DigitalOcean 's App Platform

In Part 3 we will focus on:

Adding Memory to the @LangChain Chain with PostgreSQL
Add Multiquery to the chain for better breadth of search
Add sessions to the Chat History

Github repo

https://github.com/focused-labs/pdf_rag

Beyond a JPEG: NFT as a Primary Key

Austin Vance — Wed, 12 Jan 2022 14:17:10 +0000

These days, we most often see NFTs used to record the ownership information of artwork. There are the pie-in-the-sky folks who think NFTs will become a new standard for ownership for everything from houses, to music, to in-game items - only time will tell.

NFTs are powerful, but they get a bad rap. I don't have strong opinions about the disruptive nature of NFTs or how they affect art, games, or anything else. I do see that the "Non-Fungible" attribute of an NFT has some remarkable properties that allow smart contract developers to store state in a permissionless manner and enable that state to be transferred or sold.

Ok, I admit that's rather abstract and confusing. Since this is a dev blog, let's build an app that uses an NFT contract and holds information specific to a user.

Before we dive in, this is not revolutionary. Several projects already do this. The QiDAO uses NFTs to manage loan ownership and Uniswap V3 uses NFTs to manage a Liquidity Position. Before the release of V3, Uniswap recorded Liquidity by issuing the liquidity provider an LP Token. These tokens are an ERC-20 token, and ERC-20's are fungible. Fungibility means that one token is the same as another. Think if someone hands you a 1€ note. That note is the same as the other 1€'s in your wallet. The ERC-20's are 100% transferable, farmable, and sellable, but they cannot store any secondary information about a Liquidity Position.

NFTs allow for encapsulation and transfer and sale of metadata in a permissionless manner

Uniswap V3 enables the addition of metadata to a liquidity position. Instead of issuing an ERC-20 token to represent a liquidity position, they issue an ERC-721 (NFT). With that ERC-721, Uniswap can now add unique features (like impermanent loss protection) to each liquidity position.

How cool is that! But how does it work? Let's build it.

Without giving too much background, at Focused Labs, we offer a blog bounty and a bonus for blogging streaks. The more frequently the company blogs, the larger the blog bounty becomes.

I want to move this bounty from a spreadsheet to the blockchain and use an NFT to identify wallets contributing a blog to the streak.

We will need an ERC-721 contract. Let's use OpenZeppelin to enforce the correct interface for our NFT.

// contracts/FocusedBlogPost.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

contract FocusedBlogPost is ERC721 {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIds;

    const 
    constructor() ERC721("FocusedBlogPost", "FCSD") {}

    function publishBlog(address blogger)
        public
        returns (uint256)
    {
        _tokenIds.increment();

        uint256 newItemId = _tokenIds.current();
        _mint(blogger, newItemId);

        return newItemId;
    }
}

Whenever we call publishBlog() with an address, we will mint and transfer an NFT to the blogger.

A new blog must be published every two weeks to earn a streak. Each week at least one new blog post goes out our streak counter increases. This streak counter is a multiple on our Blog Bounty! Now let’s set up our contract to add logic around a streak.

Let's start by tracking when new posts are published.

contract FocusedBlogPost is ERC721 {
    // ...

    struct BlogPost {
        string postUri;
        uint256 publishedAt;
        address originalAuthor;
    }

    // ...

    // two weeks in seconds
    uint constant twoWeeks = 60 * 60 * 24 * 14;

    // map of NFT ids to Blog Posts
    mapping(uint256 => BlogPost) public blogPosts;

    function publishBlog(address blogger, string memory postUri)
    public
    returns (uint256)
    {
        // ...
        _mint(player, newPostId);

        blogPosts[newPostId] = BlogPost({
            postUri: postUri,
            publishedAt: block.timestamp,
            originalAuthor: blogger
        });

        // ...
    }
}

Now every time a new blog post is published, we not only create an NFT for the post, but we record when it was published and keep track of the original author.

We still don't track a streak, though, so let's add a new method to our token contract.

contract FocusedBlogPost is ERC721Enumerable {
    using SafeMath for uint256;

    // ...

     function getCurrentStreak() public view returns (uint) {
        uint streak = 0;
        if (totalSupply() == 0 || totalSupply() == 1) {
            return streak;
        }

        for (uint256 i = totalSupply().sub(1); i > 0; i--) {
            BlogPost memory currentBlog = blogPosts[tokenByIndex(i)];
            BlogPost memory previousBlog = blogPosts[tokenByIndex(i).sub(1)];

            if (currentBlog.publishedAt - previousBlog.publishedAt >= twoWeeks) {
                break;
            }

            streak++;
        }
        return streak;
    }

We use OpenZeppelin's ERC721Enumerable; this gives us a few new methods to loop through each NFT we have minted. Then we can check the timestamp of each BlogPosts.publishedAt. Pretty easy, right?!

In a future part of this series, we will continue to add features to the NFT, allowing for payouts to streak contributors and adding validations like only increasing a streak if the author isn't in the current streak.

Although this example is a bit contrived, honestly, why would someone want to transfer their streak? I think the practical applications are straightforward.

The NFT can act as a unique identifier, recording metadata about an event or individual actions. A dApp can then use that NFT to make decisions like providing access to a "secret" website or paying a dividend for contributing a blogpost.

Source code is available on GitHub where there is a complete example with passing tests.

Testing Interactions with other Smart Contracts

Austin Vance — Tue, 04 Jan 2022 00:34:51 +0000

Developing on the blockchain is an incredible experience. The ecosystem is open and permissionless; each project becoming a lego brick in whatever idea a developer has in mind. Because of the open nature of the blockchain, it's not uncommon to have your smart contracts interact with another project’s contracts. It may be a Chainlink Oracle, a Dex like Uniswap, or a Lending platform like the QiDAO, or maybe you interact with all three in a single contract?

But how do you test your contract based on responses and interactions with these external contracts?

There are two ways: you can deploy "mock contracts" or you can use a mocking library. There are tradeoffs, but for this post I am going to focus on using a Smock's mocking library to put external contracts into a place for testing.

Smock depends on Hardhat so you need to have a Hardhat project. For the sake of this post let's write and test a smart contract that can liquidate a loan on the QiDAO.

The QiDAO contracts can be found in their docs and the source can be found on their github.

Specifically we will be using the erc20Stablecoin contract deployed for LINK - 0x61167073E31b1DAd85a3E531211c7B8F1E5cAE72

Our simple liquidation contract looks like this.

contract LoanLiquidator {
  address const vaultAddress = 0x61167073E31b1DAd85a3E531211c7B8F1E5cAE72
  function liquidate(uint256 vaultId) external {
    erc20Stablecoin vault = erc20Stablecoin(vaultAddress);
    require(vault.checkLiquidation(vaultId), "Vault not below liquidation threshold");

    vault.liquidateVault(vaultId);
  }
}

For simplicity let's test the two cases of checkLiquidation as liquidateVault doesn't return anything. First we will test but there is a gotcha. We can get into that later!

describe("LoanLiquidator", () => {
  describe("#liquidate", () => {
    it("should revert if the vault cannot be liquidated")
    it("call the vaults liquidateVault if the loan can be liquidated")
  })
})

If we aren't using Smock then this is pretty difficult. I would either need to inject a contract address into the LoanLiquidator and then have that address implement erc20Stablecoin's interface. That's for another blog post.

In this post it's a lot simpler because we will use Smock, but there are limitations. First let's focus on it("should revert if the vault cannot be liquidated")

#...
it("should revert if the vault cannot be liquidated", async () => {
  const VAULT_ADDRESS = "0x61167073E31b1DAd85a3E531211c7B8F1E5cAE72"
  # I am using Typechain to generate types for the erc20Stablecoin ABI
  const fake = await smock.fake<Erc20QiStablecoin>(
    Erc20QiStablecoin.abi,
    {address: VAULT_ADDRESS}
  );

  fake.checkLiquidation.returns(false);

  const LoanLiquidatorFactory = await ethers.getContractFactory("LoanLiquidatator") as LoanLiquidator__factory;
  const loanLiquidator = await LoanLiquidatatorFactory.deploy();
  await loanLiquidator.deployed();

  await expect(loanLiquidator.liquidate(1)).to
    .be
    .revertedWith("Vault not below liquidation threshold")

  expect(fake.liquidateVault).not.to.have.been.called
})
#...

The magic here lies in the opts for Smock's #fake() method. You can pass an existing contract address to #fake() and Smock will use Hardhat's [hardhat_setCode](https://hardhat.org/hardhat-network/reference/#hardhat-setcode) rpc call to replace the contract at the address given with Smock's fake implementation of the contract.

Next lets test it("call the vaults liquidateVault if the loan can be liquidated").

it("call the vaults liquidateVault if the loan can be liquidated", async () => {
  const VAULT_ADDRESS = "0x61167073E31b1DAd85a3E531211c7B8F1E5cAE72"
  # I am using Typechain to generate types for the erc20Stablecoin ABI
  const fake = await smock.fake<Erc20QiStablecoin>(
    Erc20QiStablecoin.abi,
    {address: VAULT_ADDRESS}
  );

  fake.checkLiquidation.returns(true);

  const LoanLiquidatorFactory = await ethers.getContractFactory("LoanLiquidatator") as LoanLiquidator__factory;
  const loanLiquidator = await LoanLiquidatorFactory.deploy();
  await loanLiquidator.deployed();

  await expect(loanLiquidator.liquidate(1)).not.to
    .be
    .reverted

  expect(fake.liquidateVault).to.have.been.called
})

In this case you'll get green lights and you can keep on coding. In the real world there's a gotcha. When you fake a contract you fake all of it. By default, functions will now return their Zero value. If you have calls to later in your implementation that require non-zero values.

A clear example of this is if we add the method #getVaultAddress() to our LoanLiquidator contract:

function getVaultAddress() public view returns (address) {
  return vaultAddress;
}

Now in test, after faking, if you call #getVaultAddress() you will get the zero address 0x0000000000000000000000000000000000000000 If you had code that used the returned address you may see an error like:

Error: Transaction reverted: function call to a non-contract account

This just scratches the surface of what's possible with Smock and Solidity. The Web3 space is one of the most test driven development friendly and open ecosystems I have ever encountered.

If you're interested in TDD, writing great software, and developing cutting edge technology, don't hesitate to check out our careers page. Or if you’re looking for a partner to help build your next dApp, backend, or frontend and up-skill your team please reach out to us at work@withfocus.com.

TIL: the Git -p flag!

Austin Vance — Fri, 15 Jan 2021 19:03:17 +0000

Today I learned about the -p flag in git and now I want to use it everywhere!

According to the man page:

$ man git-add

...
-p, --patch
Use the interactive patch selection interface to chose which changes to commit. See git-add(1) for details
...

You can use the -p flag with checkout, add, commit

Blog Golf: Smallest Post Wins

Austin Vance — Fri, 15 Jan 2021 15:01:24 +0000

At Focused Labs we have been really trying to emphasize blogging. So, our Editorial Board sat down and brainstormed. The goal of the Editorial Board was to make blogging fun, show that it doesn't take tons of time to write good posts, and get people to post!

They came up with an awesome idea, like code golf, why don't we try Blog Golf!

Here are the rules:

Write a blog post in 15 minutes or less
Smallest blog post wins
Code samples are judged on size of code not words

The winner will win a life changing prize!

Watch out for a series of posts each in Blog Golf and try yourself by tagging #bloggolf to guarantee some 🦄🦄🦄

DEV Community: Austin Vance

Everybody Tests

Everybody Tests

You already think test-first

The cost nobody talks about

The teams that say they don't have time

The same satisfying satisfying, all over again

Eval Driven Development

Vibes don't ship

The choice is the same as it always was

Context Will Replace Your Design

The Translation Layer We Built

When the System Adapts to You

The Clawdbot Case Study

Context Engineering: The New Discipline

What Agents Need

The Skills That Transfer

Design Becomes Invisible

Customizing Memory in LangGraph Agents for Better Conversations

Overview of Memory Types in LangChain

Setting Up Simple Memory Buffers

Custom Memory Implementation

Example: Persistent Chat History

Optimization Techniques

Conclusion: Enhancing Agent Intelligence

Migrating Classic LangChain Agents to LangGraph a How To

WHY MIGRATE NOW?

WHAT CHANGED IN LANGCHAIN 0.2 AND LATER?

CODE DIFF: FROM initialize_agent TO A LANGGRAPH NODE

Create the ReAct agent node

Build a simple single‑node graph

UPDATING TESTS AND CALLBACKS

PRODUCTION ROLLOUT CHECKLIST

FINAL WORD

Why Big Classes Get Bigger: Understanding Preferential Attachment in Your Code

The Law of Preferential attachment: Why your User class keeps growing

The pull of the common class

Yes there’s math

There is no strength in numbers

The only constant is change

Build for change

Unlock the Power of LangChain: Deploying to Production Made Easy

Github repo

Chat With Your PDFs: Part 2 - Frontend - An End to End LangChain Tutorial. Build A RAG with OpenAI.

Github repo

Chat With Your PDFs: Part 1 - An End to End LangChain Tutorial For Building A Custom RAG with OpenAI.

Github repo

Beyond a JPEG: NFT as a Primary Key

Testing Interactions with other Smart Contracts

TIL: the Git -p flag!

Blog Golf: Smallest Post Wins

CODE DIFF: FROM `initialize_agent` TO A LANGGRAPH NODE