DEV Community: Emma Schmidt

Your AI Assistant Forgets What You Told It an Hour Ago, and It Never Says So

Emma Schmidt — Thu, 10 Sep 2026 05:30:53 +0000

Long AI coding sessions have a failure mode nobody warns you about upfront. Not a crash, not an error message. The assistant just quietly starts acting like earlier instructions never happened, and it does this with exactly the same confident tone it uses when it's right.

I started paying close attention to this after noticing a pattern across long sessions: constraints I'd set early on, "don't touch this file," "always use this naming convention," would get silently violated well into a session, with zero indication anything had changed. This is what's often called context degradation, and it's become one of the more actively discussed reliability concerns around long-running AI coding sessions this year, right alongside the usual conversation about custom AI development and how much production infrastructure actually needs to sit around a model to make it trustworthy at scale.

Why This Happens at All

Every AI assistant works within a fixed context window, everything it can "see" at once: the conversation, the code, the instructions. As a session grows, older parts of that context matter less to how the model weighs its next response, even when they're technically still present.

This isn't a bug in the traditional sense. It's a structural property of how these systems work:

Instructions given early in a long session compete with everything said afterward for the model's attention
There's no built-in mechanism forcing a model to re-check "wait, did I violate something I was told forty messages ago"
A model degrading gracefully looks identical, on the surface, to a model working correctly, until the specific violated constraint actually matters

An Illustrative Pattern, Not a Formal Benchmark

I want to be upfront about something here. What follows is a simplified illustration of a pattern that shows up anecdotally across long sessions, not a rigorously controlled experiment with precise run counts. I haven't published raw transcripts or a reproducible harness for this one, so I'm deliberately not dressing it up as harder data than it is.

Session Length	Common Pattern Observed
Early in session	Constraints followed closely and consistently
Mid-session	Constraints generally still respected, occasional inconsistency
Late in session, many turns in	Constraints increasingly treated as optional, without any signal that anything changed

The shape of that pattern, gradual, silent drift rather than a sudden failure, is the part worth taking seriously, even without a formal number attached to exactly when it happens.

A Concrete Example of What This Looks Like

Early in a session:

User: Never modify files in the /legacy folder, they're frozen for a compliance audit.
Assistant: Understood, I'll leave /legacy untouched for the rest of this session.

Forty messages later, deep into an unrelated refactor:

Assistant: I've updated the shared utility function and its usage across
the codebase, including legacy/utils/formatter.js, to match the new signature.

No warning. No "I know you said not to touch this, but." Just a quiet, confident violation of something established earlier, presented with the exact same tone as every correct thing the assistant did in between.

Why This Is Genuinely Dangerous, Not Just Annoying

The comment-staleness problem and this one share a root cause: a model treating something as true well past the point where it stopped being reliably true, without any signal that the confidence should have dropped.

A security constraint set early in a session can quietly stop being honored without any error or warning
A reviewer skimming a long session's final output has no easy way to know which instructions from turn three are still actually being respected by turn eighty
The failure looks identical to success right up until the specific violated constraint gets tested by something real, a deployment, an audit, a data leak

What Actually Helps

A few practical habits that reduce how often this bites, based on how teams building serious AI tooling this year are approaching it:

Re-state critical constraints periodically, rather than assuming a single early mention holds for the entire session
Break long tasks into shorter, focused sessions where possible, since a fresh session starts with full attention on the current instructions rather than competing with dozens of prior turns
Treat critical constraints as things to verify in review, the same way stale comments should get flagged, a violated early instruction should be something a reviewer is actively checking for, not assuming was respected
Build guardrails outside the conversation itself where the constraint really matters, a file permission, a linter rule, a CI check, rather than relying purely on the model remembering an instruction from earlier

Where This Gets Genuinely Hard to Solve Alone

Building actual production-grade reliability around this, proper session management, automated re-verification of critical constraints, structural guardrails that don't depend purely on a model remembering something from fifty messages ago, is real engineering work that goes well beyond writing a good system prompt. This is exactly the kind of gap that custom AI development and AI workflow automation work tends to close, building the surrounding infrastructure that catches what a model alone eventually drifts on, rather than hoping a longer, more carefully worded prompt fixes something that's a structural property of how these systems function.

Caveats, Genuinely

This piece leans on a widely observed pattern rather than a controlled study I ran myself, and I want to be honest about that rather than presenting invented precision. If you've run rigorous, reproducible testing on this specific failure mode, I'd genuinely like to see it, and I'd trust real data over my own anecdotal pattern-matching here without hesitation.

Conclusion

A model degrading gracefully and a model working correctly look identical from the outside, right up until the moment the gap actually matters. The fix isn't a cleverer prompt, it's treating long-session reliability as an engineering problem with structural guardrails, not a memory problem you can politely ask a model to solve better.

Has anyone actually run controlled tests on this specific failure mode? I'd love to see real numbers instead of my own anecdotal pattern here.

Your Codebase Is About to Start Fixing Itself. Are You Ready?

Emma Schmidt — Wed, 09 Sep 2026 08:47:01 +0000

A bug hits production. Nobody's paged. No Slack alert wakes anyone up. By the time your team checks the dashboard the next morning, an autonomous agent has already traced the error, written a patch in a sandbox, tested it against the full suite, and shipped the fix.

That's not a thought experiment. It's what "agentic AI" actually looks like in practice in September 2026, and it's the single biggest shift happening in how software gets built right now.

If you're a developer, this isn't a trend to watch from the sidelines. It's changing the shape of the stack you'll be working in for the next decade.

From Autocomplete to Autonomy

The last generation of "AI in dev" was reactive: you typed, the model suggested. Useful, but fundamentally a tool waiting for input.

Agentic AI flips that relationship. Agents now:

Plan multi-step tasks on their own (not just single completions)
Call tools, APIs, and other agents to gather context
Test their own output against real environments
Course-correct without a human re-prompting them

That's why 2026 conversations aren't just about "AI code assistants" anymore. They're about agent architectures: how you design systems where autonomous components make real decisions, and where you draw the line for human sign-off.

Where This Is Actually Showing Up in Engineering Work

Here's the part that matters for anyone shipping software right now. Agentic AI isn't one feature bolted onto a product, it's touching nearly every layer of the stack:

1. AI/ML Development

The foundation of any agent is the model layer underneath it: predictive models, NLP pipelines, and computer vision systems that give an agent something real to reason over. Teams building agentic systems are investing heavily in AI/ML development to make sure the "brain" behind the agent is actually grounded in their data, not just wired to a generic API call.

2. AI-Driven Software Development

This is where agentic AI stops being a bolt-on and starts being architecture. Instead of writing rigid, rule-based logic, engineering teams are designing software where AI-driven decision-making is baked into the core workflow from day one, things like automated triage, self-adjusting business logic, and intelligent process orchestration.

3. Custom Software Development

Off-the-shelf tools rarely handle agent orchestration well out of the box. Companies are turning to custom software development to build the specific guardrails, permission systems, and audit trails their industry and compliance requirements demand, rather than retrofitting a generic platform.

4. SaaS Development

Multi-tenant SaaS platforms are a natural home for agentic features: think an agent that autonomously manages onboarding, usage-based scaling, or customer support triage across every tenant. SaaS development teams are now designing multi-tenant architecture with "agent slots" in mind from the start, so autonomous features can scale safely across the whole customer base.

5. Mobile App Development

Agents aren't staying server-side. On-device and hybrid agents are starting to handle scheduling, personalization, and workflow automation directly inside mobile apps, which means mobile app development now has to account for local inference, permission boundaries, and battery-conscious agent design.

6. Digital Transformation

For larger organizations, agentic AI isn't a feature request, it's a full operating-model shift. Digital transformation initiatives are increasingly centered on figuring out which business processes can safely be handed to autonomous systems and which still need a human in the loop.

7. Digital Product Engineering

Building an agent-ready product from scratch (rather than retrofitting one) is its own discipline. Digital product engineering teams are baking agent orchestration, observability, and rollback mechanisms into products at the architecture stage, not as an afterthought.

8. Hiring Dedicated Developers

Because agentic architecture is still a rapidly evolving specialty, a lot of teams are choosing to hire dedicated developers with hands-on agent-building experience rather than trying to upskill an entire team overnight.

The Real Engineering Challenge: Trust, Not Just Capability

Here's the uncomfortable truth every engineering team is running into: getting an agent to act autonomously is the easy part now. Getting your organization to trust that action is the hard part.

That means the real 2026 engineering work isn't just "add an agent." It's:

Building permission scopes so agents can't touch what they shouldn't
Logging every decision an agent makes so it's auditable after the fact
Designing rollback paths for when an agent gets it wrong
Deciding, explicitly, where a human still has to approve before anything ships

Skip these, and you don't have agentic AI. You have an unsupervised script with a marketing budget.

Where This Leaves Developers

If you're heads-down writing code right now, here's the practical takeaway: the value of a developer is shifting from "writes the logic" to "designs the boundaries the logic operates within." Understanding how to architect for autonomous systems, not just how to code around them, is quickly becoming a core skill, not a nice-to-have.

The teams pulling ahead aren't the ones with the flashiest agent demo. They're the ones who've quietly figured out how to make autonomy safe, auditable, and boring in the best possible way.

That's the real story behind the "agentic AI" headlines this September. Not magic. Just really good engineering discipline applied to a genuinely new kind of system.

Are you building with agents yet, or still evaluating where they fit in your stack? Drop your experience in the comments, I'd love to compare notes.

Payment Gateway Integration in 2026 Isn't What It Was Two Years Ago. Here's What Actually Changed.

Emma Schmidt — Tue, 08 Sep 2026 12:27:31 +0000

Ask a developer who last touched payment integration in 2023 to rebuild the same flow today, and they'll hit friction almost immediately. Compliance requirements have shifted, fraud prevention has moved from a bolted-on rules engine to something running continuously in real time, and the messaging standard underneath the whole transaction pipeline is being replaced globally. This is exactly the ground where digital banking software development has quietly moved the furthest since the last time most teams touched this part of their stack.

Here's what's genuinely different about payment integration this year, and what to actually plan for if you're building or modernizing this now.

The Messaging Standard Shift Nobody Outside Fintech Is Talking About

The financial industry has been migrating to ISO 20022, a richer, structured messaging standard replacing older, more limited payment message formats. This isn't a cosmetic update.

Old Standard Limitation	What ISO 20022 Changes
Limited, truncated reference data on transactions	Rich, structured data travels with every payment
Manual reconciliation often required	Machine-readable structured data makes automated reconciliation far more reliable
Inconsistent formats across regions and networks	A common structured format designed for global interoperability
Fraud detection working with sparse transaction context	Fraud systems get meaningfully more data per transaction to work with

For anyone doing core banking software development or building payment flows that need to interoperate internationally, this migration isn't optional background noise, it directly affects how transaction data needs to be structured and processed.

Fraud Prevention Moved From Rules Engine to Real-Time AI

The old model was largely reactive: a rules engine flagging transactions that matched known fraud patterns, reviewed after the fact. That model hasn't kept pace with how fast synthetic identity fraud and account takeover techniques have evolved.

Continuous risk scoring now happens throughout a transaction, not just at a single checkpoint
Behavioral biometrics increasingly factor into risk assessment, typing patterns, device handling, session behavior, not just the transaction data itself
Synthetic identity detection has become a genuine specialty, since fabricated identities built from a mix of real and fake data are harder to catch with traditional verification checks
Merchant account requirements have gotten more data-intensive specifically to combat this, meaning onboarding now typically requires more verification than it did even a couple of years ago

What Modern Integration Actually Requires

Step one: understand your settlement model
Real-time settlement rails have expanded significantly, and choosing between real-time and traditional batch settlement affects everything downstream, reconciliation timing, cash flow visibility, and how quickly disputes can actually be resolved.

Step two: plan for structured ISO 20022 data from the start
Retrofitting rich, structured transaction data after building around a simpler format is significantly more painful than designing for it from the beginning. This is one of the most common gaps in legacy banking modernization projects, systems that were never built to carry this much structured context per transaction.

Step three: build fraud detection as a continuous layer, not a single checkpoint
Rather than one fraud check at the point of payment, effective systems now score risk continuously across the transaction lifecycle, adjusting friction dynamically rather than applying the same static check to every transaction regardless of risk profile.

Step four: design for biometric-friendly, low-friction checkout
Reducing checkout friction while maintaining strong verification is a genuine balancing act. Biometric authentication has become a standard expectation for mobile banking app development specifically, since users increasingly expect a fingerprint or face check rather than typing a password on a small screen.

Step five: account for emerging settlement patterns like escrow-based flows
For higher-value or automated transactions, smart contract-based escrow patterns are gaining ground, holding funds until delivery or fulfillment conditions are verifiably met, an approach that's becoming more relevant as automated purchasing and agentic commerce grow.

Where This Gets Genuinely Complicated

Multi-region compliance. A payment flow that works cleanly in one jurisdiction can require substantial rework to meet another region's specific data and settlement requirements, particularly as open banking APIs development expands what's expected across markets
Legacy core system compatibility. Older core banking infrastructure often wasn't built to carry ISO 20022's richer data structures, which makes this as much a modernization project as an integration one
Reconciliation complexity during migration. Running old and new message formats in parallel during a transition period is common, and it adds real operational overhead that's easy to underestimate in a project timeline

Common Mistakes Worth Avoiding

Treating this as a purely technical integration task and underestimating the compliance and data structure implications of the ISO 20022 shift
Bolting fraud detection on as an afterthought rather than designing it as a continuous part of the transaction flow
Assuming existing merchant account setups will transfer cleanly, when data requirements for these accounts have gotten meaningfully stricter
Underestimating how much legacy banking modernization work is actually required before a modern payment flow can run cleanly on top of older core systems

A Quick Self-Check Before You Start

Is your current transaction data structure ready to carry ISO 20022's richer data, or would this require a genuine schema rework?
Does your fraud detection run continuously across the transaction lifecycle, or only at a single checkpoint?
Have you actually verified your merchant account setup meets the current, more data-intensive onboarding requirements?
If you're operating across multiple regions, have you confirmed compliance requirements for each one specifically, rather than assuming one setup covers all of them?

Why This Deserves Real Planning

Getting payment integration right in 2026 touches compliance, fraud architecture, core banking data structures, and the mobile experience all at once, which makes it a genuinely cross-functional project rather than a narrow technical task. This is exactly the kind of work that benefits from real experience across digital banking software development, core banking modernization, and open banking API integration together, rather than treating payment integration as an isolated feature bolted onto an otherwise unrelated system.

The Takeaway

Payment gateway integration has quietly become a substantially different discipline than it was even two years ago. The messaging standard underneath transactions is changing globally, fraud prevention has shifted from reactive to continuous, and the compliance bar for merchant onboarding has risen meaningfully. Teams still building against the old assumptions are going to hit real friction the moment they need to interoperate with a modernized counterpart.

Has your team already started planning for the ISO 20022 shift, or is this still sitting further down the roadmap? Curious how far along different teams actually are with this transition.

Your Banking App's Chatbot Isn't the Problem. What's Behind It Is.

Emma Schmidt — Mon, 07 Sep 2026 05:38:56 +0000

Ask a typical bank's chatbot to dispute a transaction, and watch it either loop you through a rigid decision tree or hand you off to a human anyway, the exact outcome the chatbot was supposed to prevent. That gap between "we have an AI assistant" and "our customer operations actually got faster" is exactly where a lot of digital banking software development is quietly shifting focus right now.

Here's what's actually changing in how banks are using natural language processing for customer operations, why the old chatbot approach fell short, and what a genuinely effective setup looks like.

Why the First Wave of Banking Chatbots Disappointed Everyone

Most early banking chatbots were built on rigid, rule-based decision trees. Ask something slightly outside the expected phrasing, and the whole experience broke down.

Intent recognition was shallow. A question phrased even slightly differently than the training examples often failed to match any intent at all
No real context retention. Every message was treated in isolation, so a natural follow-up question required the customer to repeat information they'd already given
Escalation happened too late or too early. Either the bot stubbornly tried to handle something it clearly couldn't, frustrating the customer, or it escalated routine questions that a well-built system should have resolved on its own
Compliance and accuracy were treated as an afterthought. In a regulated industry, a confidently wrong answer about fees, terms, or account status isn't just annoying, it's a real liability

What Modern NLP Actually Changes

The shift happening now isn't just "a smarter chatbot." It's NLP applied across the entire customer operations pipeline, not just the visible chat window.

Traditional Approach	Modern NLP-Driven Approach
Rigid decision trees, exact phrase matching	Genuine intent understanding across varied phrasing
No memory between messages	Contextual memory carried through a full conversation
Manual routing of support tickets	Automated classification and routing based on actual content
Generic responses regardless of customer history	Personalized responses informed by account and transaction context
Human review needed for most escalations	Automated resolution for a meaningfully larger share of routine requests

Real Ways Banks Are Applying This Right Now

Automated transaction dispute intake, where NLP classifies the nature of a dispute and routes it to the correct resolution workflow instead of a generic support queue
Sentiment-aware escalation, detecting frustration or urgency in a customer's message and prioritizing it for human review before it becomes a complaint
Document and KYC processing, extracting and validating information from submitted documents far faster than manual review
Multilingual support at scale, handling customer queries across languages without maintaining separate support teams for each one
Fraud pattern detection in customer communications, flagging unusual language patterns in support requests that may indicate account takeover attempts

Why This Matters More for Banking Than Most Industries

Two forces make this particularly relevant to financial services right now.

Legacy banking modernization is already underway. A large share of banks are actively working through legacy banking modernization efforts, replacing decades-old core systems. NLP-driven customer operations is often one of the more visible, customer-facing parts of that broader modernization, since it's where customers directly feel the difference.

Open banking is raising the complexity of customer questions. As open banking APIs development expands what customers can actually do, connecting accounts across providers, initiating payments through third parties, the range of questions customer support needs to handle has grown substantially. A rigid, rule-based system simply can't keep pace with that expanding surface area the way genuine language understanding can.

A Practical Framework for Evaluating This

Before investing in an NLP-driven customer operations overhaul, these questions are worth answering honestly.

What percentage of current support volume is genuinely routine and repetitive, versus requiring real human judgment?
Does your current system retain context across a conversation, or does every message start from zero?
How is compliance and accuracy currently verified for AI-generated responses, especially anything touching account details or regulatory information?
Is your legacy core banking software development stack capable of feeding real-time data into an NLP layer, or does that integration itself need modernization first?

Common Mistakes Worth Avoiding

Deploying NLP-driven automation without a clear, tested escalation path for anything genuinely ambiguous or high-stakes
Treating this as a pure customer support project when it actually requires deep integration with core banking and account systems to be genuinely useful
Underestimating the compliance review needed before any AI-generated response touches account-specific or regulatory information
Rolling this out across every channel simultaneously instead of piloting on a lower-risk workflow first, like general inquiries, before touching disputes or account changes

Why This Deserves Real Investment, Not a Quick Bolt-On

Getting this right touches more than a chatbot interface. It requires real integration with core banking systems, careful compliance review, and often work on the mobile banking app development side too, since a growing share of these interactions now happen inside the app itself rather than through a website or phone call. This is exactly the kind of cross-cutting fintech software development work that benefits from experience across both the AI layer and the underlying banking infrastructure, rather than treating the two as separate projects that happen to sit near each other.

The Takeaway

The gap between a bank that "has a chatbot" and one that's genuinely automating customer operations well usually comes down to what's happening underneath the interface, real intent understanding, real context retention, and real integration with the systems that actually hold the answers. As legacy banking modernization and open banking both continue expanding what customers expect to be able to do, the operations layer handling their questions needs to keep pace, not lag a generation behind.

Has your team started genuinely modernizing customer operations with NLP, or is the current setup still the same rigid chatbot from a few years ago wearing a new coat of paint? Curious how far along different banks and fintechs actually are with this.

The Vulnerability That Took Down Your Build Wasn't in Your Code

Emma Schmidt — Wed, 19 Aug 2026 05:46:54 +0000

You didn't write a single insecure line. You reviewed every pull request. Your own code is clean. And yet a routine dependency update just pulled in a compromised package three layers deep in your dependency tree, and now there's malicious code running in your CI pipeline that nobody on your team ever actually looked at. This isn't a hypothetical, it's the exact pattern behind a wave of real software supply chain attacks that's made securing the dependency chain one of the most active DevSecOps priorities of the year, not a compliance checkbox anymore, but a genuine engineering discipline.

Here's what's actually driving this, what a real defense looks like in practice, and how to start building it into a pipeline that doesn't already have it.

Why This Became Urgent Rather Than Theoretical

For years, supply chain security lived in the "we should probably think about this someday" category for most teams. A few things changed that.

Attackers shifted their target. Compromising one popular open-source package gives an attacker access to every downstream project that depends on it, which is a dramatically better return on effort than attacking one company directly
Dependency trees have grown enormous and mostly invisible. A modern project with a handful of direct dependencies can easily pull in hundreds of transitive ones, most of which nobody on the team has ever actually reviewed
CI/CD pipelines became a genuine attack surface of their own. A compromised build step doesn't just affect one developer's machine, it can inject malicious code directly into what gets shipped to production
Regulatory pressure caught up. Software bill of materials requirements are increasingly showing up in vendor contracts and compliance frameworks, turning "do we know what's in our dependency tree" from a nice-to-have into a real audit question
AI-driven systems raised the stakes further. As more production pipelines now include model training, fine-tuning, and inference steps alongside traditional code, the same supply chain exposure now extends to model weights, training data sources, and the infrastructure feeding them

What a Real Supply Chain Attack Actually Looks Like

Understanding the shape of these attacks makes the defense make a lot more sense.

A maintainer's account on a popular package gets compromised, and a malicious update gets published under a trusted name
A typosquatted package with a name one character off from a popular library gets installed by mistake during a routine npm install or pip install
A legitimate package gets acquired or handed off to a new maintainer who quietly introduces malicious code in a later version
A build script inside a dependency runs arbitrary code during installation, before your own application code ever executes

None of these require your team to write a single insecure line. They exploit the trust baked into how modern dependency management works by default.

The Core Defenses Worth Actually Building

Software Bill of Materials (SBOM)
A structured, complete inventory of every dependency in your project, direct and transitive. Without this, you genuinely don't know what's actually running in production, which makes it impossible to respond quickly when a vulnerability in a specific package gets disclosed.

Dependency pinning and lockfiles
Pinning exact versions rather than accepting a range prevents a compromised update from silently flowing into your build the next time someone runs an install. Lockfiles should be committed and treated as part of your actual source of truth, not a generated afterthought.

Automated vulnerability scanning
Continuously checking your dependency tree against known vulnerability databases, ideally as part of CI, so a newly disclosed issue in something you already depend on gets flagged automatically rather than discovered by accident.

Provenance verification
Confirming that a package actually came from where it claims to have come from, using cryptographic signing where the ecosystem supports it, rather than trusting a package registry blindly.

Least-privilege CI pipelines
Build steps should only have access to exactly what they need. A compromised dependency running inside an overprivileged CI job can do far more damage than one running with tightly scoped permissions.

A Practical Starting Sequence

You don't need to solve every layer of this at once. A reasonable order to tackle it in:

Generate an SBOM for your existing project as a baseline, so you actually know what's in your dependency tree today
Enable automated vulnerability scanning in CI, so new issues surface automatically going forward
Audit and commit your lockfiles, closing the gap where version ranges could silently pull in something unexpected
Review CI pipeline permissions, scoping down anything with broader access than it actually needs
Set a recurring cadence for dependency review, not just reacting when something breaks or gets flagged

Common Mistakes Worth Avoiding

Treating an SBOM as a one-time compliance document instead of something that needs to stay current as dependencies change
Scanning for vulnerabilities but never actually acting on what gets flagged, which makes the scanning theater rather than defense
Assuming a popular, widely-used package is automatically safe, when popularity is exactly what makes a package an attractive target
Giving CI pipelines broad, unscoped access "to make things easier," which turns a single compromised dependency into a much bigger incident
Skipping this entirely for internal tools and side projects, when those often have the least oversight and the most direct access to sensitive systems

A Quick Self-Check

Do you actually know every dependency in your project right now, including the transitive ones, or would you have to go find out?
Is your CI pipeline scanning for known vulnerabilities automatically, or does that only happen when someone remembers to check?
If a popular package you depend on were compromised tomorrow, how quickly could your team confirm whether you're affected?
Do your CI build steps have more access than they actually need to do their job?

If more than one of those gave you pause, there's real, addressable exposure sitting in your pipeline right now.

Why This Deserves Real Investment, Not a Checkbox

Supply chain security tends to get deprioritized precisely because it's invisible until the day it isn't. Building this properly, real SBOM tooling, automated scanning wired into CI, scoped pipeline permissions, is genuinely cross-cutting work that touches DevOps, security, and every team shipping code, and it's easy to underestimate the ongoing maintenance this requires as dependencies constantly shift underneath a project. This is exactly where AI security and AI infrastructure work increasingly overlaps with traditional DevSecOps too, since teams running models in production now need the same rigor applied to ML CI/CD pipelines, model governance, and compliance around training data provenance that they'd apply to any other dependency chain. Getting this foundation right early, across both code and model infrastructure, is a lot cheaper than untangling it after an incident.

The Takeaway

The vulnerability that takes down your build was never guaranteed to be one your own team wrote. Most modern software is built on a foundation of trust in dependencies nobody on the team has actually reviewed, and that trust is exactly what attackers are exploiting at scale right now. Treating supply chain security as core infrastructure, not an afterthought, is quickly becoming table stakes rather than a nice-to-have.

Has your team actually built out SBOM tooling and automated dependency scanning yet, or is this still sitting on the someday list? Curious how far along everyone actually is with this.

7 AI Integration Mistakes I Keep Seeing Teams Make in 2026

Emma Schmidt — Tue, 18 Aug 2026 05:32:29 +0000

I don't write about AI integration failures because they're rare.

I write about them because I keep seeing the exact same ones, on different teams, in different industries, month after month.

A mistake earns a spot on this list when I've watched it happen more than once. Not a one-off bad decision. A pattern.

I've spent a lot of time this year looking closely at how companies actually bring AI into existing products, not the demo version, the real production version with real users and real data on the line.

These are the seven mistakes that showed up again and again.

1. Treating AI Integration Like a Feature Flag

Repository of thought: "we'll just bolt it on and see how it goes."

I get why this feels reasonable. Ship fast, learn fast, iterate. But AI features aren't like a new button on a page. They touch data flow, user trust, and cost in ways a typical feature toggle doesn't.

The teams that get burned here usually find out the hard way, weeks later, when the "quick add" needs a rewrite because nobody thought about:

Where the data actually comes from
What happens when the model is wrong
How much this costs at real usage volume

2. Skipping the "What Happens When It's Wrong" Conversation

Every demo works. Every demo is cherry-picked, even unintentionally.

The conversation that actually matters happens after the demo: what does the user see when the AI confidently gives a wrong answer? Is there a fallback? Is there a way to flag it? Does anyone even find out it happened?

I've watched teams skip this conversation entirely and only have it for the first time after a customer complaint. That's the wrong order.

3. No Evaluation Loop, Just Vibes

"It feels like it's working well" is not a metric.

Teams that are serious about this build some kind of evaluation loop, a way to systematically check output quality against known good examples, before shipping and continuously after. Teams that skip this find out their AI feature quietly got worse three months in, and nobody noticed until a user did.

4. Underestimating the Data Quality Problem

This one isn't glamorous, which is probably why it gets skipped so often.

AI integration is only as good as the data feeding it. I've seen teams spend weeks tuning a prompt to fix a problem that was actually a data quality issue the whole time. Messy, inconsistent, or outdated source data will sink an otherwise well-built integration every time.

5. One Model, No Fallback

Betting an entire feature on a single model provider with no fallback plan is a real, recurring pattern I keep seeing.

What happens when that provider has an outage. What happens when pricing changes overnight. What happens when a model update shifts behavior in a way that breaks your carefully tuned prompts.

Teams that plan for this from day one recover from disruptions in hours. Teams that don't scramble for days.

6. Governance as an Afterthought

This is the one that worries me most, because it's invisible until it's a real problem.

Who's responsible for reviewing what the AI feature actually does. Who signs off on it touching sensitive data. Who's accountable if it produces something harmful or wrong in a regulated context. If nobody can answer these clearly, that's the actual gap, not a hypothetical one.

7. Measuring the Wrong Thing

"We shipped an AI feature" isn't a success metric. Neither is "users are using it."

The teams doing this well are measuring whether the feature actually improved the outcome it was supposed to improve, resolution time, task completion, accuracy against a real baseline. Everything else is activity dressed up as progress.

A Quick Table, Because Patterns Are Easier to See This Way

Mistake	What It Actually Costs You
Bolting AI on like a feature flag	Rework once real data and edge cases show up
No plan for wrong answers	Trust erosion the first time a user hits one
No evaluation loop	Silent quality drift nobody catches in time
Ignoring data quality	Wasted weeks tuning prompts that were never the real problem
No fallback model	Full outages instead of graceful degradation
No governance ownership	A real incident with no clear accountability
Vanity metrics	Confidently shipping something that isn't actually working

What I'd Tell a Team Starting This Today

Slow down on the parts that feel boring. Data quality, evaluation, governance, none of it is exciting, all of it is where the real risk actually lives.

The AI part is usually not the hard part anymore. The hard part is everything around it, the parts that don't show up in a demo.

Final Thoughts

None of these seven mistakes are exotic. They're not edge cases. They're the ordinary, predictable ways AI integration goes sideways when a team moves fast without slowing down for the boring, unglamorous parts.

I don't think that's a knock on any team that's hit one of these. I've watched genuinely sharp engineers walk into every single one of them, because the pressure to ship fast is real and these mistakes are easy to make with the best of intentions.

If you're integrating AI into a real product right now, I'd rather you catch these on paper than in production.

Which of these have you actually run into? Curious how many of these seven are familiar to people reading this.

Top AI Coding Tools Every Developer Should Know in 2026

Emma Schmidt — Mon, 17 Aug 2026 12:56:58 +0000

A year ago, "AI coding assistant" mostly meant autocomplete on steroids. In 2026, that's no longer true. We've moved from inline suggestions to agentic AI tools that can plan a task, write across multiple files, run your test suite, and fix their own mistakes before you even open the diff.

If you're a developer trying to figure out which tools are actually worth wiring into your workflow (and which are just hype), this guide breaks it down: what's changed, how to evaluate these tools, a side-by-side comparison, and a practical framework for adopting them on a real engineering team.

Why This Shift Matters

The jump from "autocomplete" to "agent" isn't just a marketing term. It changes how you work:

Autocomplete-era tools predicted the next few lines of code based on context.
Chat-era tools let you ask questions and get code snippets back.
Agentic-era tools take a goal ("add pagination to this API and update the tests"), break it into steps, execute those steps across your codebase, and self-correct using tool feedback like compiler errors or failing tests.

That last category is what's driving real productivity gains right now but it also introduces new questions around code review, security, and trust that teams need a process for, not just a tool.

How to Evaluate an AI Coding Tool

Before comparing specific products, it helps to have a checklist. Here's what actually matters when you're picking a tool for a team (not just a solo side project):

Context window & codebase awareness: Can it reason across your whole repo, or just the open file?
Agentic capability: Can it execute multi-step tasks (run tests, fix errors, open a PR) or only suggest text?
IDE / CLI fit: Does it live where your team already works, or does it force a workflow change?
Security & data handling: Where does your code go? Is there an enterprise/on-prem option?
Cost model: Per-seat, usage-based, or bundled into an existing subscription?
Review friction: Does it produce diffs a human can review quickly, or large unreviewable rewrites?

Comparison: Popular AI Coding Tools in 2026

Tool	Best For	Works In	Agentic?	Notable Strength
GitHub Copilot	General-purpose autocomplete + chat	VS Code, JetBrains, GitHub.com	Partial (Copilot Workspace)	Deep GitHub/PR integration
Claude Code	Terminal-first, multi-file agentic coding	CLI, VS Code, JetBrains	Yes	Strong reasoning on large refactors
Cursor	AI-native IDE experience	Standalone editor (VS Code fork)	Yes	Tight inline editing + chat loop
Amazon Q Developer	AWS-centric teams	IDEs, AWS Console	Partial	Native AWS service knowledge
Windsurf	Agentic pair-programming	Standalone editor	Yes	"Flow" mode for long tasks
Tabnine	Privacy-conscious teams	Most major IDEs	No	Self-hosted / on-prem options

Note: this landscape moves fast pricing, features, and even product names shift every few months, so treat this as a snapshot rather than a permanent ranking. Always check the vendor's docs before committing a team to one.

A Practical Adoption Framework

Handing an entire engineering org an AI coding tool on day one usually backfires you get inconsistent usage, review bottlenecks, and skepticism from senior engineers who've been burned by low-quality AI output. A more reliable rollout looks like this:

Pilot with a small, willing team: on a real (but non-critical) project for 2–4 weeks.
Define review rules: e.g., AI-generated PRs still require the same review bar as human ones, no exceptions.
Track outcomes, not vibes: cycle time, bug rate, and PR size are better signals than "it feels faster."
Standardize the toolchain: so context (style guides, architecture docs) is shared across the team instead of living in one engineer's prompts.
Revisit quarterly:this space changes fast enough that a tool decision from six months ago may already be outdated.

This is close to how engineering teams evaluate any new dependency: agentic AI coding tools are powerful, but they still need the same rigor as any other addition to a production workflow. Teams that treat AI tooling as an accelerant for experienced engineers not a replacement for code review and architecture decisions tend to get the most durable results.

A Quick Example: Agentic Refactor in Practice

Here's a simplified illustration of the kind of task an agentic tool can now handle end-to-end, versus what you'd have done manually a year ago:

# Old way: you write the prompt, get a snippet, paste it, fix imports, run tests manually
$ ai "write a function to paginate this list"

# Agentic way: the tool plans, edits multiple files, runs tests, and reports back
$ agent run "add cursor-based pagination to /api/users, update the OpenAPI spec, and make the existing tests pass"

# Example output the agent might produce and then validate against your test suite
def paginate_users(users, cursor=None, limit=20):
    start = 0
    if cursor:
        start = next((i for i, u in enumerate(users) if u["id"] == cursor), 0) + 1
    page = users[start:start + limit]
    next_cursor = page[-1]["id"] if len(page) == limit else None
    return {"items": page, "next_cursor": next_cursor}

The difference isn't the code itself it's that the agent verified the change against your real test suite before handing it back, closing the loop that used to require a human every time.

Where This Is Heading

A few trends worth watching as 2026 progresses:

Agentic AI moving from "assistant" to "team member": tools that pick up tickets, open draft PRs, and tag humans only when they're stuck.
AI-driven workflow automation: spreading beyond coding into project management, QA, and DevOps pipelines not just writing code, but operating around it.
Low-code/no-code and pro-code converging: with AI acting as the translation layer between visual builders and hand-written code for teams that outgrow no-code tools.
Stronger emphasis on governance: code provenance, license compliance, and audit trails for AI-generated code, especially in regulated industries like fintech and healthcare.

Final Thoughts

AI coding tools in 2026 aren't a novelty anymore they're infrastructure. The teams getting the most value aren't the ones chasing every new tool, but the ones treating adoption like any other engineering decision: pilot it, measure it, standardize it, and keep your review bar exactly where it was before AI showed up.

If you're building out this kind of process for your own team, start small, measure real outcomes, and resist the urge to lower your review bar just because the code came from an agent instead of a human.

Your AI Chatbot Forgets Everything the Moment You Close the Tab. Here's the Fix Nobody's Talking About Yet.

Emma Schmidt — Wed, 05 Aug 2026 05:18:19 +0000

Ask a typical RAG-powered AI assistant a follow-up question that depends on something you mentioned three messages ago, and watch it quietly lose the thread. Standard retrieval-augmented generation is excellent at pulling relevant chunks of text based on similarity, and genuinely terrible at understanding how pieces of information actually relate to each other or persisting what it learned about you across a session. This exact gap is what's pushing serious AI application development toward GraphRAG and contextual memory, two of the fastest-moving concepts in AI architecture right now.

Here's what's actually broken with traditional RAG, what GraphRAG and contextual memory do differently, and how to think about building with them.

Why Standard RAG Hits a Wall

Traditional RAG works by chunking documents, embedding them, and retrieving the chunks most semantically similar to a user's query. It's simple, effective for straightforward lookup questions, and has become the default pattern for grounding AI responses in real data.

It also has real, well-known limitations that show up quickly in production.

Limitation	What It Looks Like in Practice
No relationship awareness	Retrieves individual chunks but misses how entities and facts connect across documents
Weak multi-hop reasoning	Struggles with questions requiring several linked facts, like "which vendor supplies the part used in the product that failed last quarter"
No persistent memory	Each query is treated in isolation, with no real understanding of what happened earlier in the conversation
Chunking artifacts	Splitting documents into fixed-size chunks can sever context that spans a chunk boundary, losing meaning
Redundant retrieval	Similar chunks from different documents often surface together, adding noise instead of new information

None of this makes standard RAG useless. It makes it a genuinely good starting point that runs out of runway the moment your application needs to reason across relationships or remember anything meaningfully across turns.

A Concrete Example of Where This Breaks Down

Picture an internal AI assistant built for a mid-sized company's operations team, trained on years of vendor contracts, compliance documents, and internal policy memos. Someone asks: "Which of our vendors would be affected if the new data residency policy applies to our EU contracts?"

A standard RAG setup retrieves chunks mentioning "vendors," separately retrieves chunks mentioning "data residency policy," and separately retrieves chunks mentioning "EU contracts." Nothing in that retrieval step actually confirms which vendors are tied to which contracts, or which contracts fall under EU jurisdiction. The model is left to guess at the connections from loosely related text, and in a compliance context, a confident guess dressed up as an answer is genuinely dangerous.

This is exactly the class of failure that pushed graph-based approaches from a research curiosity into a real production pattern this year, anywhere the cost of a wrong but confident-sounding answer is high.

What GraphRAG Actually Changes

GraphRAG restructures the underlying knowledge as a graph, entities as nodes, relationships as edges, instead of a flat collection of embedded text chunks. Instead of retrieving isolated pieces of text based purely on similarity, the system can traverse relationships to answer questions that require connecting multiple facts together.

Entity-relationship structure. Facts aren't just stored, they're connected: a product links to its supplier, which links to a region, which links to a regulation
Multi-hop query support. A question requiring three connected facts can be answered by traversing the graph, rather than hoping all three facts happen to land in the same retrieved chunk
Community-level summarization. Graph-based approaches can summarize entire clusters of related entities, giving a system a genuine overview rather than a pile of disconnected snippets
Better handling of sparse or niche domains. Where a document corpus is small or highly specialized, relationship structure often surfaces relevant context that pure similarity search misses entirely

How a Knowledge Graph Actually Gets Built

It's worth demystifying this a bit, since "build a knowledge graph" can sound more exotic than the actual process.

Entity extraction. An initial pass through the source documents identifies key entities, people, products, organizations, regulations, dates
Relationship extraction. A second pass identifies how those entities connect, which vendor supplies which product, which contract falls under which jurisdiction
Graph construction. Entities become nodes and relationships become edges, forming a structured map of the underlying data instead of a flat pile of text chunks
Community detection. Related clusters of nodes get grouped, which enables the community-level summarization that flat retrieval simply can't produce
Ongoing maintenance. As source documents update, the graph needs re-processing to reflect new entities and relationships, which is the step most teams underestimate when planning a build

Contextual Memory: The Other Half of the Problem

GraphRAG solves the relationship problem. Contextual memory solves the persistence problem, the part where a system actually remembers relevant information across a conversation or across sessions, instead of starting from zero every single time.

Short-term working memory tracks what's been discussed in the current session, so a follow-up question doesn't need to restate context the user already gave
Long-term memory persists meaningful facts about a user or task across sessions, a returning customer's preferences, a project's ongoing status, a prior decision that shouldn't need repeating
Selective memory, not total recall matters just as much as remembering. A well-designed system decides what's actually worth retaining rather than storing every message verbatim, which keeps retrieval fast and relevant instead of bloated

Different Approaches to Implementing Memory

Not all contextual memory systems work the same way, and picking the right approach matters.

Approach	How It Works	Best Suited For
Sliding window	Keeps the last N messages in full	Short interactions where recent context is all that matters
Summarization-based	Periodically compresses older turns into a running summary	Longer conversations where full detail on early turns matters less over time
Fact extraction	Pulls out specific durable facts and stores them separately from the raw conversation	Cross-session persistence, like remembering a user's stated preferences
Hybrid	Combines a short-term window with extracted long-term facts	Most production systems, balancing responsiveness with genuine persistence

Most serious production systems end up using some version of the hybrid approach, since a sliding window alone can't persist across sessions, and pure summarization alone tends to lose specific, useful details that fact extraction preserves.

How These Two Pieces Fit Together

GraphRAG and contextual memory solve different problems, and the strongest AI applications right now are combining both rather than picking one.

GraphRAG handles reasoning across your knowledge base, connecting facts that live in different documents or records
Contextual memory handles reasoning across the conversation itself, remembering what the user already told the system
Together, they let an AI application answer a question like "does this apply to the client I mentioned earlier, given the update we discussed last week" by pulling both the relationship structure from the knowledge graph and the recalled context from memory

A Simplified Illustration of the Difference

Standard RAG on a multi-hop question:

"Which of our suppliers are affected by the new import regulation?"
Retrieves chunks mentioning "suppliers" and chunks mentioning "import regulation" separately, with no guarantee the system connects which supplier is actually affected by which regulation.

GraphRAG on the same question:

Traverses supplier nodes connected to region nodes connected to regulation nodes, returning the specific suppliers actually linked to the affected region, because that relationship is explicitly modeled rather than inferred from text similarity.

Add contextual memory:

If the user previously said "we're focused on our European suppliers this quarter," the system recalls that context and narrows the answer accordingly, without the user needing to repeat it.

Where Teams Get This Wrong

Jumping to GraphRAG for every use case, when a simple, well-chunked standard RAG setup is genuinely sufficient for straightforward lookup tasks and adds unnecessary complexity for no real benefit
Building memory that stores everything indiscriminately, which bloats retrieval and actually makes responses slower and noisier rather than smarter
Treating graph construction as a one-time task, when knowledge graphs need ongoing maintenance as entities and relationships change over time
Ignoring evaluation entirely, shipping a GraphRAG or memory system without a way to systematically test whether it's actually improving answer quality over the simpler baseline it replaced
Conflating memory with logging, storing raw conversation history and calling it memory, without any real process for deciding what's actually worth retaining long term

A Quick Framework for Deciding What You Need

Does your use case genuinely require connecting facts across multiple documents or records, or are most queries simple, single-fact lookups?
Does your application need to remember information across turns or sessions, or is each interaction naturally self-contained?
Do you have the ongoing resources to maintain a knowledge graph as your underlying data evolves?
How costly is a wrong but confident-sounding answer in your specific use case? The higher that cost, the stronger the case for the added structure GraphRAG provides

Common Questions Teams Ask When Evaluating This

Does GraphRAG replace standard RAG entirely?
No, most production systems use both together. Simple lookups can still go through standard retrieval, while multi-hop reasoning questions route through the graph.

How much does this increase latency?
Graph traversal adds some overhead compared to a single similarity search, though well-indexed graphs with efficient traversal patterns keep this manageable for most interactive use cases. Benchmarking on your actual data is essential rather than assuming.

Is this only worth it for large enterprises?
No. Smaller, highly specialized domains often benefit even more, since sparse document corpora are exactly where relationship structure tends to add the most value over pure similarity search.

Why This Is Worth Building Properly

Getting graph construction, retrieval traversal, and memory persistence right together is genuinely more involved than standing up a basic RAG pipeline, and it's easy to underestimate the ongoing maintenance a knowledge graph requires as your data changes. This is exactly the kind of RAG development and AI application architecture work that separates a genuinely smarter AI app from one that just looks smart in a demo, and it's usually worth getting a second opinion on before committing to a full build.

The Takeaway

Standard RAG got a lot of AI applications off the ground, and it's still the right choice for plenty of use cases. But the moment an application needs to reason across relationships or remember anything meaningfully across a conversation, that flat, isolated retrieval model runs out of road fast. GraphRAG and contextual memory are exactly the pair of ideas closing that gap this year, and understanding when you actually need them, not just how to build them, is quickly becoming a core skill for anyone building serious AI products.

Has your team started experimenting with GraphRAG or persistent memory yet, or is standard RAG still handling everything you're throwing at it? Curious how far along everyone actually is with this.

Your App Has AI Features. That's Not the Same Thing as Being an AI Company Anymore.

Emma Schmidt — Fri, 31 Jul 2026 10:48:07 +0000

There's a quiet but important distinction reshaping how serious software gets built in 2026, and most teams haven't caught up to it yet. Bolting a chatbot onto an existing app and designing an application where AI is the actual architecture are two completely different engineering disciplines, and the gap between them is becoming one of the clearest competitive differentiators in software today. This is exactly the shift driving demand for real custom AI development, not a plugin added after the fact, but AI woven into how a system makes decisions, processes data, and adapts from the very first architectural diagram.

Here's what actually separates AI-native software from AI-enhanced software, why the distinction matters more than it sounds, and how to think about it if you're planning a build.

AI-Enhanced vs AI-Native: The Real Difference

Most existing "AI-powered" products today are AI-enhanced. A traditional application, built the same way it always would have been, with a recommendation widget, a search-with-AI feature, or a support chatbot added on top. The underlying system, its data flow, its decision logic, its architecture, remains essentially unchanged.

An AI-native application is architected differently from day one. Intelligence isn't a feature sitting on top, it's part of how the system actually functions.

Dimension	AI-Enhanced	AI-Native
Where AI sits	Bolted on as a feature or module	Built into the core architecture
Data flow	Static, mostly predefined	Continuous, feeding real-time model decisions
Adaptability	Fixed behavior between releases	Learns and adjusts from ongoing data
Typical origin	Retrofit of an existing product	Designed around AI from the first architecture decision
Failure mode when done poorly	AI feature feels bolted on, inconsistent with the rest of the app	Poor governance and evaluation gaps compound across the whole system

Neither approach is inherently wrong. A lot of genuinely good products are AI-enhanced and don't need to be anything else. But for products where intelligence is meant to be the actual value proposition, retrofitting an existing architecture tends to be far more expensive and painful than building AI-native from the start.

Why This Shift Is Happening Now

A few forces are converging to push serious teams toward AI-native thinking rather than incremental AI feature additions.

Retrofitting is proving genuinely costly. Teams that added AI as an afterthought are running into architectural walls, data pipelines that weren't built for continuous model input, decision logic that was never designed to be adaptive, and it's turning into expensive rework rather than a quick feature addition
Evaluation and observability are now considered table stakes, not extras. Serious AI development in 2026 increasingly means having real evaluation pipelines that systematically test outputs against known-good examples, not just shipping a prompt and hoping it behaves
Security expectations have caught up with adoption. Prompt injection, data exfiltration through AI interfaces, and output manipulation are now treated as real attack vectors, which means the AI layer needs the same security discipline as any other system boundary, not a bolted-on afterthought
Multi-model orchestration is becoming a standard architectural component. Rather than routing everything through one model, AI-native systems increasingly route different tasks to different models based on cost, latency, and capability, which only works cleanly if the architecture was designed with that flexibility in mind

What AI-Native Architecture Actually Requires

Building this way touches more of the stack than a typical feature addition would.

Data pipelines designed for continuous flow, not periodic batch updates, since adaptive systems need fresh data to actually adapt
Evaluation infrastructure built in from the start, tracking output quality, catching model regressions, and validating behavior against real, known-good examples
Clear governance around AI decision-making, especially for anything touching regulated data or high-stakes outcomes, where explainability and audit trails matter
Architecture flexible enough for multi-model routing, so the system isn't locked into a single model provider or a single point of failure
Security treated as a first-class concern for the AI layer specifically, not assumed to be covered by the same protections as the rest of the application

Real-World Scenarios Where This Distinction Actually Matters

To make this concrete, here's where the AI-native versus AI-enhanced choice genuinely changes the outcome.

A support platform adding a chatbot to an existing ticketing system is AI-enhanced. A support platform where routing, prioritization, and resolution suggestions are all driven continuously by live data from the start is AI-native, and it behaves fundamentally differently as ticket volume and complexity grow
A financial analytics tool with an AI summary feature bolted onto existing dashboards is AI-enhanced. One where risk scoring and forecasting are core to how the system processes every transaction is AI-native
An internal knowledge tool with search-with-AI added to an existing wiki is AI-enhanced. One built around continuously updated embeddings and adaptive retrieval from the ground up is AI-native
A logistics platform with a recommendation widget for routing suggestions is AI-enhanced. One where routing decisions are made continuously by an adaptive model integrated into the core dispatch logic is AI-native

Where Teams Get This Wrong

Assuming AI-native means "use more AI features." It's an architectural distinction, not a feature count. A product can have fewer visible AI features and still be genuinely AI-native if intelligence is core to how it functions
Skipping the evaluation and governance layer to move faster. This is the corner that gets cut most often, and it's the one that causes the most expensive problems later, once the system is handling real production decisions
Treating security as something to add after the AI features work. By the time an AI-native system is live, retrofitting proper security around prompt handling and data access is far harder than designing it in from the start
Underestimating the data infrastructure work. Teams often plan for the model and the interface, but underestimate how much of the actual effort lives in the data pipelines that feed continuous, adaptive behavior

A Quick Framework for Deciding What You Actually Need

Before committing to a full AI-native rebuild, it's worth being honest about which category your product actually falls into.

Is intelligence the core value proposition, or a helpful addition to a product that works fine without it?
Does your system need to adapt continuously based on new data, or would periodic updates genuinely be sufficient?
Do you have, or are you willing to build, the evaluation and governance infrastructure this approach requires?
Is your team prepared for the security implications of treating the AI layer as a first-class system boundary?

If the honest answer to the first two questions is "yes, genuinely," AI-native architecture is worth the upfront investment. If AI is a nice complement to an otherwise solid, deterministic product, a well-built AI-enhanced approach is often the more practical, lower-risk choice.

Why This Is Genuinely Hard to Get Right Alone

This isn't a criticism of any team, it's just an honest reflection of how new and fast-moving this discipline still is. The specific technical profile this requires, deep experience across data pipeline design, model evaluation, multi-model orchestration, and AI-specific security, remains genuinely scarce in most hiring markets right now. That's exactly why a lot of serious AI software development work today involves custom AI development support and AI readiness assessment brought in from outside, specifically to architect the foundation correctly before a team commits to a direction that's expensive to unwind later. Getting an experienced second opinion on whether a product genuinely needs full AI-native architecture, or whether a well-built AI-enhanced approach would serve it just as well, is often the highest-leverage conversation to have before writing a single line of the core architecture.

The Future Outlook

The gap between AI-enhanced and AI-native products is likely to keep widening over the next year or two, not narrow. As evaluation tooling matures and multi-model orchestration becomes more standardized, AI-native architecture is expected to shift from a differentiator into a baseline expectation, particularly for products where intelligence genuinely is the value proposition rather than a nice-to-have layered on top.

The Takeaway

Having AI features and being architected as an AI company are not the same thing, and that distinction is only going to matter more as the products competing for the same users diverge further along these two paths. The teams thinking carefully now about whether they genuinely need AI-native architecture, versus a solid, well-built AI-enhanced product, are the ones avoiding the expensive retrofit conversation a year or two from now.

Is your product built AI-native from the ground up, or is it AI-enhanced with intelligence layered on top? Curious where most teams here actually land on that distinction once they think it through honestly.

Build Your First MCP Server: A Practical Guide to Connecting AI Agents to Real Tools

Emma Schmidt — Thu, 30 Jul 2026 06:43:25 +0000

Learn how to build a working MCP server from scratch and connect it to an AI client, step by step.

Introduction

If you've ever needed an AI agent to check a database, call an internal API, or search a knowledge base, you've probably hit the same wall: every tool integration ends up as custom, one-off code that doesn't transfer to your next project. MCP server development and MCP integration solve this by giving you one standardized way to expose any tool or data source to any compatible AI client, instead of writing bespoke glue code for every combination.

This tutorial walks through building an actual working MCP server, connecting it to a client, and testing that it works end to end. By the end, you'll have a functioning server exposing a real tool, and you'll understand exactly what's happening at each layer instead of just copying a snippet.

Prerequisites

Comfortable reading and writing basic Python
Python 3.10 or later installed
A terminal and a code editor
Roughly 30-45 minutes

What We're Building

We're building a small MCP server that exposes one practical tool: looking up the weather for a given city. It's simple enough to fully understand in one sitting, but it demonstrates every core piece of setting up MCP tool integration.

The finished server will be able to:

Advertise its available tools to any connecting MCP client
Accept a tool call with a specific input (a city name)
Return a structured response back to the calling AI agent
Run locally so you can test it directly from your terminal

Step 1: Set Up Your Environment

Create a project folder and install the MCP SDK.

mkdir mcp-weather-server
cd mcp-weather-server
python -m venv venv
source venv/bin/activate  # on Windows use venv\Scripts\activate
pip install mcp requests

This gives you the core MCP library plus requests, which we'll use to call a public weather API inside our tool.

Step 2: Define the Server and Register Your Tool

Create a file called server.py. This is illustrative, simplified code meant for learning, not a full production implementation.

# server.py
from mcp.server import Server
from mcp.types import Tool, TextContent

app = Server("weather-server")

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_weather",
            description="Get the current weather for a given city",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "Name of the city"}
                },
                "required": ["city"]
            }
        )
    ]

This list_tools function is how a client discovers what your server can do. When an AI agent connects, it asks "what tools do you have," and this is the answer it gets back, in a structured format it can reason about.

Step 3: Implement What the Tool Actually Does

Now add the logic that runs when the tool is actually called.

# server.py (continued)
import requests

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_weather":
        city = arguments["city"]
        # Simplified example call, replace with a real weather API and key
        response = requests.get(f"https://example-weather-api.test/v1/current?city={city}")
        data = response.json()
        summary = f"The weather in {city} is {data.get('condition', 'unknown')} at {data.get('temp', '?')}°"
        return [TextContent(type="text", text=summary)]

This is the execution layer. The AI model never talks to the weather API directly, it calls your tool through the protocol, and your code decides exactly what happens and what comes back.

Step 4: Run the Server Locally

Add a simple entry point so the server can actually start.

# server.py (continued)
from mcp.server.stdio import stdio_server
import asyncio

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(read_stream, write_stream, app.create_initialization_options())

if __name__ == "__main__":
    asyncio.run(main())

Run it with:

python server.py

At this point, the server is running and waiting for a client to connect over standard input and output, which is the simplest transport for local development and testing.

Step 5: Connect a Client and Test It

To actually test this, you need an MCP-compatible client configured to launch your server. Most MCP client configurations use a simple JSON entry pointing to your script.

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/full/path/to/server.py"]
    }
  }
}

Once your client is configured and connected, ask it something like "what's the weather in Lisbon." If everything is wired correctly, the client will discover your get_weather tool through the list_tools call, invoke it with the city argument, and return the result from your call_tool function back through the model's response.

Testing / Verifying It Works

A few checks to confirm your MCP server integration is actually functioning correctly:

Confirm the client's tool list shows get_weather as an available tool after connecting
Manually call the tool with a test city and check that the response text looks correct
Try an invalid or missing argument and confirm your server doesn't crash silently
Restart the client and reconnect to make sure the server initializes cleanly every time, not just on the first run

Common Pitfalls and How to Avoid Them

Forgetting to validate input. A missing or malformed city argument will crash a naive implementation. Add basic validation before making the external call.
Blocking calls inside async functions. Using a purely synchronous HTTP library inside an async tool handler can freeze your server under load. Consider an async HTTP client for anything beyond a simple learning project.
Not handling API failures gracefully. If the weather API is down, your tool should return a clear error message, not throw an unhandled exception that breaks the whole session.
Overloading one server with too many unrelated tools. Keeping a server focused on one coherent set of capabilities makes it easier for both you and the connecting AI agent to reason about.

Best Practices for Production Use

Add proper authentication and scoped permissions before exposing any server beyond local testing
Log every tool call, including inputs and outcomes, so failures are debuggable after the fact
Set reasonable timeouts on any external API calls inside your tools
Validate all inputs against your declared schema before executing any logic
Version your tool definitions so you can evolve them without silently breaking existing clients

What to Explore Next

Add a second, related tool to the same server, like a multi-day forecast, and see how tool discovery scales
Swap the stdio transport for Streamable HTTP to run your server as a proper remote service
Explore adding authentication middleware so only verified callers can invoke your tools
Look into structured output schemas so responses can be validated programmatically instead of just returned as plain text

Conclusion

Building your first MCP server strips away a lot of the mystery around MCP integration once you've actually wired up discovery, execution, and a real client connection yourself. The pattern you just built scales directly to far more complex tools, databases, internal APIs, search systems, without changing the underlying shape of what you learned here. Once this clicks, adding your next tool is a lot faster than the first one was.

There's a New Universal Plug for AI, and Most Developers Haven't Wired It In Yet

Emma Schmidt — Wed, 29 Jul 2026 12:26:39 +0000

Picture this. You've built an AI feature that needs to check a customer's order status, pull data from your CRM, and search internal documentation, three separate systems, three separate custom integrations, each with its own auth, its own data format, its own maintenance burden. Now imagine adding a fourth tool next quarter. And a fifth. This exact integration sprawl is precisely the problem the Model Context Protocol was built to solve, and it's become one of the fastest-adopted standards in recent memory across LLM & GenAI development. Understanding how to actually build with it, not just read about it, is quickly becoming a core skill for anyone shipping AI features that need to touch real data and real tools.

Here's what MCP actually is, why it's spreading this fast, and how to build your first working MCP server step by step.

Why This Protocol Is Spreading Faster Than Almost Anything in AI Tooling

The adoption numbers here are genuinely unusual, even for an industry used to fast-moving trends.

Metric	Figure
Monthly SDK downloads (March 2026)	97 million, up from roughly 100,000 at launch
Time to reach 100M+ monthly downloads	About 16 months
Comparable milestone for React's npm package	Roughly 3 years
Public MCP servers in the official registry	Around 9,600 as of a May 2026 snapshot
Fortune 500 companies with MCP deployed	Roughly 28% within 18 months of launch
Major platforms with shipped MCP support	OpenAI, Google, Microsoft, and others within about 13 months of launch

That last row is the one worth sitting with. A protocol originally released by Anthropic in November 2024 has since been adopted broadly enough across the industry that it now functions as shared infrastructure rather than one company's proprietary approach, which is exactly the kind of cross-platform momentum that turns a promising idea into a genuine standard.

What MCP Actually Solves

Before MCP, connecting an AI application to external tools meant building a custom integration for every single combination of model and tool. Ten AI applications and a hundred tools meant a potential one thousand separate integrations, each one bespoke, each one a maintenance burden of its own.

MCP replaces that with one standardized interface. Think of it the way USB-C replaced a drawer full of proprietary charging cables. Any MCP-compatible client can talk to any MCP-compatible server through the same protocol, regardless of which model or which tool is on either end.

The Three Core Pieces You Need to Understand

MCP Host. The AI application itself, the thing the end user actually interacts with
MCP Client. Lives inside the host and manages the connection to one or more MCP servers
MCP Server. Exposes specific tools, data sources, or capabilities in the standardized format the protocol expects

Most developers building on top of MCP will spend their time on the server side, exposing their own systems and tools so any compatible AI application can use them.

Building Your First MCP Server, Step by Step

Let's build a simple MCP server that exposes a single tool, checking an order status, using the official Python SDK.

Step one: install the SDK

pip install mcp

Step two: define the server and register a tool

from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("order-status-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_order_status",
            description="Look up the current status of a customer order",
            inputSchema={
                "type": "object",
                "properties": {
                    "order_id": {"type": "string"}
                },
                "required": ["order_id"]
            }
        )
    ]

This is the discovery step. Any MCP client connecting to this server can now ask what tools are available and get back a structured description it can reason about.

Step three: implement what the tool actually does

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_order_status":
        order_id = arguments["order_id"]
        status = lookup_order_in_database(order_id)
        return [TextContent(type="text", text=f"Order {order_id} status: {status}")]

This is the actual execution layer. The AI model never touches your database directly, it calls the tool through the standardized protocol, and your server controls exactly what happens and what gets returned.

Step four: run the server with the appropriate transport

from mcp.server.stdio import stdio_server

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await server.run(read_stream, write_stream, server.create_initialization_options())

Local development typically uses stdio transport. Production deployments increasingly use Streamable HTTP, which lets the server run as a proper remote service rather than a local process, and it's the transport most enterprise MCP rollouts are standardizing around this year.

Step five: secure it before it goes anywhere near production

from mcp.server.auth import RequireAuth

@server.call_tool()
@RequireAuth(scopes=["orders:read"])
async def call_tool(name: str, arguments: dict, context):
    # verified caller identity is available in context
    ...

Every tool call should carry proper identity and scope verification. A recent industry analysis noted that in the MCP era, trust isn't established once at login, it's re-earned with every single tool call and data access an agent makes, which is a meaningfully different security posture than traditional API authentication.

What's Changing Right Now, as of This Week

This is genuinely current, not stale reporting. The next major MCP specification, dated 2026-07-28, has its release candidate locked and is shipping as the final spec this week. It introduces a stateless protocol core, an Extensions framework for adding capabilities without breaking existing implementations, a formal deprecation policy, and hardened authorization. If you're starting a new MCP implementation right now, building against this version rather than the November 2025 spec is the right call, since SDK maintainers are expected to support it within a defined validation window.

Common Mistakes Teams Are Making With Early MCP Adoption

Tool overexposure. Registering far more tools than a given workflow actually needs, which bloats the context an AI model has to reason over and increases the chance of it calling the wrong tool
Treating authentication as an afterthought. Standing up a functional MCP server quickly and only addressing proper scoped auth after it's already been connected to something sensitive
Ignoring observability. Deploying MCP servers into production workflows without tracking tool call success rates, latency, or error patterns, which makes debugging a failed agent workflow nearly impossible after the fact
Skipping the governance conversation. Rolling out MCP servers across a team or organization without agreeing on security, compliance, and identity controls up front, then retrofitting governance after adoption has already sprawled

Why This Matters Beyond the Hype Cycle

MCP exhibits genuine network effects. Every new MCP server makes every existing MCP client more capable, and every new client makes building an MCP server more worthwhile. That's a structurally different growth pattern than most developer tools, and it's part of why the ecosystem has grown as fast as it has.

For teams evaluating whether to invest in this now, the practical answer is usually yes, but scoped carefully. Building custom MCP connectors and servers for your own internal tools and data sources, wired into RAG development and existing LLM and GenAI workflows, is exactly the kind of foundational integration work that compounds in value as your AI features grow, rather than something that needs rebuilding from scratch every time a new tool gets added to the stack.

The Takeaway

The integration sprawl that used to make connecting AI to real business tools a slow, custom, one-off project each time is exactly what MCP was built to eliminate. With cross-vendor support, a maturing specification, and genuine network effects driving adoption, this has moved well past experimental territory into shared infrastructure that's shaping how serious AI applications get built this year.

Has your team started building or adopting MCP servers yet, or are you still wiring up custom integrations one tool at a time? Curious how far along everyone actually is with this.

Tags: #ai #llm #genai #tutorial

Your AI Feature Isn't Slow. Your Architecture Is Making It Feel Slow.

Emma Schmidt — Tue, 28 Jul 2026 10:30:54 +0000

You've seen it a hundred times. A user types a question into an AI feature, hits submit, and then just stares at a blank screen for eight seconds before a wall of text dumps onto the page all at once. That gap between "I asked something" and "something happened" is exactly where users lose patience, and it's rarely the model's fault. It's almost always a streaming problem, not a speed problem. This is one of the core patterns behind modern AI services and AI web application development, and getting it right in Next.js is simpler than most developers expect, especially now that the framework's App Router and Server Actions map almost perfectly onto how real-time AI responses actually need to flow.

Here's how to build a genuinely responsive, streaming AI feature in Next.js from the ground up, understanding what's actually happening under the hood instead of just wiring up a library and hoping.

Why Streaming Changed What "Fast" Means for AI Features

A non-streaming AI feature waits for the entire response to generate before showing anything. For short answers that's tolerable. For anything longer, a paragraph, a summary, a generated document, it means staring at a static loading spinner for several seconds with zero feedback that anything is actually happening.

Streaming flips this. Tokens appear as the model generates them, the same way ChatGPT-style interfaces work. The perceived speed difference is enormous even when the total generation time is identical, because the user sees progress immediately instead of waiting in silence.

The Real-World Difference This Makes

Picture a support tool generating a written summary of a long customer thread. The generation itself takes about six seconds either way.

Without streaming: the user submits, sees a static spinner, and waits the full six seconds staring at nothing. To someone who isn't sure the request even registered, six seconds of silence feels much longer than it actually is, and a meaningful number of users will refresh or click again out of doubt, sometimes triggering a duplicate request.

With streaming: the user sees the first words appear within a few hundred milliseconds, and text keeps flowing steadily until the summary is complete. The total time is identical, but it reads as fast because there's constant, visible progress instead of dead air.

Same backend, same model, same six seconds of actual compute. The only difference is architecture, and it's the difference between a feature that feels broken and one that feels instant.

Choosing Your Transport Mechanism

Before writing code, it's worth understanding the three real options for getting streaming data from server to client, since picking the wrong one for your use case creates real problems later.

Server-Sent Events (SSE)

One-directional, server to client only
Works over standard HTTP, no special infrastructure required
The natural fit for AI text generation, since the client only needs to receive tokens, not send data mid-stream

WebSockets

Bidirectional, full duplex communication
Better suited for genuinely interactive real-time features like collaborative editing or live multiplayer state
Overkill for most AI chat features, and adds real infrastructure complexity you don't need for one-way token streaming

Web Streams API (ReadableStream)

The lowest-level option, giving direct control over how chunks are read and processed
What the AI SDK and most Route Handler implementations are actually built on under the hood
Best when you need fine-grained control over parsing structured data mid-stream, like tool calls or JSON fragments

For the vast majority of AI chat and generation features, SSE built on top of the Web Streams API is the right choice. Reach for WebSockets only when you genuinely need bidirectional communication during generation, which is rarer than most implementations assume.

Step-by-Step: Building a Streaming AI Route Handler

Step one: set up the project

npx create-next-app@latest ai-streaming-app
cd ai-streaming-app

Select the App Router when prompted. This pattern depends on Route Handlers, which live specifically in the App Router architecture.

Step two: create the streaming Route Handler

// app/api/chat/route.ts
export async function POST(req: Request) {
  const { message } = await req.json();

  const stream = new ReadableStream({
    async start(controller) {
      const response = await callModelProvider(message);

      for await (const chunk of response) {
        controller.enqueue(new TextEncoder().encode(chunk));
      }
      controller.close();
    },
  });

  return new Response(stream, {
    headers: { "Content-Type": "text/event-stream" },
  });
}

The key detail here: the API key and the call to the model provider stay entirely server-side. Nothing sensitive ever ships to the client bundle, which matters both for security and for keeping your provider costs from being exposed.

Step three: consume the stream on the client

// app/components/ChatInput.tsx
'use client';
import { useState } from 'react';

export default function ChatInput() {
  const [response, setResponse] = useState('');

  async function handleSubmit(message: string) {
    setResponse('');
    const res = await fetch('/api/chat', {
      method: 'POST',
      body: JSON.stringify({ message }),
    });

    const reader = res.body?.getReader();
    const decoder = new TextDecoder();

    while (true) {
      const { done, value } = await reader!.read();
      if (done) break;
      setResponse((prev) => prev + decoder.decode(value));
    }
  }

  return <div>{response}</div>;
}

This is the piece that actually creates the typing effect. Each chunk arrives and appends to state as it comes in, instead of waiting for one giant response.

Step four: add proper error and cancellation handling

const controller = new AbortController();

async function handleSubmit(message: string) {
  try {
    const res = await fetch('/api/chat', {
      method: 'POST',
      body: JSON.stringify({ message }),
      signal: controller.signal,
    });
    // stream reading logic here
  } catch (err) {
    if (err.name === 'AbortError') {
      console.log('Generation cancelled by user');
    } else {
      setError('Something went wrong, please try again');
    }
  }
}

function handleCancel() {
  controller.abort();
}

A stop button that actually cancels an in-flight generation is a small detail users notice immediately when it's missing, and it costs very little to implement properly.

Step five: validate structured output when you need more than plain text

import { z } from 'zod';

const responseSchema = z.object({
  summary: z.string(),
  confidence: z.number(),
});

function validateResponse(raw: string) {
  const parsed = JSON.parse(raw);
  return responseSchema.parse(parsed);
}

Instead of hoping a model returns well-formed JSON, defining a schema and validating against it catches malformed output before it ever reaches your UI, which matters a lot once an AI feature is doing more than just displaying conversational text.

Step six: add rate limiting before this ever reaches production

// app/api/chat/route.ts
const requestCounts = new Map<string, number>();

export async function POST(req: Request) {
  const userId = getUserIdFromSession(req);
  const currentCount = requestCounts.get(userId) ?? 0;

  if (currentCount >= 20) {
    return new Response("Rate limit exceeded", { status: 429 });
  }

  requestCounts.set(userId, currentCount + 1);
  // proceed with streaming logic
}

This is a simplified example, a real implementation would use a proper store like Redis rather than an in-memory map, but the principle holds regardless of scale. Without rate limiting, a single user or a scripted abuse pattern can run your model provider costs up fast, and this is one of the most commonly skipped steps in early AI feature builds.

Step seven: track cost per feature, not just in aggregate

function logUsage(feature: string, tokenCount: number, model: string) {
  const cost = tokenCount * getCostPerToken(model);
  analytics.track("ai_usage", { feature, tokenCount, cost, model });
}

Breaking cost down by feature rather than watching one aggregate monthly number lets you catch a specific feature quietly ballooning in usage long before it shows up as a surprise on the bill.

Common Mistakes Worth Avoiding

Forgetting to handle stream errors mid-response, leaving the UI stuck in a permanent loading state if the connection drops partway through
Skipping the cancellation handling entirely, which leaves users stuck watching a response they no longer want finish generating
Calling the model provider directly from client-side code, which exposes API keys and lets costs run up uncontrolled
Not validating structured output, and discovering malformed data only when it breaks something downstream in production
Shipping without rate limiting and finding out the hard way when a single user or bot script drives up provider costs overnight
Choosing WebSockets by default out of habit when SSE would be simpler, cheaper to run, and perfectly sufficient for one-way token streaming

A Quick Self-Check Before You Ship

Does your UI show visible progress within the first second, or does it sit on a static spinner while waiting for the full response?
Can a user actually cancel a generation mid-stream, or does clicking away just leave the request running in the background?
Is there a rate limit in place, or is the endpoint currently wide open to unlimited requests per user?
Are you tracking cost per feature, or would a sudden spike in usage only show up once the monthly bill arrives?

Why This Is Worth Building Properly, Not Just Quickly

Getting a demo chat working in an afternoon is genuinely easy now. Getting it production-ready, proper error handling, rate limiting, cost monitoring, structured output validation, and a UI that gracefully degrades when something goes wrong, is where most teams underestimate the actual scope of the work. Custom AI development and API integration work focused specifically on shipping these features at production scale tends to close that gap far faster than assembling it piece by piece under a deadline, especially for teams integrating multiple providers or building on top of an existing enterprise codebase.

The Takeaway

The gap between an AI feature that feels instant and one that feels sluggish usually isn't the model's raw speed, it's whether the response streams token by token or dumps all at once after a long, silent wait. Next.js's architecture, particularly Server Actions and Route Handlers, maps naturally onto this pattern, which is exactly why it's become the default framework for AI-powered web applications this year.

Has your team already shipped a streaming AI feature in production, or are you still working through the plumbing on this one? Curious what's tripped people up most.