DEV Community: jpatanooga

GitHub Copilot isn't the first tool to raise your ceiling — here's the 50-year pattern you're actually living through

jpatanooga — Wed, 08 Apr 2026 14:45:08 +0000

You've read a dozen posts about how AI coding tools are "changing everything."

Most of them treat it as structurally novel.

It isn't.

And that's actually reassuring. (what? no existential dread?)

Every major cognitive tool since the 1950s — word processors, spreadsheets, relational databases, email — hit knowledge work and followed the same pattern:

Specific tasks got automated (bookkeeping, typing, data retrieval, correspondence)
Demand for the underlying capability expanded because the cost dropped
New roles emerged adjacent to the tool
Skill requirements migrated upward within the domain
Net employment grew

The spreadsheet didn't end accounting — it ended bookkeeping as manual drudgery and created a generation of analysts who could model scenarios entire teams previously couldn't run.

Sound familiar?

Because Copilot isn't ending software development — it's ending boilerplate as manual drudgery.

(read: just changing the ol' jobbie job)

What's genuinely useful here: cognitive tools historically raised the ceiling on individual capability rather than just cutting headcount. The surviving bookkeeper became an analyst. The surviving junior dev becomes... something with more leverage and more abstract scope.

There's also the Solow Paradox buried in here — early computing productivity gains were real but statistically invisible for years.

If you're watching AI productivity metrics right now and finding them underwhelming, that's a known phase of this curve, not a referendum on the technology.

This is part of the "Hitchhiker's Guide to Knowledge Work" — a series worth reading if you want a grounding framework beyond vibes:

https://pattersonconsultingtn.com/content/hitchhikers_guide_kw/early_cognitive_labor_evolution_post_tools.html

Stop Shipping LLM Agents Without a Safety Net: Using MLflow's ResponsesAgent Interface

jpatanooga — Tue, 07 Apr 2026 15:12:54 +0000

Here's a pattern I keep seeing: someone builds a genuinely useful LLM agent, it works great, gets deployed, and then six months later nobody knows what version is running, how to update it safely, or what changed between the version that worked and the one that doesn't.

The capability was never the hard part.

MLflow 3.6 introduced the ResponsesAgent interface, and it's worth your attention if you're building agents for anything more serious than a weekend project. Two methods to implement (load_context and predict), an OpenAI-compatible request/response schema, and automatic integration with MLflow's tracking, versioning, and deployment infrastructure.

The part I like: it doesn't care what's inside. LangChain, DSPy, custom Python — you keep your internals, you just standardize the outer contract. Tool call tracking and token usage logging come along for free.

Full walkthrough here, including how to structure the code and wire it into Databricks:

👉 https://pattersonconsultingtn.com/blog/building_mlflow_responseagent_agents.html

What Happened to Physical Labor Roles After Mechanization

jpatanooga — Mon, 06 Apr 2026 17:41:53 +0000

Before you worry about AI taking your job, read what happened to the Luddites

There's a version of the AI-and-jobs conversation that goes: "Don't worry, new technology always creates more jobs than it destroys. The Luddites were wrong."

That framing is lazy. It's also half wrong.

The Luddites — skilled handloom weavers who smashed power looms across the English Midlands in 1811 — were right that their specific skill was being destroyed. Wages for handloom weavers collapsed over the following decades. What they were wrong about was whether the underlying need for cloth production would shrink. It didn't. Cheaper cloth drove demand that a cottage industry could never have satisfied. Aggregate textile employment grew.

Agriculture is the darker version: 80% of the US workforce in 1800. ~1-2% today. That's not "role transformation." That's near-complete displacement of a labor category. The workers moved. They went into manufacturing, services, and eventually every sector that industrialization made possible.

Both histories show the same five-beat pattern:

Immediate displacement of specific task-holders
Productivity gains drive demand expansion or labor shifts to other sectors
New roles emerge around the tools themselves
Remaining roles require more sophisticated judgment
Total employment across the economy grows

I wrote this up as the first entry in a longer series on cognitive labor automation — specifically, what these historical precedents actually imply for knowledge work roles when it's judgment being automated rather than muscle.

If you're a developer building AI systems, or an analyst whose workflow is being restructured around LLMs, the Luddite story is more nuanced and more useful than the usual dismissal suggests.

For my longer take on the full subject and series:

https://pattersonconsultingtn.com/content/hitchhikers_guide_kw/physical_labor_evolution_post_tools.html

What is MLflow?

jpatanooga — Tue, 31 Mar 2026 15:53:57 +0000

In this guide, we’ll walk through why MLflow is becoming the enterprise standard for agentic workloads, how ResponsesAgent offers a clean and typed development interface. In future articles we'll walk you through how to build a ResponsesAgent agent on MLflow, deploy it, and then integtrate it into an application architecture from the previous article.

MLflow provides the operational foundation required to transform agent logic—prompts, contextual data access, and LLM reasoning—into a governed, production-grade service that can be embedded directly into enterprise knowledge-work applications. Just as data platforms manage the lifecycle of tables and materialized views, MLflow manages the lifecycle of agents by packaging their code and instructions, capturing execution environments, versioning them, and exposing them through standardized REST endpoints.

What is MLflow?

MLflow provides a unified framework to manage the entire lifecycle of both traditional ML models and modern LLM agents, which we dig into in detail in this article.

pattersonconsultingtn.com

Your job isn't being automated — but parts of it are. Here's how to think about which parts.

jpatanooga — Mon, 30 Mar 2026 16:40:40 +0000

There's a framing problem in most "AI and jobs" discourse: we talk about job titles when we should be talking about task composition.

A new piece from Patterson Consulting makes this concrete using what I think is the most useful version of the industrial revolution analogy I've seen: the mechanical loom.

The power loom didn't eliminate weavers. It automated established-pattern work (thread production at scale) and shifted weavers toward design, quality control, and coordination — work that requires judgment you can't fully specify in advance. Employment in the textile industry grew after mechanization.

The same frame applies to knowledge work and AI. The key distinction isn't easy vs. hard:

AI-tractable work: tasks where "the pattern is established before you begin" — variance reports, status summaries, first-pass code reviews, boilerplate generation
Judgment-intensive work: tasks that produce the pattern — architectural decisions, debugging novel failure modes, understanding what the customer actually needs vs. what they said they needed

This maps cleanly to Simon's programmed/unprogrammed decision framework from 1960, and to Polanyi's Paradox: skilled engineers know more than they can articulate, and that tacit knowledge is a structural barrier to full automation.

Worth noting: engineering job openings are currently at multi-year highs (67K+ globally), with demand accelerating through early 2026 even as AI coding tools are everywhere. The loom didn't kill the weaver. It changed what weaving means.

Read it here: https://pattersonconsultingtn.com/content/hitchhikers_guide_kw/mechanical_loom_mental_synthesis.html

3 Architecture Patterns for Embedding AI Agents in Enterprise Applications

jpatanooga — Thu, 26 Mar 2026 15:59:21 +0000

Most generative AI tutorials stop at the API call. This post is about what happens after — how you actually integrate agent functionality into the applications where knowledge work gets done.

The core framework I use organizes integration around three application types:

Conversational User Interfaces Web chat, Slackbots, SMS. These are the most familiar but have real tradeoffs around brand control, customer data exposure, and external system dependencies.
Workflow Automation Batch jobs scanning warehouse tables, structured extraction pipelines, and human-in-the-loop review workflows. Architecture here differs significantly depending on whether a human is reviewing output before it's committed downstream.
Decision Intelligence Automated analysis of KPIs against business rules, next-action recommendations, and root cause analysis. This is where LLM reasoning over private enterprise data has the highest leverage — and requires the tightest security architecture.

There's also a section on the "Games of Materialized Views" framing — the idea that enterprise software is fundamentally a hierarchy of precomputed views, and LLMs extend this by enabling dynamic views built from reasoning over data. The "real-time data" discussion is worth reading if you've ever had a stakeholder demand real-time everything without thinking through what that actually costs.

Read the full post here: - https://pattersonconsultingtn.com/blog/architecture_patterns_for_integrating_agents_into_knowledge_work.html

This is part of a series — next piece digs into MLflow as an agent server for these architectures.

Why Every Information Revolution Increases Cognitive Labor Demand — and What That Tells Us About AI

jpatanooga — Tue, 24 Mar 2026 16:03:27 +0000

There's a pattern in the history of information technology that I think is underappreciated in conversations about AI and the future of knowledge work.

Every major infrastructure layer — writing, the printing press, the telegraph, databases — solved a different property of the information problem. Each one made cognitive labor more powerful and more necessary. Not less.

Writing made information persistent. Before it, organizations were bounded by direct coordination and living memory. After it, a decision in one city could govern a province. Records outlasted the people who made them. The first empires were, in part, massive information infrastructure projects.

The printing press made knowledge distributable at scale. The result wasn't fewer scholars — it was an explosion of new professions requiring literacy and synthesis: lawyers, scientists, journalists. More accessible knowledge meant more knowledge to reconcile.

The telegraph made information real-time. Financial markets, logistics, news — suddenly operating at a new tempo. But faster signals meant more decisions per unit time, which meant more analytical demand, not less.

Databases and the internet made information queryable at volume. And that's where we are now: a senior analyst can access regulatory filings, market data, internal reports, competitor intelligence, and customer signals before lunch. Access is not the problem. Making sense of it is.

The bottleneck in knowledge work is no longer access to information — it's the cognitive labor of synthesis.

AI is the first infrastructure layer that directly targets synthesis. Not persistence, not distribution, not speed, not volume — synthesis. That's the qualitative break from every prior wave.

The historical pattern is unambiguous: more infrastructure leads to more cognitive labor demand, not less. Writing didn't make administrators obsolete. It made larger administrations possible. The pattern has run the same way every time.

The question AI poses isn't whether cognitive labor survives. It's what cognitive labor looks like after the infrastructure changes — which synthesis tasks get accelerated, what that frees human judgment to do, and what new cognitive labor the expanded infrastructure calls into existence.

Full piece here, with references: https://pattersonconsultingtn.com/content/hitchhikers_guide_kw/information_as_infrastructure.html

What Determines Which Knowledge Work AI Can Actually Automate

jpatanooga — Wed, 18 Mar 2026 19:47:46 +0000

Applies the routine/non-routine task distinction from labor economics (Autor, Levy, Murnane 2003) to the question of where AI automation of knowledge work is structurally tractable vs. where Polanyi's Paradox applies. Introduces the concept of "defensible but not differentiating" cognitive labor as the prime zone for acceleration.

Cognitive Labor: The Mental Work Behind Knowledge Work | The Hitchhiker's Guide to Building Knowledge Work Systems (Series)

Defining cognitive labor, mental synthesis, and the defensible-but-not-differentiating framework — the foundation for understanding what AI actually changes about knowledge work.

pattersonconsultingtn.com