Category: Artificial Intelligence

Categories
Artificial Intelligence Conferences

Notes from Advantage, part 3 — Rod Johnson: Language Stacks and Gen AI

Last week, Anitra and I attended both the Dev/Nexus conference and its companion conference, Advantage, an AI conference for CTOs, CIOs, VPs of Engineering, and other technical lead-types, which took place the day before Dev/Nexus. My thanks to Pratik Patel for the guest passes to both conferences!

I took copious notes and photos of all the Advantage talks and will be posting summaries here. This set of notes is from the third talk, Language Stacks and Gen AI, presented by Rod Johnson.

Here’s Rod’s bio:

Rod is a developer, author, investor and entrepreneur. He has authored several best-selling books on Java EE. He is the creator of the Spring Framework and was cofounder and CEO of SpringSource. He has served on the board of Elastic, Neo Technologies, Apollo, Lightbend and several other successful companies. He is presently developing a structured RAG system using Spring and Kotlin.

And here’s the abstract of his talk:

Python is the language of data science and dominant in AI research. However, it is not the language of enterprise apps, and there are good reasons for this. In this session, Rod will discuss when to use what language and stack for AI success in enterprise. He’ll discuss the key adjacencies for success: LLMs, existing data and business logic, and how to choose what language, stack and framework for a particular problem.

My notes from Rod’s talk are below.

Your existing enterprise systems are an asset, not a liability

Rod opened with something that probably felt like a relief to many in the room: a clear-eyed argument that the overwhelming pace of AI change is not a reason to abandon what your organization has already built. Enterprise systems represent years of accumulated business logic, domain knowledge, and battle-tested reliability. These things change slowly, and in this case, the cliche is true: that’s not a  bug, but a feature. The pressure to throw out existing applications and start fresh with AI-native rewrites is, in Rod’s view, is not just misguided, but reckless.

He was equally direct about the organizational risk of letting AI enthusiasm displace experienced people. Every major technology wave produces a class of self-declared experts who rush in and crowd out the engineers who actually understand the business. Domain expertise doesn’t get replaced by a new framework. Instead, it gets more valuable, because it’s the thing that makes AI systems accurate and useful rather than fluently wrong.

The message to leaders was clear: protect your people, and make sure your AI strategy grows out of your existing institutional knowledge rather than treating it as an obstacle.

Personal assistants and business processes are fundamentally different. Stop conflating them.

One of the sharpest distinctions in Rod’s talk was between AI as a personal productivity tool and AI embedded in enterprise business processes. The personal assistant category (for example: chatbots, coding agents, tools like Cursor) operates under forgiving conditions. If a coding agent produces bad output, a developer catches it before it reaches production. The feedback loop is tight, human oversight is immediate, and the cost of failure is manageable. This is why maximizing agent autonomy makes sense in that context.

Business processes are an entirely different environment. Rod pointed to the Air Canada chatbot case, where the airline told a customer it would honor a discounted bereavement fare and then tried to disclaim responsibility when the customer held them to it. Unlike a coding error that gets caught in review, a business process error engages real customers, real employees, and real legal and financial consequences. You can’t roll back a workflow the way you can roll back a pull request. The asymmetry between these two domains is enormous, yet most of the noise driving enterprise AI strategy comes from the personal assistant space, where demos are impressive and the failure modes are invisible.

Rod is clearly frustrated with this conflation, and you should be too. The loudest voices in the generative AI conversation are the ones driving media coverage and executive attention, and they’re overwhelmingly people with no background in or interest in enterprise software. Leaders who let those voices set their enterprise AI agenda are optimizing for demo impressiveness rather than production reliability, and that’s a recipe for expensive disappointment.

Structure (almost always) beats natural language

Perhaps the most technically counterintuitive point in Rod’s talk was his argument that interacting with LLMs in natural language is often the wrong approach. Yes, LLMs are trained on vast amounts of natural language text, but the underlying Transformer architecture is fundamentally about predicting tokens. It’s not inherently about language at all. The seductive thing about natural language interfaces is that you can demo them impressively in minutes. The unsettling thing is that natural language is ambiguous, extremely difficult to test, and essentially opaque when something goes wrong.

Rod’s alternative is to structure your interactions with LLMs as much as possible: structured inputs, structured outputs, and as little free-form natural language in the critical paths as you can manage. His thought experiment about what a bank knows about its customers illustrated the point neatly. The vast majority of the high-value data a bank holds — transactions, account balances, product relationships — is already highly structured. The fringe cases that exist in text (notes from a branch visit, a customer service transcript) are real but marginal. Adding generative AI to that environment should leverage the structure that’s already there, not dissolve it into a sea of markdown and free text.

The practical consequences of over-relying on natural language are significant. Systems built around unstructured text accumulate context rapidly, which drives token counts (and therefore costs) through the roof. They become increasingly unpredictable as that context grows, and when they produce wrong outputs, there’s no clean way to explain or audit what went wrong. Rod’s point, reinforced by his analysis of OpenAI’s Operator product, is that even sophisticated AI systems hit a hard ceiling when they’re built on a foundation of loose text rather than structured data and deterministic logic.

Your language stack probably shouldn’t change, but your thinking about AI layers should

Rod was characteristically direct on the language debate that consumes a lot of oxygen in AI developer communities: Python is not magical for building enterprise AI agents, and the fact that most academic AI research is published in Python is not a reason for a Java or C# shop to rewrite everything. There are reasons your enterprise applications were written in the languages they were written in: stability, ecosystem maturity, existing tooling,  and team expertise, and those reasons haven’t changed. What sits in the generative AI layer is substantially shallower than your core application logic, and the risk-reward calculation for rewriting those core systems in a trendier language is deeply unfavorable.

That said, Rod drew a reasonable distinction: Python genuinely does have advantages for certain tasks like document processing, model fine-tuning, and data ingestion pipelines, where the research community’s tooling is simply more mature. The error isn’t using Python for those things. It’s letting data science people with a Python background architect the entire enterprise AI strategy, because data science and enterprise AI application development require genuinely different skills. Conflating them leads to frameworks that are academically interesting but operationally fragile when exposed to real enterprise requirements around security, observability, testability, and integration.

The practical implication for enterprise leaders is that you need a good agent framework. Rod’s example was Embabel, a framework his company developed. Agent frameworks should feel like a natural extension of your existing stack. It should play nicely with Spring, respect your existing domain model, integrate with your existing observability tooling, and support unit testing at every level. You shouldn’t have to introduce an entirely new operational paradigm just to add generative AI capabilities. Adjacency to your existing systems is where the value gets unlocked, and any framework that treats your existing applications as irrelevant legacy to be worked around is solving the wrong problem.

Categories
Artificial Intelligence Conferences

Notes from Advantage, part 2 — Pratik Patel: AI Architecture for Tech Leaders

Last week, Anitra and I attended both the Dev/Nexus conference and its companion conference, Advantage, an AI conference for CTOs, CIOs, VPs of Engineering, and other technical lead-types, which took place the day before Dev/Nexus. My thanks to Pratik Patel for the guest passes to both conferences!

I took copious notes and photos of all the Advantage talks and will be posting summaries here. This set of notes is from the second talk, AI Architecture for Tech Leaders: Building Blocks for AI Applications, presented by Pratik Patel.

Here’s Pratik’s bio:

Pratik Patel is VP of Developer Relations at Azul Systems. An all around software and hardware nerd with experience in the healthcare, telecom, financial services, and startup sectors.

And here’s the abstract of his talk:

The AI space is moving incredibly fast, it seems new methodologies and technologies are coming every week. How’s a technology leader (whether your a VP Engineering, Software Dev Manager or Team Lead) supposed to understand what are the true building blocks for this new class of applications. How do you scope an AI development project, both in terms of developer time and cloud & AI infrastructure? Should you buy AI hardware or pay for API access to OpenAI, Claude, Gemini, etc? Do you have sensitive information that you want to keep from leaking out to an external LLM provider? In this session, we’ll tackle these issues and also discuss the evolution of applications and the difference between: existing applications that have added AI capability as an accessory this new class of applications that are built with AI in mind from the start This session is intended to be interactive – I’ll start by laying the foundation for building AI applications today, and we’ll discuss the experiences of the tech leaders in the room so everyone can share and learn from each other.

My notes from Pratik’s talk are below.

Note: You can find a more developer-focused version of this talk in an earlier posting, from when Pratik came to Tampa to deliver this talk for the Tampa Bay Java User Group and Tampa Bay AI Meetup.

Skate to where the puck Is going

Pratik opened with the AI version of the Wayne Gretzky line: don’t build for where AI is today, build for where it will be in six to twelve months. The pressure many tech leaders currently feel to add AI to everything so the organization can say it’s doing AI is producing a wave of surface-level implementations that won’t hold up. Sprinkling a chatbot on top of an existing application is not a strategy, but a reaction.

The analogy Pratik kept returning to was the shift from manual, infrequent deployments to cloud-native, continuously-delivered software. That transition wasn’t just about adopting new tools. It required a fundamental rethinking of how teams design, build, and release software. Organizations that made that leap early didn’t just move faster; they built a compounding capability advantage. Pratik’s argument is that we’re at a similar inflection point with AI, and the leaders who recognize it now will be the ones whose systems look prescient rather than antiquated in two years.

AI-native vs. AI-augmented: A critical distinction

The conceptual core of Pratik’s talk is the difference between bolting AI onto an existing application and building an AI-native one from the ground up. An AI-native application doesn’t just use AI as a feature, and is organized around AI’s ability to learn, adapt, and act autonomously. Those three verbs matter. Most of what organizations are building today qualifies as AI-augmented at best: an agent that can act, but that doesn’t genuinely learn from interactions or adapt its behavior without human intervention.

Pratik illustrated this with a content management system example. A traditional CMS requires humans to manually tag articles. An AI-native CMS handles tagging automatically, continuously improves based on feedback, and integrates that intelligence into the editorial workflow without requiring a separate AI plugin to be configured and maintained. The business value isn’t just efficiency, but that the system gets better over time in a way that a bolted-on tool never will.

His hotel booking example pushed the concept further. A truly AI-native booking platform wouldn’t just filter hotels by amenities; it would learn individual user preferences from past behavior, weight them against contextual signals, and surface recommendations that reflect both explicit preferences and inferred ones. More importantly, it would adapt its pricing and inventory strategies automatically in response to real-world events (examples: a competitor hotel going offline for renovations, a major sporting event driving demand) without requiring a human to catch the signal and manually adjust rates.

Foundational data strategy is the real competitive moat

Pratik was clear that all the architectural sophistication in the world collapses without a serious approach to data. The core question every leader should be asking is “Is the data your organization holds actually usable by an AI system?” Not just stored somewhere, but clean, current, structured in ways that a model can reason about, and governed in ways that ensure its quality over time. Most companies, when they’re honest, have to answer that question with “not really.”

The cultural shift required here is moving from a “collect it and figure it out later” mentality to a data-first culture where data quality is treated as a continuous engineering concern, not a cleanup project. Pratik framed this as the AI equivalent of the DevOps automation mindset: just as teams had to change how they thought about deployment.

Instead of thinking of deployment as a periodic event but as a constant, automated process, teams now need to think about data not as a byproduct of operations but as the fuel that makes AI systems defensible.

Unstructured data adds another layer of complexity. RAG  is the most common approach to incorporating things like PDFs and documents into an AI system, but Pratik was careful to note that “just do RAG” massively undersells the challenge. He’s catalogued over 36 distinct RAG implementation techniques, each with different trade-offs around chunking strategies, retrieval quality, and error rates. Leaders who treat RAG as a checkbox rather than an engineering discipline will find their AI systems returning confidently wrong answers from their own documents.

The AI-native development lifecycle

Building AI-native systems requires updating how teams think about the software development lifecycle itself. Pratik drew a direct parallel to the DevOps transformation: just as continuous integration and deployment automated away the pain of manual releases, AI-native development requires building automation into the AI feedback loop,  from code generation assistance to automated testing of non-deterministic outputs.

The trickiest part of this is monitoring. Traditional software testing assumes deterministic behavior: you give it inputs, you check the outputs against known values. AI systems don’t work that way.

Pratik described two approaches that are gaining traction:

  1. Human-in-the-loop feedback: the five-star rating prompt that many AI products now show after a response, which feeds real quality signals back into the system.
  2. “LLM as judge”: using a second AI model (potentially a smaller, cheaper one) to evaluate the outputs of your primary model, essentially automating quality checks at scale.

The practical implication for tech leaders is that shipping an AI-native application is not a one-time event followed by monitoring dashboards. It requires building the infrastructure for continuous retraining, output validation, and drift detection from day one. The underlying model, the data it draws from, and the world it’s reasoning about all change over time. A system that doesn’t account for that will quietly degrade in ways that are hard to detect until users start complaining.

Categories
Artificial Intelligence Conferences

Notes from Advantage, part 1 — Frank Greco: A Leader’s Playbook for AI

Last week, Anitra and I attended both the Dev/Nexus conference and its companion conference, Advantage, an AI conference for CTOs, CIOs, VPs of Engineering, and other technical lead-types, which took place the day before Dev/Nexus. My thanks to Pratik Patel for the guest passes to both conferences!

I took copious notes and photos of all the Advantage talks and will be posting summaries here. This first set of notes is from the first talk, A Leader’s Playbook for AI, presented by Frank Greco.

Here’s Frank’s bio:

Frank is a senior technology consultant and enterprise architect working on cloud and AI/ML tools for developers. He is a Java Champion, Chairman of the NYJavaSIG (first JUG ever), and runs the International Machine Learning for the Enterprise conference in Europe. Co-author of JSR 381 Visual Recognition for Java API standard and strong advocate for Java and Machine Learning. Member of the NullPointers.

And here’s the abstract of his talk:

AI is no longer a side experiment. It is quickly becoming a standard part of enterprise IT, both in how systems get built and how teams get work done. For CIOs, CTOs, and team leads, the hard part is figuring out which AI efforts will actually pay off without creating unnecessary risk for the company. In this session, you will get a practical way to pick the right first pilots, define success metrics that matter, and avoid the most common traps. Those traps include leaking sensitive data, getting unreliable output, having no clear owner, and running pilots that never turn into real ROI. We will talk about how AI tools fit into everyday team workflows, how to balance value and risk so you know where to start, and what guardrails to put in place from day one. That includes data boundaries, human oversight, auditability, evaluation, and safe fallback behavior. You will leave with a simple checklist and an action plan you can use right away to launch a secure, measurable AI pilot that your team can ship and your organization can scale.

My notes from Frank’s talk are below.

Most people don’t know what AI is, and that’s okay

One of the most reassuring moments in Frank’s talk came early. It was a reality check about how widely AI is actually understood. Frank pushed back against the anxiety many tech leaders feel about falling behind, pointing out that most people (which includes plenty of CTOs at large companies) genuinely don’t know what generative AI is or how to use it effectively. The adoption curve is far flatter than the hype suggests, and people inside the I.T. bubble consistently overestimate how much the rest of the world has embraced this technology.

This doesn’t mean complacency is wise, but it does mean leaders can take a breath before making reactive, poorly-considered AI investments. The real competitive advantage is in taking the time to actually understand AI instead of rushing in blindly. Frank’s argument is that leaders who build foundational knowledge now will be far better positioned than those who bolt on AI tools under pressure and learn nothing durable in the process.

Three pillars of an AI strategy

Frank outlined a clean, actionable framework for leaders thinking about where to start: AI/business strategy, understanding the core technology, and implementation.

The first pillar is the business strategy. It’s about deciding what problem you’re actually trying to solve with AI, and why it matters to your organization. Without that anchor, AI initiatives tend to drift toward whatever is technically interesting rather than what’s genuinely valuable.

The second pillar, understanding the core technology, is where Frank pushed hardest. He argued that even developers often treat generative AI like just another framework to learn, which fundamentally misunderstands what makes it different.

LLMs are non-deterministic. Given the same input, they can produce different outputs, which is a conceptual break from over 60 years of computing where the same data reliably produced the same result. Leaders who don’t grasp this distinction will struggle to set appropriate expectations, evaluate outputs, or assess risk.

The third pillar, implementation, is where strategy meets reality. Frank recommended starting with a pilot project that is useful but not mission-critical. It should be something meaningful enough to teach you real lessons, but not so central to operations that failure results in dire consequences. It’s similar to how most organizations handled the move to cloud, where they didn’t migrate their core banking system first, but instead learned on something lower-stakes, built confidence and competency, and scaled from there.

The security and legal risk nobody is taking seriously enough

Frank was emphatic on one point that he felt wasn’t getting enough attention: LLMs are inherently insecure, and organizations need to treat them that way from day one. He demonstrated this himself, describing how he was able to manipulate a chatbot into behaving like a pizzeria employee simply by using prompt injection. The bigger concern today is AI coding assistants that incorporate third-party skills and prompts without vetting them, potentially executing malicious code inside a developer’s environment.

The legal dimension is equally underappreciated. Frank flagged recent changes to platform liability law that affect companies deploying chatbots. Where organizations once had certain protections if a third party misused a service, that shield has eroded. If someone misuses your company’s chatbot, the legal exposure may now land squarely on you. His advice was direct: before deploying any customer-facing AI, talk to your lawyers.

Data privacy is another key risk. Frank noted that roughly 90% of people using AI tools at work don’t realize they’re sending potentially sensitive data to an external service. An employee typing internal business details into a public chatbot is effectively sharing that information with a third party, regardless of what the vendor’s terms of service say about data use. Vendors get acquired, policies change, and by then the data is already out there.

Build an internal AI “center of gravity”

Frank’s final set of recommendations centered on organizational structure rather than technology. His experience educating middle management at Google taught him that top-down mandates to “use AI” rarely work. People need to see practical, relatable examples of AI making their actual jobs easier before they engage. The model that worked at Google was a recurring internal showcase: a weekly lunch where AI practitioners demonstrated small, concrete wins to colleagues across the organization. Over time, 500 people were showing up voluntarily.

The broader lesson is that companies should deliberately build a team of internal AI experts who can shepherd the technology across the organization and serve as resources, translators, and guardrails simultaneously. This goes beyond training developers. It’s about creating the infrastructure for responsible adoption at every level. That includes establishing model risk management practices, particularly in regulated industries like financial services and healthcare, where the consequences of a non-deterministic system making a wrong call can be severe.

Finally, measure the ROI. If you can’t demonstrate that your AI initiatives are delivering value, you can’t justify continued investment or make the case for scaling them. Leaders who want AI to take root in their organizations need to make the results visible (successes and failures) so the organization can learn and iterate rather than just chase the next tool.

Categories
Artificial Intelligence Conferences Meetups Programming What I’m Up To

I’m speaking at “Arc of AI” in Austin, Texas — April 13 – 16!

I just got added to the list of speakers who’ll be presenting at the Arc of AI conference, which takes place April 13 – 16 in Austin, Texas!

Arc of AI is the premier AI conference for deep technical talks on everyone’s favorite two-letter field. If you’re one of these kinds of people interested in AI…

  • Software developer
  • Architect
  • Data engineer
  • Technology leader

…and you want to learn the latest strategies, tools, and practices for building AI-powered applications and boosting your development workflows, with AI, this is your conference!

The early bird ticket price is $799, but that lasts only until this Saturday, March 14th. It goes up to $899 until April 4th, after which the price becomes $999.

Tampa Bay AI Meetup is a community partner of Arc of AI, and we can help you save $50 off the ticket price! Just use the discount code TampaBayAIMeetup when checking out.

There’s another way to attend Arc of AI for even less: come to this Thursday’s Tampa Bay AI Meetup, where we’re covering vibe coding, and find out how you can win a ticket to Arc of AI for FREE!

I’ll be writing more about Arc of AI soon — watch this space!

 

Categories
Artificial Intelligence Meetups Tampa Bay What I’m Up To

Vibe Coding Workshop with Tampa Bay AI Meetup – THIS THURSDAY!

If you’re curious about vibe coding and want to know how to get started, bring your laptop to Tampa Bay AI Meetup’s Vibe Coding Workshop, taking place on Thursday, March 12 at 6:00 p.m. at the Hays office (4350 W Cypress, Suite 1000, Tampa)!

The phrase “vibe coding” was coined just over a year ago by Andrej Karpathy, founding member of OpenAI and Tesla’s former Director of AI. You’ve probably read a post or article saying that it’s the future of programming and that if you don’t take it up, you’ll be left behind. But have you tried it yet?

You’ve seen people on LinkedIn, Reddit, and other social media talk about how much they’ve been vibe coding, but perhaps you haven’t had the chance yet. That’s okay: MOST of the *actual* work that needs to get done doesn’t involve vibe coding, at least for now.

We’ll help you get started with a couple of vibe coding exercises, including building a Chrome plugin that you’ll find useful for vibe coding.

This is another one of Tampa Bay AI Meetup’s signature “code along with me” exercises. Bring your laptop, make sure you’ve got VS Code installed, and get ready to vibe code!

Categories
Artificial Intelligence Meetups

Notes from Pratik Patel’s presentation, “AI Native Architecture” (Feb. 19, 2026 @ Tampa Java User Group / Tampa Bay AI Meetup)

Last Thursday, February 19th, Tampa Java User Group welcomed Pratik Patel, Java Champion and Director of Developer Relations at Azul Systems, to give his AI Native Architecture talk at Kforce headquarters. Tampa Bay AI Meetup was happy to partner with Tampa JUG, and we thank Ammar Yusuf for the invite!

We had a pretty full room…

…followed by an accordion number…

…followed by Pratik’s presentation.

Here are my notes from the presentation:

Three kinds of AI

Here’s a fun “icebreaker” game to try at your next tech gathering: ask the room to name the three fundamental types of AI, and watch what happens.

When tried on the crowd at last Thursday’s Tampa Java User Group / Tampa Bay AI Meetup, a lot of people called “generative AI,” which was hardly a surprise.

We came close, but didn’t directly name, the second kind: predictive analysis. It’s the kind of AI that’s been quietly running inside every credit card transaction you’ve made for the past decade. It saved me a lot of headache last year when someone used my credit card number to buy enough gas to fill an F-250 in rural Georgia while I was having a poke bowl in St. Pete. A neural network detected the mismatch between the gas-guzzler purchase and my usual spending and location patterns, which led to a text from the credit card company, and my immediate “That wasn’t me” response.

None of us got the third one: time-series AI. It’s the branch that looks at data across time to spot trends and make forecasts. Not “Will Joey buy 50 gallons of gas in rural Georgia?” but “What has Joey been buying every Friday evening for the past two years, and what does that predict about next Friday?”

Pratik kicked off his talk on AI-native architecture with this. By the time he was done, we’d gotten a serious rethink of not just what kinds of AI exist, but what it actually means to build an application with AI at its core, as opposed to just bolting AI onto the side and hoping for a stock price bump.

Your data is your moat

One of the central arguments Pratik made is that data is what separates a defensible business from one that can be replicated by a developer with a generous cloud credit and a free afternoon.

He used Penske Truck Leasing as his example. Anyone can, theoretically, buy a bunch of trucks and stand up a website. What you can’t easily replicate is a decade of auction data, bidding history, customer behavioral patterns, and operational intelligence. That data is what lets Penske do something like: identify a customer who bid on a truck but didn’t win the auction, then automatically reach out to offer them a similar vehicle. The data made it obvious, and a system acted on it.

This is why the old saying “data is the new oil” is actually more apt than it sounds. Raw oil isn’t useful until it’s refined. Raw data sitting in an S3 bucket isn’t useful either until it’s refined toom by cleaning it, structuring it, and using it to power an application that your competitors simply don’t have the history to replicate. This kind of advantage that sets you apart is referred to as a moat.

In this new world, where anyone can vibe-code a decent SaaS clone in an afternoon using AI tools, your proprietary data may be that moat protecting you from someone in their mom’s basement with good taste and ambition.

The architecture stack (or: Where all this stuff actually lives)

Pratik laid out a three-layer view of what an AI application architecture actually looks like in the real world. It was a helpful maps to the “who does what” question that comes up whenever engineering teams start building this stuff.

On the left side is data acquisition and preprocessing. This comprises tools like Apache Kafka for event streaming, Apache Iceberg as a data layer that lets multiple teams share the same underlying datasets without tripping over each other, and Spark for processing data at scale. This is where collection, cleaning, and transformation happen. It’s also where most AI projects quietly die, because the data turns out to be messier than anyone admitted during planning.

In the middle is model building and fine-tuning. Pratik was direct here: your company is almost certainly not going to train its own large language model from scratch. The estimates for what it cost to train GPT-5 range from $100 million to over a billion dollars in GPU time. Unless “Uncle Larry” is personally funding your AI initiative, you’re going to use an off-the-shelf model, like OpenAI, Gemini, Claude, or one of the increasingly capable open-weight models like DeepSeek or Alibaba’s Qwen3. The Python ecosystem owns this tier for now, thanks to its long history in data science and extensive libraries, though Java options like Deep Learning4J are maturing.

On the right is inference and integration, which is where most application developers will actually spend their time. This is the code you write to orchestrate models, retrieve relevant context, handle the results, and deliver a useful experience to users. This is also where AI-native thinking diverges sharply from “AI bolted on,” which Pratik spent considerable time on.

The most important thing Pratik said all evening

Here it is: LLMs are non-deterministic, and that changes everything about how you build software.

Traditional software is built on deterministic foundations. If you write a database query that asks for a specific user profile, you will get the exact same answer every time: that user’s profile. The result is deterministic, and it’s  reliable in a way that software developers have spent the previous decades taking for granted.

LLMs don’t work that way. Ask the same question twice and you may get meaningfully different answers. That’s just a fundamental property of how token prediction and the attention mechanism work. The model doesn’t do the deterministic thing and look up an answer. Instead, it generates an answer based on probabilistic similarity to everything it has ever been trained on.

When the generated answer is wrong, we call it hallucination. But the more accurate framing is that hallucination is the shadow side of the same capability that makes these models useful at all.

(Joey’s note: I like to say “All LLM responses are hallucinations. It’s just that some hallucinations are useful.”)

For casual applications, such as “Find me a bar with karaoke near downtown Tampa,” we can put up with a certain amount of “wrongness.” You go there, find out there’s no karaoke, drink anyway, call it a night. However, for a system that’s analyzing medical imaging and flagging potential tumors, our tolerance for wrongness is zero, and “the model felt pretty confident” is not an acceptable answer.

The emerging approaches to this are interesting: evaluation frameworks built into tools like Spring AI and LangChain that let you run suites of tests against model outputs; and something called “LLM as a judge,” where you use a second model to evaluate the outputs of the first. Ask OpenAI a question, get an answer, hand both the question and the answer to Gemini and say: “Does this look right?” It’s new, it’s imperfect, and it’s the current state of the art.

The good news, as Pratik put it: everyone is early. You are not behind.

About those costs

Don’t let the $20/month subscription price fool you into thinking AI inference is cheap at scale.

Pratik made the case that inference costs are not going to come down dramatically anytime soon, and offered some uncomfortable data points in support. Moore’s Law, the Intel cofounder’s observation that transistor density on chips doubles every 18 months, is effectively dead. We’re at the sub-nanometer level of chip fabrication and at that level of miniaturization, you’re really starting to fight the laws of physics.

GPU prices have gone in the opposite direction of what you might hope: the Nvidia 5090, the top consumer-grade card, has gone from roughly $2,000 at launch to $4,000 on the secondary market. RAM prices have spiked because every data center on Earth is buying it for AI workloads. When Pratik noticed RAM prices shooting up, he moved money into Western Digital and Seagate stock. He may be onto something.

The practical upshot for developers building applications: if you’re running hundreds of evaluation tests per hour during development (which is what you should be doing, given the non-determinism problem described above)  burning frontier model tokens for all of that is going to get expensive fast.

Pratik’s solution is to do the bulk of development testing against locally-run open-weight models via Ollama. His current recommendations: qwen3-coder for coding-adjacent tasks (and it legitimately does not phone home, I’ve run Wireshark to confirm), and nemotron from Nvidia for more general work. Then switch to the frontier model for production and final evaluation. Your laptop handles the iteration, and the cloud handles the deployment.

AI-native vs. bolting AI on (or: What actually matters)

You’ve heard this story before, even if you don’t immediately recognize it.

Pratik brought up an old term: sneakernet. That’s from  the era when all software was executables running on your machine, and deploying software meant physically walking to a user’s desk with a floppy disk. Then came the cloud, and suddenly continuous deployment became a thing, and anyone still doing quarterly releases felt like a relic.

But here’s what’s easy to forget: cloud native wasn’t just about faster deploys. It forced a complete rethink of how applications are designed, how they’re operated, and how they fail. The servers went from being pets (named, tended, mourned when they died) to being cattle (anonymous, disposable, replaced without ceremony). This called for a different approach.

Pratik’s central argument is that we’re at exactly that same inflection point with AI, and that most companies are going to blow it, at least initially.

When your boss comes in and says “put some AI in the product so our stock price goes up” (Pratik confirmed this is a real conversation people are having in real offices, not a joke), the tempting response is to bolt on a RAG endpoint, add “AI-powered” to the marketing copy, and call it a day. Retrieve some relevant documents. Stuff them into a prompt. Return a plausible-sounding answer. Ship it!

That’s not AI-native. That’s sneakernet with an LLM duct-taped to it.

An AI-native system learns, adapts, and acts autonomously. Not when a user presses a button. Proactively, in response to new data, with judgment that improves over time.

Pratik described the evolution of his own download analytics system as a concrete example. It started as “AI bolted on,” with a natural language interface that let people query a Spark cluster without writing SQL. Useful. Not native.

Over the past year and a half, he rebuilt it into something different: a system that monitors weekly data feeds, detects when something has changed (for example, a spike in Java 17 downloads), connects that to relevant context from an internal knowledge base (there was a critical security patch), and proactively sends him a synthesized briefing before he even thinks to ask. He still reviews it. But the thinking now happens without him.

The hotel booking example he used to illustrate the idea is even more vivid. Pratik has a specific, consistent set of hotel preferences: he wants to be within walking distance of wherever he’s speaking, the gym needs to be a real gym (not a treadmill and a motivational poster — Hotel 5 in Seattle, I’m lookin’ right at you), and he always searches by exact address rather than city name. He does this exact sequence of clicks every single time he books a hotel. An AI-native Marriott system would see this behavioral pattern, learn from it, and surface the right three options without him having to do any of that manual filtering. Not because someone programmed “Pratik likes gyms” into a rule engine, but because the system observed his behaviors, inferred some patterns, and generalized.

Could you do all of this algorithmically? Technically, yes. But think about it: you’d be writing bespoke preference logic for millions of users with different, compounded, evolving preferences, and you’d be doing it forever. The whole point of using an LLM here is that you’re borrowing its capacity for generalization instead of hand-coding every case yourself.

Agents, fine-tuning, and a grain of salt

Pratik offered a measured take on the current agentic AI frenzy. Agents can act, but do they actually learn from what they’ve done? That’s the gap between today’s agentic frameworks and a genuinely AI-native system. Agents are probably not going away because they’re real and useful, but the framing will shift again in six months ( that’s just how this space works). The best approach is to build the fundamentals, not the hype.

On fine-tuning: if you need a model that’s deeply specialized for a domain, you don’t have to build an LLM from scratch. Low-Rank Adaptation (LoRA) lets you take an existing large model and attach a domain-specific adapter that shifts its weights toward your area of expertise. OpenAI’s recently released finance-specific model that they built in collaboration with Goldman Sachs, trained on a large corpus of financial data is exactly this. The base model does the heavy lifting. The adapter makes it fluent in corn futures.

On RAG: retrieval-augmented generation is essentially fancy-pants prompt stuffing. You find the documents most relevant to a user’s query, pull them in, and let the model reason over them. It’s the right approach for a lot of use cases, it’s not magic, and it works best when your underlying data is actually clean and well-structured. Remember the greybeard saying: “Garbage in, garbage out,” a principle that the age of AI has managed to make both more important and more dangerous, since we can now generate garbage at industrial scale.

The take-away

If you walked away from Pratik’s talk with one thing, it should probably be this: the fundamental shift AI requires isn’t technical. It’s conceptual. Just like cloud native forced you to stop thinking about servers as permanent fixtures and start thinking about them as fungible infrastructure, AI native requires you to stop thinking about AI as a feature you add to an application and start thinking about it as the substrate the application is built on.

The application that learns. The application that adapts. The application that wakes up when new data arrives and starts thinking before you ask it to.

That’s the goal. We’re early. The tools are changing fast. But the direction is clear, and the developers who internalize that shift now, rather than bolting features on and hoping for a stock price bump, are going to be the ones building the interesting stuff.

Sample apps!

If you’d like to dive deeper into what Pratik was talking about, he has companion sample apps. The details are in this picture:

Categories
Artificial Intelligence Career Security What I’m Up To

A Fake Recruiter Tried to Scam Me — I Caught Him Using ChatGPT

The newest video on the Global Nerdy YouTube channel is now online! It’s called A Fake Recruiter Tried to Scam Me — I Caught Him Using ChatGPT. Watch it now!

It’s the story of how a scammer posing as an executive recruiter tried to con me out of hundreds (and possibly thousands) of dollars using AI-generated emails, a fake job description, and a fabricated “internal document” from OpenAI.

He had me… for thirty seconds, and then I thought about it.

The short version

A “recruiter” emailed me out of the blue about a developer relations role. This isn’t out of the the ordinary; this has happened before, and it’s happened a couple of times in the past couple of months.

However, this role stood out: it was Director of Developer Relations role at OpenAI. Remote-first, $230K–$280K base, Python-primary, and AI-focused. It was basically my dream job on paper.

Over the course of several emails, he asked for my resume and salary expectations while giving me nothing concrete in return: no company name, no hiring manager, no specifics.

When I finally got suspicious and asked three simple verification questions:

  1. Who’s your contact at OpenAI?
  2. Is this a retained or contingency search?
  3. What’s your formal relationship with the hiring organization?

He went silent for over a day, then came back with a wall of text that answered none of them.

Then came the real play: he told me that OpenAI required three purportedly “professional documents” before I could interview, and they had to be ready in the next 48 hours:

  1. An “Executive Impact Matrix,”
  2. A “Technical Leadership Competency Assessment,” and
  3. A “Cross-Functional Influence & Initiative Report”

The descriptions of these documents made it look as if they were complex and would take hours to prepare. The recruiter “helpfully” offered to connect me with a “specialist” who could prepare them for a fee.

None of these documents are real. No company asks for them. It’s a document preparation fee scam, and the whole weeks-long email exchange was just the runway to get me to that moment.

But the best part? When I didn’t bite, he followed up with a fake “OpenAI Candidate Review” document showing my name alongside other “candidates” with star ratings. This would be a massive HR violation if it were real:

But it wasn’t real! He generated it with ChatGPT. And he left behind evidence — the dumbass forgot to crop out the watermark.

How the AI gave him away

One of the most interesting things about this scam is how AI was both the scammer’s greatest tool and his undoing.

Every email he sent me was written in polished, flawless corporate English.

But in the one paragraph where he steered me toward paying the “specialist,” the grammar suddenly fell apart:

“a professional I have known for years that specialise in this kind of documents with many great and positive result.”

The AI wrote the con. But the human wrote the close. And the seam between the two is where the truth leaked out.

This is a pattern worth watching for. As AI-powered scams become more common, the tell is going to be a shift in quality at the moment where the scammer needs to speak in their own words. You’ll see well-written text, abruptly followed by different writing style marked by poor, non-idiomatic grammar (because they’re communicating with you in a language they don’t know  well). Keep an eye out for that sudden transition.

The 3 questions real recruiters can answer

If you’re job searching right now and a recruiter reaches out, ask them these three questions:

  1. Who is your contact at the hiring company?
  2. Is this a retained or contingency search?
  3. What is your formal relationship with the hiring organization?

A real recruiter answers these in seconds. A fake one dodges, deflects, or disappears.

8 fake recruiter red flags

Based on my experience, here are eight things to watch out for:

  1. The job seems tailor-made for you. LLMs make it trivially easy to generate a convincing “JD” (job description) from someone’s LinkedIn profile. If it checks every single box, ask why.
  2. The information only flows one direction. They ask for your resume, salary, and preferences. They give you nothing concrete: no company name, no hiring manager, no search terms.
  3. The email footer doesn’t add up. Gmail addresses or mismatched domains, vague or incomplete street addresses, and an “alphabet soup” of certifications are all warning signs.
  4. They dodge verification questions. Real recruiters are proud of their client relationships. Fake ones ghost you when you ask for specifics.
  5. They ask you to pay for documents or preparation. No legitimate employer requires this. Ever. This is always the scam.
  6. Watch for the grammar shift. Polished emails that suddenly drop in quality when money enters the conversation? That’s AI-generated content with a human-written sales pitch sloppily stitched in.
  7. Check the metadata. If they send you an “official” document, look at every corner, every file property, every detail. Scammers are playing a numbers game, and as a result, they’re often rushed and sloppy. Sometimes they literally leave the watermark.
  8. The emotional setup is part of the scam. Flattery, validation, and the sense that someone finally sees your worth is intoxicating, especially when you’ve been job hunting for months. That’s by design. The best time to be skeptical is when you most want to believe.

Why this matters right now

This isn’t just my problem. It’s an epidemic:

AI tools are making these scams more polished, more personalized, and harder to detect. The “spray and pray” emails with obvious typos are being replaced by tailored, multi-email campaigns that build trust over weeks before making their move.

If you’re job searching (or know someone who is), please share this post and the video. The more people know what to look for, the less effective these scams become.

Watch the video

Once again, here’s the video, where I walk through the entire scam step by step, from the first email to the ChatGPT watermark:

And if you haven’t already, subscribe to the Global Nerdy YouTube channel. There’s more coming soon, and I promise it’ll be less infuriating than this one. Probably.

Report it

If this has happened to you, here’s where to report it:

And if you’ve got your own story about a fake recruiter, drop me a line on LinkedIn! Let’s make these scams harder to pull off.