AI & Integration Engineering Series: Treat AI Like a Faster, Dumber Version of Yourself

Not long ago, a software engineer’s daily routine was a highly predictable... decipher a ticket, search Stack Overflow, copy a block of code, iterate line by line, and spend two weeks pulling off a mid-sized feature.

Fast forward to today, and the post-AI boom has completely upended that playbook. Developers aren't just using AI to autocomplete text; they are using it to completely architect their days, manage complex project pipelines, and clear out backlogs at lightning speed.

In a recent episode of our AI integration series, Pandium CTO and Co-Founder Shon Urbas sat down with Software Engineer Shanta to unpack what it’s actually like to be an engineer hired in the era of ubiquitous LLMs. Shanta represents a new generation of developers who don't just view AI as a novelty tool, but as a deeply integrated partner in both their professional workflows and daily lives. Together, they dig into AI's relevance in building and maintaining integrations.

The Model: Faster, More Confident, and Also Dumber

Shanta’s core philosophy for working with LLMs sets the stage for the entire conversation:

Shanta: "Treat the AI as a mini version of you. Faster, more confident, and also dumber."

This is the exact mindset needed to decide when to trust an AI and when to slow down. AI moves fast and sounds incredibly sure of itself, but being fast and articulate doesn't mean it is right. Shanta points out that models are naturally built to be overly optimistic about their own work. Because the machine cannot double-check its own logic, the engineer must verify every line.

Making AI Argue With AI

Instead of picking one tool and sticking to it, Shanta runs an adversarial workflow using multiple tools. She writes and structures her code in Claude, but when she hits a roadblock or wants a peer review, she drops a piece of the code into Gemini or ChatGPT to find the blind spots.

Shanta: "Whenever I'm not liking the answers of AIs, but I don't have enough context... I put a portion of the code with Gemini and ask, 'What faults do you see?' It finds some of the issues. Then I paste the response back to Claude, and Claude sometimes agrees. And sometimes it somehow knows that this is another AI speaking."

Claude doesn't just blindly accept or reject the outside critique; it recognizes the footprint of its rival model and occasionally pushes back directly.

Shanta: "It sounds often arrogant. I remember it said, 'This AI is wrong because it doesn't know our codebase at all.'"

Shon: "‘Our.’ I love how it takes ownership."

Keeping the Guardrails On

One thing that immediately stands out to Shon is how tight and focused Shanta keeps her pull requests (PRs). Her secret comes down to strict structure.

What can often happen with AI agents is scope creep. A simple package upgrade or a minor refactor can easily cause a tool like Claude Code to drift down a rabbit hole, writing extra modules and bleeding a single ticket across an entire codebase.

To stop this, Shanta uses a constraint called Plan Mode.

She formats her local markdown tracking files to map exactly to her Jira ticket names. This forces the model into a rigid logical box. If a terminal session goes too long and the AI begins to lose track, she manually pulls it back to the core planning file.

She also refuses to let AI write her professional voice. While she uses LLMs to clean up grammar in her PR descriptions, she explicitly instructs the model to keep the text strictly "in my tone." By treating the AI as an editor rather than the author, it functions as an extension of herself... fast, but strictly bound by her own guardrails.

The Authorship Line

This series keeps circling back to the same rule, and this conversation is no exception. Shon's first commandment in every configuration file, the same one he described in the earlier conversation with Liz Yoder on the Explore/Exploit framework, is that the AI is never the author of the code, he is.

Shon: "That's the first rule in my Claude MD. You are not the author, you have no responsibility. Don't ever co-commit."

Shanta holds the same line from a different angle. She writes her own PR descriptions and commit messages by hand, then asks AI to clean up the grammar, specifically instructing it to keep her own tone rather than let a generic one take over.

Shanta: "I feel like this is something I still like, writing PR descriptions and creating comments by hand. And I also don't want my commits to be co-authored by Claude."

Are We Shipping More, or Just Filing More Tickets?

The two also got into something engineering teams rarely measure well. Whether bug counts going up actually means quality is going down, or whether teams are simply reporting more now because filing a ticket takes ten seconds instead of ten minutes.

Shon: "There are tickets now that I'll put in because it's so much easier to get it into Jira than it was two years ago. I'm curious if we're actually reporting more things now, and it's not necessarily that quality's going down."

Shanta agreed, and pointed out that teams are also nitpicking smaller issues than they used to, simply because fixing them is now cheap enough to be worth the time.

Testing Discipline: Invert Before You Trust

This is where the conversation ties back directly into a rule this series has hit before: never trust a passing test you haven't watched fail first.

Shanta learned it early on, after writing a test that passed no matter what she changed in the underlying code.

Shanta: "Lizzy pointed out, whether you invert it or not, this result is the same. It's still passing even if you input anything. Claude makes mistakes on this particular simple task too."

Shon's version of the same discipline: write the test, revert the fix, and confirm the new test actually fails before trusting that it means anything.

Shon: "Every new test we've added better fail. Because if they don't fail, it's a worthless test."

The tool changes. The rule doesn't.

Use AI With Caution

The ultimate takeaway from the front lines of the AI boom is simple... treat AI as a fast, highly confident, yet fundamentally blind assistant. Never let the machine's absolute certainty outrun your own accuracy.

The tools get faster every month. The responsibility for what they produce hasn't moved an inch.

Catch the full conversation, and the rest of the series, on the Pandium YouTube channel.

Want pieces like this in your inbox? Sign up for the Pandium newsletter.

Watch the full interview: