AI + Snowpal API: Reduce Time to Market

In this episode of the Snowpal Podcast, we explore CUDA from both a software engineering and investment perspective. We examine why developers and enterprises have historically found it difficult to move away from NVIDIA, how alternative chip architectures could challenge that dependency, and why declining market share would not necessarily translate into declining revenue or profitability.

Podcast

NVIDIA's Biggest Competitive Threat May Not Be Another Chip — It May Be Software — on Apple and Spotify.

NVIDIA’s CUDA: The Software Behind the Hardware

What exactly is CUDA?

CUDA stands for Compute Unified Device Architecture. It is NVIDIA’s proprietary parallel computing platform and programming model, introduced in 2006, that allows developers to use NVIDIA GPUs for general-purpose computational workloads. GPUs were originally associated primarily with graphics processing, but their ability to execute many calculations simultaneously made them particularly valuable for scientific computing, machine learning, and eventually generative AI.

From a software engineering standpoint, CUDA provides the programming tools, libraries, compiler infrastructure, and runtime capabilities necessary to execute supported workloads efficiently on NVIDIA GPUs. Developers might write CUDA code directly, but many interact with it indirectly through machine learning frameworks such as PyTorch. When a PyTorch application runs on an NVIDIA GPU using its CUDA backend, the developer may never explicitly write a CUDA kernel, yet the underlying execution still depends on NVIDIA’s software ecosystem.

Why CUDA is such a powerful competitive moat

Building a competitive GPU is extraordinarily difficult, but producing hardware is only part of the challenge. Developers also need mature software tools, optimized libraries, debugging capabilities, documentation, and reliable integrations with the frameworks they already use. NVIDIA has spent approximately two decades developing this ecosystem, creating a substantial advantage that competitors cannot easily reproduce.

Imagine an enterprise that has invested years developing and optimizing its AI applications around NVIDIA GPUs. Its engineers understand CUDA, its infrastructure is configured for NVIDIA hardware, and its performance benchmarks have been established around that environment. Switching to another chip architecture would require more than purchasing replacement hardware. It could involve rewriting portions of the software, replacing dependencies, validating numerical behavior, benchmarking performance, and retraining engineering teams. These switching costs make NVIDIA’s ecosystem particularly difficult to displace.

Broadcom, Google, and the Rise of Alternative AI Chips

GPUs versus ASICs

Although NVIDIA dominates important segments of AI GPU computing, other companies are developing specialized processors that can perform certain AI workloads efficiently. One prominent category is the application-specific integrated circuit, or ASIC. Unlike a general-purpose GPU, an ASIC is designed around a more narrowly defined set of computational requirements, potentially delivering advantages in performance, energy efficiency, or cost for suitable workloads.

Broadcom is an important participant in this market, collaborating with major technology companies on custom semiconductor solutions. Google’s Tensor Processing Units, or TPUs, represent another approach to AI acceleration. TPUs are specialized processors designed to accelerate machine learning workloads and are supported by a software ecosystem that differs from NVIDIA’s CUDA stack.

The distinction matters because AI computing does not necessarily have to run exclusively on general-purpose NVIDIA GPUs. Certain workloads may be more economical on custom accelerators, particularly when large organizations have the resources to optimize their software around those processors.

Why cheaper chips alone may not be enough

Suppose a competing accelerator offers a compelling cost advantage over an NVIDIA GPU. An enterprise cannot automatically take its existing CUDA-dependent application and execute it unchanged on that alternative architecture. The software stack, kernel implementations, compiler support, memory management, and hardware characteristics may all differ.

This creates an interesting economic problem. Even when competing hardware is cheaper, the cost of migrating the software could exceed the potential savings. Consequently, NVIDIA’s competitive advantage comes not simply from offering powerful processors, but from making the entire computing environment difficult and expensive to replace.

Anthropic and the Possibility of Hardware Flexibility

Why multi-chip AI infrastructure matters

One of the most interesting developments discussed in the podcast is the possibility of AI workloads operating across different hardware architectures rather than remaining tied to a single semiconductor vendor. Anthropic is relevant to this conversation because its AI workloads and infrastructure relationships span multiple computing platforms.

A hardware-flexible environment could allow organizations to evaluate NVIDIA GPUs alongside alternatives such as Google’s TPUs and other custom AI accelerators. Instead of making a long-term commitment to one vendor, enterprises could select hardware based on workload requirements, cost, performance, and availability.

An important distinction is that Anthropic does not provide a universal software layer that automatically makes every CUDA application portable across all competing processors. Its multi-platform infrastructure strategy illustrates the potential for hardware diversification, while the technical work of supporting different accelerators still depends on compilers, frameworks, libraries, and engineering effort.

How AI agents could reduce migration costs

Perhaps the more significant long-term threat to NVIDIA’s software lock-in comes from AI-assisted software engineering. Historically, migrating applications between substantially different computing architectures has been expensive and time-consuming. Developers must understand the existing code, identify hardware-specific dependencies, implement alternative kernels, and validate that the migrated application behaves correctly.

AI coding agents could make portions of this process considerably easier. An agent might examine a CUDA-dependent codebase, identify hardware-specific components, propose alternative implementations, generate tests, and help developers optimize workloads for another platform. Tools such as Anthropic’s Claude could potentially assist engineers with these tasks.

This does not mean migrating a sophisticated AI workload becomes a one-click operation. Performance tuning, correctness testing, hardware availability, and operational reliability remain significant challenges. Nevertheless, if AI agents reduce the time and cost required to migrate, companies that previously considered switching impractical may begin evaluating alternatives.

The key point is that NVIDIA’s moat could weaken without competing chips necessarily becoming more powerful than NVIDIA’s GPUs. Making it easier to use alternative hardware may itself increase competition.

OpenAI’s Triton: Another Challenge to CUDA Dependency

What is Triton?

OpenAI’s Triton is an open-source programming language and compiler designed to make writing high-performance GPU kernels more accessible. It allows developers to express parallel computations at a higher level than traditional low-level CUDA programming, while still targeting efficient GPU execution.

Triton is particularly relevant for machine learning workloads where developers need specialized computational kernels. Instead of manually implementing every operation using conventional CUDA programming techniques, engineers can use Triton to express the computation and rely on its compiler infrastructure to handle portions of the optimization process.

Does Triton replace CUDA?

Not necessarily. Triton can run on NVIDIA GPUs and may still rely on NVIDIA’s underlying driver and execution infrastructure. It is therefore not accurate to describe Triton as an immediate or complete replacement for CUDA.

However, Triton can reduce developers’ dependence on writing hardware-specific CUDA code directly. With suitable compiler backends and hardware support, higher-level programming approaches may make it easier to target multiple accelerator architectures over time.

The strategic implication is important: if developers can write more portable GPU software, the relationship between applications and a particular hardware vendor may become less restrictive. NVIDIA could continue selling enormous quantities of GPUs while facing greater competition at the programming and infrastructure layers.

Could NVIDIA Lose Market Share Without Losing Revenue?

Market share and market growth are different questions

The podcast raises an important distinction between NVIDIA’s share of the AI computing market and the overall size of that market. NVIDIA may face increasing competition from custom accelerators, alternative GPU suppliers, and more portable software frameworks. Yet that does not automatically mean its revenue must decline.

Consider a hypothetical scenario in which NVIDIA controls 90% of a particular AI accelerator market worth $100 billion. Its corresponding revenue opportunity would be $90 billion. If the market subsequently expands to $300 billion but NVIDIA’s share falls to 70%, its corresponding opportunity would increase to $210 billion.

Hypothetical revenue opportunities; assumes market share translates proportionally into revenue.

Despite losing 20 percentage points of market share, NVIDIA’s corresponding revenue opportunity would have more than doubled. This illustrates why market share alone is insufficient to evaluate the company’s future financial performance.

The podcast also mentions approximate market-share figures for NVIDIA GPUs, Broadcom ASICs, and the overall AI chip market. These were explicitly pres

ented as rough estimates rather than verified industry statistics. The broader competitive argument does not depend on those particular percentages being accurate.

Why total addressable market matters

The total addressable market, commonly abbreviated TAM, represents the potential demand for products and services within a particular industry. AI infrastructure spending could continue expanding as enterprises adopt AI applications, inference workloads increase, and new computationally intensive products become commercially viable.

If that expansion is sufficiently large, NVIDIA could continue generating substantial revenue growth even while competitors capture a greater portion of incremental spending. Conversely, strong market growth does not guarantee that NVIDIA will maintain its current profit margins or valuation multiples. Pricing pressure, customer concentration, custom-chip adoption, and capital expenditure cycles could all affect its financial performance.

The Investment Perspective: Dominance Versus Competition

For investors, the central question is not simply whether NVIDIA will remain the leading AI GPU supplier. It is whether its competitive advantages will continue translating into revenue growth, attractive margins, and sustainable profitability as the industry matures.

CUDA creates meaningful switching costs, but switching costs are not permanent barriers. More capable AI development tools could lower those costs, while alternative accelerators could provide economically attractive options for selected workloads. Large technology companies also have incentives to diversify their suppliers, negotiate better prices, and reduce their dependence on any single semiconductor company.

At the same time, NVIDIA continues benefiting from its hardware performance, integrated software ecosystem, networking technologies, developer adoption, and substantial investment in research and development. Even if alternative platforms become easier to use, NVIDIA may remain the preferred option for many demanding AI workloads.

The most plausible competitive outcome is not necessarily a sudden collapse in NVIDIA’s position. It could instead be a gradual transition toward a more diversified AI computing market in which NVIDIA remains a major supplier but no longer captures the same overwhelming share of every incremental investment.

Final Thoughts: NVIDIA’s Moat May Evolve Rather Than Disappear

CUDA has been an extraordinary strategic asset for NVIDIA. By combining advanced hardware with a deeply integrated software ecosystem, the company has created barriers to entry that extend far beyond semiconductor design. But AI is also changing the economics of software development itself. If AI agents can reduce migration costs, frameworks become more portable, and alternative accelerators become increasingly capable, customers may gain choices that were previously impractical.

That does not mean NVIDIA is destined to lose its leadership position. Its revenue could continue growing even as the market becomes more competitive, particularly if demand for AI computing expands faster than its market share declines. The important distinction is between a company losing some of its exclusivity and a company losing its relevance.

For software developers, this evolution could create more flexibility and potentially lower infrastructure costs. For investors, it introduces a more nuanced question: how much of NVIDIA’s future growth depends on maintaining its current competitive dominance, and how much depends on the extraordinary expansion of the AI computing market itself?

As discussed in the podcast, the answer will become clearer as the industry evolves. What seems increasingly likely is that competition will take place not only between chips, but also between the software ecosystems that determine how those chips are used.

This article is adapted from the November 6, 2026 Snowpal Podcast transcript. The market-share and revenue examples are illustrative, and the technical discussion includes clarifications where the original recording expressed uncertainty.

AI + Snowpal API: Reduce Time to Market

In this episode of the Snowpal Podcast, I explore the recent market downturn, the potential consequences of increased AI regulation, the financial implications for semiconductor manufacturers and hyperscalers, and why I believe AI development is unlikely to come to a standstill despite political headwinds.

Podcast

The AI Gold Rush Meets Washington: Why Tech Stocks Are Falling and What Comes Next — on Apple and Spotify.

The Market Selloff: Technology Stocks Take a Beating

The market reaction following the midterm elections has been dramatic. After initially responding positively to the election results, stocks reversed direction, producing what felt like a bloodbath across major indexes. During the podcast, I estimated that the Nasdaq had fallen approximately 1,400 points, the Dow had declined more than 1,000 points, and the S&P 500 had dropped approximately 4.5%. These figures were estimates discussed during the recording rather than independently verified market data.

The semiconductor sector has been particularly vulnerable. Nvidia, AMD, Broadcom, Micron, SanDisk, and other companies associated with AI infrastructure have experienced substantial selling pressure. The immediate question is whether investors are reacting to a genuine deterioration in business fundamentals or simply reassessing the pace at which AI infrastructure spending can continue under a potentially more restrictive regulatory environment.

Semiconductor stocks face significant selling pressure

Several companies stood out during the discussion. Nvidia was estimated to have declined approximately 22–23% over the preceding four weeks, while Micron had fallen below $700 after trading near $1,000 around its previous earnings announcement. SanDisk, which had approached $2,000 earlier in the year, was trading below $1,000, while Broadcom had declined nearly 10% and fallen below $300.

These numbers were recalled from memory during the podcast and should be treated as approximate rather than verified historical prices. Nevertheless, the broader observation is that companies closely associated with AI infrastructure have experienced considerable volatility. Amazon appeared to be a relative exception during the session, having maintained stronger momentum following its recent earnings announcement.

A hypothetical AI portfolio loses approximately 50%

To illustrate the magnitude of the correction, I discussed a paper-trading portfolio tracking approximately ten companies associated with AI infrastructure. Over roughly four to five weeks, that hypothetical portfolio had declined approximately 50%. The portfolio was not funded with actual capital, but its performance demonstrated how quickly losses can accumulate when highly correlated technology stocks experience simultaneous corrections.

This raises an important distinction: a company can continue growing its revenue and expanding its business while its stock price declines significantly. Market valuations reflect expectations about future growth, not merely the financial results companies have already delivered.

Political Changes and the Prospect of More AI Regulation

The podcast discusses the Democratic victories in the House and Senate during the midterm elections and the possibility that the incoming Congress will pursue additional AI-related regulation. The concern is not necessarily that artificial intelligence development will be prohibited, but that restrictions could increase the cost, complexity, and time required to expand AI infrastructure.

There is a reasonable argument for regulation. AI development raises legitimate questions about energy consumption, environmental impact, public safety, and the effects of increasingly powerful technologies on employment and society. At the same time, excessive restrictions could slow investment, reduce competitiveness, and discourage companies from developing infrastructure in the United States.

Why the pace of AI development matters more than an outright shutdown

The stock market does not require AI development to stop entirely before repricing AI-related companies. Even a relatively modest reduction in expected growth can have significant consequences for businesses whose valuations depend on years of rapid expansion. If investors previously expected data center capacity to increase at an extraordinary pace but begin anticipating a slower expansion, semiconductor manufacturers and infrastructure suppliers could experience substantial valuation adjustments.

This is especially important because stock prices often incorporate expectations well beyond the next quarter or fiscal year. A company can remain profitable, continue selling products, and report growing revenue while still disappointing investors who had anticipated substantially faster growth.

Data Centers: The Center of the AI Regulation Debate

Data centers are among the most visible and controversial components of the AI infrastructure boom. As technology companies build increasingly powerful computing facilities, communities are beginning to question the environmental and economic consequences of these developments.

I live in Loudoun County, Virginia, an area with a substantial concentration of data centers. Many residents work in technology and benefit directly or indirectly from the growth of AI, yet they may understandably oppose having enormous computing facilities constructed near their homes.

Electricity, water consumption, and noise pollution

The concerns surrounding data center expansion extend beyond their physical appearance. Large facilities consume substantial electricity, may require considerable water for cooling, and can contribute to local infrastructure costs. Noise is another important consideration, particularly where cooling equipment, backup generators, or gas turbines operate near residential neighborhoods.

Facilities that cannot obtain sufficient electricity from the existing grid may require alternative power arrangements, potentially introducing additional environmental and noise concerns. These issues help explain why local communities and policymakers may support restrictions on new development even when they recognize the economic importance of AI.

Could restrictions slow new data center construction?

The podcast raises the possibility of additional controls on the number of data centers permitted in certain counties and states, as well as more stringent requirements governing their construction and operation. It also references potential moratoriums in Texas as an example of the broader regulatory uncertainty facing the industry.

The underlying economic relationship is straightforward: if fewer data centers are constructed, demand for the equipment required to build and operate those facilities could grow more slowly. That includes processors, memory, storage, cooling systems, electrical infrastructure, and other components.

However, fewer new facilities would not automatically translate into an equivalent reduction in equipment demand. Existing data centers could still be upgraded, and companies could continue investing in more efficient and powerful computing systems.

Nvidia and AMD: Why AI Chipmakers Are Particularly Exposed

Semiconductor manufacturers have become some of the most prominent beneficiaries of the AI investment cycle. Their growth is closely associated with the willingness of major technology companies to continue purchasing enormous quantities of computing hardware.

Nvidia’s dependence on data center demand

Nvidia is central to the AI infrastructure ecosystem because its GPUs are widely used to train and run increasingly sophisticated AI models. During the podcast, I estimated that approximately 90% of Nvidia’s revenue could be associated with data centers and that quarterly revenue might be approaching $100 billion. Both figures were explicitly presented as estimates from memory, not verified financial results.

The broader concern is that Nvidia’s growth expectations depend heavily on continued demand for AI computing capacity. If regulatory restrictions slow infrastructure expansion, investors may begin questioning whether the company can sustain the extraordinary growth rates reflected in its valuation.

Even if Nvidia continues generating substantial revenue and profits, a slowdown relative to expectations could produce meaningful stock-price volatility.

AMD’s growing exposure to AI infrastructure

AMD faces a similar challenge, although its business includes several revenue streams beyond data centers. During the discussion, I estimated AMD’s quarterly revenue at approximately $13–14 billion, with roughly 60% potentially associated with data centers. These were also unverified estimates made during the recording.

AMD operates across data center computing, gaming, and other semiconductor markets, but its growth narrative is increasingly connected to the expansion of AI workloads. If the construction of new computing facilities slows, demand for its data center products could be affected.

The distinction between Nvidia and AMD is important because investors must consider not only the size of each company’s AI opportunity but also the degree to which its valuation already assumes continued success.

Broadcom, Micron, SanDisk, Seagate, and Vertiv: The Wider AI Supply Chain

AI infrastructure requires far more than GPUs. The expansion of data centers supports an extensive ecosystem of semiconductor designers, memory manufacturers, storage providers, networking specialists, and cooling equipment companies. This creates a chain of dependencies in which changes to hyperscaler spending can influence numerous businesses simultaneously.

Broadcom and Marvell: Custom chips and AI connectivity

Broadcom and Marvell occupy important positions in the semiconductor ecosystem, particularly through custom silicon and related technologies. Broadcom’s application-specific integrated circuits, or ASICs, represent an alternative approach to AI computing hardware compared with general-purpose GPUs.

The podcast emphasizes that the United States has substantial strength in this area, with companies such as Nvidia, Broadcom, and Marvell contributing to its semiconductor leadership. However, if hyperscalers reduce or delay infrastructure investments, companies supplying custom AI chips and associated technologies may also face changing demand expectations.

Micron, SanDisk, and Seagate: Memory and storage demand

AI systems require enormous amounts of memory and storage capacity. Micron, SanDisk, and Seagate were discussed as companies potentially affected by a slowdown in data center development. Although these businesses operate in different segments of the memory and storage markets, they share exposure to the broader expansion of digital infrastructure.

A reduction in anticipated data center construction could moderate future demand growth for certain products. Nevertheless, AI workloads may continue requiring increasing amounts of memory and storage even if the number of newly constructed facilities grows more slowly.

Vertiv: Cooling infrastructure and the AI buildout

Vertiv represents another important part of the AI infrastructure supply chain. Powerful computing systems generate substantial heat, creating demand for specialized cooling and thermal management equipment.

As data center computing density increases, efficient cooling becomes increasingly important. If infrastructure projects are postponed or canceled, suppliers such as Vertiv could experience changes in expected orders. Conversely, continued upgrades to existing facilities and increasing computing density could sustain demand even under a more restrictive construction environment.

Hyperscalers: Could Lower AI Spending Actually Be Good News?

One of the more interesting questions discussed in the podcast is whether restrictions on AI infrastructure investment could benefit the companies currently spending the most money.

Meta, Amazon, and Alphabet have committed substantial resources to AI-related capital expenditure. Investors have frequently expressed concerns about the scale of these investments and the uncertainty surrounding their eventual financial returns.

If regulations force these companies to spend less on infrastructure, the immediate financial consequences could be positive in certain respects.

Reduced capital expenditure could improve free cash flow

Capital expenditure represents money invested in assets such as servers, networking equipment, computing infrastructure, and data centers. When companies increase these investments substantially, their free cash flow can decline even while their underlying operations remain highly profitable.

If Meta, Amazon, or Alphabet were required to reduce capital expenditure, they could retain more cash in the short term. This could improve reported free cash flow, provide greater financial flexibility, and potentially reduce investor concerns about the cost of the AI expansion.

From this perspective, lower spending is not necessarily bad news for hyperscalers. In fact, it could make their near-term financial statements appear more attractive.

The problem: Lower spending could also limit revenue growth

The other side of the argument is that AI infrastructure investments are intended to support future revenue growth, product development, and competitive advantages. Companies are not spending billions of dollars simply because they have excess cash. They expect those investments to generate economic benefits.

Meta, for example, requires substantial computing capacity to develop and deploy increasingly sophisticated AI products. The podcast references its Muse application as an example of a product associated with significant computing requirements.

If regulations prevent companies from expanding their infrastructure at the desired pace, their ability to launch new products, improve existing services, or scale AI capabilities could become constrained. That could ultimately limit future revenue growth.

The tradeoff is therefore between improved short-term free cash flow and potentially weaker long-term growth opportunities.

Growth Stocks Versus Mature Businesses: Why Valuation Matters

One of the most consequential risks for hyperscalers is not necessarily declining revenue but a change in how investors classify their businesses.

Companies expected to deliver substantial earnings growth often command higher valuation multiples than businesses operating in mature industries. Investors are willing to pay more for future earnings when they believe those earnings will increase rapidly over time.

What happens when a growth company begins to mature?

Suppose investors begin believing that a major technology company can no longer expand its AI capabilities as quickly as previously expected. Even if the company remains profitable and continues increasing earnings per share, the market may no longer assign it the same valuation premium.

During the podcast, I compared this possibility with mature consumer businesses such as Coca-Cola and Pepsi. The comparison was not intended to suggest that hyperscalers would become identical to beverage companies, but rather to illustrate how different growth expectations can influence valuation.

A business generating steady earnings growth may still be an excellent company, yet its stock could perform poorly if investors previously priced it for extraordinary expansion.

Why better free cash flow does not guarantee a higher stock price

A reduction in capital expenditure could improve free cash flow while simultaneously weakening expectations for future revenue growth. Investors would then have to decide which development matters more.

This explains why a forced reduction in AI spending might not produce an immediate rally in Meta, Amazon, or Alphabet. The market could reward stronger cash generation, penalize slower growth, or respond differently depending on the company’s valuation and competitive position.

The outcome would depend on how effectively each company converts its existing AI investments into measurable financial returns.

The United States, China, and the Global AI Race

Beyond financial markets, AI development has become an important component of international technological competition. The podcast argues that policymakers must consider the consequences of slowing domestic AI development while competing nations continue investing aggressively.

China is particularly relevant because it has substantial ambitions in artificial intelligence, semiconductor development, and advanced computing infrastructure.

Can the United States afford to slow AI investment?

The United States benefits from a powerful technology ecosystem that includes Nvidia, Broadcom, Marvell, and major hyperscalers such as Amazon, Alphabet, Microsoft, and Meta. These companies collectively contribute to the country’s capabilities in semiconductor design, computing infrastructure, software, and AI development.

Excessively restrictive policies could create opportunities for international competitors if they substantially reduce the pace of American technological progress. This does not mean regulation should be abandoned, but it does suggest that policymakers face a difficult balancing act between managing risks and preserving competitiveness.

Why AI development is unlikely to stop

My expectation is that AI development will continue despite additional regulation. The technology has already become deeply integrated into business operations, software development, and a growing range of industries.

There may be delays, higher compliance costs, and changes in the pace of infrastructure construction. However, the economic incentives to improve AI systems remain substantial, and the international competition to develop more powerful technologies provides another reason for continued investment.

The more realistic question is how quickly AI will advance and which companies will benefit most from the next phase of development.

AI and Employment: The Transformation Is Already Underway

As someone working in technology and running a software startup, I have seen how AI is changing expectations around productivity and staffing. The podcast discusses the possibility that work previously requiring ten employees might, in some circumstances, be accomplished by a much smaller team using AI-powered tools.

The example of reducing a ten-person team to three was intended to illustrate the potential scale of productivity changes, not to establish a universal employment ratio.

Fewer resources may be needed to accomplish the same work

AI can automate repetitive tasks, accelerate software development, assist with research, and improve the efficiency of numerous business processes. This creates opportunities for smaller teams to accomplish work that previously required larger organizations.

At the same time, the effects will vary considerably across industries and occupations. Some roles may shrink, others may evolve, and entirely new categories of employment may emerge as the technology develops.

What seems increasingly difficult to dismiss is that AI has already moved beyond being merely an experimental technology. Businesses are actively incorporating it into their operations, and its influence on productivity is likely to remain an important economic consideration.

Is the AI Selloff an Overreaction or the Beginning of a Larger Correction?

The market’s recent decline raises an obvious question: are investors responding rationally to a meaningful change in future growth expectations, or is the selloff primarily a knee-jerk reaction to political uncertainty?

Both explanations may contain some truth. Regulation could affect infrastructure expansion and investment economics, but the extent of those effects remains uncertain. Political outcomes do not automatically translate into immediate restrictions, and proposed policies may be modified, delayed, or never implemented.

Why a market rebound remains possible

If investors conclude that AI infrastructure investment will continue at a healthy pace, confidence in semiconductor and technology companies could recover. Strong earnings, sustained hyperscaler capital expenditure, and evidence of increasing AI adoption could support that reassessment.

The international competition surrounding AI may also limit how aggressively policymakers pursue restrictions that could weaken domestic technology companies.

However, the possibility of a rebound does not establish that current stock prices represent a bottom.

Why further downside remains possible

Even companies with excellent long-term prospects can experience substantial corrections when valuations are elevated or earnings expectations change. If investors anticipate slower growth, reduced infrastructure spending, or weaker returns on AI investments, stock prices could continue declining.

The podcast does not attempt to identify an exact market bottom. Instead, it recognizes that prices could be approaching attractive levels while acknowledging that additional downside remains possible.

This uncertainty is particularly important for investors considering semiconductor companies whose valuations are closely connected to the continuation of the AI infrastructure expansion.

The Next Two Years: Politics, Regulation, and Technological Progress

With the next presidential election approximately two years away, the political environment could remain an important source of uncertainty for technology investors. Legislative proposals, regulatory changes, and debates over data center development may continue influencing market sentiment.

Nevertheless, technological advancement and political decision-making do not always move at the same pace. Companies can continue innovating while governments debate regulatory frameworks, and the competitive incentives driving AI development are unlikely to disappear simply because the political environment becomes less favorable.

The central question for investors is whether the next two years will bring restrictions severe enough to materially alter the financial outlook for AI-related businesses, or whether the market is currently assigning too much importance to an uncertain regulatory future.

Final Thoughts: AI Is Here to Stay, but Stock Prices Are Another Matter

My central argument is that artificial intelligence is unlikely to disappear or become irrelevant because of increased regulation. The technology is already influencing software development, corporate productivity, infrastructure investment, and international competition. Those forces are powerful enough that continued development appears more likely than a complete reversal.

However, believing in the long-term future of AI is not the same as believing that every AI-related stock is attractively valued. Nvidia, AMD, Broadcom, Micron, SanDisk, Seagate, Vertiv, and the hyperscalers operate in different segments of the ecosystem, and their financial performance could respond differently to changes in infrastructure investment.

Regulation may slow certain projects without stopping the broader AI expansion. Reduced capital expenditure could improve hyperscaler free cash flow while creating challenges for semiconductor suppliers. More importantly, even modest changes in expected growth could produce substantial stock-market volatility.

The recent selloff may ultimately prove to be an overreaction, or it may represent an adjustment to more realistic growth expectations. We cannot know that with certainty today. What remains clear is that the intersection of AI, politics, infrastructure, and financial markets will be one of the most important developments to watch over the next several years.

Disclaimer: This article reflects the opinions, estimates, and predictions discussed in the podcast recorded on November 5, 2026. Market figures and company financial estimates mentioned in the recording have not been independently verified. The content is intended for educational and informational purposes and does not constitute financial or investment advice.

Artificial intelligence is driving one of the biggest shifts the technology industry has seen in decades. It is changing how businesses operate, how people find information, and how the world’s largest companies spend their money. Some are pouring hundreds of billions of dollars into AI infrastructure. Others are designing specialized processors, expanding cloud platforms, or chasing ambitious goals in autonomous vehicles, robotics and space.

AI + Snowpal API: Reduce Time to Market

The timing makes this especially interesting. Tech stocks have pulled back after a strong year, and several big names are trading well below their highs. The episode was also recorded around the November 2026 U.S. midterm elections, which historically have been followed by strong months for stocks. Against that backdrop, the question isn’t simply which companies will benefit from AI. It’s which ones can turn technological leadership into durable profits, and whether their share prices already assume too much.

Podcast

Big Tech's $Trillion Gamble: AI, Earnings, and the Next Market Winners — on Apple and Spotify.

Alphabet (Google): Can AI Disrupt the King of Search?

Alphabet reported earnings shortly before we recorded, and I seriously considered trading around them. I passed, not because I expected weak numbers, but because I’m worried about the future of Google Search. By my rough recollection, Alphabet brings in more than $100 billion a quarter, with search making up about half, Google Cloud around 30%, YouTube ads around 10% and everything else roughly 15%. Those estimates don’t add up neatly to 100%, but the point stands: search is the engine of the business, so any lasting damage to its economics matters a great deal.

What concerned me most was the slowdown. Search revenue grew about 12% year over year this period, down from roughly 17% in an earlier comparable period. Alphabet isn’t losing search revenue outright, but when one product carries this much of the company, even a modest drop in growth can hit the valuation hard, and it may signal changing user habits, tougher competition or a maturing business. My own habits are part of why I worry. I used to rely on Google for everything, and now I turn to ChatGPT, Claude and other AI assistants for many of those same questions. That’s one person’s experience, not data, but I doubt I’m alone. Generative AI gives people direct, conversational answers instead of a list of links, and Google now faces real competition from companies that were never considered search rivals. Gemini and AI-powered search may boost engagement, but more time spent doesn’t automatically mean more ad revenue if AI answers are cheaper to monetize than traditional search.

Alphabet is far more than search, though. Google Cloud is growing quickly and competing harder with AWS and Azure, and may be growing faster than both, though that’s worth checking against their reports. Google also designs its own AI chips, called Tensor Processing Units (TPUs), with help from Broadcom. Custom silicon could reduce its reliance on outside suppliers like Nvidia, and I wonder whether Google might eventually sell more of that computing power to other companies rather than keeping it mostly in-house.

On the stock itself, Alphabet was trading just under $280 at recording time, against a high I recalled as roughly $400. By my estimate, it fell about 20% before earnings and another 10–12% after, wiping out perhaps $500 billion in market value. These are approximate figures, and the $400 high in particular needs confirming. None of this changes the fact that Alphabet, under Sundar Pichai, is an extraordinary company with world-class engineers, deep pockets and a broad product lineup. The question is whether Cloud, Gemini, TPUs and YouTube can produce enough new profit to offset any structural pressure on search. The investment question: is the share-price weakness a buying opportunity, or an early sign that the economics of Alphabet’s most important business are changing?

Amazon: Is AWS Worth the Massive AI Investment?

Amazon’s latest earnings showed how jumpy investors have become about AI spending. As I recall, the stock dropped about 11% after hours, recovered to a 5–6% loss, and by the next session was down less than 2%. Notably, Amazon hadn’t backed away from its aggressive infrastructure plans. Investors simply seemed to weigh the enormous spending against AWS’s growth potential and decide it was acceptable, a good reminder that the first after-hours reaction rarely has the final word.

The spending really is enormous. We discussed Amazon potentially putting more than $200 billion into capital expenditure, mostly for AI data centers and hardware, though that’s my estimate rather than confirmed guidance. Spending on that scale isn’t good or bad in itself; what matters is demand, utilization, pricing, depreciation and the returns those assets earn over their lifetime. Here AWS is the key. Amazon’s retail business generates huge revenue on thin margins, while AWS, though a smaller slice of sales (I loosely estimated total quarterly revenue at around $100 billion), has long produced an outsized share of operating profit. Because AI demand flows into a business Amazon already runs profitably, it can grow something proven instead of inventing a new model.

The upside case is striking. I mentioned a scenario, which I attributed to Amazon leadership, where AWS grows to between $500 billion and $1 trillion in annual revenue over roughly five years. The exact source and timeframe need verifying, and it shouldn’t be plugged into a valuation model without scrutiny, but it shows the scale investors are imagining. AWS still faces stiff competition from Azure and Google Cloud, both spending heavily on AI. At recording time, Amazon traded around $250, roughly 12% below a recalled high of about $284. I called that an interesting potential entry point, but a lower price alone doesn’t make a stock cheap. The investment question: can AWS produce enough new revenue and profit to justify Amazon’s massive infrastructure bets while holding its ground against Microsoft and Google?

Apple: The Tech Giant Taking a Different Approach to AI

Apple works very differently from the cloud and chip companies on this list. The iPhone still drives more than half of its revenue, backed by fierce brand loyalty, premium pricing and an ecosystem that keeps customers inside Apple’s world. Services such as subscriptions and software add recurring revenue, which I estimated at around 30% of the total, though that figure should be checked. This mix of hardware and steady services income means Apple’s fortunes don’t hinge on data center construction or chip demand the way its peers’ do.

The stock has had a remarkable year, up roughly 25% in 2026 for a company nearing a $5 trillion valuation. From a $5 trillion base, that would be about $1.25 trillion in added value. At recording time, I had it trading near $340–$350, about 4% below its high, with Apple and Nvidia trading places as the world’s most valuable public company. Those numbers are from memory and need confirming. Partly in jest, I described Apple as spending very little on AI infrastructure, but the serious point is that its business simply doesn’t need the data center footprint of AWS, Azure or Google Cloud. What matters more is product launches and holiday demand. We discussed a premium device I recalled as the “Duo,” priced somewhere between $2,000 and $3,000 (name and price both need verifying), along with a possibly faster release cycle and how a strong holiday quarter could lift earnings.

The catch is valuation. Apple trades at a relatively high forward P/E compared with several peers, a premium investors pay for its ecosystem, brand, cash generation and loyal customers. But a premium sets a high bar, and brand strength doesn’t protect against slower growth, competition or disappointing returns. The investment question: can Apple keep delivering strong earnings and shareholder returns without matching its rivals’ huge AI infrastructure spending?

Broadcom: The Custom AI Chip Opportunity

Broadcom stands out in AI semiconductors because it doesn’t sell what Nvidia sells. Nvidia’s GPUs are flexible processors that handle a wide range of workloads. Broadcom specializes in application-specific integrated circuits (ASICs), chips built for one job that can be far more efficient at it. Its role helping big tech companies design custom AI chips, including Google’s TPUs, puts it in a strong position as hyperscalers try to cut costs, boost performance and control more of their own hardware. AMD competes with Nvidia head-on in GPUs, and Marvell works in custom silicon and networking, but Broadcom’s ASIC focus means it doesn’t compete with Nvidia the way AMD does.

The company is led by Hock Tan, who is originally from Penang, Malaysia, a detail I mentioned because of my family’s ties there, though leadership and results are what count for investors. Broadcom is also more than a chip company. Its acquisition of VMware gave it a large infrastructure software business, which matters when you assess its overall revenue, profit and valuation.

Its share price saw one of the sharpest drops in the series, falling from a recalled high of about $480 to around $330. Using those rounded numbers, that’s a decline of about 31% (I estimated 30–33% on the podcast). A big drop doesn’t automatically make a stock cheap, though. If earnings expectations fall or the old valuation was too rich, a stock can stay expensive even after a steep slide, and Broadcom still carries relatively high trailing and forward P/E ratios compared with Nvidia. We also touched on the increasingly circular nature of AI financing, where companies like Nvidia invest in businesses that then buy their products. These arrangements can be legitimate, but investors should ask whether the underlying demand is real and whether customers can keep funding their commitments. I raised concerns about borrowing, off-balance-sheet deals and credit default swaps, but to be clear, credit default swaps transfer credit risk rather than hide capital spending, and there’s no evidence Broadcom used any particular financing structure. The investment question: does Broadcom’s steep correction create an opportunity, or does its valuation still assume too much AI growth?

Meta: Advertising Profits Versus Enormous AI Spending

Meta makes its money from advertising across Facebook, Instagram, WhatsApp and the rest of its apps. By my rough estimate, ads account for more than 90% of revenue, and Meta reaches something like 3.5 billion people a day (Meta reports several engagement measures, so the exact figure needs checking). That audience makes Meta hard to ignore for any business. At Snowpal we also advertise on LinkedIn and elsewhere, but Meta’s reach makes it central to customer acquisition. My sense is that organic reach is getting harder, which may push businesses to rely even more on paid ads, though that’s an observation rather than a proven trend.

Investors have long applied what I call the “Zuckerberg discount,” a lower valuation reflecting Mark Zuckerberg’s willingness to spend heavily on bets with uncertain payoffs, such as Reality Labs and AI infrastructure. Reality Labs has lost a great deal of money while the ad business keeps producing large profits, and the tension is whether those long-term bets will pay off or simply consume cash that could go to shareholders. The stock’s ride this year shows how quickly sentiment can swing. I recalled Meta trading near $750 before an earlier earnings report, falling more than 10% right after, and eventually dropping below $600, a decline of at least 20%. It then rallied on excitement about new products and AI, only to sell off again when Meta reaffirmed its big spending plans. At recording time, it was around $620 after a drop of nearly 20% over two or three weeks.

AI can make Meta’s existing business better through sharper ad targeting, recommendations, engagement and conversions. But Meta faces a different monetization challenge than AWS or Azure. Cloud providers bill customers directly for computing, while Meta mostly captures AI’s value indirectly through better ad performance. We also mentioned a new product I recalled as “Muse” that had generated buzz, though its identity and results need verifying. The bigger question is whether Meta can build meaningful new AI revenue on top of its ad engine. The investment question: can Meta’s huge audience and ad profits fund its AI ambitions without capital spending overwhelming future returns?

Microsoft: Enterprise AI Meets Cloud Computing

Microsoft has staged a strong comeback. The stock traded around $380 roughly two to three months before the recording and climbed back to about $520. I called it a 30% gain on the podcast; using those rounded prices it’s closer to 37%, a big move for a company this size. Part of that was catch-up, since Microsoft had lagged earlier, but its cloud business is clearly firing. Azure is benefiting from strong demand for computing and AI services, and Microsoft’s biggest advantage is distribution. Companies already using Microsoft 365, Azure and GitHub can add AI features without overhauling their technology, giving Microsoft several ways to cash in: cloud infrastructure, software subscriptions and productivity tools.

The build-out is happening fast. I mentioned Microsoft opening about 25 data centers recently, though I wasn’t sure whether that was in one quarter or year to date, and the figure needs verifying. Either way, turning that new capacity into profitable demand is critical given how much the industry is spending. I also brought up reports or impressions of large workforce cuts or voluntary retirement programs, speculating about figures as high as 25% of staff or around 60,000 employees. Those numbers are unconfirmed and shouldn’t be treated as Microsoft announcements, nor should any job cuts automatically be blamed on AI. Still, the broader idea is worth watching: if AI agents can automate work employees used to do, Microsoft could improve its own margins while selling the same capabilities to customers.

Under Satya Nadella, Microsoft has become a leading enterprise cloud and software company, and we spoke highly of its management. The issue is price. After its rebound, the stock sits fairly close to its highs, which makes it less obviously attractive than names that have corrected more. Forward P/E, price-to-sales, earnings growth and capital spending all matter in judging what return it can deliver from here. The investment question: can Microsoft’s enterprise reach and Azure growth generate enough earnings to justify its valuation after such a strong recovery?

Nvidia: The AI Chip Leader Everyone Is Watching

Nvidia is approaching a $5 trillion valuation and trades places with Apple as the world’s most valuable company. Under Jensen Huang, it has become the essential supplier of the GPUs used to train and run AI models, and its lead rests not only on hardware but on its software ecosystem, engineering depth and close customer relationships. At recording time, the stock was around $206, against a high I put at $238–$240. From $240, that’s a drop of about 14% (I said roughly 12% on the podcast). It had traded around $215, $220 and $225 in prior months, which made me wonder whether the dip might be a good time to build a long-term position gradually. That wasn’t a call to buy right away, just an observation about how a correction shifts the balance between price and expected returns.

Could Nvidia reach $6, $7, $8 or even $10 trillion? Going from $5 trillion to $10 trillion means doubling, which gets harder the bigger a company becomes. Future gains depend on earnings growth, valuation multiples and holding its competitive position, and I’d caution against leaning too much on analyst price targets, which shift quickly. Competition comes from two directions. AMD challenges Nvidia directly in GPUs, while Google, Amazon and other hyperscalers are designing their own chips. Those in-house chips may not compete everywhere, but every one a customer builds for itself is one it doesn’t buy from Nvidia, and that can shrink Nvidia’s market even if the hyperscaler never sells chips to anyone else.

There are also questions about how long the current boom lasts. I speculated that Nvidia and other suppliers may have demand lined up several quarters ahead, possibly into late 2027 or early 2028, though that’s an estimate, not a confirmed backlog. Eventually the build-out will mature, and customers may slow purchases, squeeze more out of existing hardware or switch architectures. Depreciation matters too. If these expensive chips stay useful for four to six years, the economics look one way. If newer generations make them obsolete sooner, they look worse, although older chips could be resold to smaller data centers that don’t need the latest hardware. On the positive side, demand is spreading beyond the big cloud providers to governments and enterprises building private AI, and sovereign AI efforts, where countries want their own computing capacity, could widen the market further. The investment question: can Nvidia keep its lead and pricing power as its biggest customers build alternatives and AI infrastructure economics evolve?

TSMC: The Company Behind the Chips

Taiwan Semiconductor Manufacturing Company holds a crucial spot in the industry because it actually makes the advanced chips that Nvidia and other designers create. Designing a chip is only half the job. Someone has to manufacture it at scale, and that takes enormous capital, deep engineering expertise and extreme precision. With a market value approaching $2 trillion, TSMC benefits from demand across many customers and product types rather than depending on any single AI application. The trade-off is that chipmaking is capital-intensive and cyclical, so TSMC must keep pouring money into cutting-edge factories.

Geography is the other big factor. TSMC is expanding in Arizona to build manufacturing capacity in the United States, but it remains headquartered in Taiwan, where tensions with China add a layer of risk. I’m more cautious about companies with that kind of exposure, even while recognizing TSMC’s engineering strength and importance. That risk isn’t necessarily a reason to avoid the stock, but it belongs in the analysis alongside valuation and growth. The investment question: can TSMC’s manufacturing leadership and broad customer base outweigh its geopolitical exposure and capital-heavy business model?

Tesla: Is the Future About Cars, Software, or Robots?

Tesla, valued at around $1.5 trillion, is hard to judge with normal car-company metrics because so much of its story rests on technologies that may take years to reach real scale: self-driving software, robotaxis and humanoid robots. Full Self-Driving (FSD) was a big part of our discussion. I suspect some buyers now choose Tesla specifically for FSD rather than just picking an electric car. If adoption grows, subscriptions and other recurring payments could become a major revenue stream, but that depends on how well the technology performs, how regulators respond and whether customers feel it’s worth paying for month after month. Robotaxis could go further, creating a business model quite different from selling cars. Tesla is rolling out autonomous rides in select cities, yet the economics are still unproven, with fleet utilization, maintenance, insurance, regulation, reliability and demand all affecting profitability.

The boldest idea is Optimus, Tesla’s humanoid robot. We speculated about prices around $20,000 to $30,000 per unit and the possibility of selling hundreds of thousands a year if the technology works. These are hypothetical scenarios, not forecasts. If robots could reliably do valuable work at those prices, the market could be huge, but demos and ambitions are not the same as proven manufacturing, real demand and profits. Meanwhile, competition in electric vehicles is fierce, especially from BYD. I’m skeptical that BYD will easily enter the U.S. passenger car market given political, regulatory and security hurdles, but Tesla sells worldwide and already competes with Chinese automakers in many markets.

Tesla’s trailing and forward P/E ratios are high compared with more established tech companies, a sign that investors are paying mostly for future possibilities rather than today’s earnings. The stock can swing wildly day to day, so time horizon and risk tolerance matter a lot. True believers in autonomy and robotics may happily ride out long stretches of uncertainty, while skeptics may prefer to stay on the sidelines. The investment question: how much of Tesla’s valuation is supported by its current business, and how much depends on ambitious future technologies succeeding?

SpaceX: A Different Kind of Technology Investment

SpaceX came up with an estimated valuation of around $1.8 trillion, a figure from memory that needs checking. The recording also referred to a SpaceX IPO and later share-price moves; its listing status should be confirmed before publication, because a private-market valuation can’t be read the same way as the constantly traded market cap of a public company. We also played with the idea of combining Tesla and SpaceX. Using the rough figures of $1.5 trillion and $1.8 trillion, the combined company would be worth about $3.3 trillion, bigger than many established tech firms. That’s purely a hypothetical exercise, not evidence of any planned merger.

On revenue, I recalled about $2 billion a quarter, set against much larger long-term ambitions attributed to Elon Musk, and both need verifying. The gap between them illustrates a core challenge: when a valuation rests on growth far in the future, small changes in assumptions produce huge swings in value. SpaceX does have tangible businesses to anchor it, including rocket launches for commercial and government customers and Starlink’s recurring satellite internet revenue, though infrastructure costs, competition, regulation and capital spending still weigh on the picture. Like Tesla, SpaceX pairs bold goals with real uncertainty about execution and timing, so investors need to separate what management hopes to do from what it has already proven, and decide how much volatility they can live with. The investment question: can SpaceX’s launch and satellite businesses generate enough sustainable profit to justify its ambitious valuation and growth expectations?

Beyond the Giants: AMD, Marvell, Micron and Emerging AI Infrastructure

Several other companies deserve attention. AMD, led by Dr. Lisa Su, has grown from a much smaller player into a major force in advanced computing and AI accelerators, and I recalled it approaching a trillion-dollar valuation, though that needs checking. I also mentioned that Lisa Su and Nvidia’s Jensen Huang are relatives, and both run impressive companies. Marvell works in custom silicon and AI networking, while Micron matters because memory is essential to advanced AI computing, making it worth a closer look in a future episode. We also touched on newer AI cloud providers such as CoreWeave and Nebius. These companies may offer faster growth than the giants, but their smaller size brings bigger risks around financing, customer concentration and execution.

The Bigger Picture: Valuation, Market Timing and Risk

Because we recorded around the November 2026 midterms, we discussed a historical pattern: over roughly the past four decades, stocks have often done well in the nine months after midterm elections. It’s just as important to look at the nine months before, and history offers context, not guarantees. Valuations, interest rates, earnings and the economy can make each cycle very different. The backdrop also included a sharp tech sell-off, with the Nasdaq falling an estimated 1,200–1,500 points over two sessions (exact size and dates need checking) after a strong run in tech and semiconductor stocks. Corrections like this can create opportunities, but the key is telling a temporary mood swing apart from a real decline in a company’s fundamentals.

Valuation came up again and again. Forward P/E compares the share price with expected earnings, trailing P/E uses past earnings, price-to-sales measures value against revenue, and the PEG ratio relates the P/E to expected growth. My general impression was that Nvidia, Alphabet and Meta looked more attractive on some forward measures, Broadcom and Apple looked relatively expensive, and Microsoft fell somewhere in between. These were impressions, not a verified side-by-side comparison, and no exact ratios were given on the podcast, so adding numbers would require independent research.

Then there’s portfolio construction. You can spread money across many companies or concentrate it in a few, as investors like Warren Buffett and Bill Ackman are known for. Concentration can deliver outsized returns when you’re right and painful losses when you’re wrong, while diversification reduces reliance on any single outcome without removing market risk. The right mix depends on your time horizon, finances and tolerance for swings. I also talked about dollar-cost averaging, buying shares of a company like Nvidia gradually rather than all at once. That reduces the pressure to pick a perfect entry point, but averaging down doesn’t make a falling stock safer, so you have to keep checking whether your original thesis still holds. Finally, there’s opportunity cost. Even if all ten companies thrive, their stock returns could differ wildly, with one doubling while another goes nowhere for years. Money in one can’t be working in another, so the challenge isn’t just finding great businesses. It’s picking investments whose expected returns justify their risks.

By the Numbers

All figures are approximate recollections and as of November 2026; percentages are calculated from those rounded numbers and are unverified.

Share prices at recording

Valuations

Revenue, spending and growth

Market backdrop

Final Thoughts: Not Every AI Winner Will Be a Stock Market Winner

AI is opening huge opportunities across chips, cloud computing, enterprise software, advertising, consumer devices, self-driving cars, robotics and space. The ten companies in this series come at it from very different angles. Nvidia supplies the critical hardware, Broadcom enables custom silicon, TSMC manufactures the chips, and Amazon, Microsoft and Google run the major cloud platforms. Meta and Apple bring massive consumer ecosystems, while Tesla and SpaceX chase ambitious technologies with potentially transformative long-term payoffs.

But technological leadership doesn’t guarantee good investment returns. Capital spending has to turn into profit, competitive advantages have to last, and valuations have to rest on realistic expectations. Tech history is full of companies that once seemed untouchable. IBM was among the most influential names in computing, yet the industry moved in ways that changed its standing, and today’s leaders could face similar shifts as AI changes how software, infrastructure and consumer products are built and sold. Some of these companies may one day be worth $6, $8 or even $10 trillion. Others may struggle to hold their current values, and new competitors will emerge.

The real challenge isn’t figuring out which companies are involved in AI. It’s identifying which ones can turn that involvement into sustainable earnings, strong returns on capital and long-term shareholder value. A wonderful company can still be a disappointing investment if you overpay, while a temporary correction can create an opportunity when the business underneath remains strong. The questions worth continuing to explore are simple to ask and hard to answer: which companies have the strongest competitive advantages, which can monetize AI most effectively, which are taking on too much financial risk, and which are priced well enough to reward investors for the uncertainty they’re accepting?

Editor’s note: This article reflects the estimates, market observations and opinions shared on the Snowpal podcast recorded in November 2026. Prices, valuations, percentages, company statements and hypothetical scenarios have not been independently verified and should be fact-checked before publication. This is educational commentary, not personalized financial advice.

AI + Snowpal API: Reduce Time to Market

In this episode, host Krish Palaniappan speaks with Mandar Chaudhari, a full-stack geospatial engineer at Land IQ and aviation researcher at George Mason University. Mandar walks through RASAT (Regional Air Service Analysis Tool), a research application developed through his work with Dr. Lance Sherry at the Center for Air Transportation Systems Research. Their conversation explores the problem RASAT addresses, its underlying architecture, the selection of machine learning algorithms, data processing pipelines, geospatial visualization, and the broader challenges of building products that solve meaningful problems.

Podcast

A practical exploration of regional airport viability, machine learning, data engineering, model explainability, and the challenges of turning research into useful software — on Apple and Spotify.

Understanding the Problem: Which Airports Could Support Commercial Service?

The United States has thousands of airports, but only a portion offer regularly scheduled commercial passenger flights. Some serve private aviation, flight training, and other general aviation activities, while others provide commercial service supported by federal subsidies through the Essential Air Service (EAS) program. RASAT attempts to identify airports whose surrounding communities exhibit characteristics associated with successful commercial airline operations. Consider a small town where residents must drive several hours to reach an airport with scheduled flights. If that community has a growing population, meaningful economic activity, and tourism demand, could its local airport potentially support commercial service?

RASAT categorizes airports into three groups: Type 1 airports without scheduled commercial passenger service, Type 2 airports with subsidized service, and Type 3 airports with unsubsidized commercial service. Type 3 airports provide positive training examples because they already support commercial operations without subsidies, while Types 1 and 2 provide contrasting examples. The objective is to identify airports in the latter groups whose characteristics resemble those of airports already supporting unsubsidized service. Mandar emphasizes that the tool is intended for initial screening rather than replacing detailed aviation feasibility studies, which must also consider passenger demand, airline economics, operating costs, aircraft availability, and other operational factors.

Using Machine Learning Instead of Manually Weighted Rules

One approach to evaluating airports would be to identify relevant characteristics, assign weights to each, and calculate an overall score. Krish raises this possibility, comparing the problem to evaluating a collection of records through a consistent set of parameters. RASAT takes a different approach by using XGBoost, an open-source machine learning library particularly well suited to structured, tabular datasets. Rather than manually assigning fixed weights, the model learns relationships between airport characteristics and existing commercial service patterns.

The research incorporates approximately 45 features covering demographics, economics, hospitality, alternative transportation, nearby airports, ports, borders, and industry composition. Population, population growth, median household income, poverty rates, gross regional product, tourism activity, and proximity to other commercial airports provide different perspectives on potential passenger demand. Some relationships are indirect. For example, proximity to a seaport may indicate logistics, manufacturing, or international trade activity that could contribute to business travel, even though the port itself primarily handles freight.

Mandar explains that the feature selection process was informed by aviation expertise and the availability of consistent data across airports, rather than relying on another AI model to recommend parameters. The team considered alternatives such as logistic regression and random forests before selecting XGBoost for its ability to capture nonlinear relationships and interactions between variables. A large population alone may not indicate strong commercial potential, but population combined with tourism activity and limited access to alternative airports could provide a more meaningful signal.

Understanding Commercial Viability Scores and Model Explainability

RASAT generates a commercial viability score for each airport, indicating how closely its regional characteristics align with patterns learned from airports supporting unsubsidized commercial service. During the demonstration, Mandar selects Friedman Memorial Airport in Idaho, which receives a score of approximately 92.3. John F. Kennedy International Airport receives a score of approximately 90, illustrating an important distinction: the score is not a ranking based on airport size, passenger volume, or proximity to a major international hub. A smaller airport can receive a higher score than a major airport because the model evaluates regional characteristics rather than treating the largest airports as ideal benchmarks.

The application also explains which features influence individual predictions using SHAP, a technique for interpreting machine learning outputs. Instead of presenting a score without context, RASAT displays feature contributions so researchers can understand which variables influence an airport’s assessment. For example, median household income, proximity to tourist destinations, or distance from alternative airports may contribute differently depending on the airport being evaluated. These are not fixed coefficients applied uniformly across every airport. Their influence varies according to the relationships learned by the model. The demonstration also surfaces a presentation issue: the displayed feature contributions do not appear to total 100%, potentially because some features are omitted from the interface. This reinforces the importance of ensuring that model explanations are presented accurately and transparently.

Data Engineering: The Foundation of the Application

A significant portion of the discussion focuses on the work required before machine learning can begin. RASAT combines information from several public sources, including the U.S. Census Bureau, Federal Aviation Administration, Department of Transportation, Bureau of Economic Analysis, National Park Service, and OpenStreetMap. These sources provide data in different formats, including JSON responses from APIs, downloadable CSV files, spreadsheets, and geographic datasets. The engineering challenge is to collect, preserve, clean, normalize, and combine this information into a consistent representation for every airport.

Mandar describes a Python-based data processing pipeline that begins by preserving the original source files. Separate scripts retrieve datasets, standardize identifiers, handle missing values, and convert information into compatible structures. Geographic aggregation is particularly important because many demographic and economic datasets are organized by county rather than airport. RASAT uses airport coordinates to identify surrounding counties within a defined catchment area, generally around 60 miles for regional demographic features, and aggregates the relevant information into airport-level records. This transforms disparate county-level statistics into features that can be associated with individual airports.

Interestingly, the application does not rely on a traditional SQL, NoSQL, or vector database. Its research-oriented architecture uses files throughout the processing pipeline. Once the data is prepared and the machine learning model has generated its predictions, the application stores airport records, feature values, scores, and contributions in precomputed JSON files. The web application loads these records and displays the relevant information when a user selects an airport. Updated source data can be incorporated by rerunning the Python pipeline and regenerating the output files. This architecture keeps the application relatively straightforward while separating data preparation and model execution from the user-facing interface.

Local Machine Learning Development and Cloud Costs

The conversation also examines whether machine learning applications require expensive cloud infrastructure. Mandar explains that RASAT’s data processing, feature engineering, and model training were performed locally on his computer, with the web application deployed through a hosting platform. The relatively modest dataset—roughly a few thousand airports with approximately 45 features each—does not inherently require large-scale distributed infrastructure.

Krish connects this to a broader concern faced by independent developers and startups: the cost of cloud services, model usage, and infrastructure during experimentation. While cloud platforms such as AWS offer substantial capabilities, usage-based pricing can become expensive without appropriate controls. Mandar contrasts RASAT’s local development approach with his professional work at Land IQ, where AWS services such as EC2 and Lambda support hosted applications and data processing workflows. Their discussion highlights the importance of choosing infrastructure according to actual project requirements rather than assuming every machine learning application needs an elaborate cloud architecture.

Building an Interactive Geospatial Application

RASAT uses Mapbox to visualize airports geographically and allow users to explore their surrounding regions. The interface includes an airport selector, commercial viability scores, feature values, contribution indicators, and an interactive map. Airports are distinguished by their service categories, and users can inspect locations and nearby alternatives. Geographic visualization is particularly relevant because proximity to other commercial airports, regional population centers, and transportation infrastructure influences how an airport’s potential should be interpreted.

Krish questions whether a graphical interface is necessary when the underlying information could be queried through an API or conversational interface. Mandar acknowledges that questions such as identifying the five highest-scoring airports without commercial service could be answered directly from the processed data. RASAT also provides downloadable rankings that can be filtered and sorted. However, he argues that the map and dashboard support a different kind of exploration. A researcher may not know which questions to ask initially, and seeing nearby airports or geographic relationships can reveal patterns that might not emerge from a textual response. The distinction is between retrieving a known answer and discovering relationships through visual exploration.

Limitations: Airfare, Passenger Behavior, and Real-World Demand

One of the more interesting exchanges concerns factors that RASAT does not currently incorporate. Krish uses the Washington, DC metropolitan area as an example, where travelers may choose among Dulles International Airport, Reagan National Airport, and Baltimore/Washington International Airport. Proximity matters, but passengers may willingly travel farther for cheaper tickets, more convenient schedules, or direct flights. If an airport scores highly based on regional population and economic activity, does that necessarily mean passengers will choose to fly from it?

Mandar acknowledges that airfare is an important limitation of the current model. Airports without scheduled passenger service do not have existing airfare data, while prices at operating airports vary significantly by airline, destination, season, and booking date. This makes it difficult to construct a consistent pricing feature across the dataset. Similarly, strong regional characteristics do not guarantee actual passenger demand. For airports already offering commercial service, passenger traffic and load factors can provide additional context, but airports without service lack equivalent historical observations.

The discussion identifies a potential direction for further research: comparing predicted viability against observed passenger behavior, including where residents currently travel to catch flights, what they pay, and which destinations they choose. Such information could help distinguish between an airport that appears promising based on regional characteristics and one that could realistically attract sufficient passengers to support airline operations.

Where Does the Engineering Effort Actually Go?

Krish asks Mandar to hypothetically divide 100 hours of project development across research, data acquisition, processing, machine learning, and interface development. Mandar estimates that problem definition might account for approximately 10 hours, data discovery and validation for 20, cleaning and feature engineering for 20, pipeline integration and machine learning for another 20, and experimentation and evaluation for approximately 20 more. The remaining 10 hours would go toward the web application and integration.

Although these are illustrative estimates rather than actual project time records, they reveal an important characteristic of applied machine learning: the majority of the work may occur outside the visible application. Mandar identifies research and analysis as the most challenging aspects, while building the interface was comparatively straightforward. The discussion also considers how AI-assisted coding tools are changing the skills required for projects like RASAT. When asked which capabilities he would prioritize when hiring someone for similar work, Mandar identifies problem-solving and analytical thinking first, followed by data engineering and data literacy. Programming remains useful, but the ability to define ambiguous problems, identify suitable data, and evaluate results is central to the project’s success.

From Software Engineer to Product Builder

The final portion of the conversation moves beyond aviation analytics when Mandar asks Krish how an engineer can develop a product-oriented mindset. Drawing on his experience building products at Snowpal, Krish explains that developing technically sophisticated software is only one part of creating a successful business. Engineers accustomed to receiving requirements may underestimate the difficulty of identifying customer needs, validating demand, marketing products, acquiring customers, and generating revenue.

One of his most important lessons is that developers frequently overestimate the value of features they find technically challenging. A capability that required months of engineering might generate little customer interest, while a relatively simple feature could prove highly valuable. This creates a difficult psychological challenge: developers become attached to what they build and may resist removing or simplifying features that customers do not need.

Krish advocates shipping early versions quickly, even when they lack the polish developers would ideally prefer. The goal is to validate the core value of a feature before investing heavily in supporting functionality. He compares this to demonstrating the experience of living on the 57th floor of a building without first constructing and presenting all 56 floors beneath it. In software, the challenge is finding ways to demonstrate the most valuable capability without spending excessive time building infrastructure that customers may not care about.

The conversation also addresses entrepreneurship more broadly. Krish emphasizes that starting a company involves substantially more than engineering and is rarely the easiest path to making money. Sales, customer acquisition, product positioning, hiring, and sustaining motivation can prove more difficult than writing the software itself. For engineers considering entrepreneurship, understanding these responsibilities is essential to moving from implementing requirements to building products that people actually want.

Conclusion

RASAT provides a practical example of applying machine learning to a real-world transportation research problem. By combining public aviation, demographic, economic, and geographic datasets, the application helps researchers identify regional airports whose characteristics suggest potential for unsubsidized commercial service. Its architecture demonstrates how Python-based data pipelines, XGBoost, SHAP, precomputed JSON files, and Mapbox can work together without requiring an expensive or unnecessarily complex infrastructure.

Equally important are the broader engineering lessons that emerge from the discussion. Selecting an algorithm is only one part of building an analytical application. Understanding the problem, collecting reliable data, designing meaningful features, explaining predictions, recognizing limitations, and presenting results in a useful form all contribute to the quality of the solution. The conversation also reinforces the distinction between creating technically sound software and building a successful product.

For students, early-career engineers, and independent developers, Mandar’s experience offers an encouraging example of what can be accomplished with publicly available datasets, established machine learning libraries, and a focused research question. Meaningful software does not necessarily require a large team or expensive infrastructure, but it does require curiosity, disciplined problem-solving, and a willingness to test assumptions.

AI + Snowpal API: Reduce Time to Market

Drawing on their experiences in software development and entrepreneurship, they explore practical questions about organizational structure, technical expertise, AI spending, and the emergence of software ecosystems designed for autonomous agents.

Podcast

Exploring the changing economics of software engineering, the future of technology consulting, AI-driven workflows, and agent-to-agent integrations — on Apple and Spotify.

Building Software Is Easier. Building Reliable Products Is Another Matter.

Giacomo began developing iPhone applications as a teenager in Florence, Italy, eventually turning his interest into a career spanning more than a decade. Today, he helps startup founders and business owners navigate technology decisions, evaluate development proposals, and avoid architectural mistakes. He describes a client who initially had a family member build an application using AI-assisted coding tools. Although the application looked impressive, the client returned several months later seeking professional help because the underlying implementation wasn’t sufficiently reliable for business operations. The experience illustrates the distinction between generating functional code and engineering software that can support a growing business. Technical decisions have consequences extending beyond the initial implementation, including maintainability, scalability, security, and operational reliability. Giacomo’s advisory role focuses on anticipating these consequences and translating between business objectives and technical realities, often helping organizations make important decisions without requiring a permanent executive or engineering hire.

Is Traditional Technology Consulting Becoming Obsolete?

One of the conversation’s central questions is whether organizations will continue paying consultants for work they can increasingly accomplish using the same AI tools. Historically, consulting firms provided specialized expertise, development capacity, project management, and access to talent that businesses couldn’t justify employing full-time. But when software implementation, documentation, research, and analysis become more accessible, consultants must reconsider their value proposition. Krish questions why a company should pay an external consultant to use tools that its own employees could operate directly. Giacomo suggests that consulting will increasingly move toward strategic advisory work, helping organizations determine what to build, evaluate technical decisions, implement effective AI workflows, and organize internal knowledge. Rather than performing every task for a client, consultants may help clients develop the capabilities to execute independently. This creates opportunities for professionals who can combine technical experience with business judgment, while placing pressure on consulting models built primarily around billable implementation hours.

Smaller Teams, Accountability, and the Future of Employment

The discussion examines the implications of reducing organizational layers, particularly middle-management positions and traditional software development roles. Giacomo argues that smaller teams can accomplish considerably more when employees possess strong domain expertise and understand their organization’s priorities. He emphasizes accountability over elaborate management structures, suggesting that companies may increasingly favor individuals who can make decisions, supervise automated processes, and take ownership of outcomes. The conversation also explores whether white-collar professions face greater exposure to automation than jobs requiring physical presence. Software development, technical writing, administrative work, and other computer-based activities are particularly suitable for AI-assisted workflows, while hospitality and similar industries still require people to perform physical services.

Krish introduces an additional economic consideration: industries can experience disruption even when their own operations are difficult to automate. If a consulting engagement previously required ten employees to travel regularly but now requires only two, hotels, airlines, restaurants, and other businesses serving those travelers could experience reduced demand. Giacomo distinguishes this indirect impact from the automation of hotel operations themselves, where housekeeping and guest services still require physical labor. Their exchange highlights the broader economic consequences of changing workforce requirements and raises questions about how employment patterns, business travel, and service industries might evolve.

From Manual Coding to Automated Development Pipelines

Giacomo shares a particularly striking example from his own development work. Although he has largely stopped writing code manually, he reports releasing approximately 30 iOS applications and 40 Android applications over five months using AI-assisted workflows. For certain applications, work that previously required six to eight months can now be completed in a morning. His approach extends well beyond code generation. He describes an automated pipeline covering idea discovery, market research, competitor analysis, user-review mining, feature prioritization, implementation planning, coding, and validation. Multiple agents and models review one another’s plans and outputs, allowing him to supervise the process rather than manually execute every step.

An important part of this approach is capturing knowledge that would otherwise remain undocumented. Giacomo calls this creating a map of work: recording business rules, procedures, technical requirements, and accumulated experience so that agents can operate with organizational context. He also describes changing his approach to repetitive tasks. Previously, he might automate something after performing it several times; now, he aims to capture the process immediately so it can be reused. The resulting system moves human involvement toward defined checkpoints for review, verification, and decision-making. His experience illustrates how development productivity can depend as much on workflow design and knowledge management as on the capabilities of individual models.

The Economics of AI: Employees, Tokens, and Return on Investment

A substantial portion of the conversation focuses on a difficult financial question: how should companies balance spending on human employees against spending on AI tools and tokens? Krish considers hypothetical startups choosing between hiring additional developers and allocating larger budgets to AI infrastructure. He also connects the question to the enormous capital expenditures of major technology companies, whose investments in AI infrastructure have raised investor concerns about profitability and future returns. For smaller organizations, the challenge is more immediate: determining whether additional model usage creates enough value to justify its cost.

Giacomo acknowledges that there is no straightforward formula for measuring AI’s return on investment. Productivity improvements may be visible, but translating them into financial outcomes depends on the business, the task, and the organization’s growth strategy. A company might use AI to reduce staffing requirements, accelerate its existing roadmap, or pursue additional projects without increasing headcount. Each approach produces a different economic result. He also cautions against optimizing token costs too early in the adoption process. Organizations still experimenting with AI should first identify workflows that create meaningful value, then improve efficiency through techniques such as selecting less expensive models or adjusting reasoning requirements. His concern is that aggressively minimizing initial expenditure could prevent companies from discovering opportunities whose benefits substantially exceed the cost of experimentation.

Agent-to-Agent APIs: A New Model for Software Integration

The conversation turns to the changing role of APIs as AI agents become more involved in software development. Krish explains how Snowpal’s API-first business, which offers several RESTful APIs through AWS Marketplace, is adapting to this shift. Traditionally, developers read documentation, selected endpoints, obtained API credentials, and wrote integration code. Increasingly, users can describe a business problem to an AI agent and rely on it to identify suitable APIs, generate the necessary code, and combine services from multiple providers. The developer may not need to understand every underlying endpoint or even know which provider supplies a particular capability.

This creates new requirements for API businesses. Documentation must be accessible not only to human developers but also to agents that need to discover services, understand their capabilities, and integrate them correctly. Krish discusses the importance of adapting API descriptions, documentation formats, and supporting files for agent consumption. Giacomo shares related work converting projects into MCP-compatible tools and plugins, reflecting growing interest in agent-accessible software interfaces. Both recognize that agent-to-agent interaction could change how software services are discovered, distributed, and consumed. For API providers, making products understandable and usable by autonomous systems may become an important part of their distribution strategy.

What Happens to Technical Expertise?

The conversation ultimately raises a broader question about the skills developers, consultants, and technology professionals should cultivate. Krish describes his own movement away from manually writing code and toward reviewing generated implementations, evaluating design patterns, identifying potential problems, and supervising agents. Giacomo’s experience reinforces the importance of technical judgment, domain expertise, and the ability to organize complex workflows. Professionals who understand business requirements and can evaluate the quality of AI-generated work may be better positioned than those whose value depends primarily on executing repetitive technical tasks.

The discussion also acknowledges uncertainty. Neither participant claims to know precisely how consulting demand, employment levels, or organizational structures will evolve. What emerges instead is a practical framework for adapting: understand the business problem, develop strong technical judgment, experiment with automated workflows, capture institutional knowledge, and evaluate investments against measurable outcomes.

Conclusion

The conversation highlights several interconnected changes in the technology industry: software implementation is becoming more accessible, traditional consulting models face pricing pressure, organizational structures may become leaner, and APIs are evolving to serve autonomous agents. Yet easier implementation does not eliminate the need for reliable architecture, sound business decisions, or accountability. Giacomo’s development experience demonstrates the potential of coordinated AI workflows, while the discussion of consulting economics and token spending reveals the challenges businesses must still resolve.

For founders, developers, consultants, and technology leaders, the central question is no longer simply how quickly software can be produced. It is how to build dependable products, organize work efficiently, allocate resources intelligently, and develop expertise that remains valuable as implementation costs decline. The competitive advantage may increasingly belong to those who understand what needs to be built, why it matters, and how to deliver it reliably.

Read more

Most organizations have already tried AI. They’ve drafted emails with ChatGPT, built slides with Claude, and maybe run a pilot or two. Many of those pilots quietly stalled. In this episode of the Snowpal Podcast, Krish talks with Trehan Stenton, who helps multi-location and growing businesses turn strategy into process and then uses AI and change management to make those changes stick. His main argument: when AI implementations fail, the tool is rarely the cause. The usual causes are unclear processes, messy data, missing governance, and people who were never told why the change is happening.

AI + Snowpal API: Reduce Time to Market

Podcast

The Human Side of AI: Leading Change That Lasts — on Apple and Spotify.

1. Why pilots fail

Trehan cites research estimating that about 95% of AI pilots fail. In his experience, the causes are consistent:

• The expected results are unrealistic. Leadership treats AI as a fix for the whole organization, but it can’t be one.

• The rollout moves faster than people can absorb it. An excited CEO pushes AI down the org chart, and middle managers are left unsure how to apply it.

• The tools sit on broken processes. If the process underneath is incomplete, the data is dirty, or information is spread across systems, the model gives wrong answers. Automating a mess makes the mess bigger.

• People stop trusting it. One bad answer (”I tried Claude and it was completely wrong”) turns into resistance to every AI tool that comes after.

His key distinction is that using AI as a personal assistant and using it inside business workflows are different disciplines. Writing emails and slides needs no governance. Automating workflows and deploying agents need defined requirements, success metrics, exception handling, and a governance model.

2. Case study: two AI rollouts in dentistry

Trehan has a healthcare background and offers two examples from dental practices. They show that the same kind of technology can fail or succeed depending on how it’s introduced.

AI radiography: what went wrong, then what fixed it

AI-assisted radiograph analysis marks likely decay, recession, and cracks on the image, which helps both the clinician and the patient see the problem. The first rollout struggled:

• Clinicians weren’t told how the model reaches its conclusions, so they didn’t trust it.

• Nobody explained that the system has to be trained with feedback, the same way a new dental assistant isn’t fully capable on day one.

• Distrust of this one tool spread into resistance to AI tools in general.

The fix was mostly about positioning. The tool was reintroduced as a “second opinion.” The clinician is still the primary decision-maker, and the AI adds another view. After that change, adoption picked up quickly.

Ambient transcription: success from the first day

Ambient AI scribes record the clinical conversation (in a HIPAA-compliant way) and draft notes and treatment outcomes. This rollout worked from the start because it:

• Started small with one group of users, the hygienists.

• Delivered an obvious benefit right away: about 10 minutes saved per hour on writing notes.

• Kept a human reviewing the output. Hygienists checked the notes before they went into the system.

• Posed a low threat to clinicians’ professional identity. It took over a chore and left their judgment alone.

Pattern to reuse: choose first use cases that are high-benefit, low-risk, and low ego-impact. They produce people who will advocate for the next rollout.

3. Process first: a framework for implementation

Trehan jokes that his advice is always “boring,” but the order of steps matters:

1. Start with why. Leadership states the direction and the reasons behind it, so the team understands the change instead of seeing it as a threat.

2. Set priorities. Decide what the effort is for: efficiency, revenue, or customer experience.

3. Map the core processes. Document how work actually gets done today, including where the bottlenecks are.

4. Redesign the processes, don’t just speed them up. She cites research finding that only about 35% of organizations implementing AI actually redesign the underlying process. The rest try to make a five-year-old workflow run faster.

5. Clean the data and plan for exceptions. Models are only as good as the data and edge-case handling underneath them.

6. Apply tools to specific areas, at specific times, for specific outputs. Avoid broad multi-department transformations.

7. Define failure along with success. Run a time-boxed trial (for example, three months) with clear kill criteria, so a failing initiative gets shut down and replaced instead of lingering.

8. Build on small wins. Each quick win makes people more willing to accept the next change.

4. Governance and the cost of letting everyone experiment

Without governance, broad access to AI burns budget without producing results. Trehan mentions a report that Uber employees used about three months’ worth of tokens in one week after the company opened generative AI to everyone, with little to show for it.

Governance also covers accountability. Directors and boards are still responsible for decisions made in the business, whether a person or a model produced them. Trehan points to the case where an airline argued that its customer-service chatbot was effectively a separate entity. The court disagreed: the bot belongs to the company, so its decisions are the company’s responsibility. In legal and regulated settings especially, “the model told me” is not an audit trail.

Questions every AI program should be able to answer:

• Is the organization aligned on direction and priorities?

• Does the governance model keep up with how fast decisions are now being made?

• Where does risk sit in each automated process, and who owns it?

• What is the budget for tokens and compute, and how is usage monitored?

5. The real cost of an AI-assisted role

Krish raises a practical question that many startups now face. The cost of getting work done is no longer just salary:

Total cost of output = Human cost + AI cost (tokens, models, tooling)

Take two extremes for an engineering role:

Trehan’s answer: it depends on the process, but he would pay more for someone with a curious, questioning mind. His reasoning is that cheap labor producing AI output still needs an expensive person to validate it. When she builds agents for a manufacturing client, she wants a strong analyst who can question the numbers, understand what they mean for the business, and make recommendations, not someone who just generates answers.

The cost that gets overlooked is validation. If nobody on the team can tell whether an output is correct, the AI spend is wasted.

6. Discernment: knowing when to stop thinking and when not to

The word that comes up most in the conversation is discernment. AI can get a task about 90% of the way done. The remaining 10%, which includes judgment, reasoning, and context, is where people add value. Because AI speeds up decisions, organizations have to deliberately protect time for that judgment.

Krish describes the tension from an engineer’s point of view:

• When to delegate: if Claude or Cursor can do the work, he lets it, then reviews, adjusts, and merges.

• When not to: sometimes delegating made him slower on problems he has solved many times before, because the tool “sent him on a wild goose chase.”

Both hosts gave examples of AI not saving time. Trehan gave up on having AI build a presentation slide and made it himself in PowerPoint. Snowpal set aside two four-hour sessions to generate course images with ChatGPT instead of Canva, and after all the back-and-forth it took the same time. The images may have been better, but no time was saved.

Krish compares this to mental math. Calculators exist, but when he sets a stop-loss on a day trade, working out 1.6% in his head is faster than reaching for a tool. If you hand off every skill you have, you stop being different from anyone else using the same tools.

Trehan takes this further: value is shifting from IQ to EQ. That means noticing when a P&L looks wrong before running it through a model, sensing problems inside an organization, and explaining a vision clearly. These are the soft skills that make good leaders, and they are becoming more valuable as everyone else focuses on hard outputs.

7. What this means for software engineers

Asked how developers should adapt, Krish, who has built software for over 20 years, makes several points:

• The pace of change is what’s new. Software has always changed; now it changes much faster. What worked a month ago may not work today.

• Programming languages matter less. Snowpal has always used several languages and stacks. With current tools, the specific language or framework matters much less than knowing how to approach and architect an engineering problem so it scales and lasts.

• Consistency is the new hard problem. Checking that generated code works is fairly easy. You can even test it with other code-generation tools. Keeping code from several AI tools consistent with the rest of the codebase is harder. Without that discipline, the result looks like a thousand developers each contributing in their own style.

• Engineers still own production. When something breaks, AI will help find the bug, but the engineer needs to understand the codebase and how it grew: which tools generated which parts, how contributions were made, and how deployments run.

• Structural decisions still need people. Monorepo or polyrepo, how the team is organized, how contributions and deployments flow: these are still engineering leadership decisions.

• Being comfortable with constant change is a core skill. Expect something to be significantly different every week.

Trehan adds that specialists increasingly need to work like generalists. They should understand the upstream and downstream effects of a change, how it affects the customer journey, and how it connects to other parts of the business.

8. The consultant’s changing role

Both the client and the consultant now have access to ChatGPT, Claude, and Cursor. So why hire outside help? Trehan’s answer:

• Time and follow-through. Clients often have ideas but not the bandwidth to finish them while running the business. Consultants commit to timelines, measurement, and outcomes.

• An outside view. Clients tend to think about processes in terms of how they’ve always done them. Consultants bring patterns from across the industry.

• Transparency. Be open about when and how AI is used to produce deliverables.

• Teaching the client. Build the methodology into the client’s team, such as documenting processes and finding bottlenecks, so they can keep going on their own.

• Pricing on outcomes instead of hours. Tie fees to efficiency gains, revenue, or acquisitions delivered, rather than billable hours or documents.

9. Workforce and global perspective

On jobs, the conversation is candid. Trehan notes that many corporate layoffs are driven by share price as much as by AI. Still, as a small-business operator she now asks “hire or automate?” and has found that growing the business 4x no longer means growing headcount 4x. Back-office work such as accounting is an obvious target for automation. Commoditized offshore work is at real risk, and some of that capacity may move toward quality assurance.

His view is that AI is revolutionary in what it can do but will be evolutionary in how it rolls out, similar to the printing press or the early internet, when “SeniorNet” classes taught people how to get online. Adoption will be uneven, even within a single neighborhood.

On global competition, she describes New Zealand’s “number 8 wire” mindset: the idea that you can fix anything with basic fencing wire and ingenuity. Smaller countries and companies can iterate faster in niche markets (Xero is a New Zealand example). AI helps level the field further because meaningful products no longer need large teams.

Key takeaways

1. Fix the process before adding AI. Automating a broken workflow makes it worse.

2. Start small, choose low-ego use cases, and show value quickly. Ambient transcription succeeded where radiography first struggled.

3. Position AI as a second opinion, and explain how it works and how it learns.

4. Define failure and set kill criteria up front.

5. Govern token usage and accountability. The organization owns its bots’ decisions.

6. Budget for validation. Total cost = people + tokens + review.

7. Protect discernment. Delegate what the tool does well and keep the skills that set you apart.

8. For engineers: architecture, consistency across the codebase, and comfort with constant change matter more than any single language.

As Trehan put it at the end: “We’re only limited by the questions that we can ask.”

Statistics mentioned in the episode (95% pilot failure rate, 35% process redesign, 65% wage premium for AI roles, the Uber token figure) are as cited by the guest and have not been independently verified here.

AI + Snowpal API: Reduce Time to Market

To make the numbers concrete, the examples use a hypothetical young U.S. couple with one child. They are rough planning estimates, not universal averages. Costs vary widely by location, income, and lifestyle, and several categories overlap, so the figures should not simply be added together.

Introduction

Personal finance rarely fails because of one catastrophic decision; it erodes through a compounding system of depreciation, financing costs, behavioral friction, recurring expenses, and lost investment returns. A car upgrade, deferred-interest purchase, oversized shopping trip, or daily convenience may appear manageable in isolation, but collectively these choices can redirect tens of thousands of dollars away from emergency reserves, debt reduction, homeownership, education, and long-term wealth. For a young couple raising a child, understanding this system is especially important: every dollar spent carries both an immediate price and an opportunity cost—the future value it could have created elsewhere. The fifteen categories that follow quantify these hidden tradeoffs and show how greater visibility, intentional limits, and better allocation decisions can convert ordinary spending into lasting financial security.

1. A Car Is a Depreciating Asset—and the Bling Dies Quickly

A car starts losing value the moment it leaves the lot, and the fastest way to accelerate that loss is chasing the version with more bling: the bigger trim, the newer model year, or the upgrade that felt necessary at the dealership but stops mattering within a month.

The type of car matters less than the pattern around it—how often it gets upgraded, how many optional packages get added, and how much of the purchase gets financed. A modest, reliable car kept for eight to ten years will almost always beat a nicer one traded in every three, even though the second option feels more successful in the moment.

The payment is only part of the bill. AAA estimates that the average new vehicle costs about $1,072 per month to own and operate when depreciation, financing, fuel, insurance, maintenance, and fees are included. A family with two newer vehicles could easily devote $1,500 to $2,100 per month to transportation.

**Potential savings:** Keeping reliable cars longer, avoiding unnecessary upgrades, and replacing only one vehicle at a time could preserve roughly $400 to $800 per month, or $4,800 to $9,600 per year. The real luxury is not a prestigious badge; it is dependable transportation without a crushing payment.

2. Interest-Free Loans on Random Purchases

“Interest-free” financing on furniture, electronics, phones, appliances, or exercise equipment sounds like a gift. Even when the interest rate is genuinely zero, however, the purchase still commits future income.

A family could easily accumulate the following payments:

- Furniture: $125 per month

- Two phones: $80 per month

- Exercise equipment: $75 per month

- Electronics: $70 per month

That is $350 per month, or $4,200 a year, assigned to things purchased months ago. It is also $350 that cannot go toward an emergency fund, retirement account, vacation, or education savings.

Zero-percent financing is safest when the purchase was already planned and the money needed to pay for it already exists. Otherwise, it can make an unaffordable purchase appear affordable simply by shifting attention from the total price to the monthly payment.

3. Deferred-Interest Credit Cards

Deferred interest is more dangerous than a conventional zero-percent offer. If the balance is not fully paid by the promotional deadline, interest may be charged retroactively from the purchase date—not merely on the balance that remains.

Suppose the couple charges $2,000 for furniture on an 18-month deferred-interest card. If the account carries a rate near 30% and the promotional conditions are not satisfied, the resulting interest could approach $700 to $900, depending on the agreement and payment history. A $2,000 purchase can therefore become a $2,700 to $2,900 purchase.

The fine print is where the real terms live. Read it, create an automatic repayment schedule, and aim to eliminate the balance several months before the deadline. Waiting until the final billing cycle leaves no room for a missed payment, posting delay, or calculation error.

4. Buy Now, Pay Later

Buy Now, Pay Later services split a purchase into smaller installments, making the total easy to lose track of. Four payments of $50 don’t feel like $200, even though they are.

The greater danger is stacking several plans:

• Clothing: $50 per month

• Children’s equipment: $75 per month

• Electronics: $100 per month

• Household purchases: $75 per month

Together, those plans consume $300 per month, or $3,600 per year. The Federal Reserve reported that 15% of adults used BNPL in the preceding year and that nearly one-quarter of users had made a late payment.

BNPL is designed to make borrowing feel almost invisible. Before using it, ask whether the purchase would still happen if the entire amount had to leave the checking account today. If the answer is no, the installment plan may be disguising an affordability problem.

5. Buying a Home Versus Renting

This is one of the biggest financial decisions most people make, and it is rarely as simple as “buying is always better.” A mortgage payment can build equity over time, which is a genuine advantage renting doesn’t offer. But buying also involves interest, property taxes, insurance, maintenance, closing costs, and less flexibility to move.

Consider a $400,000 home with 10% down. At a mortgage rate near 6.75%, principal and interest alone would be about $2,335 per month. After adding property taxes, homeowners insurance, maintenance, and possibly mortgage insurance, the actual cost could reach $3,300 to $3,800 per month. A comparable rental might cost $2,300 to $2,700, depending on the market. The purchase could also require $50,000 to $70,000 in upfront cash for the down payment and closing costs.

That does not automatically make renting the better choice. Part of the mortgage payment builds equity, and ownership may provide valuable stability to a family. The right answer depends on how long the couple expects to stay, the local price-to-rent ratio, the property’s condition, and what the down payment could be doing elsewhere. Run the actual numbers for the specific home rather than treating either answer as a rule of thumb.

6. Opportunity Cost: What Else Could That Money Be Doing?

Every dollar tied up in debt has a cost that doesn’t appear on the receipt: what it could have done somewhere else. Carrying a loan isn’t just paying interest. It is also giving up the saving, investing, or financial flexibility that the monthly payment could have provided.

Suppose car loans, personal loans, and financed purchases consume $500 per month. That is $6,000 each year unavailable for other goals. If $500 per month were invested and earned a hypothetical average return of 8%, it could grow to approximately $91,000 after 10 years or $295,000 after 20 years.

Those returns are not guaranteed, but the principle ties much of this list together. The real cost of a purchase or loan is the price tag, the interest, and everything that money didn’t get to do.

7. Savings, Treasury Securities, CDs, Index Funds, and Stocks

Not all places to keep money serve the same purpose. Savings accounts, CDs, and Treasury securities are generally appropriate for emergencies and shorter-term goals because stability matters more than maximizing returns. Broad stock-index funds, including funds that track the S&P 500, may be suitable for long-term goals because they offer greater growth potential but can also fall sharply. Individual stocks add still more company-specific risk.

A young family able to set aside $1,000 per month might direct:

• $500 toward an emergency fund

• $200 toward shorter-term goals in CDs or Treasury securities

• $300 toward diversified long-term investments

As a simple illustration, investing $1,000 per month for 10 years could produce approximately $147,000 at a hypothetical 4% return or $183,000 at 8%, compared with $120,000 in contributions. Neither result is promised.

The goal is to match each dollar to its timeline. Emergency money should not depend on the stock market being favorable when the furnace fails. At the same time, leaving money that will not be needed for decades entirely in a low-yield account can carry its own opportunity cost. This is general information, not personalized financial advice; the appropriate mix depends on the family’s goals, circumstances, and tolerance for risk.

8. Shopping: The $100 Plan That Becomes a $500 Receipt

Some of the greatest damage happens in categories that never feel like serious spending. A Costco or Target trip planned for $100 somehow becomes $500 because everything appears useful, is sold in bulk, or is presented as a deal.

If that happens once a month:

• Planned spending: $100 per month

• Actual spending: $500 per month

• Budget overrun: $400 per month

• Annual overrun: $4,800

A discount is not a saving if it causes the family to buy something it did not need. Use a list, avoid browsing unrelated aisles, and calculate the cart total before reaching the register. For clothing and other nonessential purchases, a 48-hour waiting period can reveal whether the item fills a genuine need or only creates a brief feeling of getting a bargain.

9. Concert Tickets, Games, Shows, and Other Events

Concerts, games, and live shows are genuinely enjoyable and can be worth paying for. The problem is not necessarily the experience; it is the total cost and frequency.

A family outing advertised as $100 per ticket might actually include:

• Three tickets: $300

• Service fees: $75

• Parking or transportation: $40

• Food and drinks: $75

• Merchandise: $60

The $300 event becomes a $550 evening. Six such outings would cost approximately $3,300 per year, or an average of $275 per month.

Budget for the entire experience, not just the advertised ticket price. A dedicated entertainment fund allows the family to enjoy events without receiving the real bill on a credit-card statement weeks later.

10. Travel Is Good—If You Can Afford It

Travel isn’t a trap to avoid. It can be one of the more defensible uses of money because it produces lasting memories and family experiences rather than more household clutter. The caveat is affordability.

A one-week domestic trip for two adults and one child might cost:

• Transportation: $1,000 to $1,500

• Lodging: $1,500 to $2,000

• Food: $700 to $1,000

• Activities and local transportation: $700 to $1,000

That places the total at roughly $3,900 to $5,500 before easily overlooked expenses such as baggage fees, airport parking, pet care, and souvenirs. Saving $325 to $460 per month would fund the trip over a year.

A vacation budgeted for in advance and paid for with savings can be an excellent use of money. The same vacation financed with debt and paid off for the following year is a different financial decision, even if the destination is identical.

11. Online Shopping Every Day of the Week

Online shopping removes nearly every psychological barrier that once accompanied a purchase. There is no drive to the store and no time to reconsider—just a saved card and a button that says “buy now.”

A $20 household order on Monday, $35 of children’s clothing on Wednesday, and a $25 impulse purchase on Saturday may not feel excessive. But three $25 orders per week equal approximately $325 per month or $3,900 per year.

Much of this spending disappears into normal household clutter, which makes its cost even harder to remember. Keep nonessential items in the cart for 48 hours, disable promotional notifications, remove stored payment details, and designate one day per week for online orders. The purpose is not to ban online shopping; it is to restore the pause that convenience removed.

12. Makeup and Personal-Care Costs

Makeup, skincare, salon visits, hair products, manicures, and similar expenses are easy to underestimate because each purchase seems relatively small. Added together, they can become a meaningful recurring category.

A moderate monthly estimate might include:

• Makeup and skincare: $75

• Hair products or services: $75

• Nails or other treatments: $50

That is approximately $200 per month or $2,400 per year. This is not an argument against personal care. It is an argument for making the total visible. Setting a monthly limit, using products before replacing them, and eliminating overlapping subscriptions can reduce the bill without eliminating the routine.

13. Death by a Thousand Cuts

A daily coffee purchase feels harmless—it’s a few dollars, barely worth thinking about. Small recurring purchases add up precisely because no single instance feels significant.

If both adults buy a $6 coffee five mornings per week, the household spends about $250 per month or $3,000 per year. Add lunches, delivery fees, forgotten subscriptions, convenience-store stops, and app purchases, and the small-expense category can readily reach $500 to $800 per month.

None of these pleasures has to disappear. Buying coffee twice a week rather than five times preserves the ritual while saving roughly $1,800 per year. The objective is not to declare every small purchase irresponsible. It is to notice when repeated convenience is quietly crowding out something the family values more.

14. Digital Money: Make Spending Feel Real Again

Paying with physical cash often feels more consequential than tapping a card or phone, and that friction can be useful. Digital payments make transactions convenient but can also make overspending harder to perceive.

Suppose the family spends $2,000 each month across groceries, dining, shopping, entertainment, and personal purchases. If cash envelopes and firm category limits reduce that spending by only 10%, the family retains $200 per month, or $2,400 per year.

Cash does not have to replace electronic payments for rent, utilities, or other fixed bills. It can be reserved for the two or three discretionary categories where spending most often gets away. When the envelope is empty, the category is finished until the next budget period.

15. Track Your Expenses and Know Where the Money Is Going

This is the habit that makes every other item actionable. It’s hard to fix a car-upgrade habit, a Costco overspend, or a coffee run nobody is counting if there is no visibility into where the money actually goes.

If a family spending roughly $6,500 per month finds that just 5% is disappearing into forgotten subscriptions, fees, food waste, duplicate purchases, and impulse spending, that represents $325 per month—or $3,900 per year.

Tracking doesn’t require a complicated spreadsheet. A budgeting app, a bank’s built-in categorization, or a weekly review can work. Sort spending into housing, transportation, food, childcare, debt, shopping, entertainment, travel, personal care, and saving. Then ask which purchases were worthwhile, which would not be repeated, and which category should be capped next month.

The point isn’t to judge every purchase. It is to know, with actual numbers, where the money goes instead of guessing.

The Bottom Line

A young family does not have to eliminate cars, travel, coffee, concerts, makeup, or online shopping. It needs to see their full cost. A handful of deliberate changes—keeping a car longer, avoiding overlapping payment plans, controlling impulse purchases, and tracking expenses—could realistically redirect $500 to $1,500 per month toward emergency savings, debt repayment, education, retirement, or another family goal.

That is $6,000 to $18,000 per year without giving up everything that makes life enjoyable. Saving is not simply about spending less. It is about deciding what deserves the family’s money before convenience, advertising, and easy credit make that decision for them.

Sources

• U.S. Bureau of Labor Statistics, Consumer Expenditures 2024

• AAA, 2026 Your Driving Costs analysis

• Federal Reserve, Economic Well-Being of U.S. Households in 2024

• Freddie Mac Primary Mortgage Market Survey

The course walks through setting a realistic budget, defining your property requirements, comparing different types of homes, and using online tools to research properties and markets. It also examines the role of real estate agents, how commissions work, what to consider when choosing an agent, and how research and negotiation can help buyers navigate the search and offer process more effectively.

From there, the focus shifts to the financial mechanics of homeownership. You’ll explore down payments, mortgage insurance, interest rates, loan options, amortization, refinancing, and loan recasting, along with the many costs that extend beyond the monthly mortgage payment. The course also considers the risk of becoming “house poor” and why understanding affordability—not simply how much you can borrow—is essential when determining how much home to purchase.

Finally, the course takes a longer-term view of the decision. You’ll examine new versus older properties, maintenance and ownership costs, home appreciation, the time and financial commitment involved in owning a property, and the tradeoffs between putting money into a home versus renting and investing elsewhere. Together, these topics provide a broader framework for evaluating a home not only as a place to live, but also as a significant financial commitment and long-term investment.

Takeaways

1. Renting vs. buying is a financial and lifestyle decision — compare the true long-term costs, benefits, and opportunity costs before choosing.

2. Affordability goes beyond what a lender approves — consider your income, lifestyle, savings, other obligations, and the risk of becoming “house poor.”

3. Budget for more than the down payment and mortgage — closing costs, taxes, insurance, maintenance, repairs, HOA fees, and eventual selling costs can significantly affect the economics of ownership.

4. Understand how mortgages actually work — interest rates, APR, amortization, loan terms, points, PMI, equity, and monthly payments all influence the true cost of borrowing.

5. Loan structure matters over the long term — choosing between loan terms such as 20 or 30 years can substantially change monthly payments, equity accumulation, and total interest paid.

6. Know your options after purchasing — refinancing and recasting can potentially reduce borrowing costs or monthly payments as your financial situation or interest rates change.

7. Research the property and the surrounding market — property type, age, condition, location, schools, commute, amenities, and local market conditions can all influence desirability and long-term value.

8. New and older homes involve different tradeoffs — newer homes may offer customization and lower initial maintenance, while older homes may come with different pricing, locations, and repair requirements.

9. Use technology to become a better-informed buyer — property platforms and online research tools can help compare listings, neighborhoods, prices, features, and market activity.

10. Understand the role—and cost—of real estate professionals — learn how agents and commissions work, choose representation carefully, and recognize how much research you can perform independently.

11. Inspections and due diligence are critical — understanding a property’s condition before purchasing can help uncover potential repairs, expenses, and risks.

12. Negotiation is an important part of buying a home — your leverage can vary depending on the property, seller, market conditions, and whether you’re purchasing an existing, new-construction, or spec home.

13. Homeownership can build equity and benefit from appreciation, but neither should be assumed — evaluate potential returns alongside financing costs, maintenance, transaction expenses, and alternative uses for your money.

14. Approach a home purchase as both a lifestyle and financial decision — the right property should meet your living needs while fitting comfortably within your broader financial plan.

15. Be patient and avoid rushing the purchase — buying a home takes time, and carefully comparing properties, financing options, and long-term costs can help prevent an expensive decision you may later regret.

Watch on Computer

You should receive an email with course details within 96 hours of purchase. If you don’t see that email in your inbox shortly, check your spam folder. If you don’t find it there either, reach out to varun@getsnowpal.com.

Buy $64.99

Watch on Mobile App

Prefer to watch it on the go? We’ve got you covered. Download our Mobile App from the App/Play Store, and all our courses are available there as well.

Download from App Store

Download from Play Store

More Courses

Check out our other Software, Finance, and AI courses on the Snowpal Education page.

AI + Snowpal API: Reduce Time to Market

Podcast

Own Your Weights: The Real Economics of Private AI — on Apple and Spotify.

Introduction

A conversation between host Krish and guest Sam Sammane, founder and CEO of Quantum General Intelligence (QGI) and author of The Singularity of Hope.

Sammane brings an unusual vantage point to the discussion: two decades in symbolic AI and automated theorem proving in the late 1990s, followed by a career in mergers and acquisitions, before returning to AI full time in 2022. Across the conversation, Krish and Sammane cover the real gap between frontier and open-source model performance, the economics and security tradeoffs of Chinese open-weight models, why coding and agentic workloads call for different tools, and the growing business and national case for private, sovereign, and deterministic AI infrastructure that companies and governments own outright rather than rent.

Every few months, a new leaderboard claims to settle which large language model is “best.” But according to one AI founder with a two-decade history in symbolic reasoning and automated theorem proving — a discipline that predates the current generative AI boom by twenty years — the leaderboard question is the wrong one. The more consequential question for any company deploying AI in production is who owns the model, who controls its weights, and what happens when the vendor changes the rules.

This article distills a wide-ranging technical discussion covering the evolution from symbolic AI to today’s hybrid, tool-using “agentic” systems; the real gap between marketing claims and coding performance across frontier labs; the rise of cheap, high-quality open-weight models out of China; and the practical, cost-driven case for private and sovereign AI infrastructure once a company crosses a certain size. Throughout, one theme recurs: renting a frontier model is convenient, but ownership is what protects a business from deprecation, policy bans, and vendor lock-in.

From Symbolic AI to the Agentic Revolution

The speaker’s background sits outside the neural-network mainstream. In the late 1990s and early 2000s, he worked on automatic theorem proving and symbolic simulation for hardware design — a field colleagues at the time dismissed as “too theoretical” for anyone to care about. He left academia for consulting and mergers and acquisitions, running three separate testing-lab businesses over two decades, before a 2022 encounter with ChatGPT sent him back into AI full time.

“In 25 years ago, I built a certain symbolic AI that can handle 65,000... tokens as a context window. And people told me that’s nothing. ChatGPT in 2022 was handling 8,000.”

That background turned out to be an advantage rather than a liability. Generative AI in 2023 was purely neural; his own expertise was in the older symbolic tradition. Blending the two, ahead of the industry’s own shift toward hybrid, tool-augmented “agentic” architectures, became the founding thesis of his company, Quantum General Intelligence (QGI). Of the roughly 80,000 AI startups he estimates exist today, he argues barely a hundred are doing substantive technical work — the rest are thin prompt wrappers around someone else’s model.

The Illusion of “Open” and the Real Leaderboard

The discussion is unsparing about naming conventions and marketing in the industry. “Open AI,” he notes, is now a closed company — one that began as a nonprofit funded by a $50 million donation from Elon Musk and later converted to a for-profit structure despite reporting tens of billions of dollars in annual losses. “Deep learning” and “neural networks,” in his view, are wishful branding for decades-old statistical input-output modeling, not literal replicas of biological cognition — and he is emphatic that no current or near-term system qualifies as artificial general intelligence in the science-fiction sense.

On model quality specifically, he draws a sharp line between public benchmarks and his own internal testing, developed by stress-testing models against real coding and agentic tasks at his company:

“According to [the press], always Chat GPT models are the best. And I’m sorry to tell OpenAI like this plainly: you don’t know how to code. Your models are stupid... A small Chinese model is better than that.”

His actual ranking: Anthropic’s Claude (”Fable” in the transcript) leads decisively on coding quality, followed closely by xAI’s Grok 4.6 (built on the former Cursor codebase following its acquisition). For agentic work that isn’t complex software engineering, he argues the gap between frontier and low-cost open-weight models has essentially closed.

The Open-Source Insurgency

DeepSeek’s release is described as a watershed moment for the industry — not because it beat frontier models outright, but because a five-million-dollar company demonstrated a near-frontier model at a fraction of the cost, breaking the assumption that only labs with billions in capital could compete.

“Deep Seek... was the best thing happened for the AI industry. It started somehow a new era when we had OpenAI, arrogant as they are, pretending we have AGI in two years.”

He’s equally direct about the security anxiety surrounding Chinese models, distinguishing between hosted Chinese applications (which he says frequently phone home to servers in China) and open-weight models a company downloads and runs itself: “If you are familiar with the technology of AI, that’s all what you need to run the model... open source is not open weight — okay, it’s not [the same thing]. But in the practicality, it is.” His current recommendation for cost-sensitive agentic workloads points to Alibaba’s Qwen family, alongside DeepSeek V4, Moonshot AI’s Kimi/K3 line, and Zhipu’s GLM-5.3 — models he says cost roughly one cent per million tokens against fifty dollars per million for top-tier proprietary models.

Coding vs. Agentic Work: Different Tools for Different Jobs

A recurring practical distinction: use the best available model for coding, and the cheapest viable model for everything else.

“It’s like bringing Einstein to your office... if you are building something that needs Einstein, and coding is complex.”

For software generation specifically, he places Claude ahead of OpenAI’s Codex and his own company’s in-development coding assistant, Quark. But for agentic workflows — research, writing, classification, orchestration — he argues that tiny open-weight models like Qwen 3.8 are close to indistinguishable from frontier models like Opus 4.6 in practice, while costing orders of magnitude less per token.

The Business Case for Private AI

The private-AI argument is framed around company size and risk exposure rather than ideology. Below roughly fifty employees, he argues, building private infrastructure is a distraction; above that threshold, renting model access starts to look like a strategic liability.

“It’s like someone who preferred to rent a Ferrari over buying a Volkswagen because he wanna appear cool. Yes, he will appear cool, but you cannot have it all the time.”

The risk isn’t hypothetical: he describes being banned outright by a commercial AI provider over a misclassification of his company’s activity, cutting off access to data and workflows built entirely on that vendor’s platform. His broader point is about vendor dependency: a company that builds its operations on a rented model has no recourse when a provider changes pricing, deprecates a model version, or revokes access — a risk he says is fundamentally different from consumer software, because it touches a company’s operational intelligence rather than its entertainment.

On the economics of self-hosting once at scale, he cites an internal example: an engineer running 280 million tokens per day of agentic (non-coding) workload against a self-hosted open-weight model, on a GPU server costing roughly $600 per month — compute cost effectively at zero beyond the fixed hardware bill.

Deterministic AI and the Role of the Human in the Loop

Despite his enthusiasm for automation, he rejects “vibe coding” — the idea that a business can be run purely by prompting an AI without a human who understands the system — as a scam premise.

“AI will never propose to you [an intent]... it will put the constitution in the repository, and it will not change it, even if you [ask new questions ten days later]... that’s against our policy. Who wrote the policy? You — but it’s an AI.”

Every private-AI deployment, in his framing, needs a dedicated human owner — a CTO or a contracted AI specialist responsible for the tool contracts, input-output relationships, and standardization layers between the model and the business logic. That role, he notes, does not need to be co-located or full-time, since remote specialists can service multiple companies simultaneously.

Rethinking Education Around Intuition and Critical Thinking

The conversation closes on education, where he argues that traditional assignments — the five-paragraph essay in particular — have been rendered obsolete by AI in the same way calculators made mental arithmetic drills obsolete. His proposed replacement is a curriculum built around what he calls the “educated guess”: human intuition sharpened by domain expertise, which he argues remains a form of intelligence current AI systems cannot replicate.

“Your guess is a very strong form of intelligence that we don’t know how to replicate... we don’t have it in the machine. This is our superpower.”

The goal, in his words, is teaching people to be human again rather than to behave like machines — since decades of institutional education optimized students for the kind of rote recall and procedural compliance that AI now performs by default.

Sovereignty as a National Strategy

The same private-versus-rented logic scales up to nation-states. He argues governments should build their own fine-tuned, sovereign AI systems on top of open-weight foundations rather than depending on commercial providers, whose models he characterizes as commercially biased despite public claims of neutrality.

“You cannot rent intelligence. That’s basic, but it’s true. Any human will not love to bring someone and tell him, ‘Now for my life I will not think anymore, you think for me.’”

He singles out the United States as notably exposed on this front — among the world’s most AI-advanced nations, yet without a government-operated foundation model independent of private commercial labs.

Technologies

The conversation moves across a wide field of proprietary and open-weight language models, spanning US, Chinese, and independent labs. For reference, the models and coding assistants discussed by name include:

• ChatGPT / GPT models — OpenAI’s consumer and API-facing model line

• Codex — OpenAI’s dedicated coding assistant

• Claude (including Claude Opus 4.6 and Claude 4.5) — Anthropic’s model family, described as the current leader in coding quality

• Claude Code — Anthropic’s AI coding tool

• Grok 4.6 — xAI’s model, built on the former Cursor coding assistant following its acquisition

• DeepSeek (V3 and V4) — DeepSeek’s open-weight models, credited with triggering the current open-source AI race

• Qwen (including Qwen 3.8) — Alibaba Cloud’s open-weight model family

• Kimi / K3 — Moonshot AI’s model line

• GLM-5.3 — Zhipu AI’s model

• Mimo — Xiaomi’s open-weight model

• Llama — Meta’s open-weight model family, referenced generically as one of the “smaller models” now competing in the space

• Quark — Quantum General Intelligence’s own coding assistant, not yet publicly released

Summary

The throughline across this discussion is a distinction between renting intelligence and owning it. Frontier proprietary models remain the strongest choice for complex software engineering, but for agentic and general business workloads, the practical gap between expensive frontier models and cheap open-weight alternatives — largely originating from Chinese labs — has narrowed dramatically. Companies above roughly fifty employees are advised to weigh the ongoing risk of vendor dependency, pricing changes, and outright access bans against the fixed cost of hosting fine-tuned, open-weight models on owned or rented GPU infrastructure. None of this removes the need for human oversight: a dedicated AI-responsible role remains essential to translate business intent into working systems, since no current model can infer what a company actually wants. And the same logic that applies to individual businesses, the discussion argues, applies to national governments — sovereignty over one’s own models is becoming as strategically important as owning any other piece of critical infrastructure.

Read more

On a recent episode of the Snowpal Podcast, Krish Palaniappan sat down with Gerard Holland, a chartered accountant turned tech entrepreneur and founder of Talent Match Africa (TMA), to make the case for a “next frontier” that most Western businesses have barely considered: Africa.

AI + Snowpal API: Reduce Time to Market

Podcast

Africa, AI, and the Future of Global Talent — on Apple and Spotify.

Introduction

Holland, who lives in Melbourne, Australia, but runs operations out of Johannesburg, Durban, Cape Town, Nairobi, and Addis Ababa, didn’t set out to build an Africa-focused talent company. His path started in international education, building an internship placement platform that he took from Australia to the UK and Canada. Everything changed in 2020, when he was introduced to the continent through Zondwa Mandela, a grandson of Nelson and Winnie Mandela.

“I’d never been to Africa, but it definitely ignited something inside of me, an interest and that entrepreneurial flair, you could call it,” Holland recalled. He flew into Ethiopia first, then Rwanda, Kenya, and South Africa. What he found didn’t match his expectations at all: “I was completely blown away by the talent that is on the continent, the level of English proficiency, the tech capability, education levels, the infrastructure that’s happening in Africa. It wasn’t what I expected in my head.”

Talent Match Africa was born from that trip. Today the company places people in tech, finance and accounting, sales support, customer service, legal support, logistics, and operations roles with companies across the US, Australia, Canada, the UK, France, and China — and increasingly, in AI-related work.

The Demographic Case for Africa

Holland’s pitch for Africa starts with numbers most business leaders haven’t encountered. By 2035, every second person entering the global workforce will live on the African continent. By 2050, the continent’s population is projected to reach two billion. The driver is age: the average age in Africa is 19, compared to the 40s in the US and 72 in Monaco. That young population is now flooding into the workforce, backed by millions of university graduates every year.

Crucially, that talent pool is largely untapped. “India has become very congested and saturated,” Holland said. “The US went in the 70s and 80s and helped India become this tech powerhouse. But now it’s very saturated because everyone’s there. Whereas people haven’t quite worked out yet that there’s amazing talent in Africa. So you don’t have that competitive pressure. Price becomes more favorable, access to really good talent.”

He also pointed to a retention advantage Africa currently holds over the Philippines, where job-hopping has become endemic. “You don’t have people moving around as much... We’re not having those issues in Africa. Not yet anyway. We’re probably five years away from when that may become a problem.”

“Africa Is Not One Country”

Palaniappan pushed back with an obvious question: Africa is a continent of more than fifty countries, spanning enormous cultural and linguistic differences. Isn’t that a barrier for companies trying to figure out where — and how — to hire?

Holland pointed to a book that shapes his own thinking: Africa Is Not One Country. “A lot of people do sometimes think about Africa as being a country, when it’s like saying Europe is a country,” he said. “People in Germany are very different to people in France. And they’re next to each other.” A company that wants French-speaking talent needs to look at specific regions; language, accent, and business culture all vary sharply from country to country.

Accents, in particular, have become a bigger consideration than Holland expected. “I’m finding more and more that accent is even more important, particularly for a lot of USA companies. I’ll often get calls from businesses saying, ‘Look, Gerard, we really want people, but just so you know, we need really neutral accents.’ Where if they’re talking to clients, we don’t want people to know that they’re from another country — Americans want to deal with Americans.” South African, Kenyan, and Nigerian accents are all distinct, he noted, and clients increasingly specify which they’re comfortable with.

For companies looking to enter the continent, Holland recommends South Africa as an entry point: “It’s probably the most westernized of a lot of the countries in Africa. So a lot of businesses will get a foothold in South Africa and then they might work up into different parts of the continent.”

The Affordability Equation — And Why It’s Shifting

Palaniappan asked Holland directly whether Africa’s core value proposition, like India’s before it, ultimately comes down to cost. Holland didn’t dodge the question.

“India has become a lot more expensive now,” he said. “Eight, nine years ago, India was still very, very affordable. With all the demand on talent, people know what they’re worth and they can ask to be paid more, which then costs go up.” He described clients who saw quarterly price increases of 15% just to keep pace with local wage inflation. Africa, by contrast, is earlier in that cycle — global demand hasn’t yet driven up local wages the way it has in India, though Holland noted that large employers like Google and Amazon are already establishing a presence on the continent.

He also pointed to a cultural shift in how openly companies discuss offshoring. “Pre-COVID, it was almost like businesses when they talked about offshoring, it was a bit taboo... Now, post-COVID, people are like, ‘Yeah, I’ve had 20 people in Bangalore for 10 years.’” Rising costs of living in the US, UK, and Australia have made the math increasingly unavoidable for businesses trying to stay profitable: “If you can get someone doing the exact same job, but it costs 70% less, then businesses are saying, well, I’m going to do that.”

Underlying all of it, in Holland’s view, is a shift in trust that COVID accelerated. “What COVID made everyone appreciate... is that I can trust my people working remotely to do their job if we’re tracking the outcomes of what they do. If I’m in Boston and I’ve got a team member in Boston that’s working from home anyway, well why can’t I have a team member in Johannesburg or Bangalore doing the same work?”

The AI Question: Does Cheaper Labor Even Matter Anymore?

The most pointed exchange of the conversation came when Palaniappan raised what he called playing “devil’s advocate.” If AI is allowing companies to do the same work with a fraction of the headcount — he cited an example of a company that reportedly went from 52 employees to eight — does the whole premise of chasing cheaper labor abroad start to break down? If you only need eight people, why not just hire eight people locally?

Holland’s answer was refreshingly candid about the uncertainty in the room. “I don’t think anyone has the answer yet. Every business I speak to now has a different perspective on it.” He described playing golf with a business owner who’d cut his team from 22 to 12 while becoming more profitable than ever, driven by AI efficiency — and, in the same breath, other businesses that tried to cut headcount with AI and had to reverse course and rehire because “the AI wasn’t the efficiency they thought they would get.”

Holland laid out two divergent futures he sees as plausible. On one end: mass unemployment. “We actually need way, way less people across the entire economy, and we end up at 25, 30 percent unemployment globally. That’s a pretty drastic position. It’s not impossible. I think it’s a low probability, but it’s not impossible... The USA cannot possibly survive with more than 20 percent unemployment. The country will implode on itself.”

On the other end is a more optimistic scenario, and it’s the one Holland is building his business around: AI as an equalizer for the developing world. “If we can have people that are based in South Africa, Kenya, Philippines, Colombia — doesn’t matter — and you upskill them with the latest tools... they can perform at two to three times higher than what they otherwise would have three years ago. And then all of a sudden you can have lower-cost resources doing the same work but at a higher level than previously possible.” For a business owner, he added, “this is amazing — I can get people that are much more affordable, doing work at a really high level because they’re using AI tools.”

He offered a concrete example: a client in Toronto had built out 20-25 AI agents running parts of their business, with the CEO and CFO each managing some directly. But agents need constant supervision. “You have to actually manage them. They break, something’s not working, you need to fine-tune it... it’s not a ‘you do it once, you leave it there, and happy days, you go sit on a beach while your business makes all this money.’” TMA now has two people in Johannesburg dedicated to managing that client’s AI agents — a role that didn’t exist a few years ago.

He also shared a striking data point from a French airline-software client: “Of their thousand engineers, no one writes code anymore. Literally no one writes a line of code. They’re all reviewing code. They’re all on their phones watching the code build.” That shift, Holland argued, is changing the profile of the talent companies need — not less experienced people, but more experienced ones who can supervise AI output. “So rather than getting very early-stage grads who don’t have the experience yet, it’s actually targeting the people who do have a lot of experience... We can go and target the top 10 percent. It’s harder to do in India now because the top 10 percent are getting paid a lot of money. We don’t have that saturation in these markets at the minute.”

Summing up the uncertainty, Holland offered one of the conversation’s sharper lines: “There’s this saying that you’ve probably heard — AI won’t take your job, but someone using AI will take your job.”

Beyond the Bottom Line: Culture, Trust, and Why Remote-Only Failed

Palaniappan raised a challenge that goes beyond skill or price: the fatigue that comes with building trust across cultural and geographic distance. Holland admitted TMA learned this the hard way. “When we first took the business into Africa... we did a work-from-home model, and it was a disaster. It didn’t work 98 percent of the time.” The fix was physical offices: pristine, well-equipped spaces in each city where TMA’s talent works alongside other engineers, marketers, and business professionals, creating a sense of team and accountability that pure remote work didn’t provide. It also lets TMA intervene directly when something’s off: “We’ve got managers on the ground that can actually go and sit next to them and have a coffee and say, what’s happening? Your performance has dropped off. Is there something we need to know about?”

But Holland was clear that the deeper responsibility for culture sits with the client, not the vendor. “That always comes down to treating people no different if they’re based in Johannesburg or they’re based in Seattle. It’s how they bring them into team meetings, how they speak to them the same as they would speak to any employee. If you foster a nice culture like that, you get loyalty and longevity, and then you get better results as well. But it does take effort.”

Entrepreneurship and Creativity: Is Africa Just Playing Catch-Up?

One of Palaniappan’s more provocative questions was whether developing economies are destined to remain in a support role — providing affordable labor to execute someone else’s vision — rather than originating new ideas themselves. Holland pushed back, pointing to Africa’s fintech sector as evidence of homegrown innovation. “MPESA was actually developed before WeChat, and it’s a full financial system that sits on an app on your phone... Nigeria has a huge tech entrepreneurial startup scene.” He described a grassroots hustle culture across the continent: “Most Africans I meet have a side hustle. By nature, there’s this hustle entrepreneurship mentality.”

He does concede the obvious gap: Africa isn’t attracting Silicon Valley-scale venture capital. “There’s not like the unicorn VC money — people aren’t putting five billion dollars into a company like you are in Silicon Valley.” But he sees AI tools lowering the barrier to entry for African founders in a way that could change that calculus over time: “Now you don’t need capital to go and build a startup. You don’t need to go and hire engineers to build an idea that you’ve got. You can get a license to Claude Code, put a certain amount in per month, and go build it.”

The Perception Problem

Asked about political stability, Holland said he’s personally never run into trouble operating in the countries where TMA works. His bigger concern is reputational, not operational — specifically, how migration coverage in Western media shapes perceptions of Africa as a business partner. “I think what the bigger issue is now is what’s happening in the media around migrants... it’s too often being pointed at — it’s someone from Africa, it’s someone from Morocco. And it’s only telling part of the story... That’s not the real Africa that I know.”

He argued that this narrative directly complicates his sales pitch: “It makes my life more difficult because I’m convincing businesses to look to Africa for their global resourcing. But if all they’re seeing on the news is that migrants are causing problems in their own country, and those migrants are from Africa, then that subconsciously or consciously changes their view as to whether they want to engage with people from the continent.” He turned the lens back on the US as well, noting the political polarization he’s observed there: “I’ve never seen — I mean, the US — I’ve never experienced before, the last probably four years, is almost a hatred between political parties... there’s a lot of things simmering underneath the surface in America.”

Krish’s Own Playbook

Toward the end of the conversation, Holland turned the tables and asked Palaniappan why he wouldn’t look to Africa when adding resources to his own US-based company. Palaniappan laid out his personal decision hierarchy: local talent within driving distance first, for the value of in-person connection; then talent elsewhere within the US; then, if cost becomes the deciding factor, international markets — where he’s worked with people in the Czech Republic and Ukraine, and extensively with talent in India, drawing on his own upbringing there to navigate regional differences in colleges, credibility, and culture.

His core caution about outsourcing to any new region, Africa included, wasn’t about talent quality — it was about the ongoing relational work required to make a distributed team function, even when AI is doing much of the technical heavy lifting. “Even if you’re building software, even if you’re using AI to build software, you don’t actually hire a developer like you did three years ago. There’s still a lot of conversation that needs to happen constantly so you’re building the best quality software... There’s got to be a connect, or lack of disconnect, between your team and that person or those people.”

He also named a practical awareness gap that Holland’s business exists to solve: most people, he noted, can probably name fewer than twenty of Africa’s roughly fifty-eight countries, let alone distinguish the talent, culture, working norms, and political context of South Sudan versus Mauritania versus Kenya. “If there’s a way to bridge that gap, I can see more people wanting to explore this as an option, so they don’t feel like they’re coming from a place of being ignorant about who they’re going to be potentially working with.”

Holland’s closing point tied the whole conversation together: the decision calculus for every business leader now runs through AI first. “A lot of decision-makers, well, how does — can AI automate it? If not, how do I have someone that can help me use AI to do it? If not, what’s the human I need to do it? And then how much does it cost? We all as business professionals are weighing that up all the time.”

Closing Thoughts

What emerges from the conversation isn’t a simple sales pitch for African outsourcing — it’s a picture of an industry in flux, where the old logic of “cheaper labor, same work” is being rewritten by AI in real time, and where the winners may be the regions that combine affordability with rapid AI adoption rather than those competing on cost alone. Holland’s bet is that Africa, still early in its global-talent journey and unburdened by the wage saturation now facing India, is positioned to make that leap.

Gerard Holland is the founder of Talent Match Africa. More information is available at talentmatchafrica.com.

Viktor Popovic has closed two very different kinds of impossible sales. The first was convincing an old-school pressure washer manufacturer, in 2003, that people would actually buy heavy equipment over the internet. The second, twenty years later, is convincing payment processors to compete against each other in real time for the same merchant. Between those two sales sits a masterclass in what it actually takes to sell something the market isn’t ready to buy.

AI + Snowpal API: Reduce Time to Market

Podcast

How One Founder Cracked Two Impossible Sales — on Apple and Spotify.

The first sale is never the one you planned for

Viktor didn’t set out to sell pressure washers. He’d built a list of roughly 40 products tied to the aviation industry — his original field of study — but a keyword analysis run by his business partner turned up an unexpected signal: “pressure” had unusually high search volume. One of the aviation-adjacent items on his list happened to be a pressure washer used for cleaning hangar floors. That accident of keyword research became a 21-year business.

“A friend asked me if I wanted to start a business. Without a second thought — yes, I'm ready. Why not?"

But finding the product was the easy part. The real sales problem was upstream: getting manufacturers to trust an unproven sales channel. In 2003, the standard model was regional reps who drove vans full of equipment around town, pulled machines off the truck, hooked up a garden hose, and demoed them live. Viktor was asking manufacturers to abandon that entirely and hand their equipment to a stranger promising to sell it through a browser. It took him six months to land his first vendor, a company called Cam Spray out of Iowa. The first actual sale — a cold-water diesel-powered pressure washer to a U.S. military base in San Diego — came down to a simple phone call and a fast, confident shipping quote.

The lesson he draws from it: the hardest sale often isn’t to the end customer. It’s convincing the party one step removed — the vendor, the partner, the gatekeeper — that a new way of doing business is worth the risk.

The second time around, he was wrong about what would be hard

When Viktor started Avendo, a fintech SaaS company that lets credit card processors compete for merchant transactions in real time, he assumed the sales motion would be straightforward. Merchants would obviously want lower processing rates. Processors would obviously want to compete for that business. “Why wouldn’t they love this idea?”

He was wrong. Payment processors have run the same playbook for 50 to 60 years: evaluate a merchant, assess risk off their statements, quote a flat rate, done. Avendo was asking them to shift into a model where they compete for the same merchant’s business transaction by transaction. That’s not a product objection — it’s an identity objection. It took Viktor seven or eight reworked pitches to find language that got processors past their blind spots and objections before the idea started to click.

“I thought the sales process would be where I need to worry, that everybody would be on board because the idea is great — why not? Man, was I wrong. It's actually the hardest part: getting payment processors to change the way they think, because they've been doing business this same way for the last 50-60 years.”

Notably, once it did click, it clicked fast — because the pitch to merchants and referral partners is genuinely simple: save 1% on a million-dollar-a-year processing volume, and that flows straight to net margin. Decision-makers get it in one sentence. The friction isn’t in the value proposition. It’s in getting the party whose behavior has to change to actually change it.

Referral partnerships beat cold outreach — but only after the failures teach you why

Before landing on what works, Avendo ran seven or eight different marketing motions in parallel: cold email, referral partnerships, paid advertising, and more. Viktor is candid that most of it didn’t work on the first try. One cold-email platform was pulling leads from what turned out to be a stale database — they were spending real money generating zero responses before they figured out the list itself was the problem. Email deliverability issues meant learning to run domain warm-ups, rewrite subject lines, and rebuild sender reputation from scratch.

What eventually worked was narrowing to three referral partner types who already understand net margin economics well enough to sell on Avendo’s behalf without much friction: business consultants and coaches, fractional CFOs, and accounting firms. These partners refer their clients into Avendo, and Avendo reciprocates leads back to them with client approval — a two-way referral loop built on partners who don’t need convincing on the math.

The broader point: there’s no way to know in advance which channel will work. The only path is running several simultaneously, tracking results honestly, and being willing to kill a channel that isn’t converting rather than defending the plan for its own sake.

80% planning, 20% execution — and still 70% wrong

A mentor once told Viktor that a well-run initiative is 80% planning and 20% execution — get the plan right and the execution mostly takes care of itself. He believes it, and he still spent months in heavy planning before launching Avendo. And yet roughly 70% of that original plan changed once reality intervened.

That’s not a contradiction. The planning wasn’t wasted just because the specifics changed — it forced him to actually understand the payment industry’s layers (network fees, acquiring banks, issuing banks, card types, government and gift cards) instead of assuming his merchant-side experience had already taught him the business. Planning, in his framing, isn’t about predicting the future correctly. It’s about doing the homework deep enough that when the plan breaks, you know enough to fix it fast.

Resilience is a skill, not a personality trait

Viktor doesn’t describe himself as naturally thick-skinned. He describes himself as built that way by repetition — pitching processors seven or eight different ways, absorbing rejection after rejection, and treating each “no” as information about a blind spot rather than a verdict on the idea. His practical advice for staying in a sales grind that isn’t paying off yet: celebrate small wins deliberately. Hiring the right person, closing one meaningful account, hitting a minor milestone — mark it, even briefly, because the wins that matter get lost if you’re only measuring against the ten-million-dollar outcome still years away.

The takeaway for anyone selling something the market doesn’t understand yet

Two sales, two decades apart, same underlying pattern: the product wasn’t the obstacle. The obstacle was convincing someone whose business model, habits, or risk tolerance had to change. Viktor’s approach to both is the same — treat every rejection as a missing data point, keep reworking the pitch until it lands, lean on partners who already understand your economics, and measure progress in small wins rather than waiting for the finish line to feel good.

“It's just trial and error, I think that's the bottom line. I don't think there's a secret to it, or a crystal ball you can look at.”

As he put it on the podcast: don’t get discouraged. “Not him — let’s go tweak something, do it this way.” That, more than any framework, is what got two very different sales across the line.

Summary

For sales engineers evaluating go-to-market motion design: the core signal from this conversation is that objection surface area scales with how entrenched the incumbent workflow is, not with product complexity — Viktor’s hardest technical sell wasn’t a feature gap, it was displacing a 50-60 year old risk-assessment heuristic (flat-rate quoting off a merchant’s statements) with a real-time, transaction-level competitive bidding model, which required rebuilding the champion’s mental model before any pricing conversation could land; his resolution path was iterative pitch-architecture testing (seven to eight distinct framings) to identify and patch objection blind spots rather than optimizing a single script, paired with a channel-attribution pivot away from cold outbound (killed by stale list decay in a purchased database, undetectable until response-rate analysis surfaced it) toward a referral-partner model selecting for partners who already carry the requisite domain literacy — fractional CFOs, accounting firms, consultants — so the value prop (basis-point margin capture at the transaction level) requires zero re-education before it converts, which is the throughline: reduce time-to-comprehension for the buyer by routing through intermediaries who’ve already internalized your unit economics, rather than trying to compress that education into the pitch itself.

A quick reference for the questions we get most often about the Snowpal product suite.

General

What is Snowpal? Snowpal is a Backend as a Service (BaaS) company. We build APIs that help other companies reduce the cost, risk, and effort of building software, so they get to market faster. On top of those same APIs, we also run two of our own consumer-facing products: a Project Management platform and an Education platform.

What’s the difference between Snowpal’s APIs and Snowpal’s apps? The APIs are the B2B side of the business — production-grade backend infrastructure that any company can integrate into their own web, mobile, or server-side apps, regardless of industry or tech stack. The Project Management platform and Education platform are B2C products built on top of those same APIs, so when you use them, you’re using thoroughly vetted systems already running in production.

APIs

What APIs does Snowpal offer? Our APIs are LIVE on AWS Marketplace, and include:

• Building Blocks API – a generic API providing the foundational pieces to build almost any system

• Content Management API – for managing content-heavy applications

• Project Management API – for building project management features or full platforms

• Classroom API – for managing classes and students, built for the teaching community

• Status API – for building status-tracking features (think a Slack-status-style app)

• Conversation API – for adding in-app conversations

• Custom Attribution API – for supporting virtually any form

• Access Control List API – for securing apps without building access control from scratch

Together these total thousands of endpoints, and we’re adding more regularly.

Who are the APIs for? Any company building a web app, mobile app, or server-side component/microservice — regardless of industry. The APIs are domain-agnostic where possible (Building Blocks) and domain-specific where useful (Project Management, Classroom, etc.), so teams can pick what fits.

What languages/SDKs are supported? We currently provide SDKs for Golang, with more languages planned. Full API guides, references, and recipes are available at developers.snowpal.com.

How do I get started with the APIs? Three steps: subscribe to the API, import our Postman Workspace (Sample API on Postman), and use your API key plus product code to start making requests.

Education

What is Snowpal Education? An education platform with 50+ affordable, hands-on courses, mostly in software development and architecture, plus a growing set of business, finance, and stock-trading courses. Courses are available on the web and on our mobile apps.

How long and how much are the courses? Most courses run 30–90 minutes and are priced under $10 — the goal is hands-on, practical learning for less than the cost of a coffee.

What topics are covered? Software and architecture topics include things like AWS API Gateway, Postman, Flutter, serverless (AWS SAM), DynamoDB, microservice security, multi-tenant architecture, OAuth 2.0 social login, and REST API fundamentals. Business and finance courses cover stock trading basics (getting started, buying/selling/shorting, portfolio management, research) and running a SaaS business.

Can I get a custom course or 1:1 mentorship? Yes — we offer custom-built courses tailored to your needs, and you can book time directly with our CTO for code review or consulting.

Is there a revenue-share option for course creators? Yes, we host courses for free and split revenue 80/20 with creators.

Who uses the Classroom API vs. the Education platform? The Education platform is where individuals go to take courses. The Classroom API is for developers and institutions who want to build their own class/student management tools — for example, an EdTech company building its own app on top of Snowpal’s backend.

Project Management

What is Snowpal’s Project Management product? A project management platform — available as a web app and mobile app — built on our own Project Management API. You can use it directly at snowpal.com, or integrate the underlying API into your own product.

What can I do with it? Organize work using a flexible hierarchy: Keys (containers, like Projects or Boards) contain Blocks (foundational building blocks), which contain Pods (a further level of detail). You can manage tasks, checklists, comments, notes, attachments, and favorites, link related content with symbolic links, grant collaborators Read/Write/Admin access at the Block or Pod level, and build custom charts and dashboards.

Is it available on mobile? Yes — Snowpal’s apps are available on the App Store and Play Store, in addition to the web app.

Can I build my own project management tool instead of using yours? Yes. The Project Management API that powers our own platform is available for you to integrate directly, so you can build a custom web, mobile, or server-side solution rather than using our hosted app.

Managed Services

Does Snowpal offer anything beyond self-serve APIs and products? Yes — we offer Managed Services for teams that want hands-on help integrating our APIs or building on our platforms, rather than doing it entirely self-serve.

How do I get in touch? Book a meeting, or email varun@snowpal.com.

Have a question that’s not covered here? Reply to this post or reach out to us.

In this episode, ⁠Krish Palaniappan⁠ speaks with ⁠Brian Samson⁠, founder of ⁠Plugg Technologies⁠, about the evolving landscape of remote work, particularly in the context of nearshoring and offshoring. Brian shares insights on the benefits of hiring talent from Latin America, the cultural nuances that affect remote collaboration, and the importance of a rigorous hiring process to mitigate risks associated with international hiring. The conversation delves into the value of talent beyond cost savings and the challenges faced when hiring from different countries.

• Originally featured on the Snowpal Podcast with Krish Palaniappan

• Guest: Brian Samson, Founder of Plugg Technologies

Most companies weighing nearshore hiring ask the wrong question first. They ask how much cheaper it is, when the question that actually determines whether the decision pays off is how much value they are getting for that lower cost. Host Krish Palaniappan spent much of his conversation with Brian Samson pressing on exactly that gap, playing devil’s advocate at nearly every turn, and the exchange produced one of the more rigorous breakdowns of nearshore economics available on any podcast. Krish did not let Brian get away with vague claims about savings; he wanted the actual math.

What emerged is a framework that treats nearshoring less like a discount and more like an arbitrage calculation, one where a company can save 50 percent on cost while absorbing only a 10 to 20 percent dip in output quality, netting a real gain in value rather than just a lower invoice. That distinction, cost savings versus value creation, is the thread running through the entire episode.

Samson has built his career around proving that math out in practice. He has spent 11 years in nearshoring, made more than 500 placements, and built three separate companies to $4M ARR each. He moved to Buenos Aires with two suitcases, grew a software development team there to 80 engineers, and later exited that business. Today he runs Plugg Technologies from Hawaii, placing senior Latin American developers, DevOps engineers, QA specialists, and data engineers with U.S. companies.

The Real Math Behind Nearshoring

Krish Palaniappan pushed Samson to defend nearshoring on grounds other than price, asking directly whether there was any reason to hire nearshore or offshore that had nothing to do with the dollar amount being saved. Samson’s answer reframed the entire conversation around labor arbitrage rather than simple cost cutting. Using Mexico as an example, he walked through the numbers: a U.S. based technical role paying a $150,000 base salary actually costs a company closer to $200,000 once benefits, FICA, and employer taxes are factored in. The equivalent role in Mexico, once local benefits like the aguinaldo (a mandatory 13th month salary) are included, runs closer to $100,000 all in.

That is a 50 percent cost reduction. But Samson was careful to note that quality does not drop by the same percentage. In his experience, the quality gap between a well vetted nearshore hire and a U.S. based one runs closer to 10 to 20 percent, which means the net effect is closer to a 30 percent gain in value once cost and output are weighed together. This is the calculation Samson wants hiring managers to run before they dismiss nearshoring as a race to the bottom on price. It is not about finding the cheapest person available, it is about finding where the value curve actually bends in a company’s favor.

The Cultural Question Most Hiring Managers Get Wrong

Krish Palaniappan raised a pointed objection that many hiring leaders quietly share: if a company already trusts a domestic hire’s resume, LinkedIn history, and legal accountability without a second thought, why should international hiring require extra scrutiny? “I’m not worried that Brian Samson is Brian Samson. I’m not worried that Brian’s resume is any different from what Brian purports that resume to be. I go to LinkedIn’s profile. I know Brian’s been doing this and I trust everything that Brian says,” said Krish Palaniappan, framing the deeper issue as one of unfamiliar geography and legal systems rather than talent quality itself.

Samson’s response separated two distinct kinds of culture that often get conflated. There is the surface level culture of customs and communication style, and then there is what he called startup culture, the shared experience of solving hard problems under real constraints. He argued that the attributes most hiring managers actually want, critical thinking, resourcefulness, grit, and humility, are becoming harder to find in populations that have not had to navigate real adversity. Latin American professionals who have lived through hyperinflation, labor strikes, and menu prices that change so often they are written in chalk develop those traits out of necessity. Samson pointed to the growth of venture capital ecosystems in Argentina, Brazil, and India as evidence that this same startup pressure is now producing a deep bench of talent that has been tested the same way U.S. founders have been tested.

The One Time a Candidate Was Not Who They Said They Were

Krish Palaniappan’s skepticism about international hiring risk was not abstract, and Samson met it with a real story rather than a reassurance. Over five years running Plugg Technologies, there was exactly one instance where the person who showed up for the first day of work did not appear to be the same person who had completed the interview process. “So in other words, Brian, you hired somebody and then the person who showed up to the job was different from the person who actually took the interview initially,” said Krish Palaniappan, confirming the detail before moving on.

Samson’s takeaway was not that international hiring is inherently riskier, but that hiring rigor matters more than geography. Companies that skip background checks, reference calls, and video interviews in a rush to fill a seat are the ones most exposed to this kind of problem, regardless of where the candidate is based. A disciplined process, video verification, reference checks, and a structured interview loop, catches this before it becomes a first day surprise. This is a useful reminder for any company evaluating nearshore staffing partners: the safeguard is not avoiding international talent, it is building a hiring system rigorous enough to trust regardless of where the candidate lives.

AI Is Not Killing Nearshoring, It Is Multiplying Its Value

The most forward looking exchange in the episode centered on whether AI tools make nearshoring less necessary, since companies can now do more with fewer people. Krish Palaniappan pushed this scenario hard, citing a founder who went from 50 employees to eight and asking whether the savings from AI adoption might simply replace the savings companies used to get from hiring abroad.

Samson’s answer was that the two are not competing forces, they compound. A company that combines a nearshore team with AI tooling gets what he called a double bonus arbitrage: the labor cost savings of nearshoring layered on top of the productivity gains from AI, rather than one canceling out the other. He was careful to note that AI is not a U.S. exclusive advantage; nearshore talent is adopting the same tools just as quickly, so the productivity gap does not disappear, it compounds in the buyer’s favor on both sides of the equation.

Why the Engineering Org Chart Is About to Look Different

Both Samson and Krish Palaniappan agreed that the makeup of engineering teams is shifting in ways that are hard to predict from historical hiring templates. Samson argued that mid-level engineering managers, people too senior for day to day coding but not senior enough to operate at an executive level, are increasingly exposed as companies flatten their organizational structures. He pointed to a pattern he first observed at a San Francisco unicorn: engineers overwhelmingly prefer leads who are still writing code themselves, and professionalized management layers that pull people away from hands on work tend not to last.

Krish Palaniappan extended the argument beyond engineering, noting that software developers are far from the only role that could be affected by AI driven efficiency gains. “I don’t know why it’s just software engineers that everyone seems to come after. I think there are a lot of roles that are going to disappear. It’s not just us,” said Krish Palaniappan. Both agreed that the traditional formula of one architect, three developers, one product manager, and one tester is unlikely to hold, and that team composition going forward will need to be built role by role rather than templated from past hires. Samson closed the thread on a striking note about how far this shift has already gone: “You’re building a software company, you’re building software, but you actually don’t have a technical co-founder, which is a statement that you one could not have made a year ago or maybe two years ago,” said Krish Palaniappan, reacting to Samson’s point that AI tools now let non-technical founders get a product to the validation stage before ever hiring an engineer.

How to Get Started

For companies weighing whether and how to bring nearshore talent into their hiring mix, the conversation points to a few concrete next steps.

1. Run the actual arbitrage math before deciding. Compare the fully loaded cost of a domestic hire against the fully loaded cost of a nearshore hire, then weigh the realistic quality gap, not the assumed one, before making a call.

2. Tighten the hiring process rather than avoiding international candidates. Video verification, reference checks, and a structured interview loop reduce risk far more effectively than staying domestic out of caution.

3. Pair nearshore hiring with AI adoption rather than choosing between them. The two produce compounding value when used together, not competing savings.

4. Rebuild team composition role by role. Do not assume the engineering org chart that worked two years ago still applies. Start from the specific problem being solved and staff accordingly.

The Bottom Line

The core insight from this conversation is that nearshoring, done with real rigor, is not a shortcut around quality, it is a way to buy more value for the same dollar. Samson’s own path from a San Francisco talent recruiter to a founder running nearly 100 people across Latin America shows what happens when that math is applied consistently over a decade.

Summary

🌎 Brian’s Background & Business Focus

• Former head of talent in SF tech

• 10+ years operating in Latin America

• Plug Technologies founded in 2022

• Focus: Matching U.S. companies with Latin American tech talent

• Value: Same or similar time zones → better collaboration & cultural proximity

🧠 Offshoring vs Nearshoring vs Onshoring (Key Definitions)

Outsourcing: Contracting work outside your core team

Offshoring: Hiring across oceans (e.g., US → India)

• Lower cost, follow-the-sun model

  Nearshoring: Hiring in nearby countries, same or close time-zone (e.g., US → LATAM)

• Cost savings + real-time collaboration

  Onshoring: Hiring in your country

• Shared culture, fewer risks, highest cost

💸 Labor Arbitrage & Value Equation

• Offshoring/nearshoring isn’t only about cost reduction

• Value focus:

  • Example: $200K US engineer → $100K LATAM engineer

  • ~50% savings with maybe 10–20% difference in quality

  • Net value gain ~30%

💼 Cultural & Skills Considerations

• LATAM talent described as:

  • Resourceful, gritty, clever, hardworking, loyal

• Result of real-world economic pressures & scrappy startup environments

• “Top talent exists everywhere — location is less relevant now”

👀 Trust, Vetting & Hiring Challenges

• Global hiring challenge: fake candidates & misrepresentation

• Rise in impersonation cases with remote interviews

• Solution: rigorous hiring process

  • structured interviews

  • video calls

  • references

  • background checks

🤖 AI’s Impact on Talent Models

• AI lowers cost of building software

• Teams can be smaller & more efficient, wherever they’re located

• Future = nearshoring + AI → double efficiency advantage

• Core leadership team still valuable close-by

• Supplemental talent can be global

🚀 Entrepreneurship in the AI Era

• Lower barriers to start companies than ever

• Offshoring + nearshoring + AI → “multi-order efficiency boosts”

• More global entrepreneurs, less need for huge seed capital

👷 Future of Engineering & Workforces

• Composition of engineering teams will change

• Fewer engineers needed, but higher-quality roles

• Rise of lean teams

• Mid-level managers at risk (trend already visible in Big Tech)

• ICs and senior leaders remain crucial

🎓 Education & Young Talent

• Universities lag behind tech evolution

• Students must self-learn AI and modern tools

• Product-thinking engineers become more valuable

🔮 Predictions on AI & Jobs

• AI won’t replace developers wholesale yet

• But team structure, workflow, and required knowledge will reshape

• “Everyone must re-learn how to build software”

Frequently Asked Questions

What is nearshoring in business terms?

Nearshoring means hiring talent in a nearby country that shares a similar time zone to the hiring company, as opposed to offshoring, which sends work to a distant, often lower cost region regardless of time zone overlap. Brian Samson of Plugg Technologies describes nearshoring for U.S. companies as hiring across Latin America, where teams remain available for real time collaboration during the U.S. workday.

Why do U.S. companies choose Latin America over Asia for nearshoring?

Time zone alignment is the primary reason. Brian Samson explains that Latin American countries fall on U.S. time zones or close to them, enabling same day collaboration on tools like Slack and Jira, whereas offshoring to Asia typically sacrifices that overlap in exchange for deeper cost savings.

What roles can be nearshored to Latin America?

Software developers, DevOps engineers, QA specialists, and data engineers are the roles Brian Samson places most often through Plugg Technologies. He notes that non-core functions like finance and accounting can also be outsourced regardless of location, while core technical roles benefit most from the time zone alignment that nearshoring specifically provides.

How much can a company save by nearshoring instead of hiring domestically?

Brian Samson estimates roughly 50 percent cost savings when nearshoring a technical role to a country like Mexico, once fully loaded U.S. costs like benefits and employer taxes are factored in. He argues the quality difference is much smaller, closer to 10 to 20 percent, which results in a net value gain rather than a simple discount.

Does AI reduce the need for nearshore hiring?

According to Brian Samson, AI does not replace the value of nearshoring, it compounds it. Companies that combine nearshore talent with AI tooling get layered savings, since nearshore teams are adopting the same AI tools as quickly as U.S. based teams, meaning the productivity gains apply on both sides of the equation rather than eliminating the need for nearshore staffing.

What does Plugg Technologies do?

Plugg Technologies is a nearshore staffing company founded by Brian Samson that connects software developers, DevOps engineers, QA specialists, and data engineers across Latin America with U.S. companies. The company has made more than 500 placements over 11 years and is led by Samson and his partner Ruben, both former expats in Latin America. More information is available at plugg.tech.

Brian Samson is the founder of Plugg Technologies and host of The Nearshore Cafe Podcast. This post is based on his appearance on the Snowpal Podcast.

AI + Snowpal API: Reduce Time to Market

AI + Snowpal API: Reduce Time to Market

Podcast

The Post-Vibe-Coding Era: AI Agents, Code Review, and the Future of SaaS — on Apple and Spotify.

Overview

Most “AI is changing engineering” content stays at the level of anecdote. This piece tries to go one layer deeper into four specific claims made in the conversation, each of which has concrete operational implications for engineering teams:

1. Cloud native’s definition is shifting under AI-assisted development,

2. Code review is becoming a two-stage, agent-then-human pipeline,

3. Model selection is a benchmarking problem, not a leaderboard-reading problem, and,

4. Token spend is emerging as a per-developer budget line that companies don’t yet know how to reason about. A closing section covers the SaaS market debate.

1. Cloud native as an operating model, and what AI is doing to it

Chippagiri’s framing is that cloud native was never really defined by its toolchain. Containers and Kubernetes are necessary but not sufficient: “We’re using containers, Kubernetes does not automatically make it like a cloud native system.” A cloud native system additionally has to satisfy elasticity, resilience, and observability requirements, and has to tolerate frequent change without breaking. That’s a design-time property, not a deployment-time one — you can run Kubernetes and still build a brittle, unobservable monolith split into pods.

What’s changed operationally between 2024 and 2026, in his account, is not the definition itself but who is now producing systems that have to meet it. He described developers with no formal coding background building, deploying, and iterating on entire websites without understanding the underlying code. The practical effect: time-to-first-deployment has collapsed toward zero, but the gap between “deployed” and “cloud native” (elastic, observable, resilient) hasn’t closed at the same rate. That gap is where the rest of the conversation lives.

2. The two-agent review pipeline

This is the most concrete technical artifact in the conversation. Chippagiri described a specific pattern his team uses to manage what he calls “review fatigue” — the bottleneck created when AI tools let individual contributors generate far more code than a human reviewer can meaningfully read line-by-line.

The pattern has two stages:

Stage 1 — Agent-to-agent review. One agent (”Agent A”) generates the code. A second, independently prompted agent (”Agent B”) reviews Agent A’s output against a specification: does this code do what it claims to do, and does it match the intended design? Chippagiri: “I have an agent A that writes a whole bunch of code. And now I have my own agent B that reviews what agent A has written. And then you give it a prompt saying, hey, this is what it’s supposed to look like. Does this code basically do what you want it to do?”

Stage 2 — Human gatekeeping. The human reviewer doesn’t re-derive Agent B’s findings from scratch. Instead, they validate Agent B’s comments against the diff: “So the way the human in the loop works is like, hey, at some point there needs to be a human that does the gatekeeping... So Agent A has done this, Agent B has reviewed what it is and then given a list of comments. So let’s see how valid these are.”

The engineering rationale is cognitive-load reduction, not review elimination. A human is still the final gate before production, but the human’s job shifts from generating findings to adjudicating findings an agent already surfaced. Chippagiri reports this pattern being particularly useful on large merge requests, where the volume of changes would otherwise overwhelm a single-pass human review.

Two implementation details worth noting for teams considering this pattern: first, Agent B needs an explicit spec or acceptance criteria to review against — without one, a review agent can only check for internal consistency, not correctness against intent. Second, the pattern doesn’t remove the need for engineers to independently build intuition for AI-generated code. Chippagiri’s advice here is to interrogate the model directly: “If you just ask the model, like, why did you do this, it basically explains to you the entire logic.” He frames this as a skill that compounds with repetition rather than something you either have or don’t: “The only limiting factor is yourself.”

3. Where the PRD goes when PMs can prototype

A secondary but related shift is upstream of the code entirely. Product requirements used to arrive as prose — a PRD document describing what should be built and why. Chippagiri described PMs increasingly using AI tools to produce working mockups instead: actual buttons, actual layout, a clickable approximation of the target UI, before requirements ever reach engineering.

The technical consequence is that the model doing the implementation work now has two inputs instead of one: the PRD (business logic, constraints) and a working prototype (visual/interaction target) that the model can read alongside the existing codebase to propose an integration. Chippagiri describes the resulting cycle as compressing from weeks to days — not because the code got easier to write, but because the ambiguity between “what the PM meant” and “what the PM wants on screen” got resolved before implementation started, removing a round-trip that used to consume much of the cycle time.

4. Model selection as a benchmarking discipline

With model proliferation accelerating, Chippagiri’s approach to selecting a model for a given task is deliberately unglamorous: identify the task, survey what’s already performing well in that category, then benchmark against your own use case rather than trusting general-purpose leaderboards.

He’s specific about specialization: his team leans on Claude Code and Cursor for software generation because those tools are trained heavily on code repositories — “millions of code bases” — rather than general-purpose data. His broader point is that model quality is task-conditional, not a single scalar: “Maybe Gemini may be good at certain things like visual or maybe picture management, but it may not be necessarily the right fit for the software generation.” He extends this to version-level differences within a single model family, noting that some versions outperform others on specific parameters even within the same lineage.

For narrower domains — he uses fintech as an example — his recommended process is: survey vertical AI startups that specialize in the relevant data type (video, image, financial documents, etc.), shortlist candidates based on published performance in that niche, then run internal benchmarks against your own representative tasks before committing. The throughline is that model selection is treated as an empirical, per-team decision, not a one-time platform choice.

5. Token economics: the cost side of the equation nobody’s solved yet

This is the least resolved part of the conversation, and Chippagiri is candid about that. The framing question — raised by Krish, referencing a public comment from Jensen Huang that a developer paid roughly $500K should be expected to consume roughly $2M in tokens — is how to compare token spend against developer time saved.

Chippagiri’s stated formula is simple in structure and hard in practice: compare the dollar value of time saved against the dollar cost of tokens spent. The difficulty, which both speakers acknowledge, is that “time saved” has no stable baseline — task duration estimates vary enormously by engineer seniority, domain familiarity, and team context, so the denominator in that comparison is itself an approximation, not a measured quantity.

On governance, Chippagiri describes token budgeting as moving toward per-developer caps rather than per-team pools, specifically to prevent a small number of high-usage engineers from consuming a shared budget: “I think it has to be managed per developer because that way you can be a little bit more judicious... if you do it as part of a team, then there might be instances where certain people might use most of the tokens.” The evaluative frame companies are converging on, per his account, pairs employee cost (salary, seniority level) against token consumption and expects a visible productivity return: “If you’re going to use this many tokens, show me the amount of productivity that you’ve got.”

The practical implication for engineering leadership: token spend is becoming a per-head metric that sits alongside salary in performance and budget conversations, but the tooling to make that comparison rigorous — reliable baselines for “how long would this have taken without AI assistance” — doesn’t yet exist in a standardized form.

6. Is the SaaS category structurally impaired?

The conversation closes on a market question: Krish notes that companies like Atlassian and Workday have lost significant market cap over roughly two years, against a backdrop of capital flowing hard into AI infrastructure and semiconductor names. Is this evidence that SaaS as a category is being disintermediated by AI-native, wipe-coded alternatives?

Chippagiri’s answer separates cyclical capital rotation from structural threat. On rotation, his point is that capital simply follows whatever sector is currently hottest — “there’s money always moves from what is hot right now” — and today that happens to be AI, with no guarantee it stays that way. On structural threat, his position is that the “SaaS apocalypse” narrative is overstated because SaaS value isn’t primarily code: “SaaS is not just code. It’s also years and years worth of domain knowledge, years and years worth of customization... there’s compliance, there’s governance, there’s regulatory requirements.” His specific technical claim is about scaling difficulty: a small tool can be wipe-coded and will work fine for five or six users, but the gap between that and a product serving millions of users under compliance and governance constraints is where SaaS incumbents retain structural advantage.

Takeaway

The pattern across all four technical threads is consistent: AI tooling has compressed the generation step of software work — code, prototypes, even initial review passes — much faster than it has compressed the judgment step. Review still needs a human gate. Model selection still needs empirical benchmarking per use case. Token spend still needs a cost-benefit framework that doesn’t fully exist yet. And SaaS products still need the accumulated domain, compliance, and scaling expertise that a fast prototype doesn’t carry. The engineering organizations adapting fastest, per this conversation, aren’t the ones generating the most code — they’re the ones building the review, evaluation, and governance layers around that generation as deliberately as they used to build the code itself.

┌───────────────────────────────────────────────────────────────────────────┐
│              SNOWPAL PODCAST — Krish Palaniappan × Srinivas Chippagiri    │
│                  "AI, Cloud Native & The Future of Engineering"           │
└───────────────────────────────────────────────────────────────────────────┘

  CLOUD NATIVE, REDEFINED
  ┌────────────────────────────┐
  │ Containers/K8s ≠ cloud     │
  │ native. Needs: elasticity, │
  │ resilience, observability  │
  └──────────────┬─────────────┘
                 │
                 ▼
  AI CHANGES WHO CAN BUILD
  ┌────────────────────────────┐
  │ Non-coders ship prototypes │
  │  & even production apps    │──────┐
  └──────────────┬─────────────┘      │
                 │                    │ but...
                 ▼                    ▼
  VIBE CODING RISK              PRD → PROTOTYPE
  ┌──────────────────────┐      ┌───────────────────────┐
  │ Understanding code =  │      │ PMs mock up UI with AI │
  │ proportional to how   │      │ before writing PRDs;   │
  │ well you can debug it │      │ dev cycles: weeks→days │
  └──────────┬────────────┘      └───────────────────────┘
             │
             ▼
  TWO-STAGE CODE REVIEW PIPELINE
  ┌─────────────┐      ┌─────────────┐      ┌───────────────┐
  │  Agent A     │ ───▶ │  Agent B     │ ───▶ │  Human         │
  │  writes code │      │ reviews vs.  │      │  gatekeeper    │
  │              │      │  spec        │      │  validates     │
  └─────────────┘      └─────────────┘      └───────────────┘
             │
             ▼
  WHY ENGINEERS STILL MATTER
  ┌────────────────────────────┐
  │ Coding = 1 pillar of        │
  │ engineering. Domain/tribal  │
  │ knowledge ≠ modelable       │
  └──────────────┬─────────────┘
                 │
                 ▼
  MODEL SELECTION            TOKEN ECONOMICS
  ┌────────────────────┐      ┌────────────────────────────┐
  │ Task → survey →    │      │ $ tokens vs. $ time saved  │
  │ benchmark yourself │      │ Caps set PER DEVELOPER,    │
  │ (no single winner) │      │ not per team               │
  └────────────────────┘      └────────────────────────────┘
                 │
                 ▼
  SaaS: APOCALYPSE OR OVERBLOWN?
  ┌─────────────────────────────────────────────┐
  │ Capital rotation (SaaS → AI) ≠ structural   │
  │ decline. SaaS moat = domain + compliance +  │
  │ governance + scale, not just code           │
  └──────────────────┬──────────────────────────┘
                     │
                     ▼
  CLOSING TAKE
  ┌─────────────────────────────────────────────┐
  │ Generation got fast. Judgment didn't.       │
  │ The winners build review, evaluation & cost │
  │ governance as deliberately as they once     │
  │ built the code itself.                      │
  └─────────────────────────────────────────────┘

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

Podcast

The People Who Spent 20 Years Becoming Experts Are About to Find Out That Experience Has Been Democratized - on Apple and Spotify.

The People Who Spent 20 Years Becoming Experts Are About to Find Out That Experience Has Been Democratized

Generative AI isn’t just automating tasks — it’s distributing the very thing that made experienced leaders valuable. For decades, seniority meant accumulated intelligence. You knew things others didn’t. You’d seen cycles, patterns, failure modes. That institutional knowledge was the moat.

Kelly’s argument is that the moat is filling in. “Most leaders are where they are today because of their expertise,” she says, “but what happens when that becomes democratized?” When a junior employee with the right prompt can surface the same analysis a 20-year veteran could, the value equation changes completely. What leaders offer can no longer be just what they know. It has to be something harder to replicate — judgment, trust, the willingness to be accountable for decisions made in ambiguity.

That shift is why Kelly insists we’re not in a technology moment. We’re in a leadership moment.

AI + Snowpal API: Reduce Time to Market

Middle Managers Aren’t Obsolete — They’re Just Being Asked to Do Something They Were Never Trained For

The tech industry has a running fantasy: flatten the org, cut the middle, let AI coordinate what managers used to. Kelly thinks this is a mistake, and she’s blunt about why.

Middle managers are already the most burned-out segment of the workforce. They’re sandwiched between a C-suite selling an AI vision that isn’t fully real yet, and a workforce eager to use tools their companies haven’t figured out how to deploy. “The tools are not quite where some of the C-suite and board thinks they are,” she says. Meanwhile, managers are expected to execute a transformation that hasn’t been designed.

The role isn’t disappearing, but it is changing in a specific direction. The old job — relay information up, execute instructions down — is shrinking. The new job is orchestration: figuring out which work gets done by humans, which by AI agents, and how to hold that hybrid accountable to outcomes. It’s messier, more political, and more human than ever. The managers who survive won’t be the ones who master the tools fastest. They’ll be the ones who can navigate the parts of organizations that AI genuinely cannot touch.

That said, Kelly draws an important distinction between product companies and everyone else. In a product company, middle managers typically contribute directly — they’re in the codebase, the architecture, the design decisions. Their expertise justifies their seniority. In government agencies or traditional consulting hierarchies, where tenure drives promotion more than output, the calculus is different. If your job is coordination without contribution, AI makes it very difficult to justify that role.

Nobody Actually Knows How Many AI Agents Their Company Needs, and That’s the Problem

Krish put a question to Kelly that she called “a billion-dollar question for consulting companies”: who decides how many AI agents a company deploys, and how do you separate the ones every team shares from the ones that are specific to a single function?

The honest answer right now is: nobody has figured this out cleanly. What Kelly is seeing in practice is experimentation without governance — teams spinning up agents independently, in parallel, without coordination. The result isn’t efficiency. It’s complexity. “I have more complexity, not efficiency, because of all these AI agents I’m trying to manage,” is the phrase she keeps hearing from inside organizations.

Her prescription is a shared leadership agenda anchored at the C-suite level. The CHRO needs to be in the room, not just the CTO and CIO. HR, which has historically been left out of technology decisions, has the exact expertise this moment demands: how do you design work, structure spans of control, and build organizations around outcomes? Those questions don’t have technical answers. They have human answers. And HR is where that knowledge lives.

The principle Kelly keeps returning to is simplification. Before adding more agents, define what you need at the enterprise level and at the functional level, and be ruthless about eliminating overlap. The companies winning with AI aren’t the ones running the most experiments. They’re the ones that have decided what they’re actually trying to accomplish.

CEOs Are Saying “AI” 17 Times Per Earnings Call While Their Dev Teams Are Still Figuring Out the Tools

There’s a gap between the AI story being told and the AI reality being lived, and Kelly names it directly. Leaders know that positioning their company as AI-enabled can mean a two-to-three times valuation lift. The incentive to overclaim is enormous. And so they do.

Meanwhile, the teams actually building things are still working through which tools are ready for production, which workflows have genuinely changed, and which “AI transformation” initiatives are really just rebranded pilots that haven’t shipped. The board gets the aspirational version. The engineers get the uncertainty.

This isn’t always cynical — some of the gap is genuinely a lag between where the technology is heading and where it is right now. But Kelly doesn’t let leaders entirely off the hook. The fundamental problem is that most companies have invested heavily in AI tools without doing the hard downstream work: redesigning the job, rebuilding the workflow, doing the change management that actually makes transformation stick. She’s seen what that takes in consulting. It’s an 18-to-24 month roadmap, minimum. Most executives are measuring progress by next quarter.

The SaaS Apocalypse Is Probably Overblown — But the Market Doesn’t Seem to Have Decided Yet

Krish raised the SaaS conversation with something real: Atlassian went up 40% on earnings, then added another 5% the next day. Workday, Salesforce, Asana, Monday — companies that had been hammered for a year — are bouncing. The market keeps changing its mind.

Kelly’s read is that this whiplash is structural. Most of the broader economy is in a low-to-no-growth environment. That’s not purely an AI story — macroeconomic complexity is doing a lot of work here. But it means that AI stocks are essentially holding up the equity markets, which creates an outsized sensitivity to any signal about AI’s actual progress. Jensen Huang’s position — that SaaS companies need to evolve but aren’t going away — is closer to Kelly’s view than the doom narrative. These companies have distribution, customer relationships, and institutional trust that takes years to build. AI doesn’t make those irrelevant overnight. It does, however, require them to rethink what they’re selling and how they’re delivering it.

The Consulting Industry Built Its Junior Pipeline on Tasks That AI Now Does Better, Cheaper, and Faster

Kelly grew up in consulting. She knows the model: junior staff spend two years learning the craft through PowerPoint decks and memos, billing at a premium while absorbing industry knowledge from senior partners. That pipeline produces the partners of the future.

The problem is that AI has made the first half of that equation untenable. “You don’t need that junior consultant anymore to do that deliverable,” she says. AI can produce a polished analytical deck faster and cheaper than a first-year analyst, without the overhead. If the business case for hiring junior consultants was always partly about developing future partners, that calculus just got a lot harder.

The second challenge is more fundamental. What you hire McKinsey or Deloitte for is intelligence — the framework, the insight, the perspective accumulated across hundreds of engagements. That is precisely what generative AI is democratizing. The consulting model has to move toward problems that are genuinely hard: change management, human dynamics, the ethics of automation, the decisions that require judgment that can’t be offloaded. Firms that keep selling software implementation and document production are going to feel the pressure first.

Managed services faces an even steeper reckoning. The large-scale outsourcing model — teams in the Philippines and India handling operations at volume — maps almost directly onto what AI automates. Kelly is candid that she worries about what this means for countries where those jobs represent significant economic opportunity. The question of responsibility — who thinks through these consequences before making the switch — isn’t a business question. It’s an ethical one.

The Economy Looks Fine Until You Realize It’s Being Held Up by One Sector

The K-shaped economy isn’t a metaphor. It’s a description of what’s actually happening: returns to capital and highly-skilled knowledge work are accelerating, while pressure mounts on everyone else. The upper tier keeps spending. Luxury travel, airlines, fine dining — demand stays strong. Spirit Airlines goes bankrupt. Both things are true at the same time.

Kelly isn’t panicking, but she’s watching the lagging indicators that don’t show up immediately: credit card debt rising, spending rotating toward necessities, the compounding effect of price pressure on anyone living without a significant financial cushion. Q3 and Q4 of this year, she thinks, will be telling. The part of consumer spending that looks healthy right now may be masking a delayed adjustment.

The deeper point she makes is about interconnection. The U.S. economy is not an island. Supply chains, outsourcing relationships, oil markets, demographic shifts in Asia — all of it connects back. When companies automate away managed services jobs in India, that has consequences that eventually ripple through trade, through goods, through prices here. “The bagel you go get for breakfast has tremendous world economic consequences,” Kelly says — and most of us haven’t thought about the chain that produced it.

The New Skill Isn’t Learning to Code — It’s Learning to Unlearn

The most surprising advice Kelly offers doesn’t come from a workforce development framework. It comes from a long look at what AI actually can’t do. Empathy, wisdom, ethical judgment, creativity, the ability to hold complexity and act in ambiguity — these aren’t soft skills. They’re the hard ones. They’re the ones nobody has systematically developed, because the STEM premium made everything else feel optional.

Her read: the professions most immune to AI automation aren’t the ones that sound impressive on a LinkedIn profile. They’re healthcare, education, skilled trades. There are already labor shortages in all three. The culture hasn’t caught up — it’s still glamorizing the path of the YouTube influencer, the vibe coder, the growth hacker. But the plumber and the electrician may end up significantly better positioned in the economy that’s actually forming.

Krish offered his own version of the same idea from the builder’s perspective. The new skill, in his words, is not any particular language or algorithm. It’s “how do I solve this problem better using the current suite of people, agents, technologies, and the changing dynamics of the larger world?” The muscle memory that made experienced engineers valuable — the deeply ingrained patterns of how software gets built — is now partly a liability. The engineers who thrive will be the ones who can unlearn it.

Kelly loved that framing: “That might be your snippet for social sharing.”

The Decisions We Make About AI Today Will Shape Things for Generations

Kelly’s closing wasn’t hedged. She believes this moment is genuinely consequential — not in the hype-cycle sense of transformative technology, but in the sense that the choices leaders make right now about how to use AI, and how to treat the people displaced by it, will compound.

Her book, Reclaim the Plot, is written as fiction, drawing on real patterns she’s observed across tech and consulting without naming anyone. The central argument is that leaders keep chasing new technologies at the expense of people, and that this moment requires something different: an active rewriting of the story, not just an optimization of the current one.

The session ended the way all good conversations do — a little open, a little unresolved, with more questions raised than answered. Kelly’s dinner order was sushi, steak, and New York cheesecake. Krish’s assessment: she’s not saving that thousand dollars a month.

Listen to the full conversation on the Snowpal Podcast. Check out Dr. Kelly Monahan’s new book, Reclaim the Plot: How Leaders Rewrite the Story When AI Rewrites Work.

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.