Today, Microsoft is announcing one of the largest single capacity additions in our history. In Pecos, Texas, we will build a new datacenter campus, expanding our global datacenter capacity by approximately 2 gigawatts (GW) to meet strong and sustained customer demand for AI and cloud services across industries and regions. Beyond the technology, this is a major investment in West Texas. We expect to support over 6,000 construction jobs at peak build-out and to create hundreds of permanent operational jobs that will add a new industry that supports the local economy when the new datacenter campus is operational.

This multibillion-dollar datacenter campus investment over the next five to seven years reflects both the immediate needs we are seeing today and the future trajectory of AI and advanced compute, where reliable infrastructure at scale is essential to unlocking the next generation of innovation. This expansion is grounded in a simple principle: we build where our customers need us, and we build for the long term. We have a track record of doing exactly that in Texas. In the San Antonio region, where we have operated datacenters for nearly a decade, our investment has generated billions of dollars in local economic activity and supported thousands of local jobs. We are committed to delivering the same lasting value in Pecos.

Meeting customer demand with reliable infrastructure

Customer demand for AI and cloud services continues to grow rapidly, from startups building new applications to governments, healthcare providers and educational institutions modernizing critical systems. Meeting this demand requires not only more datacenter capacity, but capacity that is predictable, resilient and able to scale quickly.

The datacenter campus in Pecos enables us to deliver on that need. By pairing new datacenter infrastructure with dedicated energy supply located onsite, we can bring capacity online at the pace our customers require while maintaining operational reliability. Critically, the energy infrastructure required to power this datacenter is being funded by Microsoft. We are paying for the new generation and supporting infrastructure needed to serve our own operations. The capacity we bring online in Pecos is built to meet our demand, ensuring that our growth strengthens, rather than strains, the energy resources the community relies on.

Putting Community First in West Texas

While meeting customer demand is critical, how we grow is equally important. At Microsoft, our Community First approach guides us where we build, own and operate our datacenters, including our new datacenter campus in Pecos.

This work begins with a simple commitment: we show up as a lasting partner, not just a builder of infrastructure.

As shared in our letter to the community in Pecos and Reeves County, we are approaching this project as a new neighbor, with a focus on partnership, transparency and listening. We recognize that earning trust takes time, and we are committed to ongoing engagement with local residents, leaders and organizations as this project moves forward. The region’s elected leadership has welcomed the investment. Reeves County Judge Leo Hung, the county’s top elected official, said:

“We are excited to welcome Microsoft to Pecos. This investment reflects the strength of our region and its ability to support innovation at a global scale. It will create new opportunities for local businesses, support workforce development and reinforce Pecos as a place where forward-looking companies can grow and thrive.”

Our Community First approach in this region focuses on three priorities:

1. Listening and engaging early
We engage early and often through community meetings, local partnerships and ongoing communication across the life of the project, which gives residents multiple ways to ask questions and share feedback, just as we have in other Texas communities.

2. Creating local economic opportunity
This project is built to drive lasting regional growth. As well as supporting thousands of construction jobs, the hundreds of permanent operational roles will add a new industry to the local economy. We will also invest in workforce development and small-business support. We are focused on ensuring that local residents are prepared to take advantage of the opportunities created by the AI economy. This is part of a sustained commitment to the region, building on more than a decade of experience in Texas, including our operations in San Antonio:

Near San Antonio, where we have operated for nearly a decade, our Datacenter Academy partners with local colleges to prepare students for datacenter careers, including a $545,000 investment that has already reached more than 450 students. Statewide, workforce programs like TechSpark have helped create more than 1,100 jobs and engaged 20,000 Texans in digital skilling. We will bring the same model of local hiring, training and small-business support to West Texas.

3. Partnering for lasting community impact
Our investment reaches well beyond the datacenter, into education, digital inclusion and nonprofit partnerships. In fiscal year 2024, Microsoft and its employees contributed $11 million in cash and $103.3 million in donated software and cloud technology to more than 10,000 Texas nonprofits, alongside 42,000+ employee volunteer hours. In Pecos, we will direct that same commitment toward the priorities that matter most to West Texas residents.

Advancing sustainability through innovation

As we expand our datacenter footprint, we remain equally committed to building and operating our infrastructure in ways that reduce environmental impact.

Energy and emissions
This includes improving energy efficiency across our infrastructure, from compute to hardware, and building on the 4.7 GW of renewable electricity we have already contracted for our electricity use in Texas, advancing carbon-free electricity through renewable generation and other technologies. This investment is intentionally designed with flexibility in mind, allowing Microsoft to adjust capacity over time as demand evolves.

At launch, the datacenter campus will operate with a co-located natural gas power facility, an arrangement known as “behind the meter.” This serves the campus directly and independently of the public grid, so this demand does not take from the current grid. The plant’s design will integrate state-of-the-art air emissions controls, such as Selective Catalytic Reduction systems to lower nitrogen oxide emissions. Over time, we anticipate connecting the power facility and the datacenter to the broader grid and becoming part of the regional energy system, working in close coordination with utilities and local authorities. We will continue to drive additional improvements in environmental performance in line with our corporate commitments. This evolution reflects our long-term mindset in the region: as we grow, we intend to contribute to a more resilient and reliable grid that delivers value not only to our operations, but to the wider West Texas community.

Water stewardship
We plan to deploy closed loop cooling systems, which significantly reduce water requirements. This approach is expected to limit water usage by requiring only an initial charge of the cooling system at the start of operations, with no additional water consumption during steady-state operation. As a result, the total lifecycle water use of this datacenter is only a fraction of that consumed annually by a typical fast-food restaurant.

We are also designing our operations to minimize reliance on freshwater sources by utilizing nonpotable water where possible, helping to reduce pressure on shared community resources.

This builds on the way we approach water stewardship across Texas. Near San Antonio, Microsoft has helped fund the permanent protection of more than 1,500 acres in the Edwards Aquifer recharge zone — safeguarding a critical water source for over two million Texans — as part of our broader commitment to be water positive by 2030. In Pecos, we will continue to prioritize responsible water use, efficient design and close coordination with local authorities as our operations grow, and we will share our progress with the community over time.

Building for the future, responsibly

The datacenter in Pecos represents an important step forward in how we build infrastructure for the AI era by combining capacity at scale, energy and a commitment to responsible growth.

But just as importantly, it reflects how we do this work: in partnership with communities, with an enduring mindset and with a focus on creating shared value.

As we move forward, we will continue to engage closely with the community in West Texas, provide updates on our progress and ensure that this investment delivers lasting benefits for both our customers and our neighbors. Community members can learn more at Open letter to Pecos and Reeves County – Microsoft Local.

We look forward to building that future together.

Noelle Walsh leads the organization that powers the global Microsoft Cloud. She oversees the company’s physical cloud infrastructure and operations, with a charter focused on safety, security, availability, sustainability and competitive infrastructure growth — bringing decades of global operational leadership.

The post Powering the next wave of AI: Expanding capacity with our new datacenter in Pecos appeared first on The Official Microsoft Blog.

The following article originally appeared on Addy Osmani’s blog and is being reposted here with the author’s permission.

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of as a recursive goal where you define a purpose and the AI iterates until complete. I believe this may be the future of how we work with coding agents. However, it’s still early; I’m skeptical, and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor), so I want to unpack what it is and what it means.

Peter Steinberger recently said: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Similarly, Boris Cherny, head of Claude Code at Anthropic, said, “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops”.

Okay, so what does any of that mean?

For like two years, the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it’s going to be.

Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model—the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.

The thing that surprised me is this is not really a tool thing anymore. A year ago if you wanted a loop you wrote a pile of bash and you maintained that pile forever and it was yours and only yours. Now the pieces just ship inside the products. Steinberger’s list maps almost exactly onto the Codex app, and then almost the same onto Claude Code. And once you notice the shape is the same, you stop arguing about which tool. You just design a loop that still works no matter which one you happen to be sitting in.

The five pieces, and then notes

A loop needs five things and then one place to remember stuff. Let me list it first and then map it.

1. Automations that go off on a schedule and do discovery and triage by themselves
2. Worktrees so two agents working in parallel don’t step on each other
3. Skills to write down the project knowledge the agent would otherwise just guess
4. Plugins and connectors to plug the agent into the tools you already use
5. Subagents so one of them has the idea and a different one checks it

Then the sixth thing, the memory. A Markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long-running agent depends on, and I went into it in “Long-Running Agents”: The model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets; the repo doesn’t.

Both products have all five now.

Primitive	Job in the loop	Codex app	Claude Code
Automations	Discovery + triage on a schedule	Automations tab: pick project, prompt, cadence, environment; results land in a Triage inbox; /goal for run-until-done	Scheduled tasks and cron, /loop, /goal, hooks, GitHub Actions
Worktrees	Isolate parallel features	Built-in worktree per thread	git worktree, --worktree, isolation: worktree on a subagent
Skills	Codify project knowledge	Agent Skills (SKILL.md), invoked with $name or implicitly	Agent Skills (SKILL.md)
Plugins and connectors	Connect your tools	Connectors (MCP) plus plugins for distribution	MCP servers plus plugins
Subagents	Ideate and verify	Subagents defined as TOML in .codex/agents/	Task subagents in .claude/agents/, agent teams
State	track what’s done	Markdown or Linear via a connector	Markdown (AGENTS.md, progress files) or Linear via MCP

The names are a bit different here and there, but the capability is the same thing. Let me go one by one because honestly the details are where a loop either holds together or quietly leaks everywhere.

Automations, this is the heartbeat

Automations are what make a loop an actual loop and not just one run you did once. In the Codex app you make one in the Automations tab and you pick the project, the prompt it will run, how often, and if it runs on your local checkout or on a background worktree. The runs that find something go to a Triage inbox, and the runs that find nothing just archive themselves which is nice. OpenAI uses them internally for boring stuff like daily issue triage, summarizing CI failures, writing commit briefings, and hunting bugs somebody added last week. And an automation can call a skill, so you keep the recurring thing maintainable; you fire $skill-name instead of pasting a giant wall of instructions into a schedule that nobody will ever update.

Claude Code gets to the same place but through scheduling and hooks. You can run a prompt or a command on a interval with /loop, you can schedule a cron task, you can fire shell commands at certain points in the agent lifecycle with hooks, or you push the whole thing to GitHub Actions if you want it to keep running after you close the laptop. Same idea exactly, you define an autonomous task, you give it a cadence, and the findings come to you so you are not the one going around checking.

There is a second in-session primitive worth knowing, and it’s the one closer to what this whole post is about. /loop re-runs on a cadence. /goal keeps going until a condition you wrote is actually true, and after every turn a separate small model checks whether you are done, so the agent that wrote the code isn’t the one grading it. You give it something like “all tests in test/auth pass and lint is clean” and walk away. Codex has the same thing, also called /goal: It keeps working across turns until a verifiable stopping condition holds, with pause and resume and clear. Same primitive, both tools, which is kind of the pattern for this whole article.

So this is the part that surfaces the work. The rest of the loop is what acts on it.

Worktrees, so parallel doesn’t turn into chaos

The second you run more than one agent, the files start colliding; that becomes the failure. Two agents writing the same file is the exact same headache as two engineers committing to the same lines and nobody talked to each other first. A Git worktree fixes it. It’s a separate working directory on its own branch sharing the same repo history, so one agent’s edits literally cannot touch the other one’s checkout.

Codex builds the worktree support right in so several threads hit the same repo at once and don’t bump into each other. Claude Code gives you the same isolation with git worktree, a --worktree flag to open a session in its own checkout, and a isolation: worktree setting you stick on a subagent so each helper gets a fresh checkout that cleans itself up after. (I wrote about the human side of all this in “The Orchestration Tax.”) The worktrees take away the mechanical collision, but YOU are still the ceiling. Your review of bandwidth decides how many you can actually run, not the tool.

Skills, so you stop explaining your project every single time

A skill is how you stop reexplaining the same project context every session like a goldfish. Both tools use the same format: a folder with a SKILL.md inside holding instructions and metadata, and then optional scripts, references, and assets. Codex runs a skill when you call it with $ or /skills, or by itself when your task matches the skill description, which is the reason a tight, boring description beats a clever one. Claude Code does it the same way and I wrote the pattern up in “Agent Skills.”

Skills are also where intent stops costing you over and over. I argued in “The Intent Debt” that an agent starts every session cold and it will fill any hole in your intent with a confident guess. A skill is that intent written down on the outside, the conventions, the build steps, the “we don’t do it like this because of that one incident,” written one time where the agent reads it every run. Without skills the loop rederives your whole project from zero every cycle; with skills it kind of compounds.

One thing to keep straight: The skill is the authoring format, and a plugin is how you ship it. When you want to share a skill across repos or bundle a few together, you package them as a plugin. True in Codex, true in Claude Code.

Plugins and connectors, the loop touches your real tools

A loop that can only see the filesystem is a tiny loop. Connectors, which are built on MCP, let the agent read your issue tracker, query a database, hit a staging API, or drop a message in Slack. Codex and Claude Code both speak MCP so the connector you wrote for one usually just works in the other. And plugins bundle connectors and skills together so your teammate installs your setup in one go instead of rebuilding the whole thing from memory.

This is the difference between an agent that says “here is the fix” and a loop that opens the PR, links the Linear ticket, and pings the channel once CI is green by itself. The connectors are the reason the loop can act inside your actual environment instead of just telling you what it would do if it could.

Subagents, keep the maker away from the checker

The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks. The model that wrote the code is way too nice grading its own homework. A second agent with different instructions and sometimes a different model catches the stuff the first one talked itself into.

Codex only spawns subagents when you ask, runs them at the same time, and then folds the results back into one answer. You define your own agents as TOML files in .codex/agents/, each with a name, a description, instructions, and optional model and reasoning effort, so your security reviewer can be a strong model on high effort while your explorer is some fast read-only thing. Claude Code does the same with subagents in .claude/agents/ and agent teams that pass work between them. The usual split in both is one agent explores, one implements, and one verifies against the spec.

I made this case twice already, once as “The Code Agent Orchestra” and once as “Adversarial Code Review.” The reason it matters specifically inside a loop is the loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away. Subagents do burn more tokens since each one does its own model and tool work, so spend them where a second opinion is worth paying for. This is also basically what Claude Code’s /goal does under the hood: A fresh model decides if the loop is done instead of the one that did the work, the maker and checker split applied to the stop condition itself.

What one loop looks like

Stick it together and a single thread turns into a little control panel. Here is one shape I keep using.

An automation runs every morning on the repo. Its prompt calls a triage skill that reads yesterday’s CI failures, the open issues, and the recent commits and writes the findings into a Markdown file or a Linear board. For each finding that is worth doing, the thread opens an isolated worktree and sends a subagent to draft the fix, and a second subagent reviews that draft against the project skills and the existing tests.

Connectors let the loop open the PR and update the ticket. Anything the loop cannot handle lands in the triage inbox for me. The state file is the spine of the whole thing; it remembers what got tried, what passed, and what is still open, so tomorrow morning the run picks up where today stopped.

And look at what you actually did there. You designed it one time. You did not prompt any of those steps. That’s Steinberger’s whole point made real, and it’s the same loop in Codex or in Claude Code because the pieces are the same pieces.

What the loop still does not do for you

The loop changes the work; it does not delete you from it. And three problems actually get sharper as the loop gets better, not easier.

Verification is still on you. A loop running unattended is also a loop making mistakes unattended. The whole reason you split the verifier subagent from the maker is to make the loop’s “it’s done” mean something, and even then “done” is a claim and not a proof. I keep saying the same line from “Code Review in the Age of AI”: Your job is to ship code you confirmed works.

Your understanding still rots if you allow it. The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get. That’s comprehension debt and a smooth loop just makes it grow faster unless you read what the loop made.

And the comfortable posture is the dangerous one. When the loop runs itself, it’s very tempting to stop having an opinion and just take whatever it gives back. I called that “cognitive surrender.” Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking: same action, opposite result.

Build the loop. Stay the engineer.

I think this is a preview of how our work is going to evolve. That said, if I weren’t reviewing the code myself or if I relied entirely on automated loops to fix it, my product’s quality would suffer. I’d likely end up stuck in a downward spiral, continuously digging myself into a deeper hole.

Go ahead and set up your loops, but don’t forget that prompting your agents directly is also effective. It’s all about finding the right balance.

Loops can also result in different outcomes depending on you. Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn’t know the difference. You do.

That’s what makes loop design harder than prompt engineering. Cherny’s point isn’t that the work got easier. It’s that the leverage point moved.

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

Cloud data platforms like Databricks and Snowflake are racing to embed AI directly into SQL. With Trino's AI functions, the open source ecosystem has the same capability, and on Red Hat OpenShift AI, you can bring your own models, your own data, and your own infrastructure.

This article provides an overview of an architecture connecting a modern Apache Iceberg lakehouse to LLM-hosted models using nothing but SQL. No Python notebooks. No ETL pipelines. No ML frameworks. Just SQL queries that "think."

The architecture

The stack runs entirely on OpenShift, and is illustrated in Figure 1.

• Red Hat OpenShift AI hosts LLMs as a Model-as-a-Service (MaaS) endpoint—in our case, Llama 4 Scout 17B via NVIDIA
• Trino is the distributed SQL engine that federates queries across multiple data sources
• Apache Iceberg on MinIO S3 provides the open table format lakehouse, managed by a Nessie catalog server
• PostgreSQL (with pgvector) adds a relational/vector data source
• HuggingFace datasets (hotel reviews, financial news) provide real-world text data for AI Function demos
• Trino Query UI gives analysts a web-based SQL editor

The key insight: Trino sits at the center, federating across data sources and LLM endpoints in a single query. A data analyst can join Iceberg tables with PostgreSQL, run sentiment analysis on the results, classify them by category, and generate an executive summary—all in one SQL statement.

What are AI functions?

Trino AI functions let you call an LLM directly from SQL. They're built-in functions that transform and enrich text data using large language models, without leaving your SQL environment (see Figure 2).

Seven functions cover the most common text analysis patterns:

• ai_analyze_sentiment(text)
  • What it does: Classifies text as positive, negative, neutral, or mixed
  • Example use case: Customer feedback triage, threat detection
• ai_classify(text, labels)
  • What it does: Assigns text to one of your predefined categories
  • Example use case: Log categorization, spam detection, risk classification
• ai_extract(text, labels)
  • What it does: Pulls structured data from unstructured text
  • Example use case: Entity extraction from logs, parsing incident reports
• ai_fix_grammar(text)
  • What it does: Corrects grammar and improves readability
  • Example use case: Cleaning noisy log data, polishing reports
• ai_gen(prompt)
  • What it does: Generates new text from a prompt
  • Example use case: Executive summaries, threat reports, daily briefings
• ai_mask(text, labels)
  • What it does: Replaces sensitive data with [MASKED]
  • Example use case: PII redaction, compliance exports
• ai_translate(text, language)
  • What it does: Translates text to a target language
  • Example use case: Multilingual log analysis, international collaboration

The functions connect to any OpenAI-compatible endpoint. On Red Hat OpenShift AI, that means you can use any model served with vLLM, NVIDIA NIM, or the MaaS gateway, keeping your data and models within your own infrastructure.

Why this matters: Data meets model

Traditional approaches to applying AI to enterprise data involve extracting data, running it through Python notebooks, calling APIs, and loading results back. This can create fragile pipelines, data movement overhead, and security concerns.

With AI functions in SQL:

• Data stays in place: Queries run where the data lives‚S3, PostgreSQL, or any Trino-connected source. No ETL to a separate ML environment.
• Models are services: The LLM is an API call, not a deployment you manage in your notebook. Red Hat OpenShift AI handles serving, scaling, and GPU allocation.
• SQL is the interface: Data engineers and analysts already know SQL. No new frameworks, no new languages, no new tools.
• Results are composable: AI Function outputs are regular SQL columns. You can filter, join, aggregate, and export them like any other data.

Query UI in action

The Trino Query UI lets analysts write and execute AI-enriched SQL queries directly in the browser—no CLI required. Figure 3 shows the knowledge graph example extracting technologies from semantically related developer articles.

Figure 4 is the Trino cluster dashboard showing active workers processing AI function queries in parallel across the distributed engine.

34 examples: From security analysis to financial intelligence

We built 34 example queries that demonstrate every AI function across three domains: cybersecurity log analysis, financial intelligence, and developer knowledge base search. Here's the breakdown:

 

Self-contained examples (inline data).

#	Example	AI functions
01-03	Sentiment analysis: Insider threats, phishing emails, support requests	ai_analyze_sentiment
04-07	Classification: Firewall logs, phishing subjects, SIEM alerts, web requests	ai_classify
08-10	Entity extraction: Authentication logs, file integrity monitoring, process logs	ai_extract
11-12	Grammar correction: Firewall logs, IDS alerts	ai_fix_grammar
13-14	Text generation: Threat report summary, anomaly explanation	ai_gen
15-16	PII masking: Login events, firewall logs	ai_mask
17-18	Translation: Japanese firewall logs, Spanish IDS alerts	ai_translate

Lakehouse examples (real data from S3).

#	Example	AI functions	Data source
19	Review intelligence pipeline	ai_analyze_sentiment + ai_classify + ai_extract	17K hotel reviews
20	Executive summary from guest feedback	ai_gen	17K hotel reviews
21	PII-safe multilingual review export	ai_mask + ai_fix_grammar + ai_translate	17K hotel reviews
22	Market mood ring: AI vs. human labels	ai_analyze_sentiment + ai_gen	100K financial news
23	Financial threat intelligence	ai_classify + ai_extract + ai_mask	100K financial news
24	Multilingual trading desk	ai_translate + ai_analyze_sentiment	100K financial news
25	AI editorial pipeline	ai_fix_grammar + ai_gen + ai_classify	100K financial news
26	Daily analyst morning briefing	ai_gen	100K financial news

The lakehouse examples are the most interesting because they combine multiple AI functions in a single query against real data stored in Apache Iceberg on S3. For example, the Market Mood Ring (example 22) cross-validates AI sentiment against human-assigned labels and explains disagreements:

WITH sample AS (
    SELECT text, label AS human_label,
           ai_analyze_sentiment(text) AS ai_sentiment
    FROM lakehouse.finance.financial_news TABLESAMPLE BERNOULLI (0.05)
    LIMIT 5
)
SELECT substr(text, 1, 80) AS snippet,
       human_label, ai_sentiment,
       CASE WHEN human_label != ai_sentiment THEN 'DISAGREE' ELSE 'AGREE' END AS verdict,
       ai_gen('In one sentence, explain why this financial news might be seen as '
              || ai_sentiment || ': ' || substr(text, 1, 500)) AS reasoning;

Daily Briefing (example 26) aggregates negative financial news into an analyst morning report:

WITH bad_news AS (
    SELECT text FROM lakehouse.finance.financial_news TABLESAMPLE BERNOULLI (0.5)
    WHERE label = 'negative' LIMIT 10
)
SELECT ai_gen(
    'You are a senior financial analyst. Write a concise morning briefing (5 bullet
    points max) summarizing key risks and themes: ' ||
    (SELECT json_format(CAST(array_agg(text) AS JSON)) FROM bad_news)
) AS morning_briefing;

These aren't toy examples. They query 100,000 real financial news articles stored as Iceberg tables on MinIO S3, with the LLM inference happening in parallel across Trino workers.

Part of a modern data mesh

This architecture isn't just a demo, but a pattern for how enterprises can operationalize AI within a data mesh strategy:

• Data products: Each Iceberg table (hotel reviews, financial news, vector embeddings) is a self-describing data product with its own schema, quality guarantees, and access controls.
• Federated governance: Trino federates across MinIO S3, PostgreSQL, and benchmark datasets without moving data. Domain teams own their sources; Trino provides a unified query layer.
• AI as a shared capability: The LLM endpoint is a platform service. Any domain team can call ai_classify() or ai_gen() from SQL queries without provisioning GPUs or managing model lifecycles.
• Open standards: Apache Iceberg, S3-compatible storage, OpenAI-compatible API, and SQL. No proprietary lock-in—swap MinIO for AWS S3, swap the LLM for Claude or GPT, swap Nessie for AWS Glue. The architecture is portable.

Red Hat OpenShift AI: The platform advantage

Running this on Red Hat OpenShift AI provides specific advantages:

Model serving at scale

OpenShift AI's MaaS gateway handles model serving, load balancing, and GPU scheduling. Models are exposed as simple REST endpoints that Trino calls using the OpenAI-compatible protocol.

Security by default

OpenShift's Security Context Constraints (SCCs) enforce non-root containers, capability dropping, and namespace isolation. Data never leaves the cluster.

One-click deployment

The entire stack—MinIO, Nessie, Trino, Query UI—deploys with a single install.sh script. Environment variables configure the LLM endpoint, S3 credentials, and optional PostgreSQL catalog.

Kubernetes-native operations

Helm charts, Kubernetes jobs for data loading, OpenShift Routes for external access. Standard Kubernetes tooling for day-2 operations.

Hybrid search: When vectors meet AI functions

The architecture gets even more interesting when you connect Trino to a vector database. Our PostgreSQL instance (with pgvector) stores 154,000 document chunks from every article on developers.redhat.com, each with a 768-dimensional embedding vector. These embeddings power the Red Hat Developer RAG chatbot.

With Trino, we can compute cosine similarity in pure SQL—no pgvector operators needed—and combine it with AI functions for hybrid semantic + AI analysis:

-- Cosine similarity computed entirely in Trino SQL
reduce(
    zip_with(a.embedding, b.embedding,
             (x, y) -> CAST(x AS double) * CAST(y AS double)),
    DOUBLE '0.0', (s, x) -> s + x, s -> s
) / (sqrt(..) * sqrt(..)) AS cosine_similarity;

This opens up powerful patterns that neither vector search nor AI functions can achieve alone.

 

Vector search + AI examples.

#	Example	What it does	Functions used
27	Semantic Reading List	Find articles similar to a seed by cosine similarity, generate a curated reading list	Cosine similarity + ai_gen
28	Topic Discovery	Classify random knowledge base chunks into Red Hat product areas	ai_classify
29	Content Quality Audit	Analyze tone and fix grammar across the knowledge base	ai_analyze_sentiment + ai_fix_grammar + ai_classify
30	Knowledge Graph	Find semantically related articles, extract technologies and products mentioned	Cosine similarity + ai_extract
31	Multilingual Knowledge Base	Find similar articles, translate to Japanese and Korean on-the-fly	Cosine similarity + ai_translate

For example, the Semantic Reading List (example 27) finds the 5 most similar articles to an LLM tutorial using cosine similarity over 768-dimensional embeddings, then asks the LLM to generate a reading list:

WITH seed AS (
    SELECT embedding AS seed_vec
    FROM vectordb.public.langchain_pg_embedding
    WHERE json_extract_scalar(cmetadata, '$.title') LIKE '%LLM%'
    LIMIT 1
),
similar_docs AS (
    SELECT DISTINCT
        json_extract_scalar(e.cmetadata, '$.title') AS title,
        json_extract_scalar(e.cmetadata, '$.source') AS url,
        reduce(zip_with(e.embedding, s.seed_vec,
               (a, b) -> CAST(a AS double) * CAST(b AS double)),
               DOUBLE '0.0', (st, x) -> st + x, st -> st)
        / (sqrt(reduce(transform(e.embedding, ..), ..))
         * sqrt(reduce(transform(s.seed_vec, ..), ..)))
        AS similarity
    FROM vectordb.public.langchain_pg_embedding e
    CROSS JOIN seed s
    ORDER BY similarity DESC
    LIMIT 5
)
SELECT ai_gen(
    'Create a reading list from these articles: ' ||
    (SELECT json_format(CAST(array_agg(title) AS JSON)) FROM similar_docs)
) AS reading_list;

The result is a semantically curated, LLM-summarized reading list built from a single SQL query that spans a vector database and an LLM endpoint. In one run, it surfaced articles on Llama Stack, AI safeguards, Compressed Granite, and AI Agents, all semantically related to the seed article, ranked by embedding similarity, and summarized by the LLM.

Knowledge Graph (example 30) maps the technology landscape around a topic by finding related articles with embedding similarity, then extracting products, technologies, and programming languages from each:

"Accelerate model training on OpenShift AI..."   0.7742  {product=SFTTrainer, language=Python, technology=Trainer}"Accelerated expert-parallel distributed..."     0.6786  {product=granite-4.0, language=Python, technology=FSDP}"Optimizing LLMs for accuracy | RHEL AI..."      0.6617  {product=tokenizer, language=Python, technology=LINUX}

This is hybrid search in its purest form: Vector similarity narrows the search space, AI functions enrich and structure the results, and SQL ties it all together. No external search infrastructure, no separate ML pipeline—just a query.

Federated queries: Joining across data sources

The real power emerges when you join data across catalogs. Trino federates queries across the Iceberg lakehouse on S3 and PostgreSQL in a single statement—something no single database can do alone.

Cross-catalog examples.

#	Example	Data sources	AI functions
32	News-to-Docs: match financial news to KB articles	lakehouse.finance + vectordb	ai_classify + ai_gen
33	Reviews-to-Architecture: hotel complaints as software lessons	lakehouse.reviews + vectordb	ai_classify + ai_gen
34	Federated Intelligence Briefing	lakehouse.finance + vectordb	ai_gen

The Federated Intelligence Briefing (example 34) is the most ambitious. It pulls negative tech news from the S3 lakehouse, finds related Red Hat developer articles from PostgreSQL, and generates a structured intelligence report connecting market risks to technology solutions:

WITH negative_news AS (
    SELECT text FROM lakehouse.finance.financial_news -- Iceberg on S3
    WHERE label = 'negative' AND text LIKE '%technology%'
    LIMIT 5
),
kb_highlights AS (
    SELECT json_extract_scalar(cmetadata, '$.title') AS title
    FROM vectordb.public.langchain_pg_embedding -- PostgreSQL
    WHERE json_extract_scalar(cmetadata, '$.title') LIKE '%OpenShift%'
    LIMIT 5
)
SELECT ai_gen( -- LLM via MaaS
    'Write an intelligence briefing connecting these market risks: ' ||
    (SELECT json_format(..) FROM negative_news) ||
    ' to these technology solutions: ' ||
    (SELECT json_format(..) FROM kb_highlights)
) AS intelligence_briefing;

A single SQL query that reads from S3, reads from PostgreSQL, calls an LLM, and produces an executive-ready intelligence report. Three data sources, one query, zero data movement.

The results are striking. In one run, the briefing automatically connected the SolarWinds supply-chain breach to Red Hat OpenShift Service Mesh as a mitigation strategy, linked Uber's service outages to Quarkus serverless architecture as a resilience pattern, and recommended OpenShift Pipelines for CI/CD hardening in response to Oracle's manual support struggles. The LLM drew these connections entirely on its own. The query just put the right data in front of it by federating across an S3 data lake and a PostgreSQL knowledge base in a single SQL statement.

Get started

The entire stack deploys in under 10 minutes. The source code is in a Git repository.

Start with the install:

export OPENAI_API_KEY=<your-maas-token>
export OPENAI_BASE_URL=https://your-openshift-ai-endpoint
export HF_TOKEN=<your-huggingface-token>
export POSTGRES_HOST=postgres.your-namespace.svc.cluster.local
./install.sh

Then run the example queries:

./examples/run_all.sh

Or open the Trino Query UI in your browser and start writing SQL that "thinks."

References

• Trino AI functions documentation
• Trino 471: When SQL Meets AI and S3 Gets Easier
• Databricks AI Functions
• Snowflake ML Functions
• Apache Iceberg
• Project Nessie
• Red Hat OpenShift AI

The post SQL with GenAI: Building an Apache Iceberg lakehouse on Red Hat OpenShift appeared first on Red Hat Developer.

In a previous post, I explained how to generate the OpenAPI document during the ASP.NET Core build and commit it to the repository. That gives you a versioned API contract that is easy to review in pull requests. In this post, let's go one step further: use that generated OpenAPI file as the input for Kiota, so your typed .NET client is also generated during build. The goal is simple: The server produces…

Travel! It’s one of our favorite things, and here is how to build a flight ticket screen in .NET MAUI.

I dare to say that one of the most loved hobbies, and one of the reasons we want vacations to arrive quickly, is traveling. Guilty as charged, haha.

But personally, beyond the trip itself, I really enjoy being involved in the whole experience—from packing my bags to having my flight ticket in an app. But you know what’s the most fun part? Besides having my ticket in an app, I can also combine my passion for traveling with my profession, by programming and replicating an app that brings these two things together.

For this reason, in this article you will continue strengthening your UI skills in .NET MAUI. Get it out of your head that you can’t build beautiful and creative UIs, because you absolutely can. Today we will replicate a ticket UI inspired by a Dribbble design, which will allow us to practice using several .NET MAUI components such as Shapes, Grid, Label, and especially a super special component: the .NET MAUI Border from Progress Telerik UI. All of this in a very simple way. We’ll break it down step by step!

How will the explanation work?

So you can understand everything 100%, I’ll explain how the process will work:

➖Visual diagram: Before we start, you’ll see a diagram with a screenshot of the design we want to achieve. This design will be divided into blocks, each identified with a name and a color. Each block will be explained individually.

➖Code explanation per block: In addition to the text explanation, each block will include the exact code snippet you need to write to achieve the result.

➖Step-by-step visual progress: Each explanation will have its corresponding screenshot, so you can see the progress as we build the UI.

⚠️ For the purposes of these articles, there will be some changes to the original user interface.

Breaking Down the Dribbble Design into Blocks

To make this easier to follow, I’ve divided the original design into clear blocks. We’ll build each part one at a time, in the order you see below.

1. Main Border Block

Let’s start building the first block. This block is the most important one, since it contains all the elements of the remaining blocks.

To replicate the element in this block, we need a control that allows us to add a background color and apply rounded corners.

We will use the RadBorder control from Progress Telerik. This control makes it easy to manage border color, thickness and even apply different corner radius values for each side. It’s super useful!

To use it, keep the following in mind:

1. If you don’t have a Telerik account yet, you can create one for free. You’ll get access to a trial license so you can explore not only RadBorder, but all the Telerik UI for .NET MAUI controls.

2. You need to install Telerik UI for .NET MAUI. This is a one-time setup, meaning you don’t need to do it for every component you use. (If you don’t have it installed yet, I’ve included an article where it is explained step by step how to set it up in both Visual Studio and Visual Studio Code).

Once you have these two points ready, go to your XAML and follow these steps:

1. Add the following namespace:

xmlns:telerik="clr-namespace:Telerik.Maui.Controls;assembly=Telerik.Maui.Controls"

2. Add a RadBorder to serve as the main container. Configure it with a background color of #29b7fc, a CornerRadius of 30, and apply Padding and Margin to control internal and external spacing, respectively.

<telerik:RadBorder VerticalOptions="Fill" 
    BackgroundColor="#29b7fc" 
    CornerRadius="30" 
    Padding="30" 
    Margin="20"> 
    
<!-- Please add the code for the following block here. -->     

</telerik:RadBorder>

2. Passenger Information Block

This second block contains approximately 95% of the remaining UI design. This is where we will display the ticket details, such as the airline name, origin and destination (from, to), gate and the customer’s name.

We will start by adding a Grid. This will allow us, in the next block, to apply the rounded side cut effect that makes the design resemble a ticket.

⚠️ Note: This Grid must be added exactly on the line in the previous code block that says:

<!-- Please add the code for the following block here. -->

<Grid RowDefinitions="auto,auto" 
    ColumnDefinitions="*,*">" 
    <!-- Add the border here --> 
</Grid>

Now, add a border with a white background. We will continue using the Telerik RadBorder control to maintain design consistency.

    <telerik:RadBorder Grid.Row="0" Grid.Column="0" 
    Grid.ColumnSpan="2" 
    BackgroundColor="White" 
    VerticalOptions="Fill" 
    CornerRadius="30" 
    Padding="30"> 

    <!-- Add the Grid here --> 
    
    </telerik:RadBorder> 
    
    <!-- Add the circles here -->

Inside this RadBorder, we will add another Grid to organize all the ticket information.

This Grid will have three columns and fourteen rows, giving us the structure needed to properly arrange each element in the UI.

<Grid ColumnDefinitions="*,auto,*" 
    RowDefinitions="auto,auto,auto,auto,auto,auto,auto,auto,auto,auto,auto,auto,auto,auto" 
    RowSpacing="20">
 
    <!--Add all the information here -- > 

</Grid>

Finally, let’s add all the passenger information. For the first section, we will use a HorizontalStackLayout, while the remaining structure will be built using Label elements, Line elements and a sample image to represent the barcode.

<HorizontalStackLayout Grid.Column="0" 
    Grid.ColumnSpan="3" Grid.Row="0" 
    Spacing="20" 
    VerticalOptions="Center"> 
    <Image Source="arrowlogo.png" 
    HeightRequest="40" 
    Aspect="AspectFill" 
    WidthRequest="40" /> 
    <Label Text="United Airlines" FontSize="15" FontAttributes="Bold" VerticalTextAlignment="Center"/> 
</HorizontalStackLayout>
 
<Line Grid.Row="1" Stroke="LightGrey" StrokeThickness="0.6" X2="800" HorizontalOptions="Center"/>
 
<Image Grid.Row="2" Grid.Column="1" Source="airplane" HeightRequest="13" WidthRequest="13"/> 

<Label Grid.Row="2" Grid.Column="0" Text="From" FontSize="10" TextColor="Gray"/>

<Label Grid.Row="3" Grid.Column="0" Text="LAX" FontSize="16" FontAttributes="Bold" />

<Label Grid.Row="4" Grid.Column="0" Text="Los Angeles, USA &#10;5:05, Mon 16 Aug&#10;Terminal 1" FontSize="10" TextColor="Gray" />

<Label Grid.Row="2" Grid.Column="2" Text="NYC" HorizontalTextAlignment="End" FontSize="10" TextColor="Gray" />

<Label Grid.Row="3" Grid.Column="2" Text="LAX" HorizontalTextAlignment="End" FontSize="16" FontAttributes="Bold"/>

<Label Grid.Row="4" Grid.Column="2" Text="New York, USA&#10;10:55, Mon. 15 Aug&#10;Terminal 1" HorizontalTextAlignment="End" FontSize="10" TextColor="Gray" />
 
<Line Grid.Row="5" Stroke="LightGrey" StrokeThickness="0.6" X2="800" HorizontalOptions="Center"/> 

<Label Grid.Row="6" Grid.Column="0" Text="Gate" FontSize="10" TextColor="Gray" />

<Label Grid.Row="7" Grid.Column="0" Text="C2" FontSize="15" FontAttributes="Bold"/>
 
<Label Grid.Row="6" Grid.Column="2" Text="Seat Place" FontSize="10" TextColor="Gray"/>

<Label Grid.Row="7" Grid.Column="2" Text="B2" FontSize="15" FontAttributes="Bold" />
 
<Line Grid.Row="8" Stroke="LightGrey" StrokeThickness="0.6" X2="800" HorizontalOptions="Center" />
 
<Label Grid.Row="9" Grid.Column="0" Text="Full Name" FontSize="10" TextColor="Gray" />

<Label Grid.Row="10" Grid.Column="0" Text="Tom Smith" FontSize="15" FontAttributes="Bold"/> 

<Label Grid.Row="9" Grid.Column="2" Text="Class" FontSize="10" TextColor="Gray"/>

<Label Grid.Row="10" Grid.Column="2" Text="Economy" FontSize="15" FontAttributes="Bold" />
 
<Line Grid.Row="11" Stroke="LightGrey" StrokeThickness="0.6" X2="800" HorizontalOptions="Center" /> 

<Label Grid.Row="12" Grid.Column="0" Text="Booking Code" FontSize="15" FontAttributes="Bold"/>

<Label Grid.Row="12" Grid.Column="2" Text="G1540D4" FontSize="15" FontAttributes="Bold" /> 

<Image Grid.Row="13" Grid.Column="0" Grid.ColumnSpan="3" Source="barcodesample" Aspect="Fill"/>

3. Perforated Edges Block

Now, we are adding the finishing touch to this UI: simulating the ticket side cutouts on the white background Border. To achieve this, we will use the Ellipse shape from .NET MAUI.

We will add two Ellipse elements, one on each side, to recreate the visual effect of a ticket.

<Ellipse Grid.Row="0" Grid.Column="0" 
    HeightRequest="60" 
    TranslationX="-130" 
    TranslationY="130" 
    Fill="#29b7fc"/>
 
<Ellipse Grid.Row="0" Grid.Column="1" 
    HeightRequest="60" 
    TranslationX="130" 
    TranslationY="130" 
    Fill="#29b7fc"/>

⚠️ Please note: this code must be placed exactly in one of the sections of the second block where it says: <!-- Add the circles here -->.

Conclusion

And that’s it! In this article, we explored how to build a ticket screen using .NET MAUI with XAML, recreating a modern and visually appealing boarding pass design.

I hope this guide helps you understand how to approach similar UI challenges and inspires you to recreate more complex designs in your own .NET MAUI applications.

If you have any questions or would like me to explore a specific part in more detail, feel free to leave a comment—I’ll be happy to help!

See you in the next article! ‍♀️

If you want to learn more about Ellipse in .NET MAUI, I invite you to read the Microsoft Learn article. It is a very useful element for creating creative UI designs.

Additional Resources

I invite you to learn more about the Telerik RadBorder.

• Here you can explore the main features and benefits of the product.
• Here you can review its technical implementation.
• And, don’t forget: You can try Telerik UI for .NET MAUI free for 30 days.