There is a meaningful difference between pasting a problem into ChatGPT and deploying an AI system that autonomously orchestrates multi-step workflows across a regulated enterprise. Karl has spent the last several years working in that gap — building what he calls “AI coworkers” for wealth management firms and manufacturers. This article unpacks the architectural decisions, engineering philosophy, and organizational implications behind that work.

AI + Snowpal API: Reduce Time to Market

Podcast

Beyond RAG: Building Production-Grade AI Coworkers for the Enterprise — on Apple and Spotify.

Summary

1. The Problem With Vanilla RAG — why knowledge graphs are necessary beyond hybrid BM25+vector retrieval

2. The Agentic Harness — multi-model routing, observability, and the two-tier feedback loop (DeepLens + aggregate optimization)

3. The Tech Stack — Python, LangChain/LangGraph/LangSmith, React, database-agnostic deployment, and in-client cloud architecture

4. Two Case Studies — wealth management meeting prep (8,000 hours eliminated) and the field service diagnostic reporting app

5. Human-AI Engineering Teams — the 80/20 assembly line, TDD enforced at the AI layer, and developers as AI coworker managers

6. Interfaces for Human and Agent Consumers — dynamic dashboard generation and why Markdown outperforms JSON for agent-to-agent handoffs

7. The Broader Shift — what changes (mid-management, SaaS economics, the value of specification over implementation) and what doesn’t (core engineering discipline)

The Problem With Vanilla RAG

Retrieval-Augmented Generation is the obvious starting point for any system that needs to answer questions grounded in proprietary data. Hybrid RAG — combining dense semantic search with sparse BM25 indexing — improves recall over pure vector similarity. But Simon argues that even hybrid RAG is insufficient for enterprise contexts, because it lacks the domain structure to know which retrieved chunks are actually relevant to the question at hand.

Consider a wealth management firm preparing for a quarterly client review. Relevant information is scattered across custodial platforms, risk management systems, retirement and estate planning tools, tax software, CRM records, email, calendar, and document storage. A naive RAG query returns semantically similar chunks, but it has no way to understand the relational context: that a particular estate plan is tied to a specific client’s risk tolerance, which is in turn constrained by a life event recorded in the CRM.

Subatomic’s answer is what Simon calls “RAG plus”: a knowledge graph that encodes the domain model — entities, relationships, and their interdependencies — and then uses that graph to bound and contextualize retrieval. When a query comes in, it is not simply sent to a vector index. Instead, the knowledge graph provides a contextual boundary that filters and ranks retrieved chunks according to their position in the domain model. The result is what Simon describes as “contextually guardrailed” retrieval — semantically relevant and domain-coherent.

Building the knowledge graph correctly is non-trivial. It requires capturing how services interconnect, how client profiles relate to financial instruments, and how different regulatory and planning concerns interact. “We handle the tricky,” Simon says. “We handle the complex.”

The Agentic Harness: Why Prompting Alone Falls Short

A common misconception Simon encounters is that a well-crafted prompt to a capable foundation model is functionally equivalent to a purpose-built agentic system. It is not — and the gap becomes obvious at scale.

Even the best publicly benchmarked models achieve accuracy rates well below the 90th percentile on complex, multi-step tasks when given only a single-pass prompt. The core issue is that a prompt is stateless and monolithic. It cannot dynamically branch on intermediate findings, consult external knowledge mid-execution, or route sub-tasks to specialized models.

An agentic harness solves these problems by decomposing complex workflows into discrete steps, each of which can independently reason, retrieve, and act. Within any given step, the harness can branch based on intermediate outputs — routing a technical diagnostic question differently from a billing inquiry, for example. This structure also enables:

Multi-model routing. Subatomic deploys multiple models simultaneously — both commercial (OpenAI, Anthropic) and open-source — and assigns tasks to models based on fit. A large frontier model handles nuanced reasoning; a fine-tuned smaller model handles a narrow classification step faster and more cheaply. This is not just cost optimization; smaller specialist models often outperform larger generalists on tasks they were trained for.

Observability as a first-class citizen. Subatomic uses LangSmith for baseline tracing and augments it with extended audit logs that surface the full chain of reasoning to clients. Every execution records which workflow steps were invoked, what reasoning was applied, and what intermediate answers were produced. This matters in regulated industries where you cannot simply say “the AI decided.”

Continuous optimization. Simon describes a two-tier feedback loop. At the request level, a dedicated AI coworker called DeepLens evaluates the execution in real time, checks it against expected reasoning patterns, and self-corrects before returning a final answer. At the aggregate level, patterns across executions are analyzed for accuracy, faithfulness, consistency, and cost anomalies — and the knowledge graph and retrieval configuration are updated accordingly.

The Tech Stack

Subatomic’s stack reflects a bias toward flexibility and interoperability over vertical lock-in.

Languages and frameworks. Python is the primary language, chosen in part because it is common enough that clients who want a co-management support model can participate. LangChain is the primary orchestration framework; LangGraph handles graph-based agent topology; LangSmith provides tracing.

Frontend. React components, with the capability to dynamically generate UI elements at runtime based on the nature of a request — not just serve a static dashboard.

Databases. Rather than imposing a fixed data store, Subatomic adapts to whatever the client already operates: Postgres by default, but also Snowflake, Databricks, SQL Server, Oracle, and others. This is less about maintaining a library of pre-built connectors and more about code generation: Subatomic’s AI coworker engineers can produce dialect-specific code for a given target system rapidly, including transformations between structural paradigms (relational, key-value, graph) when a client is migrating or consolidating.

Deployment. Subatomic is not a SaaS product. It deploys into the client’s own cloud account (AWS, Azure, GCP) or on-premises, ensuring that client data never leaves their security perimeter. Security and auditability are designed in from the start, not bolted on.

Architecture in Practice: Two Case Studies

Wealth Management: Client Meeting Preparation

The flagship use case eliminates the manual labor of aggregating information before a client meeting. An advisor’s relevant data — portfolio positions, risk profile, tax exposure, estate planning status, recent correspondence, CRM notes — is scattered across at least six distinct systems. Previously, assembling a 360-degree view required hours of manual extraction and synthesis.

With the Subatomic system in place, the AI coworker traverses the knowledge graph to identify all entities related to the client, retrieves relevant documents and structured records via hybrid RAG, and produces a synthesized briefing scoped to the meeting’s agenda. The system eliminated approximately 8,000 hours of labor annually across one firm’s advisor team.

Field Service: Automated Diagnostic Reports

A high-end commercial oven manufacturer needed to standardize the quality of field service reports. Technicians would spend multiple days on-site diagnosing complex failures; the reports they produced varied significantly in quality and structure.

Subatomic built a mobile application (tablet and phone form factors) that guides technicians through a structured diagnostic workflow. The app collects text, photos, and video as a technician progresses through diagnosis steps. Once all data is captured, an agentic system — pulling in the relevant maintenance documentation via hybrid RAG, bounded by the product’s knowledge graph — synthesizes a formatted report that reflects the company’s preferred documentation practices.

What makes this more than a form-filling tool is the dynamic branching. The workflow adapts based on the category and complexity of the fault being diagnosed, surfacing different sub-procedures and reference documents depending on intermediate findings.

Human-AI Engineering Teams

Subatomic operates with 13 human engineers and over 100 AI coworkers. The ratio was not always this way; it inverted over the past year. This inversion has specific implications for how the team is structured and how software gets built.

The 80/20 assembly line. Subatomic has two internal AI coworker platforms: Nexus for data engineering tasks, and Nucleus for workflow orchestration. Together, they generate approximately 80% of the codebase for a given client engagement. Human engineers handle the final 20% — the layer that is specific to the client’s operating procedures, cognitive patterns, and regulatory context. Below that custom layer are reusable domain modules (industry-standard patterns and entity models) that are shared across engagements, though never identical codebases between clients.

Test-driven development enforced at the AI layer. Simon is emphatic about test-driven coding. Functional and technical test conditions are specified before any code is generated, and the AI coworkers are required to produce code that satisfies those conditions. This is not just a quality mechanism — it is an accountability mechanism. When testing is separated into a distinct role, he argues, it diffuses responsibility. When the code-generating system is also responsible for passing the tests it was given, accountability stays in one place.

Developers as AI coworker managers. The practical role of a human engineer at Subatomic has shifted from writing code to managing the AI coworkers that write code — reviewing output, specifying constraints, catching edge cases that automated generation misses. Software design patterns and data engineering patterns still matter; they are what make an engineer capable of evaluating whether the AI’s output is durable for production conditions. Vibe-coded output, in Simon’s assessment, almost always lacks the security hardening and edge-case handling required for real production environments.

Interfaces for Human and Agent Consumers

The field service application raised an important design question: should the interface be a structured form or a conversational interface? Subatomic initially built headless (chat-only) interfaces and found strong adoption among technically sophisticated users. When clients requested dashboards, the team did not simply add static charts — they built dynamic visualization generation. An advisor can ask a natural-language question and receive both a synthesized answer and an auto-generated dashboard that surfaces the key metrics supporting that answer.

For agent-to-agent communication, Simon points to a structural shift away from JSON as the interchange format toward Markdown. Large language models synthesize Markdown more reliably than JSON when passing context between agents; JSON-encoded intermediate state produces less consistent output on the receiving end. This has practical implications for how agentic pipelines are designed: when agents need to hand off context to one another — whether within the same system or across organizational boundaries in something like a supply chain — Markdown-structured summaries outperform raw structured data as the information carrier.

Role-based access control applies equally to human and agent callers. A registry of accessible tools and functions is maintained per caller identity, regardless of whether that caller is a human in Slack or an upstream agent.

The Broader Shift: What Changes and What Does Not

The fundamental practices of software engineering — design patterns, data modeling, security architecture, observability — have not changed. What has changed is the ratio of human effort required to produce a working implementation. The “hello world to production” journey is dramatically shorter when 80% of the scaffolding is generated. This does not mean the scaffolding does not need to be reviewed; it means the review is more valuable than the generation.

Mid-management may be disproportionately affected. AI systems that unify information across organizational silos — eliminating the need to escalate requests through multiple layers to get a cross-functional answer — reduce the coordination function that mid-management has historically provided. Simon estimates 80% of director and senior-manager level roles could be affected by 2028.

The SaaS model faces structural pressure. If an organization can instruct an AI coworker to build a CRM tailored to its own workflows — rather than licensing a general-purpose one and customizing around its constraints — the economic case for many vertical SaaS products weakens. Subatomic itself has replaced its own CRM with an internally generated alternative.

The most durable engineering skill, in this view, is not the ability to write code. It is the ability to specify what correct code looks like — to define the test conditions, the architectural constraints, and the security requirements that a generated implementation must satisfy. That specification skill requires deep domain and systems knowledge. It is also the hardest to automate.

FAQ

Architecture & Retrieval

Q: What is “RAG plus” and how does it differ from standard RAG?

Standard RAG retrieves documents by semantic similarity. Hybrid RAG adds sparse keyword indexing (BM25) to improve recall. “RAG plus” goes a step further by layering a knowledge graph on top of retrieval — the graph encodes domain entities and their relationships, and retrieval is bounded within that contextual structure. This means the system does not just find semantically similar chunks; it finds chunks that are coherent within the domain model relevant to the query.

Q: Why is a knowledge graph necessary? Can’t a well-structured vector index do the same job?

A vector index captures semantic proximity, not relational structure. In a domain like wealth management, the relevance of a document depends on how its subject relates to other entities — a tax document is relevant to a client meeting only if it is connected to that specific client’s profile and current planning objectives. A knowledge graph makes those connections explicit and traversable. Without it, retrieval is context-blind.

Q: What interchange format works best for agent-to-agent communication?

Markdown. JSON was an earlier default for passing state between agents, but large language models produce less consistent output when synthesizing from JSON-encoded context. Markdown-structured summaries yield more reliable downstream reasoning, whether the receiving agent is internal to the same pipeline or external across an organizational boundary.

The Agentic Harness

Q: Why not just use a foundation model directly with a detailed prompt?

A single-pass prompt is stateless and monolithic. Even well-designed prompts to top-tier models achieve accuracy below 90% on complex, multi-step tasks. An agentic harness decomposes the problem into discrete steps, enables dynamic branching on intermediate results, consults external knowledge mid-execution, and routes sub-tasks to purpose-fit models. The compounding effect across many steps makes the difference between a prototype and a production system.

Q: How does multi-model routing work in practice?

Tasks are evaluated at runtime and assigned to the model best suited for that specific sub-task — a large frontier model for nuanced reasoning, a smaller fine-tuned model for a narrow classification step. The goal is both cost efficiency and accuracy: smaller specialist models often outperform larger generalists on tasks they were trained for. Sending every request to the largest available model is both wasteful and sometimes less accurate.

Q: What does observability look like inside an agentic system?

At the request level, every execution records which workflow steps were invoked, what reasoning was applied, and what intermediate answers were produced before the final output. A dedicated evaluation layer checks the execution against expected reasoning patterns in real time and self-corrects before returning a result. At the aggregate level, patterns across executions are analyzed for accuracy, faithfulness, consistency, cost, and standardization — and the system configuration is updated accordingly.

Q: How do you prevent an agentic system from hallucinating or going off-rails?

Several mechanisms work together: the knowledge graph bounds retrieval to contextually relevant information; workflow steps are pre-defined with explicit logic branches rather than open-ended generation; test conditions are specified upfront and the system must satisfy them; and a real-time evaluation layer audits the execution chain before output is returned. Security and observability are not add-ons — they are designed into the harness from the start.

Deployment & Integration

Q: Is this a SaaS product that customers sign up for?

No. The system deploys into the client’s own cloud environment (AWS, Azure, GCP) or on-premises. The client is the tenant of the account. This ensures data never leaves the client’s security perimeter and allows the deployment to conform to the client’s existing security controls rather than requiring them to adapt to a third-party SaaS boundary.

Q: How does the system handle clients with different database infrastructure?

Rather than requiring a specific database, the system generates dialect-specific code for the target data store — Postgres, Snowflake, Databricks, SQL Server, Oracle, and others. When a client is migrating between platforms (e.g., Redshift to Snowflake), the system can convert the relevant query logic with minimal impact. When the underlying data structure changes (e.g., relational to key-value), adapter code handles the transformation. The guiding principle is minimum disruption to existing architecture.

Q: Can the system integrate with existing communication tools like Slack or Teams?

Yes. A “chief of staff” layer acts as the coordination point for all AI coworker teams and is accessible from standard communication channels — Slack, Teams, email, SMS — in addition to a dedicated UI. This broadens adoption because users can interact with the system wherever they already work, without context switching into a separate application.

Engineering Teams & Development Practices

Q: Do you still need software engineers if AI generates 80% of the code?

Yes, and for a specific reason: the value of an engineer has shifted from writing code to specifying what correct code looks like. Defining test conditions, architectural constraints, security requirements, and edge-case behavior requires deep systems knowledge. Vibe-coded output — generated without those constraints — is consistently more fragile in production: it misses security hardening, fails on edge cases, and is difficult to audit. Someone with engineering discipline needs to own the final 20% and verify the 80%.

Q: How has test-driven development changed with AI code generation?

Test conditions are now specified as inputs to the AI coworker before code generation begins, not written after the fact. Functional requirements come from business stakeholders; technical requirements (performance, security, edge cases) come from engineers. Both feed into the planning and design phase before any code is produced. This approach preserves accountability: the system that generates the code is also responsible for satisfying the tests, rather than diffusing that responsibility across separate roles.

Q: What is the practical role of a human engineer on an AI-augmented team?

Human engineers function as managers of AI coworker teams. They specify what needs to be built, define the guardrails and test conditions, review generated output for durability and correctness, and handle the client-specific customization layer that requires judgment about that organization’s particular workflows and constraints. The core software design and data engineering knowledge is what makes them capable of doing that review effectively.

Q: Is vibe coding viable for production systems?

For non-critical applications where downtime is tolerable and accuracy requirements are loose, vibe coding can reach a functional state quickly. For systems operating in regulated industries, handling financial or medical data, or requiring consistent behavior across many users, it is not sufficient on its own. The generated code needs review by someone who can evaluate security posture, architectural soundness, and coverage of production edge cases — and who can be accountable to clients when something breaks.

Interfaces & User Experience

Q: Should enterprise AI systems use chat interfaces or traditional dashboards?

Both, dynamically. A chat-first interface enables natural-language access and improves adoption because users can interact without learning a new UI. But when a response warrants visualization — key metrics, comparative data, trend analysis — the system should auto-generate the appropriate dashboard for that specific query rather than serving a static pre-built view. Static dashboards answer the questions you anticipated; dynamic generation answers the ones you did not.

Q: How should UX be designed for systems that serve both humans and agents?

The interface layer needs to produce responses appropriate to the consuming audience. For human users: contextually relevant answers with dynamic visualization where useful. For agent consumers: Markdown-structured outputs that downstream models can synthesize reliably. Role-based access control applies equally to both — a registry of accessible tools and functions governs what any given caller, human or agent, is permitted to invoke.

Organizational Impact

Q: Which roles are most affected as AI takes on more knowledge work?

Engineering is the most visible impact so far, with AI systems generating the majority of code and reducing the human headcount needed for a given output level. Mid-management may be equally or more affected: AI systems that unify information across organizational silos perform the coordination function that middle management has historically provided, reducing the need to escalate requests through multiple layers to get a cross-functional answer.

Q: What happens to vertical SaaS products as AI coworkers become more capable?

The economic case for many vertical SaaS products weakens when an organization can instruct an AI coworker to build a fit-for-purpose tool tailored to its own workflows — without paying per-seat licensing fees or working around a vendor’s constraints. Organizations that are AI-first are already building internal replacements for CRM, reporting, and workflow tools rather than licensing external products. This trend is likely to accelerate as AI coworker code generation becomes more reliable.

Q: What is the most durable skill for engineers going forward?

The ability to specify what correct behavior looks like: defining test conditions, architectural requirements, security posture, and the edge cases a system must handle. This is harder to automate than code generation because it requires understanding the domain, the failure modes, and the accountability structure of the system being built. Engineers who develop strong specification skills will function effectively as the managers and reviewers of AI-generated code regardless of how capable automated generation becomes.

Podcast

Your Website Is Invisible to AI: Here’s How to Fix It — on Apple and Spotify.

The SEO Crisis No One Saw Coming

For decades, the rules of search engine optimization were clear: rank high on Google, drive traffic, convert visitors. That playbook is now being rewritten at speed.

According to Frank, a digital marketing expert and founder of LLM Scout, his agency is seeing average traffic drops of 30–35% year over year across clients — and some are experiencing drops as steep as 80%. The culprit isn’t a Google algorithm update. It’s the rise of AI.

“Google and LLMs — ChatGPT, Claude, and others — they tend now to reply directly to the user,” Frank explains. “So there is no reason for people to go and browse websites. For my clients, that’s a big problem.”

Combined with stricter GDPR enforcement in Europe, which requires explicit user consent before analytics fires, marketers are flying increasingly blind. But the story isn’t as bleak as those numbers suggest.

Is SEO Dead? Not Exactly — But It’s Transforming

Despite falling click-through rates, SEO remains foundational — because LLMs still rely on it.

Frank points to a striking statistic: roughly 18% of Google’s traffic today comes from LLM bots. When you ask ChatGPT or Claude a question they can’t answer from training data, they perform live Google searches to gather information. They break your prompt into multiple search queries — a process called “query fan-out” — then crawl the top results in real time to synthesize an answer.

“If you’re still number one in Google, the LLM will recommend you,” Frank says. “The user isn’t clicking the link, but the company is still being discovered.”

The shift, then, isn’t from SEO to something else. It’s from SEO to AEO — Answer Engine Optimization — a discipline focused on making your content readable, trustworthy, and accessible not just to humans, but to AI agents acting on their behalf.

Introducing the Third Web: Markdown Pages for AI Crawlers

One of the most practical strategies Frank recommends is creating a markdown (.md) version of your key web pages alongside the standard HTML version.

Here’s the problem markdown solves: when an LLM crawls your site in real time, it only processes a limited amount of content — approximately the first 100 kilobytes of a page. A typical HTML page is bloated with JavaScript calls, CSS, navigation menus, footers, image tags, third-party scripts, and other “noise” that has nothing to do with the actual content. By the time all that noise is cleared, the meaningful content may never make it into the AI’s context window.

Markdown strips all of that away. It retains only the essential structure — headings (H1, H2, H3), bold text, links, and tables — in a lightweight format that LLMs are deeply familiar with, since most of them were trained on markdown-rich datasets.

How to Implement Markdown Pages

The implementation is simpler than it sounds. For each important page, you:

1. Create a parallel .md file at a predictable URL (e.g., /blog/article-name.md)

2. Add a single directive in your HTML <head> tag:

<link rel="alternate" type="text/markdown" href="/blog/article-name.md">

This tells AI crawlers that a cleaner, machine-readable version of the page exists. The HTML page continues serving human visitors and Google’s traditional crawler without any changes.

Frank’s client at elsewhen.com already has this in production. You can verify it by taking any blog post URL, removing the trailing slash, and appending .md — a stripped-down, content-only version of the article appears instantly.

An Important Caution on Content Parity

Frank flags a critical risk: the markdown version must be substantively identical to the HTML version. Search engines like Google will screenshot your HTML page and compare it to what they can scrape. If the two versions differ meaningfully, you risk a cloaking penalty — the same kind applied to sites that historically hid white text on white backgrounds to game keyword rankings.

Agent-Centric Design: Rethinking How Websites Are Built

Markdown pages address how AI crawls your content. But there’s a second, equally important challenge: how AI agents interact with your pages when they’re taking actions on a user’s behalf.

When a user instructs an agent to “find me a course provider in this space,” the agent doesn’t read your HTML. It visually “sees” your page — essentially taking a screenshot and interpreting what’s there. This is where most modern websites silently fail.

Frank describes a client whose course catalog page had 80% of its content hidden behind tabs. A human visitor instinctively clicks the tabs. An AI agent sees a screenshot, identifies only what’s visually open, and reports back to the user as if the rest doesn’t exist. Entire product lines become invisible.

“We need to have this in mind when designing,” Frank explains. “If I screenshot this page and send it to someone, would they be able to understand that there is a button here, that they need to press something to watch a video?”

Design Principles for Agent Accessibility

The shift Frank advocates isn’t a complete redesign — it’s a new lens applied to existing design decisions:

Avoid hiding content behind interactive elements. Tabs, carousels, accordions, and modals are human-friendly but agent-hostile. If a piece of content matters, make it visible without requiring a click.

Use high contrast and clear visual hierarchy. Agents interpret pages visually. Background images underneath text, low-contrast buttons, and decorative styling can obscure meaning. Black text on white backgrounds, with clear structural hierarchy, performs best.

Redesign mega menus for dual audiences. Interestingly, the mega menu — once dismissed as dated UX — is making a comeback. Frank notes that well-structured mega menus give agents fast access to a site’s most important content areas without requiring deep navigation. EY Parthenon’s site is cited as an example: services and subsections laid out clearly, accessible in one visual sweep.

Carousels are a liability. A carousel only ever shows one item at a time. An agent seeing a screenshot sees one item. Everything else on those slides, for all practical purposes, does not exist.

JSON-LD and Schema Markup: Speaking the Machine’s Language

Long before AI agents arrived, SEOs were enriching web pages with structured data using the schema.org vocabulary and JSON-LD (JavaScript Object Notation for Linked Data). Now, that practice is more valuable than ever.

Schema markup allows you to define entities — companies, products, events, people, reviews, courses, FAQs — in a standardized format that machines parse directly, without hunting through prose for the information. Instead of an AI agent trying to find your phone number or office address buried somewhere in paragraph text, you declare it explicitly:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company",
  "telephone": "+1-800-000-0000",
  "address": { ... }
}

Frank explains that a modern page might carry multiple overlapping schema types: an event, a product listing, an FAQ section, a course, and company information — all described in structured JSON alongside the visual HTML, all invisible to the reader, all immediately legible to an AI.

Google Search Console now surfaces errors in your rich metadata — missing required fields, type mismatches, formatting issues — making it easier to audit and maintain this layer of your site.

LLM.txt: The AI-Native Sitemap

Traditional XML sitemaps tell crawlers what pages exist and when they were last updated. LLM.txt — a newer convention Frank describes — takes a different approach. Rather than listing URLs, it explains how a website is structured in plain language.

An LLM.txt file might say: “This is a B2B consulting firm. Service pages live under /services. New blog content appears at /blog/[slug]. All product pages follow /products/[category]/[product-name].”

It’s less a directory and more a set of orientation instructions — the kind you might give a new employee on their first day.

The adoption of LLM.txt is still uneven. Anthropic has pushed for it; OpenAI has not committed. Frank acknowledges that in practice, most LLMs appear to rely primarily on what’s on the page itself rather than reading either sitemaps or LLM.txt. But the emerging consensus among AEO practitioners is to implement it anyway — the cost is minimal and the potential upside is real.

Citations: The New Backlinks

In traditional SEO, authority was built through backlinks — other websites linking to yours. In the AI-discovery era, the equivalent is citations: your brand name appearing on other credible platforms, even without a link.

LLMs are trained on massive corpora of online text, and sites with high human-generated authority — Reddit, LinkedIn, trusted review platforms — carry disproportionate weight.

“There was a rush on getting your name on Reddit,” Frank recalls. “People found that LLMs loved Reddit and LinkedIn because they have strong spam policies and self-moderating communities. It was seen as human opinion.”

The predictable result followed: marketers flooded those platforms with AI-generated content, platforms adapted their moderation, and the SEO lift faded. But the underlying dynamic remains: authentic presence on authoritative third-party platforms signals trustworthiness to AI systems evaluating which sources to cite.

The lesson isn’t to game Reddit. It’s to build genuine presence where humans actually discuss your industry — because that’s still where AI goes to learn what’s credible.

The Bigger Shift: From Websites to APIs and MCPs

Beneath all the tactical optimizations lies a more fundamental transformation. As Frank and Krish explore in their conversation, the future of software distribution may not be websites or apps at all — it may be APIs and Model Context Protocols (MCPs).

Platforms like Claude’s Cowork already demonstrate the pattern: rather than switching between a dozen separate applications, users interact with one AI interface that connects to all their tools via connectors. Salesforce, HubSpot, Slack — their data and functionality become accessible through a single, personalized layer.

In this world, having a beautiful website matters less than having a well-documented, accessible API. The agent doesn’t visit your homepage. It calls your endpoint.

Frank’s own roadmap reflects this: “My next step is to create an MCP server so that becomes accessible to other tools. You tell the other tools: we exist, this is how you authenticate, this is what you can do. People use our services using other services seamlessly — without even knowing they’re using us.”

Krish echoes this at Snowpal: building an MCP server so AI agents across industries can consume their APIs generically, without needing to know the specific endpoints, with industry-specific sample agents demonstrating the integration model.

AI + Snowpal API: Reduce Time to Market

The Economic Undercurrent: What AI Is Doing to Jobs

No discussion of AI optimization is complete without confronting its broader consequences. Frank speaks plainly about the UK’s youth unemployment — the highest rate for under-25s in over a decade — and links it directly to AI displacing entry-level roles.

“Junior engineers, junior lawyers — that first job, second job — I think those have completely been replaced by AI,” he says. “The problem is those people are not going to climb the ladder, which means eventually there will be no mid-level, no senior. There will be a gap.”

Both Frank and Krish describe an irony shared by many in technology: the tools that increase individual productivity also compress the on-ramps through which expertise is built. Senior developers still manage and review. But without juniors learning by doing, who becomes senior?

Frank’s advice, when pressed, circles back to something almost old-fashioned: find what you genuinely love and pursue it with adaptability as your core skill. “If you have a passion for something, you will make it happen. It won’t become a job you do for money — it becomes your identity.”

How Few People Are Actually Building With AI

Perhaps the most grounding data point in the conversation comes from a graphic Krish shares — sourced, Frank believes, from Diary of a CEO — breaking down global AI adoption:

• 84% of the world population has never used AI

• 16% use a free AI chatbot

• 0.3% pay for a subscription

• 0.04% are actively building with AI

At 8.1 billion people, that 0.04% represents roughly 3.2 million builders. For anyone steeped in the AI conversation — reading newsletters, attending podcasts, refreshing LinkedIn — that number is a useful corrective. The urgency feels total because of algorithmic echo chambers. The reality is that the overwhelming majority of the world hasn’t yet clicked “sign up.”

“I’ve been living in AI anxiety,” Frank admits. “As soon as I go to LinkedIn, everything is about AI. I’m constantly bombarded. But then that graph came along and I thought — I need to breathe.”

The Mechanics of AI Crawling and Query Fan-Out

When a user submits a prompt to an LLM like ChatGPT or Claude, the model doesn’t perform a single search — it decomposes the query into multiple targeted sub-queries, a process called query fan-out. Each sub-query hits a search engine independently, returning a set of ranked URLs. The agent then crawls those pages in real time, parsing the raw HTML to extract relevant content. Because most LLMs cap their page ingestion at roughly the first 100 kilobytes, any content buried beneath heavy JavaScript bundles, third-party script calls, and navigation boilerplate may never enter the model’s context window at all. This is why rendering order in the DOM matters: content that appears early in the HTML source has a structurally higher probability of being ingested than content loaded dynamically via JavaScript after the initial parse.

Structured Data and the JSON-LD Signal Layer

Beneath every well-optimized page lies a machine-readable signal layer built on JSON-LD and the schema.org vocabulary. Unlike prose content, which requires natural language processing to extract entities and relationships, JSON-LD declares them explicitly — a product’s price, an organization’s phone number, an event’s start time — in a standardized format that search engines and AI crawlers can parse deterministically. Modern pages often carry multiple overlapping schema types simultaneously: an Organization block in the site header, a Course or Product block in the body, an FAQPage block in the footer. Each additional schema type expands the surface area of structured facts an AI can confidently extract without inference, reducing hallucination risk and increasing the likelihood that your entity is accurately represented when an LLM synthesizes an answer citing your content.

Key Takeaways for Marketers and Builders

If you’re managing a website or building a digital product in 2025, here are the actionable priorities that emerge from this conversation:

Audit your pages for agent accessibility. Take a screenshot of each important page and ask: could an AI agent understand what’s on this page and what actions are available? If the answer involves clicking tabs or swiping carousels, you have work to do.

Add markdown versions of your highest-value content pages. Use the <link rel="alternative" type="text/markdown"> directive to point crawlers to a clean, noise-free version. Keep the content identical to the HTML version.

Implement or expand JSON-LD schema markup. Every entity type your pages represent — company, product, event, FAQ, course, review — should have corresponding structured data. Audit using Google Search Console’s rich results report.

Write an LLM.txt file. Explain your site’s structure in plain language. It costs almost nothing and may provide meaningful upside as LLM adoption of the standard grows.

Build for citations, not just backlinks. Authentic presence on credible third-party platforms still matters. Focus on genuine value — useful content, honest engagement — rather than volume plays that platforms will quickly detect and discount.

Start thinking in APIs. If you’re building anything new, design it to be consumed by agents, not just browsers. An MCP server or well-documented REST API may ultimately drive more distribution than a polished homepage.

FAQ: Optimizing Your Website for AI Agents

Q: Is SEO dead now that AI answers questions directly?

No — but it’s transforming. LLMs still rely on search engines to find information. Roughly 18% of Google’s traffic today comes from AI bots performing real-time searches on behalf of users. If you rank well on Google, AI is still likely to discover and cite you. The difference is that users no longer click through to your site — the AI summarizes the answer for them. SEO remains the foundation; Answer Engine Optimization (AEO) is the layer you now need to build on top of it.

Q: What is Answer Engine Optimization (AEO)?

AEO is the practice of optimizing your website so that AI systems — ChatGPT, Claude, Gemini, and the agents they power — can find, understand, and accurately represent your content. Where traditional SEO focused on ranking signals for human searchers, AEO focuses on machine readability, structured data, agent accessibility, and authoritative citations across the web.

Q: How much traffic are websites actually losing to AI?

On average, sites are seeing traffic drops of 30–35% year over year. Some are experiencing drops as high as 80%, particularly in Europe where GDPR consent requirements have further reduced trackable traffic. The cause isn’t purely AI — privacy regulations are compounding the problem — but AI-generated answers replacing click-throughs is the dominant factor.

Q: What is a markdown page and why do I need one?

A markdown (.md) page is a stripped-down, plain-text version of your web page that contains only the essential content — headings, body text, links, and tables — with none of the HTML noise (JavaScript, CSS, navigation menus, image tags, footers). LLMs were largely trained on markdown-formatted data, so they parse it faster and more accurately. Creating a markdown version of your key pages gives AI crawlers a clean, high-signal file to ingest instead of fighting through a bloated HTML document.

Q: Will having a markdown page hurt my Google rankings?

Not if the content is identical to your HTML page. The critical rule is content parity: the markdown version must reflect the same information as the HTML version. If the two differ meaningfully, search engines may flag it as cloaking — a tactic historically used to show different content to crawlers than to users — and penalize your site. Keep them in sync and you’re safe.

Q: How do I tell AI crawlers that a markdown version of my page exists?

Add a single line to your HTML <head>:

<link rel="alternative" type="text/markdown" href="/your-page.md">

This directive signals to AI crawlers that a machine-readable alternative is available. Your HTML page continues to serve human visitors and traditional search bots without any changes.

Q: How much of my page does an AI actually read?

Most LLMs cap page ingestion at around the first 100 kilobytes of content. On a typical HTML page loaded with scripts, stylesheets, and third-party calls, the actual article content can sit well past that cutoff. A markdown page resolves this by putting only the content — nothing else — in a file that’s almost always well under that limit.

Q: What is agent-centric design?

Agent-centric design means building your website so that an AI agent — which perceives pages visually, like a screenshot — can understand what’s on the page and what actions are available, without needing to click, swipe, or hover. It’s the AI equivalent of accessibility design for humans with disabilities.

Q: What website elements are most dangerous for AI agents?

The biggest offenders are: tabbed content (agents only see what’s open), carousels (agents see one slide, everything else is invisible), content loaded by JavaScript after page render (agents may not trigger it), and buttons or CTAs that rely on animation or hover states to be understood. If a screenshot of your page wouldn’t make the content and actions obvious to a stranger, it won’t be obvious to an agent either.

Q: Do I need to completely redesign my website?

Not necessarily. The goal is to apply a new lens to existing design decisions — asking “would an agent understand this from a screenshot?” at each step. In many cases, the changes are incremental: making tabs visible by default, ensuring buttons are clearly labeled, avoiding background images underneath critical text. A full redesign is only warranted if the site’s structure is fundamentally agent-hostile.

Q: What is JSON-LD and why does it matter for AI?

JSON-LD (JavaScript Object Notation for Linked Data) is a standardized format for declaring structured facts about a page — your company name, phone number, product price, event date, FAQ answers — in a way machines can parse directly without inference. Rather than an AI trying to extract your phone number from somewhere in paragraph text, you declare it explicitly in a JSON block. This reduces hallucination risk and ensures AI accurately represents your entity.

Q: Which schema types should I prioritize?

Start with the types that match your page content: Organization for company pages, Product for product pages, Course for educational content, Event for events, FAQPage for FAQ sections, and Review or AggregateRating for review content. A single page can carry multiple schema types simultaneously. Use Google Search Console’s rich results report to identify errors and missing required fields.

Q: What is LLM.txt?

LLM.txt is a plain-language file you place at the root of your site (e.g., yoursite.com/llm.txt) that explains how your website is structured — not by listing every URL, but by describing where different types of content live. Think of it as orientation instructions for an AI: “Service pages are under /services. Blog posts follow /blog/[slug]. Product pages are at /products/[category]/[name].”

Q: Is LLM.txt widely supported yet?

Not universally. Anthropic has pushed for its adoption; OpenAI has not committed. In practice, most LLMs currently appear to rely primarily on on-page content rather than reading LLM.txt. However, implementation costs almost nothing, and adoption is expected to grow. It’s worth adding now.

Q: Should I still maintain my XML sitemap?

Yes. XML sitemaps remain important for traditional search engine crawlers and indirectly benefit AI discovery through Google rankings. LLM.txt is a complement, not a replacement — the two serve different audiences and purposes.

Q: What replaces backlinks in the AI era?

Citations — your brand name appearing on credible third-party platforms, with or without a link. LLMs are trained on vast corpora that weight authoritative sources heavily. If your company or product is mentioned genuinely and frequently on trusted platforms (industry publications, community forums, professional networks), AI systems are more likely to surface and recommend you.

Q: Is it worth trying to get mentions on Reddit or LinkedIn?

Authentic mentions on these platforms still carry value — both rank well on Google and feed into LLM training data. However, both platforms actively moderate AI-generated spam, and LLMs themselves are increasingly able to detect low-quality, synthetic content. The strategy that works is genuine participation: useful content, honest answers, real engagement. Volume plays and AI-written posts are quickly discounted.

Q: Do websites even matter if the future is AI agents?

In the short to medium term, yes — websites remain the primary surface AI agents crawl for information. But the longer-term trajectory points toward APIs and Model Context Protocols (MCPs) as the primary distribution layer. If your product or service can be consumed directly by an agent via API, you bypass the website layer entirely. Building both — an optimized web presence and an accessible API — is the safest path for the next few years.

Q: What is an MCP and why should I care?

A Model Context Protocol (MCP) is a standardized way for AI agents to authenticate with and call external services. Rather than an agent browsing your website to find information, it calls your MCP endpoint directly: “What services do you offer? What’s the pricing? Book this.” Companies that expose MCP servers become natively accessible to any AI platform that supports the protocol — without the user ever visiting a website.

Q: How urgent is all of this?

More urgent than most businesses realize. Traffic declines are already happening — 30–80% drops are live, not theoretical. At the same time, only 0.04% of the world’s population is actively building with AI right now. Early movers who optimize for AI discoverability have a significant window before the rest of the market catches up. The companies that act in the next 12–18 months will be the ones AI recommends by default.

Frank Vitetta, is the founder and CEO of Orchid Box, LLM Scout, and CodeScout. LLM Scout monitors how brands are cited and represented across major AI platforms. Krish Palaniappan is the CEO of Snowpal, an API platform helping businesses build software faster.

AI + Snowpal API: Reduce Time to Market

Sections

1. Augmentation over automation — why human-in-the-loop is a legal necessity, not timidity

2. LLM Ops in practice — how Arise, test sets, and iterative prompt tuning enforce reliability

3. Base LLMs, RAG, and differentiation — where the moat actually lives (and how it evolves)

4. The AI gateway — multi-tenancy, PII removal, prompt injection guards, and model flexibility

5. Token economics and ROI — the 3× budget overrun and how departmental accountability replaced centralised approval

6. SDLC transformation — halved time-to-merge, citizen developers, and the guardrail standardization challenge

7. The SaaS landscape — why trust and compliance posture compound into a durable moat

8. Context windows and the horizon — what becomes possible as context limits expand

Podcast

Trust the Guardrails: Building AI That Governments Can Actually Use — on Apple and Spotify.

1. Augmentation Over Automation: The Public Sector Constraint

The starting point for any AI deployment at EUNA Solutions is a deliberate philosophical choice: keep a human in the loop. This is not timidity — it is a response to the legal and regulatory realities of government procurement, grants, and budget management.

“There’s a strong bias for augmentation instead of automation... It’s about trust, explainability and transparency. We cannot roll out any agentic solution that we have not tested thoroughly.”

Stockwell’s concrete example — Euna Solutions’ AI solicitation agent — illustrates the principle sharply. The agent analyses Request for Proposal (RFP) documents and suggests categories a procurement officer may have overlooked. For a fire engine RFP, the system might prompt an official to specify hose diameter or wheel size. But it stops there deliberately.

“We cannot say to them the hose diameter needs to be X or Y, because then we kind of hold liable.”

The boundary between recommendation and prescription is not a product design preference; it is a legal firewall. Every guardrail, every observability hook, and every evaluation run exists to enforce that line in production, not just in staging.

2. LLM Ops in Practice: Building Confidence Before Go-Live

With liability stakes this high, Euna Solutions treats LLM observability as a first-class engineering discipline, not an afterthought. The team uses Arise — an LLM ops and observability platform — alongside alternatives such as LangSmith and LangFuse, to evaluate agents outside production before release.

“We have the system prompt, we have the agent, and then we run a standardised test set through Arise and we have an expected result that we want. And we have the actual output that was outputted from the LLM. And then we were able to see the difference between the two, adjust the system prompt and rerun those evaluations again to make sure we’re getting the level of accuracy that we want.”

The same observability loop runs in production. Drift in model output — inevitable as underlying models are updated by providers — is caught early and corrected by updating system or guardrail prompts before customers are affected.

The Guardrail Feedback Loop

Guardrails at Euna Solutions are product-specific rather than generic. For each feature, product managers and engineers define what the model must not output. The guardrail layer intercepts every agent response and re-prompts the model if the response violates a rule — iterating until the output is compliant before it is surfaced to the user.

“The guardrail reviews it. If it’s not [acceptable], it goes back to the agent and it keeps iterating until the response gets back. And then it’s populated in the front end for the customer to see.”

This architecture means that test coverage at the system-prompt level becomes a form of regression testing. QA engineers own the evaluation suites; software engineers own the prompts. The distinction matters because evaluation quality is ultimately a domain knowledge problem, not just a technical one.

3. Base LLMs, RAG, and the Question of Differentiation

A natural question arises: if the solicitation agent is powered by a base LLM with no proprietary fine-tuning, what stops a competitor from replicating it? Stockwell’s answer is pragmatic and instructive for anyone building in the LLM application layer.

“These large language models are trained on billions of parameters of data. So they have all those public RFPs that have been published in the past in them... The system prompt is probably the most important in this. That is a very, very long prompt, a lot of tokens where we give it examples of how we want it to output. We give it the wording that we want it to use. We give it different scenarios.”

The moat, in the near term, is prompt engineering depth, evaluation infrastructure, and the guardrail layer — not proprietary model weights. Over time, Stockwell anticipates a migration toward fine-tuned models or Retrieval-Augmented Generation (RAG) pipelines seeded with the company’s accumulated private data.

RAG as a Shared Capability

RAG is not just a customer-facing feature at Euna Solutions — it is an internal developer productivity tool. The team has built reusable RAG patterns that engineering teams can adopt by pointing their data at a managed vector store (currently AWS OpenSearch) and calling through the AI gateway.

“If you want a RAG agent, it’s a pretty easy thing to deploy, here’s the pattern. All you have to do is shift your data into this vector store, call it through the AI gateway, choose a large language model. Here’s Arise that you can use for testing. And that’s kind of enabled them.”

One illustrative internal application is developer tooling built on top of MCP (Model Context Protocol) servers, which give AI agents contextual knowledge about SharePoint, Salesforce, or role-based access control systems — reducing the friction of context-gathering in an engineering session.

4. The AI Gateway: Multi-Tenancy at the LLM Layer

Euna Solutions serves multiple government entities, each with their own data isolation requirements. The core architectural solution is a centralised AI gateway through which every LLM API call flows, regardless of which product line triggers it.

“Every single API call to a large language model goes to that AI gateway. And then we split the gateway by the different products. So we have like a procurement entry point, the grants entry point, a budget entry point broken up by the products. And we were able to see which customers are calling the model, what their token spend, what their limit is.”

Beyond multi-tenancy and billing visibility, the gateway serves as a unified enforcement point for cross-cutting concerns. Toxic language filtering, PII removal, SQL injection prevention, and prompt injection guardrails all live at this layer — applied consistently across every product without requiring each engineering team to re-implement them.

Model Flexibility and Cost Optimization

The gateway also enables provider-agnostic model selection. Engineering teams can evaluate expensive frontier models against cheaper, lightweight alternatives using the same evaluation harness and choose based on accuracy data rather than intuition.

“We can take an expensive large language model and we can take something like Gemini Flash and test it and see what the output is. And if they both give me the same accuracy, I’m going to take the cheaper one.”

In customer-facing contexts, this flexibility could eventually become a product feature — allowing government agencies to choose a model tier based on their accuracy requirements and budget, with pricing attached to that choice.

5. Token Economics and the ROI Question

Enabling Claude across the organization at Euna Solutions produced an immediate and instructive result: token spend ran to roughly three times the projected budget. The experience offers a candid case study in enterprise AI governance.

“We enabled Claude and we thought our budget would be X and it’s like three times X because of the usage... We kind of narrow it in and we say, hey, you spent $5,000 on X this month. What did you use it for? Log it in the AI innovation hub and what’s the return on investment?”

Stockwell’s response was to build an AI Innovation Hub — an internal tool where employees log their AI projects, enabling leadership to tie token spend to concrete outcomes. The shift in governance model is noteworthy: rather than centralised approval for every use of AI, departmental leaders are accountable for demonstrating ROI within their own teams.

“I should not be approving your token usage if you’re in finance or if you’re in HR... it should be the leaders in those areas understanding what their employees are using AI for and making sure that they’re using it in a way that we are getting a positive ROI from it.”

One employee, for example, completed a documentation project in four months that would have taken twelve — a result that justified elevated token consumption. The AI enablement team’s role is not cost policing but process re-engineering: helping teams understand whether an AI automation is truly the right solution, or whether the underlying process should be redesigned first.

“Instead of just, ‘should we automate this?’, it’s like, ‘can we take a step back and let’s look at the entire process to see if this is really an AI automation, is it something that Claude should be doing, is it a software engineering process?’”

6. SDLC Transformation: Speed, Quality, and the Guardrail Gap

Euna Solutions has a dedicated team focused solely on SDLC transformation through AI. The headline metric is time-to-merge-request, which has dropped by approximately half as developer adoption of AI tooling has increased.

“It’s still two weeks [sprints], but we’re able to get through a lot more in those two weeks.”

Early adopters within engineering teams have begun building their own agent-based review pipelines — ad hoc solutions to code quality and risk concerns that arise naturally as AI-generated code enters production codebases. The challenge for the AI platform team is standardizing these patterns so their benefits are available to all engineers, not just those who built them.

“As our developers start using it, they start building up their own agents within the different solutions to mitigate the risks that they’re seeing — they’ll have a review agent, they’ll have this agent. And now what we kind of have to do is figure out how do we standardise that so that all developers have access to these different things.”

Claude Code has been central to this internal transformation. Non-technical staff in HR, marketing, legal, and finance are now building their own internal applications — a dynamic that is surfacing new questions about production readiness checklists, SDLC governance for citizen-developed apps, and how to enforce coding standards outside traditional engineering pipelines.

7. The SaaS Landscape: Threats, Opportunities, and the Adoption Curve

The conversation broadened to the macro question of what AI means for SaaS companies as a category. Stockwell’s view is nuanced: the threat is real, but the response is within reach of any company willing to move quickly and invest in AI capability.

“You can go get a Replit account or Lovable and vibe code something very, very quickly. Governments move in this space pretty slowly, and there’s definitely a trust component to this. So we’ve kind of built over years all the guardrails, not just from an AI perspective, but from a data and infrastructure perspective.”

The compound moat — compliance posture, data trust, customer relationships, and now AI platform depth — is harder to replicate than any individual feature. The risk is not that AI replaces Euna Solutions outright; it is that a nimbler competitor replicates enough functionality fast enough to win new contracts.

“If you kind of have a vision — instead of pushing out five product features a year, you can maybe push out ten because you’re using AI and you’re using more and more tokens to produce things.”

Stockwell’s broader framing of the adoption curve is a useful corrective to the hype cycle. The majority of potential users have not yet meaningfully engaged with AI tooling. Teams and organizations that move quickly across that curve — in Stockwell’s words, “as quickly as possible” — are building a lead that will compound as the curve steepens.

8. Looking Ahead: Context Windows, Vibe Coding, and the Horizon

Two technical constraints define the current ceiling of AI-assisted software development in Stockwell’s view: context window size and the maturity of evaluation infrastructure. Both are moving.

“What’s stopping a company right now from taking their current software application and giving it to an AI agent and saying, ‘take this and redo X, Y, and Z with these features and deploy it’ is context. The context window is too small. It cannot take all the tokens into account of your entire codebase. But if I have to look about this — maybe a year, maybe two years from now, maybe even sooner — that’s not going to be an issue.”

The implication is that organizations building strong AI posture now are positioning themselves for a qualitatively different capability in the near term. The teams and companies that have invested in observability, guardrails, prompt engineering depth, and developer education will be able to absorb larger context windows and more autonomous agents without starting from scratch on governance.

His advice to teams navigating the current pace of change is to resist the temptation to over-engineer.

“People try and sometimes overcomplicate things when you can do a very small pilot project. It’s very easy to build an agentic pattern and it’s very easy to productionize it once you have the capabilities — your LLM ops, your guardrails. And there’s a lot of value that we can already get to our customer just by embedding a basic LLM powered by an agentic solution.”

Technologies

At Euna Solutions, every LLM API call — whether targeting Claude, Gemini Flash, or any other provider — is routed through a centralized AI gateway that enforces rate limiting, token metering, PII redaction, toxic language filtering, and prompt injection guardrails before a single token reaches a customer-facing surface. Atop that gateway sits a stack of reusable agentic patterns: RAG pipelines backed by AWS OpenSearch vector stores, Lambda functions for serverless orchestration, and MCP (Model Context Protocol) servers that give agents contextual awareness of enterprise systems including SharePoint, Salesforce, and role-based access control environments. Each pattern is observable end-to-end through Arise, an LLM ops platform analogous to LangSmith and LangFuse, which runs standardized evaluation sets against expected outputs both in pre-production and live environments — enabling the team to detect prompt drift, adjust system prompts or guardrail prompts, and rerun evals before any degradation surfaces to users. The guardrail layer itself operates as a feedback loop: agent responses are intercepted, evaluated against product-specific constraint rules, and re-submitted to the model iteratively until compliant output is produced, at which point it is passed to the front end.

On the developer productivity side, Euna Solutions has embedded Claude and Claude Code across engineering, HR, marketing, legal, and finance, producing a measurable 50% reduction in time-to-merge-request without shortening two-week sprints — the same cycles now yield significantly higher throughput. Engineers across product lines, spanning AWS, Azure, and GCP infrastructure inherited through acquisition, are building bespoke dev-side MCP servers and autonomous review agents to validate AI-generated code against production readiness checklists, effectively creating team-local SDLC guardrails that the AI platform team is now working to standardize organization-wide. Model selection is treated as an empirical rather than intuitive decision: the AI gateway enables side-by-side evaluation of frontier models against lightweight alternatives like Gemini Flash, with accuracy benchmarked against the same Arise test sets used in production monitoring, so cost optimization is grounded in observed performance deltas rather than vendor claims. Fine-tuning and expanded RAG coverage — augmenting base LLMs already trained on billions of public parameters including historical RFP corpora — remain the planned evolution path as private data assets mature and context window constraints, currently the binding limit on whole-codebase agentic refactoring, continue to expand.

Conclusion

The technical story that emerges from Andrew Stockwell’s experience at Euna Solutions is less about any single model or framework and more about infrastructure discipline. The companies and teams succeeding with AI in regulated, high-stakes environments are not doing so because they have access to better models — they are doing so because they have invested in the layers that make models trustworthy: rigorous evaluation pipelines, purpose-built guardrails, centralised observability, and a culture of measured experimentation over speculative automation.

As Stockwell put it in his closing remarks:

“Don’t look at it from a negative point of view. Look at it from a positive point of view and just have the right vision and strategy to execute on it. Anyone can do anything now. I can take anyone who’s never coded and they can vibe code an app or an idea. So there’s so many opportunities.”

The technical foundations Euna Solutions has built — an AI gateway, reusable agentic patterns, LLM observability, and a governed AI innovation hub — are a blueprint for any software organization trying to ship AI responsibly at scale. The tools are largely available. The discipline is the differentiator.

About the Guest

Andrew Stockwell is VP of AI at Euna Solutions, a cloud-based software provider for public sector organizations in the United States and Canada. His background spans actuarial economics, data science, and a Master’s degree in Computer Science. He has led AI platform, enablement, and LLM ops initiatives across multiple organizations, with a focus on responsible deployment of generative AI in regulated environments.

About the Snowpal Podcast

The Snowpal Podcast explores the intersection of technology, software architecture, and entrepreneurship. Episodes feature practitioners sharing hands-on experience building and deploying software at scale. Hosted by Krish Palaniappan, founder of Snowpal.

AI + Snowpal API: Reduce Time to Market

Podcast

AIOps: Turning Data into Action — on Apple and Spotify.

The AIOps Pipeline Diagram

Raw telemetry from across a hybrid IT estate flows into a unified data lake, where AI reasons over it to surface only what matters — routing each insight to either a human engineer or an autonomous remediation agent.

Q & A with Michael Nappi

1. What is AIOps and how does it differ from traditional IT operations?

AIOps extends traditional IT operations by applying AI/ML techniques to large volumes of telemetry data (metrics, logs, events, traces) generated across complex IT environments. While traditional IT ops relies on rule-based monitoring and manual intervention, AIOps enables automated correlation, noise reduction, anomaly detection, and actionable insights, helping teams understand system behavior and respond faster.

2. What core problem does IT operations aim to solve?

IT operations ensures that an organization’s compute, storage, and networking infrastructure runs reliably, efficiently, and continuously delivers services to the business. This includes maintaining uptime, performance, and availability while minimizing disruptions.

3. Who are the primary customers of AIOps platforms like ScienceLogic?

The primary customers are large enterprises, global 2000 organizations, government agencies (including DoD and civilian sectors), and MSPs. These customers typically operate large-scale, hybrid, and distributed IT environments requiring centralized visibility and control.

4. What role do MSPs play in this ecosystem?

MSPs manage IT infrastructure on behalf of other businesses, providing services like monitoring, incident detection, and remediation. They abstract operational complexity for their clients and are accountable for maintaining service availability and performance.

5. What value does ScienceLogic provide to MSPs and enterprises?

ScienceLogic provides a unified observability and operations platform that discovers infrastructure, aggregates telemetry, correlates signals, identifies issues, and enables both guided and automated remediation, effectively replacing multiple fragmented tools with a single system.

6. How does infrastructure discovery work in such platforms?

The platform detects all assets within an IT environment (anything with an IP address), including servers, network devices, applications, and services, using protocols like SNMP, SSH, APIs, and others. This creates a comprehensive, real-time inventory of the IT estate.

7. What are collectors and why are they used?

Collectors are lightweight Linux-based agents deployed within a customer’s environment that gather telemetry data locally and forward it to the central platform. They act as edge caches, improve resiliency, support secure communication behind firewalls, and enable operation in restricted or air-gapped environments.

8. Why not collect all data directly from the cloud without collectors?

Collectors provide architectural benefits such as reduced latency, improved reliability via store-and-forward mechanisms, compliance with security constraints (e.g., firewalls, air-gapped systems), and efficient data filtering before transmission, which is especially important in sensitive or distributed environments.

9. What types of data are collected and analyzed?

The platform ingests metrics, logs, events, and traces from infrastructure and applications. This telemetry may originate from cloud services (e.g., AWS CloudTrail), APIs, or system-level monitoring and is normalized and correlated for analysis.

10. How does the platform handle noisy or high-volume data?

It uses filtering, sampling, and intelligent ingestion strategies to avoid overwhelming the system with unnecessary data, focusing instead on meaningful signals that contribute to actionable insights.

11. Is the platform cloud-agnostic and how does it support multi-cloud environments?

Yes, it is fully cloud-agnostic, capable of monitoring workloads across AWS, Azure, GCP, on-prem systems, and virtualized environments, providing a unified “single pane of glass” view across all environments.

12. How is the platform deployed and hosted?

It can be deployed on-premises, hosted by ScienceLogic as a SaaS offering, or deployed within a customer’s or MSP’s cloud environment. The architecture is flexible to support various operational and compliance needs.

13. How does onboarding work for MSPs and their customers?

ScienceLogic provisions and configures the platform for MSPs in a SaaS environment. MSPs then onboard their customers into a multi-tenant system by deploying collectors, configuring integrations, and assigning user roles.

14. How does the platform model services instead of just infrastructure?

It maps underlying infrastructure components (servers, databases, APIs, etc.) to business services, enabling visibility into service health, performance, and risk. This allows teams to understand not just system status but business impact.

15. How does AIOps enable proactive rather than reactive operations?

By analyzing trends and patterns in telemetry data, the platform can detect early warning signs of degradation, predict potential failures, and alert teams before issues impact services, enabling proactive remediation instead of reactive firefighting.

For software developers, the current AI wave feels like a cheat code. Tools can scaffold APIs, generate documentation, write tests, and even suggest architectural decisions. What once took days can now be done in hours, sometimes minutes. On the surface, this looks like undeniable progress. But beneath that speed lies a subtle trap: doing more is not the same as creating value.

As one insight from the conversation captures, “AI adoption is easy depending on your size…you can just log into tools and get efficiencies out of it.” That accessibility is precisely the problem. When something is this easy to adopt, it becomes just as easy to misuse.

Developers are increasingly surrounded by tools that promise leverage, yet many teams end up layering AI onto workflows without questioning whether it meaningfully improves outcomes. The result is often noise disguised as productivity.

AI + Snowpal API for Faster Development

Podcast

AI Adoption Is Easy. Creating Advantage Is Not. — on Apple and Spotify.

From West Point to Waffle: The Unlikely Entrepreneur

Rob Wright didn’t set out to be an entrepreneur. He grew up in East Tennessee, graduated from West Point in 2014, and spent the better part of a decade in the military. But even before high school, his mind worked a certain way.

“When I walk into a Tropical Smoothie Cafe,” he explains, “my mind starts going — this is how many people are on the assembly line, this is how much they’re getting paid, the rent is this much, this is how many orders they have to do to break even.” That instinct to see the business inside every business eventually led him to co-found Waffle, an AI-powered platform designed to help small businesses build real competitive advantage — not just bolt on AI for the sake of it.

When Tools Start Driving the Process

A common anti-pattern emerging across engineering teams is the force-fitting of AI into workflows. Instead of starting with a problem and identifying where AI fits, teams start with the tool and look for ways to use it.

Consider something as simple as requirements gathering. Traditionally, ideas might evolve through informal notes, discussions, or quick iterations. Introducing AI into that process can seem like a natural upgrade—convert voice notes into structured documents, generate detailed specs, and standardize outputs.

But what actually happens?

The output becomes bloated. A single idea expands into pages of over-structured documentation. Signal gets buried under verbosity. What once enabled clarity now introduces friction.

This is the paradox: AI can make processes more “complete” while making them less useful.

Efficiency vs. Advantage

There is a fundamental distinction developers must internalize: efficiency is not advantage.

Efficiency means doing the same things faster. Advantage means doing things others cannot easily replicate.

Most AI usage today falls into the first category. Generating code snippets faster, automating documentation, or improving internal workflows—these are valuable, but they are not defensible. If everyone has access to the same tools, then efficiency gains are quickly commoditized.

As discussed in the conversation, “If it is not replacing something that you do or generating something that you already don’t do, it’s not giving you a competitive advantage.”

This is the crux. Developers are not competing on how fast they can write boilerplate anymore. They are competing on how effectively they can solve meaningful problems.

The FOMO Trap in Developer Ecosystems

There is also a psychological dimension at play. The developer ecosystem is heavily influenced by trends, and AI has amplified this effect. Every new tool claims to replace entire workflows. Every announcement suggests that not adopting it immediately puts you at risk.

This creates a constant sense of urgency—an artificial pressure to integrate tools before understanding their value.

But chasing tools is not the same as building systems.

The more disciplined teams are doing the opposite. They are slowing down, identifying bottlenecks, and selectively introducing AI where it creates measurable impact. They are not asking, “How do we use this tool?” but rather, “Where does this tool actually matter?”

Why Small Teams Struggle More

Interestingly, smaller teams and startups often struggle more with AI adoption than larger organizations—not because they lack capability, but because they lack structure.

Large companies assign ownership. They define metrics. They evaluate outcomes. Even if their processes are slower, they are deliberate. There is accountability tied to adoption.

Small teams, on the other hand, operate with fluid roles. The same developer might be building features, handling infrastructure, and experimenting with AI tools—all at once. In such environments, AI becomes an unstructured layer added on top of already complex systems.

The result is fragmentation. Tools get adopted inconsistently. Workflows become harder to reason about. And ironically, productivity can decline.

Building vs. Selling: The Hard Truth

Another hard lesson for developers is that building something impressive does not guarantee that anyone will pay for it.

AI has lowered the barrier to building software. More people can create products now than ever before. But this has also increased competition dramatically. The real challenge is no longer building—it is validating demand.

As highlighted in the discussion, a product can receive strong positive feedback and still fail commercially because no one is willing to pay for it.

This forces a shift in mindset. Developers must think beyond implementation and consider distribution, user behavior, and willingness to pay. AI can accelerate development, but it cannot create demand.

Letting Go of the Wrong Things

One of the most difficult skills for developers and founders alike is knowing when to stop.

There is a natural tendency to persist, especially after investing significant time and effort. But persistence without validation leads to sunk cost fallacy—continuing a path simply because of past investment.

The more effective approach is iterative validation. Build small, test quickly, and measure real-world outcomes. If the signal is weak, pivot. Not because the idea is bad, but because the market is indifferent.

AI makes iteration faster, which should make decision-making faster as well. But that only works if teams are willing to act on feedback.

Rethinking What It Means to Build Software

The role of a software developer is evolving. It is no longer just about writing code—it is about orchestrating systems, making judgment calls, and understanding where automation fits.

AI is not replacing developers. It is exposing gaps in how developers think.

Those who rely solely on tools will produce more output, but not necessarily better outcomes. Those who focus on problem clarity, system design, and user value will use AI as leverage rather than a crutch.

Closing Thoughts: Evaluate Before You Implement

Rob’s closing comment distills everything into a single sharp principle:

“Really evaluate what you’re doing. Because AI doesn’t fix what’s already broken.”

Before implementing any tool — AI or otherwise — ask whether it replaces something you do or generates something you couldn’t do before. If it does neither, you don’t have an AI problem. You might have a process problem. And the solution to a process problem is building a better process, not stacking more technology on top of broken foundations.

The businesses that will win with AI aren’t the ones who adopt the most tools. They’re the ones who adopt the right tools, in the right places, at the right time — and build the kind of trust and judgment that no tool can replicate.

Rob Wright is the co-founder of Waffle, an AI platform for small and medium businesses. You can learn more at gowaffl.com.

Modern AI-assisted development has fundamentally shifted how software is conceived, prototyped, and shipped—especially for non-traditional engineers. This article walks through a real-world case of building a data-intensive internal tool using AI-driven workflows, APIs, and modern backend/frontend patterns. The goal is to highlight not just what was built, but how developers can think in this new paradigm.

Podcast

Building Internal Tools with AI-Assisted Coding: A Developer’s Deep Dive — on Apple and Spotify.

Problem Definition: Fragmented Data and Manual Processing

Performance marketing systems—particularly platforms like Meta Ads—often produce highly fragmented datasets. The same creative may exist across multiple campaigns, ad sets, geographies, and languages. While this fragmentation is useful for media buyers, it creates a major challenge for downstream analysis.

The original workflow involved:

• Exporting CSV data from Meta Ads

• Creating pivot tables in Excel or Google Sheets

• Manually aggregating performance across duplicated creatives

• Building custom scoring models to evaluate ad performance

This process was:

• Time-consuming (monthly or quarterly execution)

• Error-prone

• Non-scalable for real-time decision-making

The core engineering problem:

Build a system that aggregates, normalizes, and visualizes ad performance data in near real-time.

System Architecture Overview

The resulting system follows a lightweight, modern architecture:

          ┌──────────────┐
          │ Meta Ads API │
          └──────┬───────┘
                 │ (Graph API calls)
                 ▼
        ┌────────────────────┐
        │ Data Fetch Layer   │  (TypeScript functions)
        └────────────────────┘
                 │
                 ▼
        ┌────────────────────┐
        │ Processing Layer   │  (Aggregation + normalization)
        └────────────────────┘
                 │
                 ▼
        ┌────────────────────┐
        │ Database (Supabase)│
        └────────────────────┘
                 │
                 ▼
        ┌────────────────────┐
        │ Frontend (Lovable) │
        │ + Chart Libraries  │
        └────────────────────┘

Backend Engineering: Data Ingestion and Constraints

1. API Integration

The system integrates directly with the Meta Ads Graph API:

• Authentication via API keys from a custom Facebook App

• Selection of specific fields (impressions, clicks, spend, etc.)

• Multiple endpoints for different data types (metrics vs creatives)

Key challenge:

• Fragmented APIs requiring multiple requests to reconstruct a single dataset

2. Rate Limiting and Data Chunking

The biggest technical bottleneck was managing API constraints:

• Too many requests → rate limiting (HTTP 429)

• Too large payloads → timeouts and memory issues

Solution:

• Implement chunked data fetching

• Balance between:

  • Request frequency

  • Payload size

• Process data incrementally instead of holding large JSON blobs in memory

This reflects a classic distributed systems tradeoff:

Throughput vs latency vs reliability

3. Data Modeling and Storage

Data was stored using Supabase (PostgreSQL-backed):

• Schema designed around:

  • Ads

  • Daily performance metrics

  • Creative groupings

Key design decision:

• Request only required fields from API (no over-fetching)

• Store normalized data ready for aggregation

This avoided:

• Excess storage overhead

• Additional transformation layers later

Data Processing: From Raw Metrics to Insights

The core transformation involved reconstructing fragmented creatives:

• Multiple line items → single logical creative

• Aggregations:

  • Total spend

  • Total impressions

  • Total clicks

Then, a custom scoring system was applied:

• Performance vs campaign baseline

• Relative efficiency metrics

• Multi-dimensional scoring

This evolved into two key axes:

• Scale potential

• Efficiency

Frontend Engineering: Visualization-Driven Development

The system is heavily frontend-driven (~70% UI focus).

1. Rapid Prototyping with AI Tools

Using an AI-native development environment:

• UI generated iteratively via prompts

• Instant preview loop enabled:

  • Fast experimentation

  • Low-cost iteration

No rigid wireframing phase—UI evolved organically.

2. Dynamic Charting and Visual Encoding

A critical breakthrough was visualizing data in a quadrant chart:

• X-axis: Efficiency

• Y-axis: Scale potential

• Each point = an ad creative

• Enhancements:

  • Images as data points (not just dots)

  • Size scaling based on spend

This enabled:

• Instant pattern recognition

• Non-technical stakeholder alignment

Example insight:

• Creative teams identified color performance differences (e.g., light vs dark blue) in seconds

3. AI-Assisted Library Selection

Instead of manually researching libraries:

• The system suggested tools like Recharts

• Automatically scaffolded design systems (e.g., Storybook-like environments)

This shifts the developer role from:

• “Library selector” → “Intent describer”

Development Methodology: AI-Augmented Thinking

A key framework used during development:

The Rumsfeld Quadrants Applied to Engineering

1. Known Knowns

   • Business logic

   • UX expectations

   • Problem definition

2. Known Unknowns

   • API constraints

   • Security considerations

   • Backend limitations

3. Unknown Knowns

   • Implicit architectural knowledge

   • Prior exposure to design patterns (e.g., DRY principles)

4. Unknown Unknowns

   • API failures

   • Edge-case bugs

   • Tool limitations

Mitigation strategies:

• Small iterative steps (Agile-like loops)

• AI-based adversarial reviews

• Limiting system complexity early

Key Engineering Principles Observed

1. Solve the Hardest Problem First

The developer prioritized:

• Data ingestion and sync reliability

  before UI work

This prevented:

• Building interfaces on unstable foundations

2. Minimize Dependencies

• Avoid external connectors

• Direct API integration

• Reduced cost and complexity

3. Incremental Scope Expansion

Start:

• Replicate existing workflow

Then:

• Expand capabilities as constraints are removed

4. Developer Role Evolution

Traditional:

• Write code

Now:

• Define intent

• Orchestrate systems

• Validate outputs

As stated in the conversation:

The hardest part is no longer writing code—it’s knowing what you want to build.

Outcomes and Impact

The system enabled:

• Real-time analysis (vs monthly)

• Unified creative performance views

• Faster feedback loops with design teams

• New types of insights previously infeasible

Most importantly:

• A non-coder shipped a production-grade internal tool using AI-assisted workflows

Final Thoughts for Developers

This case illustrates a broader shift:

• AI reduces implementation friction

• But increases importance of:

  • Systems thinking

  • Problem framing

  • Data modeling

  • UX intuition

For developers—especially those in product roles—the opportunity is massive:

• Build tools closer to the problem

• Iterate faster than traditional engineering cycles

• Unlock insights previously hidden behind manual workflows

The takeaway is simple but powerful:

The future developer is not just a coder—they are a system designer, data thinker, and problem architect.

Snowpal API on AWS Marketplace

Podcast

AI and Cybersecurity: The Escalating Intelligence War - on Apple and Spotify.

The Security Operations Center: Same Mission, Greater Complexity

At its core, the work of a Security Operations Center (SOC) has not fundamentally changed in 15 years. When an alert is triggered, analysts still ask the same foundational questions:

• Is the alert legitimate?

• Did the user interact with it?

• Has the threat spread?

• Who else might be impacted?

What has changed is scale, speed, and fragmentation. Modern enterprises operate dozens of security tools across email, endpoints, identity systems, cloud infrastructure, and web gateways. Historically, analysts manually logged into multiple consoles, ran queries, copied outputs into spreadsheets, and stitched together investigations. Integrations were brittle. APIs were inconsistent. Runbooks were manual.

Today, automation and AI-driven orchestration are finally enabling centralized triage. Alerts can be enriched with identity context, vulnerability data, and asset information in near real-time. The SOC is shifting from reactive manual labor toward intelligent, automated investigation pipelines.

The Expanding Threat Surface

Cybersecurity threats are no longer confined to phishing emails. They exist across multiple dimensions:

Social Engineering and Credential Abuse

Attackers steal usernames and passwords through phishing, then bypass multi-factor authentication using techniques like voice impersonation or MFA fatigue attacks. Even secure authentication systems can be socially engineered.

Insider Threats

Not all breaches originate externally. Malicious insiders — or compromised employees — can abuse legitimate access. Detecting insider misuse is difficult because the activity often appears operationally valid.

Software and Supply Chain Vulnerabilities

Organizations inherit vulnerabilities not only from their own code but also from open-source libraries and third-party dependencies. Compromised packages and backdoored libraries can silently propagate into thousands of systems before detection.

Edge Device Exploitation

An increasingly dangerous category involves vulnerabilities in VPN concentrators, firewalls, SSL appliances, and email gateways. These devices sit at the network perimeter and often do not allow endpoint detection agents to be installed. As a result, attackers can compromise them with minimal visibility from security teams.

The attack surface continues to widen as organizations adopt cloud services, APIs, SaaS integrations, and distributed work environments.

Reasonable vs. Unreasonable Threats

No organization can defend against every conceivable attack. Security leaders must make trade-offs between protecting against high-frequency threats and preparing for rare, highly sophisticated adversaries.

Most organizations face constant probing from automated ransomware campaigns and botnets. These are not necessarily targeted, but they can still cause catastrophic disruption. On the other end of the spectrum are nation-state-level supply chain attacks — rare but extremely damaging.

The solution is layered defense:

1. Prevent common attacks.

2. Detect what bypasses prevention.

3. Limit lateral movement.

4. Protect crown-jewel data.

5. Detect data exfiltration.

6. Recover effectively.

Security is not binary. It is probabilistic and strategic.

The Technology Shift: APIs, Automation, and AI-Driven Security

Technology has matured significantly in recent years. Security vendors now expose stable APIs that allow organizations to automate investigations across systems. What once required manual integration and brittle scripts can now be orchestrated through middleware layers and security automation platforms.

AI and large language models (LLMs) are becoming force multipliers within this ecosystem. They can:

• Correlate signals across multiple tools

• Summarize alert data in seconds

• Identify anomalous patterns across identity logs

• Detect insecure code logic

• Reduce false positives in code scanning

In software development, AI-powered static analysis tools can review vast codebases and detect vulnerabilities with far greater accuracy than previous generation scanners. These models are trained on enormous corpora of insecure code and publicly documented exploits, allowing them to recognize patterns that human reviewers may miss.

However, the same AI models that enhance defensive capabilities also accelerate vulnerability discovery. Legacy systems that have not been audited in years can now be scanned and analyzed at unprecedented speed. As a result, we may see an explosion of newly identified vulnerabilities — not because they are new, but because AI makes them easier to find.

AI as a Defensive Multiplier

In today’s SOC, AI frees analysts from low-level triage work. Many organizations generate large volumes of medium- or low-severity alerts that are often ignored due to resource constraints. AI systems can automatically enrich, investigate, and summarize these alerts, enabling human analysts to focus on deeper anomaly detection.

In effect, AI elevates human capability. A junior analyst can operate at a far higher level of effectiveness with AI augmentation. Investigations that once took hours can now be completed in minutes.

This does not eliminate the need for cybersecurity professionals. Instead, it shifts their focus toward strategic analysis, adversary modeling, and resilience planning.

AI as an Offensive Accelerator

The more alarming transformation is on the offensive side. AI dramatically reduces the cost and time required to launch sophisticated attacks.

An attacker can now:

• Scrape public data about a target

• Generate personalized phishing emails

• Simulate months-long email conversations

• Create malicious documents automatically

• Automate infrastructure deployment

Previously, such targeting required manual research and setup. Now it can be automated at scale. Social engineering becomes more believable. Reconnaissance becomes instant. Attack campaigns become scalable.

The barrier to entry has dropped. Sophisticated tactics are no longer exclusive to elite adversaries.

The Human Factor: The Most Persistent Vulnerability

Technology is only part of the equation. Seniors are increasingly targeted by AI-enhanced scams, including deepfake voice impersonation. The financial and emotional damage can be devastating.

Children and teenagers face exploitation across social platforms where billions of users make monitoring extremely difficult. Unlike financial fraud, these harms often have long-term psychological consequences.

There is no simple technical fix. Monitoring tools, education, and stronger platform governance are necessary — but the challenge is deeply societal as well as technological.

Security vs. Usability: A Global Perspective

Different regions adopt different approaches to balancing security and convenience. In some countries, banking transactions require multiple authentication steps, dual approvals, and strict timing windows. These measures may feel excessive but significantly reduce fraud liability.

In the United States, consumer protection laws and fraud absorption by financial institutions allow for simpler user experiences. The design philosophy often depends on who bears the financial risk when fraud occurs.

Security architecture is shaped as much by economics and liability frameworks as by engineering capability.

The Future: Intelligent Resilience

AI will not eliminate cybersecurity roles. It will increase the need for strategic thinkers who can interpret signals, model adversaries, and design layered defenses. Attack sophistication and volume are rising. AI empowers defenders — but it equally empowers attackers.

The future of cybersecurity lies in adaptive digital immune systems that:

• Continuously learn from telemetry

• Detect subtle anomalies

• Contain breaches quickly

• Recover without catastrophic disruption

Breaches are inevitable. Intelligent resilience is the goal.

Artificial intelligence is not a silver bullet. It is an accelerant. It amplifies strengths and weaknesses alike. The organizations that thrive will not be those that attempt to eliminate risk entirely, but those that build intelligent systems capable of surviving in an increasingly automated threat landscape.

“Right now in the world, decision is a difficult thing because there are way too many choices.”

This framing establishes the technical challenge: discovery systems today infer preference indirectly. Decisio aims to replace inference-heavy engagement modeling with explicit user intent signals.

Snowpal API on AWS Marketplace

Podcast

Rebuilding a Consumer App for Stability, Performance, and Real Traction — on Apple and Spotify.

Explicit Intent vs Algorithmic Steering

Traditional streaming platforms rely on behavioral inference. They track watch duration, replays, pauses, and abandonment patterns to model preference. These systems optimize for engagement and monetization alignment rather than authentic user satisfaction. Decisio introduces a four-direction swipe system that captures seen/like, seen/dislike, want-to-watch, and not-interested. This reduces ambiguity and increases signal quality for downstream recommendation modeling.

“We’re trying to give folks the ability to use both their intent on items and their taste on items to swipe through existing content to learn what we actually like.”

From a data architecture perspective, this changes everything. Instead of inferring preference from noisy behavior, the system stores discrete, user-declared events. That produces cleaner relational modeling opportunities and simplifies cohort segmentation.

Vibe Coding the MVP, is Phase 1!

The initial goal was speed, not perfection. Pearcey drafted the business plan with AI assistance, used Copilot to structure requirements, and leveraged AI-enabled Figma tooling for rapid UI prototyping. The first swiping implementation was functional within roughly ten days.

“I developed the existing app… I did 100% of that myself with vibe coding initially.”

Approximately 95% of the first frontend iteration was AI-generated, with about 70% of backend functions scaffolded by AI before manual cleanup. This approach dramatically reduced time-to-beta and validated demand before capital was raised.

Vibe coding served its purpose: fast market validation. But it was never intended to be the long-term engineering foundation.

Where AI Accelerated Development

AI proved extremely effective in specific domains. It handled UI scaffolding, component generation, boilerplate backend functions, business plan formatting, and marketing creative production. It even functioned as a lightweight program manager in early discussions.

“Copilot actually helped as a program manager.”

However, as complexity increased, limitations emerged. AI occasionally introduced inefficient logic, redundant code, and fragile dependencies. Performance tuning required human review. In some cases, manual refactoring reduced response times from seconds to milliseconds after identifying inefficient query paths.

Pearcey summarized the balance clearly:

“AI is a great companion. It’s not a great lead engineer yet.”

This reflects a broader truth: generative tools are strong at scaffolding but still require experienced engineering judgment for optimization and architectural consistency.

Architecture and Stack Decisions

Decisio operates primarily on Google Cloud. The operational database runs on Cloud SQL Postgres, with BigQuery handling analytics. Firebase hosts the frontend, and the backend runs on Node.js with React-based clients. The application currently ships as a Progressive Web App wrapped for both iOS and Android, enabling rapid release cycles without extended App Store approval delays.

The decision to use Postgres over NoSQL was founder-driven rather than AI-suggested. Explicit swipe data creates structured relational records involving users, titles, providers, genres, and preference states. A normalized relational schema simplifies aggregation, cohort matching, and analytics joins.

Separating transactional storage (Postgres) from analytical processing (BigQuery) creates architectural clarity early, reducing future migration complexity.

Data Integrity and the Limits of AI

One major turning point involved content attribution. AI-generated mappings between titles and streaming providers proved unreliable, producing roughly 40% false positives. Given that accurate content availability is foundational to user trust, this was unacceptable.

The team shifted to a traditional ETL pipeline approach, purchasing access to a third-party content API and implementing nightly delta syncs into BigQuery.

“I actually had to build an old school data pipeline ETL… and honestly, it’s been the best decision I made.”

This highlights a critical lesson for AI-era startups: generative systems are excellent for scaffolding, but deterministic pipelines are essential for correctness.

Testing in Early-Stage Consumer Systems

Testing remains pragmatic rather than enterprise-level. The team performs manual regression tests across multiple Android devices and iOS hardware, validating core user flows before release.

“We are really just testing… opening our phones and going through our test cases.”

Automated testing coverage is limited but acknowledged as the next maturation step. This reflects a common startup tradeoff: speed and feedback cycles outweigh full automation early on, but infrastructure hardening must follow validation.

Refactoring for Scale

Once traction was validated, the system entered a deliberate rebuild phase. Dedicated engineers began restructuring backend functions, improving environment separation, and strengthening DevOps processes.

“They’re rebuilding everything now. They’re resetting the foundation.”

This transition—from AI-heavy prototype to structured engineering rebuild—is often where startups either succeed or collapse. Addressing technical debt before user growth stresses infrastructure is essential.

AI and Team Size Compression

AI did not eliminate engineering roles, but it reduced team size requirements. Pearcey estimates the company will likely remain between 15 and 20 employees at scale—far smaller than similar startups from a decade ago.

“We’ll never probably be more than 15 to 20 employees ever because of AI.”

AI reduces boilerplate coding, accelerates marketing asset generation, and compresses DevOps overhead. However, it does not replace strategic thinking, data modeling expertise, domain understanding, or sales execution. The shift is not toward zero engineers but toward higher-leverage engineers.

Progressive Web Apps and Native Migration

The current PWA approach enables rapid iteration and immediate deployment without multi-day App Store approval cycles.

“We can… make multiple changes in a single day if we need to.”

However, the long-term roadmap includes migrating to native apps for richer push notifications and deeper system integration once the feature surface stabilizes.

Speed first. Polish later.

Building Domain-Specific Intelligence

Looking forward, Decisio aims to leverage its structured swipe dataset to create domain-specific intelligence models. The long-term vision includes building retrieval-augmented generation systems for entertainment discovery.

“I want to be the source of truth for LLMs for entertainment.”

By owning high-quality, explicit intent data, the company could build a differentiated intelligence layer that general-purpose LLMs cannot easily replicate.

Closing Reflection: Engineers with AI

Pearcey’s journey illustrates a nuanced reality. AI dramatically compresses early-stage build timelines and reduces staffing requirements. It accelerates prototypes and lowers barriers to entry. But it does not eliminate the need for architectural thinking, data modeling discipline, performance optimization, or human review.

The old startup model required large teams and long pre-launch cycles. The new model enables rapid AI-assisted validation followed by deliberate refactoring and targeted hiring.

The barrier to entry is lower. The barrier to building durable systems is not. The future is not AI replacing engineers.

It is engineers who understand architecture, data integrity, and system design—leveraging AI as a multiplier rather than a substitute.

AI agents are no longer confined to controlled demos. They are sending outreach emails, updating CRM records, retrieving internal documents through RAG systems, writing code, and orchestrating multi-step workflows. In many organizations, they are already interacting with production data and external users. What once felt experimental is now operational.

As companies deploy agents at scale, one uncomfortable truth is becoming clear: most teams have observability for software, but very few have governance for agents. That gap matters more than most people realize.

Snowpal API on AWS Marketplace

Podcast

The Governance Gap in Modern AI Systems — on Apple and Spotify.

Introduction: Agents Are Already in Production

AI agents are no longer experimental side projects. They are sending emails, updating CRM records, retrieving internal data, writing code, and triggering workflows across production systems. What started as demos has quietly become operational infrastructure.

As this shift accelerates, one gap is becoming increasingly visible: most companies have observability for software, but very few have governance for agents. That distinction is subtle but critical.

Agents Are Fundamentally Different from Traditional Software

Traditional software is largely deterministic. Given the same inputs and logic, it produces the same outputs. Once thoroughly tested, behavior is predictable within defined constraints.

AI agents behave differently. Large language models are probabilistic. Even with identical prompts and context, outputs can vary. When agents incorporate retrieval systems, tool calling, memory, and multi-step reasoning, variability compounds. Small deviations can cascade across workflows.

In a demo, this feels like flexibility. In production, it introduces operational risk.

Observability vs. Governance

Engineering teams are comfortable with observability. They monitor logs, latency, error rates, and token usage. Observability answers a retrospective question: what happened?

Governance answers a forward-looking one: should this be allowed to happen?

An agent exceeding its token budget is observable. An agent inserting sensitive data into an external API call is observable. But unless there is a policy engine capable of intervening, the system continues executing.

Observability reports. Governance enforces.

What Breaks When Agents Scale

When agents move into real workflows, failure modes change.

Costs can spike due to unexpected loops or aggressive tool usage. Sensitive data can leak through prompts in retrieval-augmented systems. Agents acting on behalf of users may overstep access boundaries if identity controls are weak. Some actions, such as sending external communications or modifying financial records, cannot be reversed.

Unlike deterministic systems, where errors are usually isolated, probabilistic systems can amplify mistakes.

The Deterministic Guardrail Principle

A practical architectural principle emerges: anything that can be deterministic should not depend on an LLM.

Budget thresholds, access control rules, scheduling logic, and validation checks should remain deterministic. LLMs should handle reasoning where variability is valuable.

Blending probabilistic reasoning with deterministic safeguards reduces risk without sacrificing capability.

Governance Across the Agent Lifecycle

Effective governance operates in three phases.

Before execution, systems verify authorization, configuration, and budget limits. During execution, policies monitor tool calls, data flows, and token usage. After execution, outputs and anomalies are reviewed, and alerts are triggered if necessary.

Governance mechanisms may warn, block, or redact depending on severity. The key is that intervention happens in real time, not after damage occurs.

From Single Agents to Agent Fleets

Most organizations do not run a single agent. They run fleets: sales agents, support agents, coding agents, finance agents. Policies must scale accordingly.

Some governance rules apply globally, such as maximum daily spend. Others are scoped to specific agent types, user groups, or operational tiers. This moves governance from purely engineering ownership to shared operational responsibility.

As agents become infrastructure, governance becomes an operational discipline.

Infrastructure Is Changing

Agent-based systems differ from traditional SaaS systems. Instead of being activated only by human interaction, agents may run continuously, trigger other agents, and execute asynchronous tasks.

This requires stronger telemetry, better traceability, event-driven architectures, and fine-grained identity management. Agents are no longer just application features; they are long-running system components.

The Enterprise Software Question

There is growing concern that AI agents will displace traditional enterprise software. A more realistic outcome is interface evolution rather than elimination.

Instead of humans navigating dashboards, agents will increasingly interact with enterprise platforms programmatically. The core systems—CRM, finance, collaboration—remain essential. What changes is how they are consumed.

The Near-Term Risk

The most significant risk today is overconfidence. Many agents that perform well in controlled environments are deployed into production as if they are hardened systems.

In hindsight, some of today’s production agents may be viewed as experiments treated as infrastructure.

Without governance, autonomy scales risk faster than it scales value.

Conclusion: Governance Is Not Optional

AI agents introduce probabilistic behavior into operational systems. They are cost amplifiers, security surfaces, and autonomous decision-makers.

Observability tells you what happened. Governance determines what is allowed to happen.

As agents move from demos to infrastructure, governance shifts from a nice-to-have feature to a foundational requirement.

The real divide is no longer who has access to AI, but who knows how to turn it into leverage. This gap—between superficial usage and deep operational transformation—is shaping the next phase of enterprise software, go-to-market execution, and workforce skills.

Sreedhar brings deep experience building and scaling B2B technology companies and offers a grounded, operator’s perspective on enterprise AI adoption. The discussion explores where AI is truly creating leverage inside organizations, why access to AI tools is no longer a competitive advantage, and how leaders, engineers, and GTM teams must rethink workflows, skills, and execution to stay ahead.

Rather than focusing on hype, the conversation dives into practical realities—what’s actually working inside enterprises today, where adoption is stalling, and what separates teams experimenting with AI from those transforming with it.

Podcast

Surface-Level AI vs. Real Enterprise Transformation — on Apple and Spotify.

The Illusion of Ubiquitous AI Adoption

Ask anyone in a technology organization whether they use AI and the answer is almost always yes. Dig one level deeper and the dominant use cases emerge quickly:

• Replacing traditional web search with conversational queries

• Summarizing documents and meeting transcripts

• Drafting emails, follow-ups, and lightweight content

• Generating first-pass marketing or sales copy

These workflows are useful, but they are table stakes. They represent efficiency gains at the edges, not structural change. For many teams, AI has become a faster Google—not a new operating model.

This creates a false sense of progress. Organizations feel modern without fundamentally changing how decisions are made, how work flows across teams, or how value is delivered to customers.

The AI “Haves” and “Have-Nots”

Across mid-market and enterprise organizations, a clear pattern is emerging:

• AI have-nots stop at generic tools and one-off prompts

• AI haves build systems, workflows, and internal capabilities around AI

The latter group doesn’t just use models—they integrate them. They connect large language models to internal knowledge bases, CRM systems, call transcripts, enablement content, and domain-specific workflows. AI becomes part of how the organization thinks, not just how it writes.

These teams are experimenting with:

• Role-specific agents trained on internal context

• AI-assisted simulations and practice environments

• Workflow automation across sales, product, and customer success

• Continuous feedback loops where AI learns from outcomes

The result isn’t just speed—it’s better judgment at scale.

Why Enterprise-Wide Transformation Is Still Slow

If AI is so powerful, why hasn’t enterprise transformation fully arrived?

The answer lies in how change actually happens inside organizations.

Bottom-up innovation is happening everywhere. Every company has a handful of tinkerers experimenting with new models, tools, and workflows. But experimentation alone doesn’t scale. Without leadership commitment, these efforts remain isolated.

Top-down mandates are equally insufficient. Declaring “we are an AI-first company” without hands-on leadership involvement often results in symbolic adoption rather than real change.

The organizations making progress combine both:

• Leaders who personally build, test, and ship with AI tools

• Teams given freedom, budget, and psychological safety to experiment

• Shared playbooks that translate experimentation into repeatable practice

Transformation accelerates when leaders stop consuming AI insights second-hand and start experiencing capability shifts directly.

AI Adoption Is a Skills Problem, Not a Tools Problem

Every employee today has access to world-class models. The differentiator is how well they collaborate with them.

This collaboration requires new skills:

• Framing problems precisely

• Iterating on outputs rather than accepting first drafts

• Encoding personal or organizational style into reusable instructions

• Knowing when not to rely on AI

There’s understandable anxiety that AI erodes foundational skills—writing, coding, reasoning. But skills don’t disappear; they change shape.

Just as calculators didn’t eliminate mathematical thinking, AI doesn’t eliminate creativity or technical depth. It shifts where judgment and originality are applied. The most effective practitioners are those who understand fundamentals deeply enough to guide AI rather than defer to it blindly.

What This Means for Technical Teams and GTM Functions

For go-to-market teams especially, the implications are profound. Selling complex products has always required context, timing, and credibility. AI now makes it possible to deliver the right knowledge to the right person at the right moment—if organizations architect for it.

This is where revenue enablement evolves into revenue activation: not just training and content, but live, contextual intelligence embedded directly into workflows. Sales reps, customer success managers, and partners are no longer left to search for information—they’re equipped dynamically, based on who they’re selling to and what matters in that moment.

The technical challenge isn’t model performance. It’s system design: integrating learning, content, and real-world signals into a coherent experience that drives outcomes.

The Road Ahead

Enterprise AI adoption has reached near-universal access, but practical differentiation now depends on how deeply models are integrated into real workflows. Most teams remain stuck at surface-level usage—search replacement, summarization, and copy generation—while a smaller subset embeds AI into systems of record such as CRM, enablement platforms, and internal knowledge graphs. These teams treat AI as infrastructure rather than a utility, designing feedback loops where model outputs are evaluated against outcomes (conversion rates, deal velocity, onboarding time) and continuously refined. The technical challenge is no longer model capability, but orchestration: connecting context, data freshness, permissions, and human judgment into repeatable, production-grade workflows.

AI adoption is irreversible. The open question isn’t whether roles will change—but how quickly individuals and organizations adapt.

Over the next few years:

• Teams that treat AI as a side tool will fall behind

• Roles will compress, but impact per individual will increase

• Experimentation will become a baseline expectation, not a differentiator

The safest position is not skepticism or blind optimism—it’s active participation. Build with the tools. Break things. Learn where AI helps and where it doesn’t. The gap between AI haves and have-nots is widening, and it’s being defined by action, not access.

Most consumer software still follows a familiar script: download an app, learn a new interface, log in once a year, forget your password, repeat. But a new wave of AI-native products is quietly challenging that assumption—not by adding more features, but by removing the interface altogether.

In a recent podcast conversation, one founder outlined a radically simple idea: if AI agents are meant to do work for people, why are we still forcing users to do the work through apps?

That question reshapes everything—from UX decisions to team structure, infrastructure, and even how companies hire.

Podcast

Stop Building Apps. Start Building Agents — on Apple and Spotify.

The Real Problem Isn’t Filing Taxes—It’s Friction

For most consumers, taxes aren’t complicated because the rules are impossible to understand. They’re complicated because the experience is fragmented, slow, and expensive.

Millions of people don’t want to file taxes themselves, yet the traditional alternatives come with tradeoffs:

• Weeks of waiting for responses

• High preparation costs

• Little to no proactive guidance

Worse, the accounting industry itself is shrinking. A majority of tax preparers are nearing retirement, and fewer people are entering the profession. The result is predictable: higher prices, slower service, and burnout on both sides.

Rather than building a better form or dashboard, this new approach reframes the experience entirely—treating tax preparation like an ongoing relationship instead of an annual event .

Why the Interface Starts With Email, Not an App

One of the most counterintuitive decisions discussed was choosing email, text, and phone calls as the primary interface—before web or mobile apps.

The reasoning is deceptively simple:

• People already know how to email their accountant

• Learning a new UX pattern is friction

• Taxes aren’t a daily activity that justify an app

If users only interact three or four times a year, asking them to download, remember, and re-learn an app each time is unnecessary overhead. Forgotten passwords alone account for a huge percentage of customer support requests across consumer software.

Instead, the system behaves like a human accountant would: you email a question, you get an answer. Documents can be uploaded securely through the web when needed, but the default interaction feels familiar and human.

The web interface still exists—but as a lightweight companion, not the center of gravity.

Designing for Agents, Not Users

The deeper insight is philosophical: traditional software assumes the user is doing the work. Agentic systems assume the agent is.

That changes everything.

If an AI agent is responsible for preparing returns, tracking status, flagging issues, and checking in quarterly, the UI doesn’t need to be a control panel. It needs to be a conversation log.

Threads replace dashboards. Decisions replace workflows. Visuals appear only when text isn’t enough—like showing the status of a return as a simple progress line instead of another email explanation.

This isn’t anti-UI. It’s UI minimalism driven by first principles, not aesthetics.

The Hidden Product Challenge: When Simplicity Grows Complex

There’s a tension in this model that’s openly acknowledged.

As conversations grow—dozens of threads, years of decisions, repeated questions—the system risks becoming exactly what it tried to avoid: a full-blown app.

The solution isn’t more screens. It’s better abstraction.

Instead of forcing users to search past conversations, the next step is summarization: decision logs, conclusions already reached, actions already taken. The goal is to prevent users from asking the same question twice—not by hiding information, but by surfacing it at the right moment.

That balance—between conversational freedom and structural clarity—is one of the hardest unsolved problems in agent-driven products.

How AI Changes Team Structure, Not Just Code

The architectural shift doesn’t stop at UX. It reshapes the company itself.

Instead of large teams divided by frontend, backend, and QA, the model now favors:

• Fewer, highly capable engineers

• Heavy use of AI coding agents

• Minimal standalone QA roles

• Fewer product managers supporting more engineers

Prototypes are often “vibe-coded” directly by engineers or product leaders. Long PRDs are disappearing, replaced by working software and fast iteration. Code reviews, testing, and even pull request approvals increasingly involve agents—with humans supervising instead of executing every step.

In some cases, more than half of production code is AI-generated.

The bottleneck is no longer typing speed—it’s judgment.

Picking Infrastructure Like a Commodity

Even infrastructure choices reflect this pragmatism. Cloud providers, once deeply strategic decisions, are increasingly treated as interchangeable. The priority is flexibility, cost efficiency, and access to the best AI tools at any given moment.

Different models serve different purposes:

• Some are better for reasoning

• Others for communication

• Others for cost-efficient background tasks

The stack adapts continuously, rather than locking into a single provider philosophy.

A Quiet Shift With Big Implications

What’s striking about this approach is how unflashy it is.

No new buzzwords. No radical UI experiments. No insistence that users change how they behave.

Instead, it asks a more uncomfortable question:

If AI can act like a capable teammate, why are we still designing software like it can’t?

The answer may redefine not just consumer products, but how software companies are built—from interfaces to org charts to the meaning of “doing the work”.

Technical Summary

Agent-native software shifts the core abstraction from user-driven workflows to autonomous task execution. Instead of designing screens that guide humans through step-by-step processes, systems are built around long-lived agents that own objectives, maintain state, and operate asynchronously. Interaction becomes event-driven—via email, chat, or APIs—while threads, memory, and decision logs replace dashboards and forms. Human involvement moves upstream to intent setting and downstream to supervision, exception handling, and final approval.

This architectural shift cascades through the stack. UX becomes a coordination layer rather than a control surface, frontends shrink in importance, and backends prioritize orchestration, evaluation, and auditability. Teams optimize for judgment over implementation, using AI to generate, test, and iterate on code continuously. Product velocity is no longer gated by interface complexity but by how well agents are constrained, observed, and corrected—making reliability, traceability, and alignment first-class engineering concerns.

Federico discusses the evolving landscape of software development, particularly the impact of AI and wipe coding. He shares insights on how non-developers can leverage AI tools, the importance of agency in hiring, and the changing dynamics of development teams. He also touches on the challenges in the FinTech space, the significance of compliance, and the future of programming languages. The discussion highlights the need for adaptability and creativity in the tech industry, as well as cultural insights from Argentina.

What emerged wasn’t hype or fear, but a more nuanced reality: AI isn’t replacing developers—it’s redefining leverage.

Podcast

Why “Vibe Coding” Actually Works - on Apple and Spotify.

What “Vibe Coding” Really Means

“Vibe coding” has become a loaded phrase. To some, it’s a shortcut. To others, it’s an insult. Federico reframes it as a spectrum, not a binary. At one end, developers use AI as a productivity boost—autocomplete, refactors, documentation. At the other, non-developers rely almost entirely on AI to translate ideas into working software.

The key insight? Vibe coding isn’t about avoiding code. It’s about not micromanaging it.

Instead of obsessing over every line, builders focus on intent, structure, and outcomes—letting AI handle the repetitive parts. This doesn’t lower standards; it shifts attention to higher-impact decisions.

Non-Developers Are Shipping Real Software

One of the most striking shifts is who gets to build. Product managers, designers, and founders—people who deeply understand user problems but don’t write code daily—are now creating real prototypes and even production features.

At Crossmint, designers have shipped UI changes directly to production using AI tools. Internal hackathon projects built by non-engineers have turned into real marketing campaigns. These aren’t toy demos—they’re business-relevant outputs.

The common thread isn’t technical skill. It’s clarity of vision. People who know what they want to build—and can describe it precisely—get the most value from AI-assisted development.

Why Developers Still Matter (A Lot)

Despite all this progress, Federico is clear: developers aren’t going anywhere.

AI excels at pattern matching, repetition, and translation. What it doesn’t do well—at least not yet—is judgment. Knowing when a change is risky, when consistency matters more than correctness, or when a “better” industry standard shouldn’t be applied retroactively—those are human calls.

In practice, AI behaves a lot like a junior developer with infinite stamina. It can produce impressive output, but it still needs direction, boundaries, and review. That’s why strong technical leadership matters more, not less.

The Myth of “AI Took the Jobs”

Layoffs at big tech companies have fueled anxiety that AI is eliminating roles. Federico pushes back on that narrative. Productivity gains don’t automatically mean fewer jobs—they often mean different jobs.

Right now, many developers are still learning how to use these tools effectively. Context switching, experimentation, and onboarding new AI workflows take time. The output may be higher, but efficiency isn’t linear yet.

More importantly, most layoffs reflect over-hiring cycles, economic uncertainty, and organizational recalibration—not AI replacing humans outright.

How Team Structures Are Shifting

What is changing is how teams are composed.

Clear lines between frontend, backend, DevOps, and even design are blurring. Developers touch more of the stack. Designers prototype with code. Testers focus less on manual checks and more on automation and system-level thinking.

The most valuable people now are “Swiss-army-knife” builders—those with strong fundamentals, high adaptability, and the agency to explore solutions independently.

You Still Can’t Vibe Code a Bank

There’s a hard boundary AI can’t cross: regulation.

In fintech especially, compliance, licensing, and legal frameworks are non-negotiable. You can spin up a wallet demo in minutes, but you can’t prompt your way past KYC laws, custody rules, or cross-border financial regulations.

AI accelerates implementation—not responsibility. Serious products still require domain expertise, legal oversight, and institutional trust.

Technologies

Federico repeatedly emphasizes that “vibe coding is a spectrum,” pushing back on the idea that AI usage is either all-or-nothing. In practice, he explains how tools like Cursor and Claude Code function inside real repositories by learning and reusing existing patterns: “AI will easily pick up on the patterns that were used in the codebase, even if they are not really great.” He explicitly compares AI-assisted contributors to junior engineers, stating, “I consider new kind of vibe coders as junior developers,” highlighting why human review, scoped permissions, and pull-request workflows remain essential. In this model, AI-generated changes still flow through standard processes such as PR reviews and CI validation in systems like GitHub or GitLab, reinforcing that AI augments—not replaces—engineering discipline.

The transcript also establishes a hard technical and operational boundary around regulated systems, especially fintech. While AI can rapidly assemble wallet integrations, SDK usage, and payment flows, Federico is blunt about its limits: “You cannot vibe-code a bank.” He explains that although cloud infrastructure on platforms like AWS and containerized deployments with Kubernetes make implementation easier than ever, regulatory context cannot be inferred from code alone. Custodial models, KYC/AML enforcement, licensing requirements, and jurisdictional constraints must be explicitly defined by humans, because “business requirements and regulations are very far away from vibe coding.” In this framing, AI accelerates execution, but accountability, compliance, and risk ownership remain fundamentally human responsibilities.

The Real Skill That Matters

If there’s one trait Federico looks for above all else, it’s agency.

Not a specific language. Not mastery of a framework. Agency—the ability to take a problem, explore options, leverage tools intelligently, and move forward without waiting for perfect instructions.

In an AI-augmented world, that mindset is the real differentiator.

Krish and Alex delve into various themes surrounding the future of work, the evolution of software development skills, the impact of AI on job markets, and the role of education in the modern workforce. They discuss the changing landscape of tech innovation globally, the implications of outsourcing, and the skepticism surrounding AI and data centers. The conversation also touches on market trends, economic concerns, and personal insights into the future aspirations of the speakers.

Introduction

Software development is undergoing a structural shift. The change is not that code is being generated instead of written—that transition already happened. The deeper change is that software systems are increasingly built, modified, and maintained by autonomous agents operating inside constraints defined by humans. Developers are moving from being primary code authors to becoming system designers, auditors, and orchestrators.

Podcast

From Code Authoring to System Steering: Software Development in the Age of Autonomous Agents — on Apple and Spotify.

Autonomous Code Is Not “Better Autocomplete”

Modern code agents are not simply faster IDE assistants. They operate across repositories, execute tests, inspect logs, browse documentation, and iteratively refine solutions. The important distinction is that they act, not just suggest.

An autonomous coding agent typically:

• Reads and reasons across multiple files and services

• Generates and modifies code in batches, not lines

• Executes tests or scripts to validate assumptions

• Revises its output based on failures or telemetry

• Documents its own decisions post-hoc

This changes the unit of work. Developers are no longer optimizing keystrokes; they are optimizing feedback loops.

The New Center of Gravity: Constraints and Verification

As agents become capable of producing large volumes of code quickly, the bottleneck moves upstream. The hardest problems are no longer “how do I implement this?” but:

• What must never happen in this system?

• How do we detect silent failures?

• What invariants must always hold?

• What signals prove correctness beyond compilation?

In practice, this means constraints matter more than specifications. A list of desired features is weak input for an agent. A set of invariants, failure conditions, security boundaries, and performance budgets is strong input.

Well-designed agent workflows typically begin with:

• Explicit system constraints

• Clear definitions of success and failure

• Executable tests or checks

• Observability hooks from day one

If these are missing, agents will still generate code—but it will drift, hallucinate integrations, or pass superficial checks while violating core assumptions.

Testing Becomes the Primary Interface

In traditional workflows, tests validate human-written code. In agent-driven workflows, tests guide code generation itself.

Agents perform best when:

• Tests exist before or alongside code generation

• End-to-end checks exist, not just unit tests

• UI and API behavior can be verified automatically

• Logs and metrics are treated as first-class outputs

Tools like browser automation, API contract tests, and property-based testing are no longer “nice to have.” They are the control surfaces that keep autonomous systems aligned.

Without strong test scaffolding, agents behave like fast interns with infinite confidence and no intuition for danger.

Human Value Shifts to Judgment and Structure

What developers uniquely contribute is not syntax knowledge. Agents are already language-agnostic at a practical level. Human value concentrates in areas where judgment, context, and trade-offs dominate.

This includes:

• Decomposing ambiguous problems into solvable components

• Identifying hidden risks and edge cases

• Choosing architectural boundaries that survive scale

• Deciding what not to build

• Auditing agent decisions and correcting course

Developers who thrive are those who can look at an agent’s output and immediately ask: what assumption is this making that might be wrong?

That ability comes from experience, not tooling.

Git Discipline Becomes a Force Multiplier

When multiple agents generate parallel changes, version control hygiene becomes critical infrastructure.

High-functioning teams emphasize:

• Small, isolated changesets

• Aggressive branching and rebasing discipline

• Frequent rollbacks without fear

• Clear commit intent and history

• Machine-generated documentation attached to changes

Poor Git hygiene no longer costs hours—it can cost days of disentangling automated changes. In an agent-driven environment, organizational entropy compounds faster.

Documentation Is No Longer Optional

Because agents can generate documentation as easily as code, failing to document is no longer a time trade-off—it is a coordination failure.

Modern workflows treat documentation as:

• A synchronization mechanism for humans and agents

• A memory layer for future automation

• A constraint surface for future changes

If a system is not documented, agents will invent explanations. Humans will misinterpret intent. Both outcomes are expensive.

Team Size Shrinks, Responsibility Expands

One of the paradoxes of autonomous development is that fewer people can now do more—but the remaining people carry more responsibility.

Teams shrink not because engineering is less important, but because:

• Execution is cheaper

• Validation is the new bottleneck

• Mistakes propagate faster

• Oversight matters more than output

This favors engineers who can operate across domains: backend, frontend, infra, testing, and product reasoning. Narrow specialization without system awareness becomes fragile.

The Future Developer Is a Systems Operator

The emerging role looks less like a traditional coder and more like a systems operator for software intelligence.

That role involves:

• Designing constraint-driven workflows

• Supervising fleets of agents

• Auditing decisions and outcomes

• Rapidly iterating on system structure

• Closing loops quickly and moving on

The metric of success is no longer lines of code or features shipped. It is cases closed per unit time without regressions.

(ChatGPT-Generated) Snippets for Golang Developers

Developer Section: Constraint-Driven Agent Workflow in Go (Copy/Paste Snippets)

If you’re building with Go, the fastest way to make agents productive and safe is to treat tests + constraints + CI as the control system. Agents can generate code quickly, but without hard verification loops they’ll drift. Strong test harnesses and auditable changes are the “steering wheel.”

1) Put constraints in the repo (agents must read this first)

# docs/constraints.md

## Non-negotiables
- No breaking API changes without version bump + migration notes.
- All handlers must enforce: authn/authz + request validation.
- Every write endpoint must be idempotent (retries happen).
- P95 latency budget: /v1/search <= 150ms staging, 250ms prod.
- No goroutine leaks in request path.

## Definition of done
- Unit tests updated/added
- At least one integration or contract test updated/added
- Structured logs on error paths
- Docs updated (architecture/runbook)

In your agent/system prompt (Cursor/Claude Code/etc.):

Read docs/constraints.md before edits.
Do not mark work complete unless `make test` and `make lint` pass.
If uncertain, add a test to lock in the assumption.

2) A Go HTTP handler with explicit dependencies (testable + agent-friendly)

// internal/http/handlers/search.go
package handlers

import (
	"encoding/json"
	"net/http"
	"time"
)

type SearchService interface {
	Search(r *http.Request, q string) ([]any, error)
}

type Logger interface {
	Error(msg string, kv ...any)
	Info(msg string, kv ...any)
}

type SearchHandler struct {
	Svc SearchService
	Log Logger
}

func (h SearchHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	start := time.Now()

	q := r.URL.Query().Get("q")
	if q == "" {
		http.Error(w, "missing q", http.StatusBadRequest)
		return
	}

	results, err := h.Svc.Search(r, q)
	if err != nil {
		h.Log.Error("search_failed", "err", err, "q", q)
		http.Error(w, "search failed", http.StatusInternalServerError)
		return
	}

	w.Header().Set("Content-Type", "application/json")
	_ = json.NewEncoder(w).Encode(map[string]any{
		"q":       q,
		"results": results,
		"tookMs":  time.Since(start).Milliseconds(),
	})
}

This style (interfaces + constructor-friendly structs) is ideal when agents are making changes because it’s easy to validate behavior without spinning the whole app.

3) Unit tests with httptest (fast proof loop)

// internal/http/handlers/search_test.go
package handlers

import (
	"errors"
	"net/http"
	"net/http/httptest"
	"testing"
)

type fakeSvc struct {
	res []any
	err error
}

func (f fakeSvc) Search(r *http.Request, q string) ([]any, error) {
	if f.err != nil {
		return nil, f.err
	}
	return f.res, nil
}

type nopLog struct{}

func (nopLog) Error(string, ...any) {}
func (nopLog) Info(string, ...any)  {}

func TestSearchHandler_MissingQuery(t *testing.T) {
	h := SearchHandler{Svc: fakeSvc{}, Log: nopLog{}}

	req := httptest.NewRequest(http.MethodGet, "/v1/search", nil)
	rr := httptest.NewRecorder()

	h.ServeHTTP(rr, req)

	if rr.Code != http.StatusBadRequest {
		t.Fatalf("expected 400, got %d", rr.Code)
	}
}

func TestSearchHandler_ServiceError(t *testing.T) {
	h := SearchHandler{Svc: fakeSvc{err: errors.New("boom")}, Log: nopLog{}}

	req := httptest.NewRequest(http.MethodGet, "/v1/search?q=go", nil)
	rr := httptest.NewRecorder()

	h.ServeHTTP(rr, req)

	if rr.Code != http.StatusInternalServerError {
		t.Fatalf("expected 500, got %d", rr.Code)
	}
}

func TestSearchHandler_Success(t *testing.T) {
	h := SearchHandler{
		Svc: fakeSvc{res: []any{"a", "b"}},
		Log: nopLog{},
	}

	req := httptest.NewRequest(http.MethodGet, "/v1/search?q=go", nil)
	rr := httptest.NewRecorder()

	h.ServeHTTP(rr, req)

	if rr.Code != http.StatusOK {
		t.Fatalf("expected 200, got %d", rr.Code)
	}
	if ct := rr.Header().Get("Content-Type"); ct != "application/json" {
		t.Fatalf("expected json, got %q", ct)
	}
}

4) Contract tests that prevent “silent breaking changes”

Lock your response schema by asserting fields and types. This catches agent-generated “creative” refactors.

// tests/contracts/search_contract_test.go
package contracts

import (
	"encoding/json"
	"net/http"
	"net/http/httptest"
	"testing"

	"yourapp/internal/http/handlers"
)

type fakeSvc struct{}

func (fakeSvc) Search(r *http.Request, q string) ([]any, error) { return []any{}, nil }

type nopLog struct{}

func (nopLog) Error(string, ...any) {}
func (nopLog) Info(string, ...any)  {}

func TestSearchResponseContract(t *testing.T) {
	h := handlers.SearchHandler{Svc: fakeSvc{}, Log: nopLog{}}

	req := httptest.NewRequest(http.MethodGet, "/v1/search?q=go", nil)
	rr := httptest.NewRecorder()

	h.ServeHTTP(rr, req)
	if rr.Code != 200 {
		t.Fatalf("expected 200 got %d", rr.Code)
	}

	var body map[string]any
	if err := json.Unmarshal(rr.Body.Bytes(), &body); err != nil {
		t.Fatalf("invalid json: %v", err)
	}

	// Required keys (expand as needed)
	for _, k := range []string{"q", "results", "tookMs"} {
		if _, ok := body[k]; !ok {
			t.Fatalf("missing required key %q", k)
		}
	}

	// Type checks
	if _, ok := body["q"].(string); !ok {
		t.Fatalf("q must be string")
	}
	if _, ok := body["results"].([]any); !ok {
		t.Fatalf("results must be array")
	}
	if _, ok := body["tookMs"].(float64); !ok { // JSON numbers -> float64 in map decode
		t.Fatalf("tookMs must be number")
	}
}

5) “Agent-proof” lint + test loop via

Makefile

.PHONY: test lint fmt ci

test:
	go test ./... -race -count=1

lint:
	golangci-lint run

fmt:
	gofmt -w .

ci: fmt lint test

Developers run:

make ci

Agents run the same command. If it fails, they don’t “argue”—they iterate.

6) Minimal GitHub Actions CI for Go + golangci-lint

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  go:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-go@v5
        with:
          go-version: "1.22"

      - name: Install golangci-lint
        uses: golangci/golangci-lint-action@v6
        with:
          version: v1.59.1
          args: --timeout=5m

      - name: Test
        run: |
          go test ./... -race -count=1

7) Parallel agent work without collisions:

git worktree

git worktree add ../wt-fix -b fix/search-timeout
git worktree add ../wt-feat -b feat/new-ranking

# Run separate agents in each directory safely

This prevents two agents from stomping the same working directory, which is the fastest way to create unreviewable diffs.

Closing Thoughts

Autonomous code does not eliminate the need for developers. It eliminates the need for developers who only write code.

The engineers who remain indispensable are those who understand systems deeply enough to steer automation rather than compete with it. In that sense, software development is becoming less about typing and more about thinking—under pressure, at scale, and with leverage.

That is not the end of the profession. It is a compression of it toward its most valuable core.

Introduction

Artificial intelligence is reshaping the technology landscape at a pace few anticipated. While much of the public conversation focuses on breakthrough models and consumer-facing tools, a quieter but more consequential battle is unfolding underneath: access to compute.

Hyperscalers like Meta, Google, Microsoft, and Amazon are spending tens of billions of dollars on AI infrastructure, locking up the most advanced chips and data center capacity. This raises a critical question for everyone else: how can startups and mid-sized companies compete when the raw materials of AI are increasingly out of reach?

This article explores that question through insights shared by serial entrepreneur Rick Bentley, drawing on real-world examples of alternative compute strategies, hardware choices, and organizational shifts.

Podcast

AI’s Hidden Bottleneck: Compute, Capital, and Control — on Apple and Spotify.

1. The Explosion of AI Compute Costs

AI is fundamentally compute-intensive. Both training models and running inference at scale require enormous processing power.

Today, the most advanced AI workloads rely on NVIDIA GPUs such as the H200 or B200, which can cost upwards of $40,000 per card—if you can even get one. Hyperscalers place massive bulk orders, often consuming nearly all available supply. For smaller players, this creates a “compute desert,” where access is limited and prices are dictated by cloud providers .

As a result, companies that rely entirely on public cloud GPU instances face mounting operational costs, often paying many times the hardware’s original value over the life of a rental.

2. Why Cloud Alone Is No Longer Enough

Public cloud platforms were built to make infrastructure easier—but not cheaper. Their business model depends on margin, and AI workloads are now among the most profitable offerings.

For companies attempting to compete with hyperscalers while running on hyperscaler infrastructure, the math rarely works. Margins compress, pricing power disappears, and innovation slows. At sufficient scale, continuing to rent compute becomes a strategic liability rather than a convenience.

This is why many large software companies—Salesforce, Adobe, ServiceNow—have already begun investing heavily in their own data centers, even though infrastructure is not their core business.

3. GPUs vs ASICs: Understanding the Hardware Tradeoffs

Not all chips are created equal.

• GPUs (Graphics Processing Units)

  GPUs excel at massively parallel workloads and remain the dominant choice for AI training and inference. NVIDIA’s success stems from making GPUs programmable for general-purpose compute, not just graphics.

• ASICs (Application-Specific Integrated Circuits)

  ASICs are custom-built for narrow tasks. They dominate crypto mining but are far less flexible. In AI, especially with large language models, heavy memory (VRAM) requirements make ASICs less compelling.

Large players like Google have built Tensor Processing Units (TPUs), but designing and manufacturing custom chips requires billions in capital and years of iteration—placing ASICs firmly out of reach for most companies .

4. A Practical Alternative: Building “Off-the-Grid” Compute

One of the most compelling insights from the conversation is that you don’t need hyperscaler-grade hardware to do serious AI work.

Instead of $40,000 data-center GPUs, many AI workloads perform exceptionally well on consumer-grade NVIDIA cards (such as RTX-series GPUs) that cost a fraction of the price. These cards often have:

• More raw compute cores

• Less VRAM (which is acceptable for non-LLM workloads)

• Far better price-to-performance ratios

When paired with strategic data center locations—areas with cheap electricity, cool climates, and lower real estate costs—the total cost of compute can drop by up to 90% compared to cloud pricing .

The key insight:

Data centers are just machines turning electricity into heat. If you control power, cooling, and hardware choices, you control your costs.

5. Vertical Integration as a Competitive Advantage

Historically, software companies avoided infrastructure ownership. Today, that mindset is changing.

Owning compute:

• Protects margins

• Preserves competitive intelligence

• Enables experimentation without runaway cloud bills

While outsourcing infrastructure reduces upfront capital expenditure, it almost always increases long-term operational costs. The companies that win in AI will increasingly be those that vertically integrate compute as a core competency, even if reluctantly at first.

6. AI’s Broader Impact on Jobs and Companies

AI disruption is not landing where many expected. Instead of blue-collar labor, white-collar professions—software development, law, medicine, consulting—are being reshaped first.

AI already:

• Drafts legal agreements

• Assists medical diagnostics

• Generates production-grade code

For software teams, AI is no longer optional. If a company builds software the same way it did two years ago, it is likely already behind. The upside, however, is enormous: small teams can now build what once required dozens of engineers.

This mirrors past industrial revolutions—fewer workers per unit of output, but dramatically more output overall.

7. Education, Skills, and the Return of the Trades

The AI era is also forcing a re-evaluation of education paths.

• Traditional college degrees remain valuable—but only when aligned with real economic demand.

• Many vocational and technical trades (electricians, technicians, infrastructure specialists) are becoming more valuable, not less.

• If a job exists entirely “on the other side of a screen,” it is far more likely to be automated.

Ironically, the physical work of maintaining AI infrastructure may prove more resilient than many white-collar roles.

Conclusion: Competing in the Age of AI Compute Scarcity

The AI revolution is not just about smarter models—it’s about who controls the infrastructure beneath them.

For startups and mid-sized companies, the path forward is not to outspend hyperscalers, but to outthink them:

• Use the right hardware, not the most expensive

• Build compute where power and cooling are cheap

• Treat infrastructure as strategy, not overhead

• Embrace AI as a force multiplier, not a threat

Disruption is uncomfortable—but it is also where the next generation of winners is being forged .

Krish & Nir dive deep into the transformative role of artificial intelligence in software development life cycles. Nir shares his unique insights on how AI is reshaping code security and the essential steps developers must take to mitigate risks. The discussion also touches on the balance between feature development and security, the role of AI in generating code, and the evolving landscape of development teams.

Podcast

Building Secure Software in an AI-First Development World - on Apple and Spotify.

Understanding the Landscape of Code Vulnerabilities

In today’s software development environment, vulnerabilities can emerge from various sources, including outdated libraries and complex dependency trees. Nir highlights the significance of understanding not just the vulnerabilities themselves but their exploitability context. For example, he discusses well-known vulnerabilities such as Log4j and recent software supply chain attacks, emphasizing that recognizing a vulnerability is only the first step. Developers must assess whether the vulnerable code is actually used in their application, which is termed “reachability analysis.”

The Importance of Reachability Analysis

Nir explains that reachability analysis allows developers to determine whether a vulnerable function is actively utilized in the source code. This critical step helps prioritize which vulnerabilities to address first, as not all vulnerabilities pose the same level of risk. For instance, a developer might find that an outdated package has several vulnerabilities, but through reachability analysis, they can pinpoint that only a fraction of those vulnerabilities are relevant to their application. This targeted approach not only saves time but also enhances the overall security posture of the application.

Building a Robust Dependency Tree

One of the biggest challenges developers face is managing the intricate web of dependencies that modern applications rely on. Nir discusses how Arnica’s platform helps by rebuilding the entire dependency tree of a project, identifying direct and transitive dependencies, and assessing the impact of potential upgrades. This level of scrutiny is essential, especially when considering that upgrading a package can lead to breaking changes across the codebase. By providing a clear view of these dependencies, developers can make informed decisions about upgrades and patches.

Leveraging AI for Enhanced Security

As Nir points out, the integration of AI in security processes is becoming increasingly important. AI can analyze changelogs, code diffs, and even predict potential breaking changes. However, he acknowledges that while AI can assist in these areas, it is not foolproof. Developers must still exercise caution and conduct thorough assessments before implementing changes, as the complexity of dependency trees can lead to unforeseen issues.

Balancing Feature Development and Security

A common dilemma faced by many organizations is the conflict between addressing vulnerabilities and focusing on feature development. Nir candidly discusses this tension, noting that while security is paramount, the drive to innovate and expand product offerings can sometimes overshadow immediate security concerns. He stresses the importance of finding a balance, emphasizing that neglecting vulnerabilities can lead to severe consequences, including breaches that may compromise the entire system.

Rethinking Vulnerabilities: Context Over Volume

Modern development teams are overwhelmed by vulnerability alerts. According to Nir, finding vulnerabilities is not the hard part anymore—understanding which ones actually matter is.

Traditional scanners often flag issues without answering critical questions:

• Is the vulnerable code actually reachable?

• Is the vulnerable function used in production paths?

• Would fixing it introduce breaking changes?

Arnica’s approach emphasizes reachability analysis—prioritizing only vulnerabilities that are demonstrably exploitable in a given codebase. Just as important, Nir stressed that declaring something “not reachable” carries real responsibility and must be done conservatively to maintain developer trust.

Dependency Management and the Reality of Breaking Changes

Upgrading dependencies sounds simple in theory, but in practice it’s risky. A single version bump can cascade across a complex dependency tree, especially with transitive dependencies. Nir highlighted that:

• Developers often settle for “partial wins” (patch or minor upgrades) rather than risky major upgrades.

• There is no reliable, deterministic way to predict breaking changes across large dependency graphs.

• AI can assist by analyzing changelogs and diffs, but human judgment remains essential.

Security vs. Feature Delivery: A False Tradeoff

One recurring tension in software teams is whether security work slows down feature development. Nir challenged this assumption.

Research cited in the conversation shows:

• Developers spend ~15% of their time in code reviews.

• Roughly 63% of AI-generated review comments are dismissed as noise.

• A significant portion of developer time is wasted evaluating low-value findings.

By reducing noise and surfacing only actionable, contextual issues earlier in the workflow, teams can actually increase overall feature velocity, not reduce it. Nir estimates that well-designed security workflows can result in more features shipped, not fewer.

Tribal Knowledge and Personalized Security

One of the most forward-looking ideas from the conversation was tribal knowledge. Over time, tools can learn:

• Which issues teams routinely dismiss

• Which patterns reflect real business logic

• Where a specific team’s blind spots lie

By feeding this context back into scanning and AI generation, security tooling becomes increasingly personalized and aligned with how each team actually builds software, rather than relying on generic rulesets.

AI’s Impact on the SDLC: More Code, More Risk

Looking ahead, Nir cited predictions that up to 90% of new code may soon be AI-generated. This creates three major challenges:

1. Exploding risk surface – more code means more potential vulnerabilities.

2. Ownership ambiguity – AI-generated code often lacks clear authorship.

3. Review bottlenecks – human review capacity doesn’t scale linearly.

The solution, he argued, lies in creating a feedback loop—or “flywheel”—where organizational knowledge about risks, dismissals, and fixes continuously informs how AI generates future code.

AI Coding Agents and “Secure by Default” Development

As AI coding assistants become ubiquitous, a new problem emerges: fragmented behavior across tools like Copilot, Cursor, and Claude. Each may follow different rules—or none at all.

Nir described a model where organizations centrally define AI coding rules (security, quality, governance) and automatically inject them into repositories. Instead of relying on optional plugins or ignored pull requests, these rules become part of the codebase itself, ensuring that AI agents generate governed code by default.

Conclusion: Key Takeaways for Developers

As software development continues to evolve, so too must the strategies we employ to ensure security. Nir Valtman’s insights underscore the necessity of understanding the nuances of vulnerabilities, employing reachability analysis, and leveraging AI to enhance security measures. Developers must maintain a delicate balance between innovation and security, recognizing that the cost of neglecting vulnerabilities can far outweigh the investment in proactive security measures.

Victor Varnado is not easily defined by a single title. A comedian, filmmaker, writer, game designer, cartoonist, actor, and software developer, he operates at the intersection of creativity and technology. As the CEO of SupremeRobot, a tech-and-media incubator, Victor develops intellectual property that can evolve into standalone companies. In this conversation, he shares how AI is reshaping writing, software development, outsourcing, and creative work at large.

Podcast

Using AI Like a Scalpel, Not a Hammer — on Apple and Spotify.

Supreme Robot: An Incubator for Ideas

Supreme Robot functions as a creative and technical incubator. Victor develops multiple ideas—ranging from software to television concepts—inside the company. Once an idea matures into viable IP, it can spin out into its own business with separate investors, while Supreme Robot continues to manage and nurture it. This structure allows experimentation across disciplines without forcing every idea into a single mold .

How Screenwriting Traditionally Worked

Before AI, screenwriting followed a well-defined but labor-intensive path:

1. Initial idea or logline

2. Synopsis

3. Outline

4. Step outline or treatment

5. Character design and descriptions

6. Full script

Each step required careful iteration, and moving from one phase to the next could take weeks or months. Writers often stalled not because of a lack of creativity, but because of the sheer effort required to progress through the process .

AI as a Writing Assistant, Not a Replacement

Victor is clear: AI is not meant to replace creativity, but to support it. His screenplay-writing software guides writers step by step—from idea to final script—while keeping humans in control at every stage. Writers review, edit, and approve outputs before moving forward, ensuring the final result reflects their intent and voice.

The biggest benefit? AI removes friction. Writers no longer get “stuck” as often, because AI can help them brainstorm options, elaborate ideas, and move forward when momentum is lost .

Creativity and the “Hammer” Analogy

Victor compares AI to a hammer:

• Used poorly, it’s a blunt instrument.

• Used skillfully, it can sculpt art.

Asking AI to “write like Quentin Tarantino” is, in his view, using it as a mallet. Instead, AI should be used to expand, challenge, and refine one’s own ideas. When treated as a nuanced tool, AI can enhance originality rather than diminish it .

Building Software with AI: How Far Can It Go?

Victor has built multiple products using AI-assisted development tools such as ChatGPT and Lovable.dev. His assessment:

• Simple apps: Non-developers can reach MVP and even launch.

• Complex apps: AI can get you ~70% of the way.

• Production-ready systems: Still require experienced developers.

In one of his products, Magic Fiction Writer, approximately 95% of the code was generated by AI, but only because it was guided and validated by an experienced engineer. AI accelerates development—but it does not replace architectural judgment, security expertise, or deep debugging skills .

The Changing Shape of Engineering Teams

Before modern AI tools, Victor relied on overseas mid-level developers to scale work affordably and quickly. Today, those roles are largely replaced by AI. The result:

• Fewer junior and mid-level developers

• Greater reliance on senior engineers and architects

• Founders who can build MVPs themselves using AI

This shift mirrors trends seen in large companies, where hiring increasingly favors senior developers who can oversee AI-generated output and handle complex edge cases .

Outsourcing, Cost, and the Reality of AI Adoption

AI is already disrupting outsourcing. Victor draws a parallel to creative fields like logo design and filmmaking: while people may prefer human-made work, businesses—especially small ones—will gravitate toward cheaper, faster solutions when quality is “good enough.”

The same logic applies globally. If AI can replace outsourced labor at lower cost and higher speed, companies will adopt it. This shift is economic, not ideological .

New Capabilities That Didn’t Exist Before

Some AI-powered capabilities go beyond cost or speed advantages. One example is expert-level administrative automation:

• AI acting as a writing coach or ghostwriter

• Interviewing an author about their ideas

• Producing a first draft of an entire book

Previously, this required hiring professional researchers or ghostwriters at significant expense. Today, similar outcomes are accessible to the general public—sometimes even for free—if users know how to ask the right questions .

Differentiation in an AI-First World

When everyone has access to the same AI tools, differentiation shifts. For Victor, the key is making AI feel like an appliance, not a novelty:

• Users should not have to “prompt engineer”

• AI should be buried inside the system

• Results should be seamless, reliable, and intuitive

Just as people don’t want to manage electricity to turn on a light, they shouldn’t need to manage AI to get value from a product .

Advice for Builders, Developers, and Creatives

Victor’s guidance is concise:

• Learn AI, regardless of your field

• Don’t change careers—enhance them

• Focus on problem-solving, not just tools

• Use AI to remove friction, not replace judgment

The future belongs to those who understand how to work with intelligent systems, not those who resist them .

Closing Thoughts: Art, New York, and the Human Element

Despite all the talk of AI, Victor remains deeply human in his outlook. He draws inspiration from New York City’s art scene, values creativity above automation, and reminds us that tools are only as meaningful as the people who wield them.

AI may be powerful—but vision, taste, and intent still come from humans.

To illustrate this, let’s examine a real-world example from a widely used online news platform. This isn’t about singling out one company—it’s about highlighting patterns that product teams should actively avoid.

Podcast

The First Impression Problem: Ads Before Value

The very first thing users encounter is not content—but ads.

Banner ads, pop-ups, floating videos, and interstitials dominate the screen before the reader even sees a headline. In many cases, ads occupy more screen real estate than the actual articles. This immediately creates friction.

Even for non-paying users, the experience should invite engagement before monetization. When users are forced to fight through noise before understanding the value of the content, trust erodes quickly.

Key takeaway:

If users don’t experience value within the first few seconds, they won’t stay long enough to convert.

Visual Noise and Cognitive Overload

Beyond ads, the interface itself feels chaotic:

• Too many colors

• Inconsistent fonts and weights

• Moving elements competing for attention

• Videos appearing without intent

Reading becomes exhausting. Focus is constantly interrupted. Instead of consuming information, users are managing distractions.

Good UX minimizes cognitive load. Great UX makes the interface almost invisible.

Key takeaway:

Every moving element, font choice, and visual cue should earn its place.

Content Without Context or Order

Another major issue is content sequencing.

On the home page, users see:

• Political news mixed with cinema

• International stories before local relevance

• Entertainment interwoven with serious news

There’s no clear logic. No hierarchy. No obvious editorial intent.

Users shouldn’t have to ask:

• Why am I seeing this?

• What should I read first?

• Is this even relevant to me?

Key takeaway:

Content must be organized with intent, relevance, and user context in mind.

Navigation That Works Against the User

Menus are overloaded with categories—many unclear, inconsistently named, or poorly grouped. Important sections like technology are buried deep, forcing users to scroll endlessly.

In contrast, strong products:

• Limit top-level categories

• Use clear language

• Offer intuitive sub-navigation

When navigation becomes a puzzle, users disengage.

Key takeaway:

If users need to think about how to navigate, the navigation has already failed.

Reading Interrupted: Ads Inside Articles

Even after selecting an article, the experience worsens:

• Full-page ads before content

• Ads injected after just a few lines

• Close buttons that move or blend into backgrounds

• Flickering elements that distract while reading

The reader never settles into the article. The flow is constantly broken.

Compare this to better-designed platforms, where users can read multiple paragraphs, understand the story, and then encounter an ad—naturally.

Key takeaway:

Respect the reader’s attention. Interruptions should be deliberate, not relentless.

Vanity Metrics That Add Bias

Displaying view counts on news articles introduces unnecessary bias. News consumption isn’t social media. Popularity doesn’t equal importance.

When users see numbers, they’re nudged toward what’s trending rather than what matters to them.

Key takeaway:

Not every metric needs to be visible. Some distort decision-making more than they help.

The Bigger Picture: This Isn’t Hard to Fix

What’s most puzzling is that these issues are not complex:

• Fewer ads, placed thoughtfully

• Cleaner layouts

• Clear content hierarchy

• Consistent typography

• Simpler navigation

These are solved problems in product design.

Whether done by humans or evaluated with AI tools, recognizing poor UX should be straightforward. The real challenge is admitting there’s a problem—and prioritizing the fix.

A Message to Builders

If you’re building a product today—especially in an era dominated by AI—don’t forget the basics:

• Can users focus?

• Does the interface respect their time?

• Is the experience calm, intentional, and clear?

Before shipping, compare your product against the best experiences in the market. Not just competitors—but exemplars of clarity and restraint.

Because no amount of intelligence can compensate for an interface that users don’t enjoy using.

At Snowpal, we’ve spent years building and running production-grade software products across multiple domains. Most recently, our focus has been on B2B APIs — tools designed to help teams move faster, build reliably, and scale without reinventing the wheel.

As we head into 2026, we’re starting work on our next API product. It will begin life as an API, but over time, it will grow into something broader — firmly rooted in the fintech space.

This article is a primer. A teaser. And the first in what will likely be a longer series where we share what we’re building, why we’re building it, and what we’re learning along the way.

Podcast

The Market - How it works today

To understand why we’re excited about fintech right now, it helps to step back and look at how the stock market itself works today.

In the U.S., the core trading window runs from 9:30 AM to 4:00 PM Eastern — just 6.5 hours per day, across roughly 250 trading days per year. That’s about 1,625 hours of active trading annually.

Yes, there’s pre-market and after-hours trading, but anyone who’s participated knows the trade-offs:

• Much lower volume

• Wider spreads

• Higher risk

Those windows are not for everyone.

But that model is changing.

From everything we’re seeing and learning, the market is moving toward a 24-hour trading day, initially five days a week — with the same core trading window, plus extended sessions on either side.

Why? Because the U.S. stock market is no longer just an American market.

Investors from Asia, Europe, Africa, and beyond want access — and a six-and-a-half-hour window doesn’t work globally.

More Time, More Traders, More Volume

At the same time, trading volume has been trending upward for years.

COVID accelerated participation as people had more time and fewer alternatives. While that surge normalized, the baseline never went back down. And looking ahead, there are two powerful forces at work:

1. Global access to U.S. markets continues to expand

2. AI is reshaping work, freeing time — sometimes voluntarily, sometimes not

In both scenarios, more people end up looking for ways to deploy capital, build income streams, or stay financially engaged. The stock market becomes an obvious place to look.

The result?

• More participants

• More trades

• Longer trading windows

• Higher sustained volume

And with that comes a simple reality: the need for better tools explodes.

The Tooling Gap We Keep Running Into

We didn’t come to this conclusion from theory alone.

Over the past several months, we’ve been:

• Actively investing

• Actively trading

• Paper trading

• Studying markets hands-on

And what we’ve felt — repeatedly — is friction.

Yes, there are more tools today than there were a decade ago. But many of them:

• Feel dated

• Are overpriced for retail traders

• Are built primarily for institutions, not individuals

• Lack features that should exist by now

At the high end, you have tools that cost tens of thousands of dollars per year. At the low end, you often get fragmented experiences that don’t scale with a trader’s growth.

Retail investors — whether passive, active, or somewhere in between — are largely underserved.

Trading Is Hard — Process Is Everything

One statistic that often gets cited (and broadly aligns with what we’ve observed) is that most day traders quit quickly:

• A large majority exit within months

• Most never achieve consistent profitability

That’s not because they’re unintelligent. It’s because trading:

• Is emotionally demanding

• Requires discipline

• Demands repeatable systems

• Punishes improvisation

If your goal is something as “simple” as averaging $1,000 per day, you quickly realize how much structure is required:

• Clear plans

• Risk management

• Defined processes

• Consistent execution

Doing all of this manually is not impossible — but it’s painful, error-prone, and unsustainable for most people.

Why We’re Building in FinTech

This is where our background matters.

At Snowpal, we’ve:

• Built multiple production systems

• Served both B2B and B2C users

• Operated as a polyglot engineering team

• Shipped, maintained, and scaled real products over years

Fintech sits at the intersection of two things we care deeply about:

• Finance

• Software engineering

We believe we’re well-positioned to build modern, API-first tooling that:

• Respects how people actually trade and invest

• Helps users spend less time while making better decisions

• Is affordable, flexible, and extensible

• Evolves alongside market structure changes

We’re also committed to sharing our learnings openly — even if that means giving away ideas. We’re confident in our ability to execute, and we welcome healthy competition.

What Comes Next

This is just the beginning.

In future posts and videos, we’ll dive into:

• Specific problems we’re tackling

• Where existing platforms fall short

• How extended trading hours change system design

• What retail-first fintech tooling should look like

Think of this as episode one.

We’ll keep the conversation going.

Talk soon.

Takeaways

• AI is changing the way junior developers are trained.

• Understanding software architecture is more important than syntax.

• AI can significantly accelerate the development process.

• The role of non-developers in coding is increasing.

• Consulting firms can deliver projects faster with AI.

• User interfaces will become more personalized and agentic.

• AI tools can help in rapid prototyping and exploration.

• Earned knowledge is crucial for effective software development.

• The quality of code is still important, especially in architecture.

• AI is a force multiplier in software development.

Podcast

Summary

1. Guest Introduction & Background

Ran Aroussi introduces himself as:

• CTO & co-founder of AutoMaze (CTO / co-founder as a service)

• Long-time developer (≈30 years)

• Open-source contributor with ~20M monthly installs

• Author of Production-Grade Agentic AI

• Creator of Moxie (MUXI) – an open-source infrastructure layer for AI agents (“Docker for agents”)

2. AutoMaze’s Developer Onboarding Philosophy

• AutoMaze hires junior developers and trains them into highly productive engineers

• Focus is on finding raw potential (“diamonds in the rough”)

• AI has changed how developers are trained, but not the core principles

3. Thinking Before Coding: Mental Models First

• Developers should not touch a computer until they:

  • Fully understand the problem

  • Build a mental model of the system

  • Understand data flow end-to-end

• Syntax, language, and tooling are secondary

• Emphasis on architecture, logic, and system flow

4. AI-Driven Developer Growth Model (4 Phases)

Phase 0 – Pure Understanding

• No coding

• Focus on:

  • Architecture

  • Data flow

  • Problem decomposition

Phase 1 – AI as Code Reviewer (≈2 months)

• Developer writes all code

• AI used for:

  • Feedback

  • Directional guidance

  • Reviewing logic and approach

Phase 2 – AI as Pair Programmer (≈2 months)

• Developer writes ~70% of code

• AI assists with:

  • Implementation

  • Speed

• Architectural decisions remain human-driven

Phase 3 – AI as Force Multiplier (≈8 months)

• Developer writes ~30–40% of code

• AI handles:

  • Well-scoped tasks

  • Prototyping

  • Exploration

• Human focuses on:

  • Delegation

  • Context

  • Constraints

Phase 4 – Architect Mode (after ~1 year)

• Human writes minimal scaffolding (~10%)

• AI writes ~80% of code

• Human handles:

  • Architecture

  • Code review

  • Final quality control

5. Teachable Knowledge vs Earned Knowledge

• Teachable knowledge:

  • Syntax

  • Patterns

  • Best practices

  • Can be accelerated with AI

• Earned knowledge:

  • Production failures

  • Scaling decisions

  • Incident response (e.g., AWS outage at 3am)

• AutoMaze waits ~1 year before full AI leverage to ensure earned knowledge develops

6. Impact of AI on Developer Seniority

• Juniors can reach near-senior level in ~18 months

• Previously took 3–4 years

• Avoids “vibe coding” (one-shot apps with no understanding)

• Emphasizes depth, not shortcuts

7. Code Quality in the Age of AI

• Disagreement with the idea that “code quality no longer matters”

• Key distinction:

  • Architectural quality > syntactic perfection

• Iterative approach:

  • Start with working code (MVP)

  • Improve quality over time using AI

• AI accelerates refinement but does not replace architectural thinking

8. Can Non-Developers Build Software Now?

• Yes, for:

  • Prototypes

  • Internal demos

  • Directional clarity

• No, for:

  • Production systems

  • Scaling decisions

• Product managers can get ~70% of the way there

• Production still requires earned engineering judgment

9. Consulting in an AI-Accelerated World

• AutoMaze ships more, faster

• Same budget → more features delivered

• Projects take:

  • ⅓ to ½ the time compared to pre-AI

• Consulting shifts from:

  • “Stretching work”

  • To continuous value delivery

• Clients don’t buy less—they get more outcomes

10. AI Beyond the UI: Rethinking Interfaces

• Future UIs will be:

  • Less visual

  • More conversational

  • Highly personalized

• Interfaces may live in:

  • Slack

  • WhatsApp

  • Phone calls

  • PDFs / summaries

• UI importance declines for knowledge work

• Agents become first-class users of systems

11. Human UI vs Agent UI (50/50 Future)

• Leisure & shopping → human-centric UI

• Business workflows → agent-centric interfaces

• APIs + agents may replace traditional dashboards

• Example: Voice-based interfaces powered by APIs (Twilio + AI)

12. Amazon Example: Where AI Shows Up

• AI already deeply embedded in Amazon’s backend

• User-facing shopping UI remains largely unchanged

• Reason:

  • Visual comparison

  • Reviews

  • Human psychology in buying

• AI enhances workflows, not necessarily the storefront

13. Junior vs Senior Developers Debate

• AI amplifies senior developers

• But juniors are still essential:

  • Seniors don’t “appear” magically

  • Training pipeline is mandatory

• Eliminating juniors leads to future senior shortages

• AI ≠ replacement for experience accumulation

14. Key Closing Themes

• AI is a force multiplier, not a replacement

• Architecture, judgment, and earned experience still matter

• Speed increases, but responsibility does not decrease

• Best teams combine:

  • Human reasoning

  • AI execution

  • Long-term learning investment

Transcript

AI Writes Code, Engineers Build Systems (feat. Ran Aroussi)

123KB ∙ PDF file

Download

Download

This conversation explores the rapid evolution of technology and its profound impact on developers. It discusses the changing landscape of work in the tech industry, the importance of adapting to new tools, and the role of AI in development. The speakers emphasize the need for developers to embrace change and navigate job security concerns in a world where 70% of traditional roles may be replaced.

Takeaways

• The tech industry is evolving at an unprecedented pace.

• Developers must adapt to new tools and technologies.

• AI is playing a significant role in transforming development.

• Job security is a growing concern for many in the field.

• Embracing change is essential for future success.

• The notion of being irreplaceable is becoming outdated.

• 70% of developers may find their roles altered or replaced.

• Continuous learning is crucial in the tech landscape.

• Collaboration with AI can enhance productivity.

• The future of work will require a shift in mindset.

Podcast

Summary

🏗️ Background & Patent Work

Patent Work at Target

• Built a digital data collection system from scratch

• Tracked UI events (page loads, clicks, impressions)

• Sent metadata to backend pipelines (Kafka → visualization in Kibana)

• Used by analysts for personalization, insights, and recommendations

⚙️ Tech Stack

• Frontend: React, TypeScript

• Backend: Scala

• Role: Full-stack engineer, frontend-leaning

🤖 AI & Development Workflow Transformation

How coding changed in 18 months

• Before: Hand-writing code + unit tests

• Now: Uses Cursor, Claude, Copilot-style tools to:

  • Break tasks into subtasks

  • Generate component scaffolding

  • Create unit tests

  • Speed up iteration cycles

AI impact

• AI now generates 60–70% of initial code

• Developer focuses on refining, reviewing, and ensuring quality

• Dramatically faster development cycles

👥 Engineering Team Evolution

Clive’s view on future engineering teams:

• Smaller teams, higher output

• Composition shifts toward mid-level and senior engineers

• Prompt engineering becomes essential

• Early-career engineers face more difficulty entering the industry

Team example shift

• 10-dev team → could become ~7-dev team with same output

• Or same team delivers 10x more features instead of fewer

🧠 Skills That Matter Going Forward

• Prompt engineering

• Understanding system logic and architecture

• QA and validation — verifying AI-generated output

• UX thinking and user empathy

💡 UX & Future Interfaces

Discussion on:

• Whether Amazon-style UIs will dramatically change

• Conversational interfaces emerging in tools

• AI-driven components replacing static pages

• Systems assisting users instead of users navigating menus

Clive expects gradual UX evolution; Krish anticipates a dramatic shift.

✅ Closing Thoughts

• AI is a multiplier, not a replacement — yet

• Engineers become curators, validators, and orchestrators

• Future belongs to hybrid technologists pairing:

  • Human creativity

  • AI execution power

Transcript

70% Auto-Generated Code: The Future of Software Teams (feat. Clive Dsouza)

94.4KB ∙ PDF file

Download

Download