DEV Community: Brian Munz

What AI Can and Can't Take off Your Integration Team's Plate

Brian Munz — Mon, 21 Sep 2026 13:39:48 +0000

While AI assistants can generate integration code in seconds, code alone doesn't make for a functional B2B SaaS integration. Integrations need multi-tenant deployment, authentication management, monitoring, and other infrastructure. AI is an author, not an execution engine. Pairing AI tools with Prismatic (using Prismatic Skills and the MCP dev server) ensures generated code turns into production-ready, scalable integrations for all your customers.

Ask Claude Code, Cursor, or Copilot to draft an integration connector, and what used to take a developer all morning happens in seconds. It's tempting to conclude the integration problem is solved, that AI will "build all our integrations now."

However, that overstates what AI does and fundamentally misunderstands integration necessities.

AI is excellent at generating code and making sense of unfamiliar documentation. But a TypeScript function that transforms a payload isn't enough. It still needs a foundation to run on.

Watch me summarize the key parts of this post below, or keep reading for all the details.

Everything, not just the code, starts on the plate

Ask most engineering leaders what an integration team does, and the answer comes down to writing code. Ask the team, and the list is usually quite a bit longer:

Reading API documentation and authentication schemes
Generating API connectors
Mapping data models between systems
Handling pagination, retries, and rate limits
Writing business logic and tests
Deploying and configuring the same integration across hundreds of customer instances
Monitoring, alerting, and responding when something breaks
Adjusting when a third-party API changes unexpectedly

The business logic is often the easiest item on that list. Everything around it takes most of the time, and it will be the maintenance focus for months and years to come.

What AI can do for integrations

API research – AI can ingest OpenAPI specs or other docs and learn the patterns in them in seconds.
Custom connectors – AI can build connectors for non-standard (niche or vertical) apps your customers need.
Data transformations – Reconciling data models and custom fields is pattern-matching work AI handles well.
Migration analysis – AI can read an export from one integration platform and propose how it maps onto a different platform.
Log diagnosis – Pointed at a stack trace, AI can often spot the issue faster than a human scanning the same output.
Test generation – AI can usually draft a reasonable set of edge cases from a spec, even if you still need a dev to figure out which ones matter.

AI compresses the distance between "we need this integration" and "working code exists." And that leads to engineers spending less time typing and more time deciding.

What AI can't do for integrations

Let's say your AI assistant generates a working Salesforce integration in fifteen minutes. Great. That's a start. Now comes the hard work.

Where are each customer's credentials stored? How are tokens refreshed? How do you deploy the integration to 145 customers without duplicating it 145 times? How will CS troubleshoot a failed execution without filing a ticket?

AI wrote the code faster, but everything else still needs to be addressed. Because the faster you build integrations, the more important it is to have the tools to deploy, monitor, and support them.

The boundary between what AI can and can't do for integrations is structural:

Multi-tenant state – AI writes code for one scenario. It has no concept of that code running, with different configs, across 500 customer instances at once.
Production-grade execution – Things like dead-letter queues and token refreshes must exist as running infrastructure.
Non-developer operations – When a token expires, or field mappings need updates, that shouldn't require an engineer or an AI agent to open an IDE.
Credential governance – AI writes code that handles data. It doesn't host a SOC 2-compliant server or enforce per-tenant access control isolation.
Judgment calls – What "production-ready" means for a given customer and which edge cases matter. AI implements a decision. It doesn't own it (or understand why the decision was made).

Could AI generate code for credential storage? Sure. A retry function? Yes. But these aren't problems you re-solve per integration; they're platform features, solved once.

Nobody asks AI to rebuild Kubernetes before deploying a web app. By the same token, nobody should ask it to rebuild an integration platform (or any piece of it) before shipping an integration.

AI assistant alone vs AI + Prismatic

Here's how we've incorporated AI into Prismatic, compared with using AI alone to build, deploy, and manage integrations.

Responsibility	AI alone	AI + Prismatic
Logic and data transformations	Writes standalone code	Writes TypeScript using SDK-defined patterns
API research	Summarizes endpoints	Scaffolds typed custom components
Auth and token refresh	Custom per integration	Handled by platform token management
Multi-tenant deployment	Manual scripting per account	Native instance configuration
Operational infrastructure	Custom queues, retries, rate limiting	Built-in execution queues and logging
Support and operations	Engineering debugs raw logs	Visual UI for CS to manage configs, auth, and more

Why the foundation decides the value

If a developer uses AI to create an integration in ten minutes but the team spends days or weeks building the infrastructure to run it reliably for hundreds of customers, the original development velocity wasn't reality. The work was just moved down the timeline and slotted into operations instead of development.

An AI creates value for an integration platform when the platform handles everything AI can't: multi-tenant deployment, credential management, logging, and a support path that routes tickets appropriately (and not all of them need to go to engineering).

How an AI and Prismatic divide the work

Our MCP dev server gives an AI direct access to Prismatic's API, SDK, and deployment patterns instead of forcing it to guess. And Prismatic Skills package the platform-specific judgment a seasoned integration developer would already have.

Your AI (working with Prismatic Skills and the MCP dev server) handles connector construction and business logic: the parts that differ per integration but follow patterns. Prismatic supplies what's common across all of them: multi-tenant management, credential handling, monitoring, and tools that provide visibility into support for non-engineers. The team keeps what neither can automate: deciding what to build and what "done" looks like for a given customer. And, of course, being human, with everything that it entails.

A simple check

Next time someone claims that an AI tool has solved integration work, ask:

Is the AI speeding up writing the integration?
Does the help still apply at 145 customers?
When something breaks, can the AI fix it?

Most AI coding tools will say yes to the first question and no to the other two. The reason is simple: those aren't the problems the tools were built to solve.

An AI is an author, not an engine

Generative AI is the most significant development accelerator to hit integration engineering in a very long time (perhaps ever). But it's an author, not an engine. The value it brings in increased development speed only holds if the generated code lands on infrastructure already built with B2B SaaS multi-tenancy, security, and scaling in mind.

Teams that treat AI as a replacement for platform infrastructure will find the same operational drag, just a bit later on in the process. Teams that treat AI as an accelerator on a purpose-built foundation will create sustainable integration strategies.

Give AI the right foundation, and you'll ship reliable, scalable integrations faster for all your customers. Turns out, that was the point of building integrations all along.

Who One-Shot Ya? Why the One-Shot Benchmark Isn't Useful

Brian Munz — Mon, 14 Sep 2026 14:57:53 +0000

"One-shot" AI development (creating entire code projects with a single prompt) is a myth that ignores the need for context. AI agents can't read your mind. And, without essential guidance on scope and environments, they make "reasonable" assumptions that are wrong. True efficiency requires collaboration and oversight. By pairing devs with tools like Claude Skills, devs align their AI assistants with project realities and drive helpful solutions.

The techno-sphere has been abuzz lately with the idea of "one shot" development, where a person gives a coding agent a prompt and it builds an entire project in one session, almost autonomously. The implication is, spoken or not, that having a human in the loop is a temporary inconvenience and soon enough people will be able to sit back in their chairs and Captain-Kirk their supercomputers into perfectly building whatever they want. Over time, it's become increasingly clear that humankind's initial impression of what AI is and is meant to be has been shaped more by assumptions and sci-fi futurism than by current capabilities and real-world use cases.

Context is absolutely critical

We've been treating AI as if it is a robot human, an autonomous mind that you can hand projects to. Some people go further, especially in talking about one-shot development, and almost treat AI like it's a mind-reader, needing no context from you, able to figure everything out itself. In reality, whether you're using AI as a developer tool or asking a human to build something for you, giving them a short prompt is like walking into a contractor's office and saying "build me a house," then covering your ears and running out. Context is needed.

I tested the whole one-shot idea in a livestream recently, and I came away understanding less about what even constitutes a one-shot and why anyone wants it in the first place. I gave the agent a prompt to build an integration and let it get to work to see how far autonomy can get. It started asking me a variety of questions about what I was trying to do and how I wanted it built, while making assumptions about other parts of the project. Basically, it was asking for the context I didn't give it for my one-shot prompt. Not surprising, of course, but does that still even count as a one shot?

What's the point of a one-shot if you have to write a tome of text to get it to run properly?

Why am I even talking about one-shots? Who cares? Where am I?

Okay, I'm back, and I've calmed down.

So forget the one-shot. The fewest-prompts contest was never the point, and it's based on a bad assumption: that the goal is to hand off the work and walk away. Instead, it's more sensible to see building with AI as collaborative and iterative. You can't cram all the context into one prompt, and you shouldn't try.

Claude Skills aren't designed to do tasks in the fewest number of prompts. They give the agent the context it needs and the definition and shape of success as it executes the tasks. It's like training an assistant to help the developer as they build, and some aspects of a project will need a human in the loop for a long time to come.

Why dev needs humans

For example: scope. If you've spent much time building with AI agents, you've inevitably made a prototype the AI agent decided needed to be production-ready, burning time and tokens adding bulletproof security to your dumb little test app. From the standpoint of AI, it's trying to build the best product possible to make its user happy, so of course it creates OAuth flows, rate limiting, audit logging, and a secrets manager for your weekend proof of concept. Something the human brain is still superior at is creative and abstract thought and the ability to see the big picture. A good developer takes a step back, clocks the scope creep, and notices when a cleanup that was meant to kill technical debt has caused it to balloon instead.

Where it breaks

Usually when I run into problems, they're boring and make me feel like an idiot, but that's the point.

I've had Claude build an integration and drop it in the wrong directory of my working folder, so when I went to the integrations folder looking for it, nothing was there. I've had it do good work against the wrong Prismatic tenant, because I was logged into one and thinking about another. Neither of those is a model failure; they're context failures, and both of them are my fault for assuming the agent would think of something I never told it.

The agent is working from the reality you handed it, and it will do its best to fill the gap with something reasonable, but reasonable is not the same as correct. The wrong directory was a perfectly reasonable place to put an integration.

People regularly expect Skills to do more than they're built for. A Skill can carry the definition of good work – things like patterns, conventions, and what "done" looks like. It's much worse at carrying the stuff that changes every time you start work, like which tenant you're pointed at, what folder this lives in, and what the thing you're building does for the customer. Cramming all of that into the Skill makes it bloated. Say it up front instead, and let the Skill do its job.

Eval isn't a buzzword; it's the check on your own assumptions

So how do you catch a context gap you didn't know you left? By checking the work, which brings me to the unglamorous but important concept of "eval." In a nutshell, eval means checking the agent's output against what you wanted, systematically, instead of eyeballing it and hoping. I'm not going to pretend I'm an expert on eval, but I feel like eval is under-hyped, not overhyped. (Check out our recent posts on evals: determinism was never the point, and risks and rewards.)

The reason is the super-brain thing. If you believe the model is a mind, you don't check its work, because checking a mind's work feels insulting or pointless. If you believe it's a tool that inherits your context, checking becomes obvious. Eval is what turns "it seems to work" into something you can feel confident about.

Even so, there's a limit. An eval measures conformance to a spec you defined. It doesn't measure whether the spec still describes the project you're building. Real projects are a living thing, and the spec you wrote three weeks ago is a snapshot of what you knew then. That's not a knock against eval; it's more an argument against lazy, one-shot development. A project is often a moving target, and you should move with it.

Now multiply that by every customer

I build, and help people build, embedded integrations, which are the connections that live inside a product and run in each customer's own account, not just one integration sitting in one place I control.

When you build embedded integrations, you build one integration that deploys into every customer's instance, and every instance has its own config, credentials, field mappings, and weird edge cases that made total sense to the customer who asked for them. You're not just building for one customer; you're building for all customers, now and in the future. No prompt can carry all of that, which is why you need to check your work and stop expecting miracles.

So who one-shot ya?

No one, I hope.

The one-shot is a lazy daydream, but the failures aren't the model being dumb, they're you handing over an incomplete reality and expecting it to fill the gaps correctly. It fills them reasonably, but reasonably isn't correctly.

Your goal should be to quickly catch the agent when it wanders away from what you intended. But, if you give it context early and keep it on track, Skills can carry the shape of good work. You can help by writing the eval that checks your assumptions (and not the model's intelligence). Then, as a human being, use your unique abilities to focus on the why behind the work, the part that your friendly neighborhood AI is happy to build right past.

Being pro-developer in the AI age

Brian Munz — Tue, 26 May 2026 13:16:48 +0000

The history of computer programming is a long journey in abstraction. 50 years ago, writing a program was punching holes in a stack of cards, handing them to an operator, and heading home while the computer ran all night. If there was a bug, you'd make the changes and go through the whole thing again. Then came assembly, then high-level languages like COBOL, then visual programming, and on and on until you see a kid in a Brooklyn coffee shop shouting into his phone at someone named Claude.

As time went on and these new advancements appeared, inevitably there would be a moment where someone would proclaim that developers were finally being automated away. No more heavy sighs from the bullpen of keyboard jockeys. The nerds have lost… huzzah! Except they hadn’t and they continued to build.

We now find ourselves in another one of those moments. In December of 2024, Mark Zuckerberg went on Joe Rogan and said that AI at Meta was already reaching the capabilities of mid-level software engineers. By 2025, he said, most of the code in Meta's apps would be written by AI instead of people.

A tech leader making bold claims is one thing, but the wave of people gleefully "dunking" on the developer during the rise of AI has been… enlightening. Developers were not only justifiably worried about layoffs, they were disturbed by the manic enthusiasm for them.

Still, this is not going to be a rage post about tech villains. A lot of the people saying naive and lazy things about AI were just following the hype cycle and repeating wild claims from people excited about the shiniest new tech. This is what drives LinkedIn after all. Still, it was quite a moment to live through for a developer. For about 18 months (and counting), if you were a working developer, you couldn't open a tab without someone in the C-suite explaining how AI would not only soon cure cancer, it would also make the builders of their products unnecessary. You probably have your own examples in mind.

Indeed, the hype cycle had consequences. Companies didn't just talk about replacing developers, many actually did it. And for many, things played out differently than they thought they would.

IBM is a good example of the lifecycle of the AI hype. In May of 2023, CEO Arvind Krishna told Bloomberg that AI was going to let the company eliminate 7,800 back-office jobs over the next five years. It was the first major Fortune 100 announcement of its kind and it set the tone for everything that followed.

Smash cut to two years later, when Krishna told the Wall Street Journal that AI had actually touched a "couple hundred" HR workers, not 7,800. IBM's total headcount, he said, had gone up, not down. The savings got reinvested in software engineering, marketing, and sales. By February of 2026, IBM's CHRO was announcing the company would be tripling entry-level hiring "for software developers and all these jobs we're being told AI can do." To be fair, I give credit to IBM for course-correcting, even if they were part of the initial panic.

And it wasn't just IBM. Forrester's 2026 Future of Work report found that 55% of employers regret laying off workers for AI-related reasons. In the rabid rush to gut development teams, it was clear they'd bought into a half-baked story based more on dreams than reality. The fact that the dream was to eliminate developers didn't go unnoticed.

Whatever the actual motive, the effect on developers was the same. Some of these tech leaders genuinely believed AI was going to replace their engineers. Others were using the AI story as cover for layoffs during an erratic economy. Either way, a lot of developers spent 2024 and 2025 being told their jobs were ending by people who didn't seem particularly sorry about it.

So what's the practical view, then?

If it's not obvious already, this isn't an anti-AI piece. I use Claude Code every day and Claude Co-work to help my ADHD-addled brain keep up to speed on what I need to do. The company I work for, Prismatic, ships AI-accelerated developer tooling. Much of the AI hype was valid but misdirected and clumsy. Used properly, AI is a multiplier for developers who already know what they're doing, whether they're full speed ahead and no longer touch code, or they prefer writing their own code but use AI to diagnose, debug, and strategize. Why simply cut developers for a cash grab when you could use them to ship features and improve code at an accelerated rate? Are we on defense or offense?

If anything, that work is getting harder to do without experience. The 2025 DORA report found that AI amplifies the quality of work. Good engineering teams will continue to ship good code, but at a faster rate. Bad engineering teams will continue to ship bad code, but also at a faster rate, piling up technical debt faster than ever before.

So what does it mean for a company to be pro-developer in the age of AI? It's a set of choices that show up in how a company actually operates.

It means respecting the leverage. A senior developer who can now work more efficiently is worth more than they were before, not less. The math of replacing them with cheaper labor and an AI subscription was wrong from the start, and those that know this are keeping their good engineers happy and hiring more of them.

It means making AI fit into the developer's workflow, not the other way around. Early in the hype cycle, the people saying "AI is a great tool" got drowned out by the ravenous enthusiasm of "AI can replace everyone." Voices of reason aren't as loud but are often right. The smart path is asking the people doing the actual work which AI features help them ship and which ones get in the way, and then building accordingly.

It means being honest about whether AI is a toy, a tool, or a replacement. There are real applications of all three, and pretending otherwise is what got us into this sloppy hot take hot mess. Some workflows really are better off automated end-to-end. Some really do need a human at every step. Most are somewhere in between, with an AI doing the boilerplate and a human owning the outcome. Figuring out which is which is an engineering question. It deserves more nuance than a clickbait quote from someone looking to talk up their valuation on a podcast.

To be clear, this isn't cut and dry. AI is a complicated topic with real concerns I haven't touched on here, from regulation to energy use to jobs that really are becoming less viable. There is a wide spectrum of sentiment amongst developers on AI. Some are all in, some hate it with the fire of a thousand suns. Most are somewhere in the middle, using the tools every day and trying to figure out what the next few years actually look like.

The fact of the matter is that the carnival barkers had their moment, and the moment is ending. What's left is the work, and the people doing the work to build software that does what it's supposed to do, for customers who are counting on it, at companies that need to keep shipping. The tools change, the abstractions get higher, and the people who actually understand what they're building keep mattering. Maybe some people at the top can learn from this and remember that what seems disposable today might be essential tomorrow. Either way, there are people underneath it all.

Let's just get to work and whatnot.