Steeltoe provides a collection of libraries that helps users build production-grade cloud-native applications using externalized configuration, service discovery, distributed tracing, application management, and more. It is proven—trusted by developers all over the world, delivering delightful experiences to millions of end-users every day, with contributions from VMware, Microsoft, and more.

Steeltoe is flexible, offering comprehensive extensions and third-party libraries that let developers build almost any web application imaginable, whether cloud-scale microservices or heavyweight enterprise applications. It is productive, building on .NET runtime libraries, providing the necessary glue code, and supporting many of Spring Cloud’s libraries, patterns, and templates.

Steeltoe is fast, with developer productivity as one of its superpowers—developers can start a new project in seconds with the Steeltoe Initializr at start.steeltoe.io. It is secure, remediating security issues quickly and responsibly, monitoring dependencies, and providing industry-standard security integrations.

Finally, Steeltoe is supportive, backed by a global, diverse community that offers guides, tutorials, videos, support, and access to the development team on Slack.

What Steeltoe Can Do

• Microservices: Production-grade features with independently evolvable services.

• Cloud: Your code, any cloud—connect and scale your services.

• Web Apps: Fast, secure, responsive applications connected to any data store.

Link: https://steeltoe.io/

Tomas Herceg lives in Prague, Czech Republic, and runs a software consulting company called RIGANTI.

He has been doing .NET development since the time of .NET Framework 1.0. He got his first Microsoft MVP award in 2009, and for a couple of years, he was also a Microsoft Regional Director. He is also running Update Conference, a company that organizes developer events focused on .NET, cloud, and security. Many people might also know him because of his recent book about modernizing .NET web applications.

Tomas’s open-source journey started in 2014 when he had the idea of creating a framework that lets you build web apps with just C# and HTML. He made a simple prototype, published it on GitHub, and demoed it in one of his conference sessions. Surprisingly, the next day someone submitted a pull request. He contacted that person, and they decided to continue working on the idea and see what happens.

That is how the DotVVM project started. Tomas and his team have been contributing to it for more than 10 years, adding hundreds of features, tests, and documentation pages. Over the years, more people have been helping with the development. They use the framework intensively at RIGANTI and are committed to its long-term sustainability. Therefore, they built a bunch of commercial extensions and components for DotVVM, which helps them secure funding for future improvements to the open-source framework.

DotVVM is an opinionated framework that enables building web apps using the Model-View-ViewModel (MVVM) approach with just C# and HTML. It requires only about 56kB of JavaScript on the client, and it can be used to build feature-rich UI interfaces. The framework supports both ASP.NET Core and classic ASP.NET, providing an easy way to incrementally modernize ASP.NET Web Forms applications. DotVVM comes with 30+ built-in components, and there is also an extension for Visual Studio and Visual Studio Code.

Links:
https://github.com/riganti/dotvvm
https://tomasherceg.com
https://modernizationbook.com

Python is ubiquitous. Millions of professionals, from scientists to software developers, rely on it. Organizations like Google and Meta have built critical infrastructure using it. Python even helped NASA explore Mars, thanks to its image processing abilities.

And its growth isn’t slowing anytime soon.

In 2024, Python surpassed JavaScript as the most popular language on GitHub, and today, it has become the backbone of modern AI systems. Python’s versatility and passionate community have made it what it is today. However, as more enterprises rely on Python for everything from web services to AI models, there are unique needs that enterprises must address around visibility, performance, governance and security to ensure business continuity, fast time to market and true differentiation.

How Python Became the Universal AI Language

Most popular languages have benefited from corporate sponsorship. Oracle supports Java. Microsoft backs C#. And Apple champions Swift. But Python has almost always been a community project, supported by several companies, and has been developed and improved over decades by a committed group of mainly volunteers, directed by Guido van Rossum as Benevolent Dictator for Life until 2018.

In the 1980s, van Rossum sought to create a language that was both simple and beautiful. Since the early ’90s, as an open source project, Python was available for anyone to inspect, modify or improve.

The Zen of Python, by Tim Peters, image originally posted by Pycon India on X.

Python quickly differentiated itself from its peers. It was easy to learn, write and understand. Developers could easily tell what was happening in their and others’ code just by looking at it, an anomaly in the days of Perl, C++ and complex shell scripts. This low barrier to entry made it highly approachable to new users.

Then there was Python’s extensibility, meaning it could easily integrate with other languages and systems. With the rise of the internet in the early 2000s, this extensibility took Python from a scripting solution to a production language for web servers, services and applications.

In the 2010s, Python became the de facto language for numerical computing and data science. Today, the world’s leading AI and machine learning (ML) packages, such as PyTorch, TensorFlow, scikit-learn, SciPy, Pandas and more, are Python-based. Still, the high-performance data and AI algorithms they use rely on highly optimized code written in compiled languages like C or C++. It is Python’s ability to easily integrate with these and other languages that has been critical in its ability to provide the best of both worlds: an easy interface to these packages for the millions of users who want to use them, but flexible interfaces for the experts that can optimize them in the language of their choice. These factors have made Python indispensable for both data science and AI workflows.

Today, if you’re working with any kind of AI or ML application, you’re likely using Python. However, as Python has become both the glue and the engine powering modern AI systems, enterprises need to be aware of critical needs specific to corporations around compliance, security and performance, and the community must strive to address them.

Helping Python Meet Enterprise Needs

Longtime Python core contributor Brett Cannon famously said, “I came for the language, but I stayed for the community.”

The community has made Python the incredible language it is today, serving users above all else. However, the community’s mission has always been to build a language that works for everyone, from programmers to scientists to data engineers. This has proven to be the right approach. This also means Python wasn’t engineered for the specific needs of enterprises running their business with Python.

And that’s OK, as long as those needs are addressed.

Anaconda’s “2025 State of Data Science and AI Report” found that enterprises face many of the same recurring challenges as they move data and AI applications to production. Over 57% reported that it takes more than a month to move AI projects from development to production. To demonstrate ROI, respondents were mostly interested in business concerns, such as:

• Productivity Improvements (58%)
• Cost Savings (48%)
• Revenue Impact (46%)
• Customer Experience / Loyalty (45%)

Think about it like cloud computing fifteen years ago. Organizations could immediately see the massive cost and operational advantages of moving workloads to the cloud. However, they realized that the security, compliance and cost model had changed entirely. They needed to continuously monitor, govern and optimize this new tool in altogether new ways. Python has reached that same point for enterprises.

I’ve spoken with dozens of leaders at organizations using Python, and here are the common challenges and themes I see.

Security

While 82% of organizations validate open source Python packages for security, nearly 40% of respondents still frequently encounter security vulnerabilities in their projects. These security issues create deployment delays for over two-thirds of organizations.

One of the strengths of Python, and all open source software, is that they’re free to download and use. You get the latest and greatest technology, and you can experiment, develop and push applications to production without paying a dime on the software.

However, history has shown that this openness and collaborative community can be abused by bad actors or even allow simple mistakes to proliferate, leading to the spread of vulnerable and malicious software. A piece of software or a package that looks fine could actually be dangerous. That problem is now compounding, with AI systems now generating and executing Python code without a human in the loop. Enterprises must protect their people, systems and data, and in turn, ensure safe AI deployment without missing deadlines.

Performance Optimization

Though Python is straightforward to use, it can also be prolonged, which is fine for many use cases. But as we saw in the “State of Data Science and AI Report,” the modern enterprise’s primary concern is to do more with less — continually improve and increase efficiency, productivity improvements, cost savings, increase revenue, etc. The economics of producing AI applications is only exacerbating performance and efficiency concerns.

With limited time, expertise or tools, most enterprises struggle to fine-tune the Python runtime, leading to far more compute than needed and higher costs, or to running AI systems that aren’t performant enough to provide a usable experience.

Auditability

Every CIO and CISO I know is staring down a wave of regulations, from the EU AI Act to internal SOC 2 and ISO 27001 compliance audits. Enterprises must be able to prove what code is running, where it’s running and how it’s interacting with sensitive data and systems.

Free and open source software makes that challenging because when anyone can download and run software freely, everyone will. New Python applications are popping up outside of IT control, packages are constantly updating, unknown or new dependencies are pulled in and there’s limited runtime visibility. Especially for organizations in highly regulated industries, this lack of runtime visibility creates present and future risk.

Managing Deployments

According to a recent survey of Anaconda’s users, over 80% of practitioners spend more than 10% of their AI development time troubleshooting dependency conflicts or security issues. Over 40% spend greater than a quarter of their time on these tasks, and time is money.

Once applications are in production, continuous maintenance, upgrades and security hardening can compound those issues. For an individual running and maintaining a small number of scripts and applications, this is not so hard. Still, for a large enterprise managing thousands of production applications, this becomes a considerable challenge.

Enterprises need a way to easily adopt new versions of Python and new technologies, while also minimizing version sprawl, security exposure and management overhead.

How To Help Enterprise AI Meet the Needs of Modern Enterprises

The good news is you can start addressing many of these challenges today. It all comes down to being intentional about your governance strategy.

More than half of organizations today have no or very limited open source and AI governance policies or frameworks in place. Creating an official policy around governance and investing in visibility and auditability already puts you ahead of most enterprises.

When building your governance strategy, start by building internal processes that track Python usage across teams and systems. Ensure you know what packages are running, where, and under what configurations.

Next, you’ll want to ensure you’re managing Shadow IT/AI and reviewing any and all AI-generated code. Agentic tools can’t replace a solid software development life cycle (SDLC) process. Ensure you have the right visibility, standards and processes in place to prevent unverified scripts from entering production.

It’s also critical to invest in workforce upskilling, increasing AI literacy among your employees so they better understand the risks of open source and AI solutions and why governance is so important. Some of the best education is in using these tools directly and gaining experience.

Finally, give your teams safe, reliable solutions across AI and data science workflows so that doing the right thing becomes the path of least resistance.

Make Python Your Competitive Edge

Python’s openness is its greatest strength and its most significant challenge. While it’s democratized AI development, it’s also created new risk vectors and blind spots that enterprises must address. IT teams need the same visibility and governance for open source solutions as they would for any other part of their tech stack. Time has shown that this is a primary source of innovation in the enterprise, so the investment in securing that innovation is worth it. And while specific upgrades to the language itself can help, intentional governance can make a difference today.

At Anaconda, we’ve seen enterprises tackle these challenges by building strong SDLC, governance, and observability layers around their Python environments. It adds a little more work upfront, but it’s a critical shift that will protect your organization in the long run and ensure the success and longevity of your AI initiatives.

The post Python Is Quickly Evolving To Meet Modern Enterprise AI Needs appeared first on The New Stack.

A recent Theory Ventures survey found that 91% out of 413 senior technical builders surveyed are either directly building AI, or managing teams that build AI. That said, only 17% are building MCP servers. This contrasts with the 46% that are using direct tool calling, including via APIs and A2A, to access data.

The survey found the most common use case for agent tools is accessing databases, with 72% of respondents using AI agents to do this.

Nearly everyone (98%) is evaluating the quality of their AI, usually using a combination of automated and manual methods, the survey found. Overall, 27% are using LLMs to judge the quality of their AI’s output and 63% are using synthetic data to evaluate their AI’s output.

46% of builders are using direct tool calling to access data, including via APIs and A2A.

Respondents were almost three times as likely to use AI evaluations to assess the quality of their AI products as compared to those using telemetry.

When it comes to LLM observability, 57% are storing interaction with their AI system as traces in a product designed for LLM observability. However, 57% say they also use spreadsheets to review the data they are collecting.

Perhaps that is why 21% said data review of interactions are the area of tooling they most believe will add value for their projects.

When it comes to context engineering, 47% are using a prompt optimization method like GEPA and Prompt Evolution. Fifty-two percent are managing prompts as code that can be checked into their code repository and handled like other code reviews. That’s in contrast to the 41% who are updating prompts with text files that people from different teams are collaborating on.

Another 41% said they are iterating on prompts outside of the code, according to the survey.

Shipaton Mobile Hack-A-Thon Won With Vibe-Coded App

Shipaton is a mobile app hackathon hosted annually by RevenueCat, a platform that powers in-app purchases for apps. This year it showed that vibe coding is truly catching on.

Only 1,700 individuals participated last year, but this year the event attracted 54,000 participants. RevenueCat said the increase reflects how vibe coding is redefining — and expanding — who is an app developer.

“Vibecoders played a prominent role in the competition, with the Grand Prize going to Payout, an app completely produced through AI-assisted development using Claude Code and Cursor,” the company said in a prepared statement. Payout enables people to find class action lawsuits for which they qualify.

“AI tools are lowering the barrier to build and ship apps, but the fundamentals haven’t changed,” said Jacob Eiting, CEO of RevenueCat. “You still need to build something people love, use, and pay for — and that’s exactly what this year’s Shipaton winners did.”

Shipaton awards were granted by category and included:

• Best Vibes: Vibe coding platforms and tools are increasingly being used in app development. The winner, OtterDay, used Perplexity Pro for dialogue and visuals, KlingAI for otter animations, and ElevenLabs for voiceovers.
• Design: Visuals are key for engagement and the winners of this category specialize in aesthetic quality. DayLoop, an app that turns everyday moments into cinematic time-lapse videos, won for its precision, privacy and delight.
• Buzziest Launch: Whether or not an app makes a splash on day one can make or break its long-term success. ReadHim, geared toward decoding men’s texts, won first place in this category for an Instagram meme account that amassed over 5.2 million views, partnering with a TikTok influencer with over 2.3M followers, and executing a creative stunt complete with supercars and a robot dog.
• Apps That Make Money: Vibe coding makes launching apps easier than ever, but sustainable monetization still sets the best apart. VectorGuard was awarded for their top-tier app monetization strategy. With thoughtful design and fair monetization, they turn public data into public good.

Shipaton celebrates the freshly built projects, new launches and prototypes that are bringing unique products to users. RevenueCat also awards six Shippies to apps that have gone to the next level, not just launching but nailing every part of the subscription journey, from onboarding and monetization to retention and creativity. The 2025 Shippies awards went to Hank Green’s Focus Friend, Ladder, Resubs, Recime, Wink and WeWard.

Warp CLI Tool Expands AI Agent Capabilities

Warp is a modern, high-performance command-line terminal application designed for macOS, Linux, and Windows. This month, Warp expanded its AI agent capabilities with the launch of Agents 3.0.

The company’s goal with this release is to offer reliable, collaborative and fully autonomous development workflows within the terminal environment.

Among the new features is the Full Terminal Use, which allows the agent to interact with live processes and full-screen terminal apps like debuggers, which solves a major bottleneck for real-world development tasks.

The update also introduces structured, versioned development blueprints and Interactive Code Review for human oversight directly in the terminal.

The post Most Developers Call AI Data With APIs and A2A appeared first on The New Stack.

Latest build and GitHub!

After I pushed out my first version of Prompt Droid (nee Prompt Drawer) a couple of weeks ago, I had a couple of realizations:

1. Someone already published an extension named “Prompt Drawer” that did something similar to mine (though I like the way mine works better), so I needed a new name.
   • EVERYTHING related to the word “prompt” is used already: the ones you’d expect, like Prompty or PromptBox and even more esoteric ones like El Prompto. Prompt Droid was not, however, so one find-and-replace in my code later and here we are.
2. It was really bothering me that the extension wouldn’t work on Copilot. I did a lot of digging and learned that I’d built the extension in the entirely wrong way, that I needed to implement it as a popup instead of having it embedded in the page itself (which some sites, including Copilot, forcibly block).
3. It took a village of AI tools to help get it where I wanted it. I used Claude as my main toolset, Gemini 3 to help with some code iteration, and Copilot was actually able to tell me why it wasn’t working on… Copilot. Physician, know thyself.

So here we are, Prompt Droid has been rewritten and fixed up so that it now works anywhere. As always, please let me know if you find any bugs.

Last month, I wrote up a blog post discussing a three-phase cycle (profile, analyze, improve) for leveraging LLMs and other AI tooling to evaluate Apache Flink jobs for potential performance improvements. This post goes through what that process might look like in a more automated fashion to help you track down those often squirrly issues hidden within your Apache Flink jobs that could be holding your pipeline back.

Introducing Squirrly

In a simple proof-of-concept, which I'm calling Squirrly, I walk through this process which automates the process by running a profiler instance against a job deployed in Kubernetes, capturing the appropriate profiler artifacts and providing those to an external LLM for analysis.

The overall concept is fairly simple – Squirrly will run within your Kubernetes cluster either as an an ad-hoc, one-off job (or potentially as an automated cron job that would periodically issue the analysis requests).

What's Squirrly Doing?

As mentioned in the beginning of this article I mentioned a three-phase cycle that I've used in the past to analyze Apache Flink jobs by feeding profiler results and potential code context into an LLM for analysis. This process was always done as a manually process – this is just taking that same concept and taking more of the legwork out of it.

In this concept, you'd just point Squirrly to an existing Flink job that's running an it will do the following:

• Issue a specific type of profiling request via the built-in Apache Flink Profiler via its exposed REST API endpoint (you can configure the duration and type of profile used)
  • This assumes that the job has profiling enabled via the rest.profiling.enabled configuration.
• After the profiler has completed, the service will gather the generated artifact and prepare a request to a given LLM for analysis. The request itself will include the following:
  • The generated HTML-based flame graph that was gathered during the previous profiling run.
  • A user-defined Markdown prompt to help frame the context to the LLM (completely configurable and baked in by default).
  • An optional series of one or more artifacts that can be provided to the LLM to define context and create associations between the code that was executed.
• Once this analysis process is completed, it will log out the recommendations provided that you can begin to take action on.

Let's See It in Action

We can easily demonstrate this by creating a sample, intentionally poor performing Apache Flink job and running it within a local environment (via minikube, etc.)

With that job running, we can configure Squirrly to point to that job and issue a request to the REST API to trigger a profiler run:

./scripts/run-profiler.sh

And what we'll find is that it successfully captures the generated artifact and then issues a submission to the configured service (in this case it uses the OpenAI API):

🔬 Squirrly Profiler
==================================
Target FlinkDeployment: sample-job

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 Processing FlinkDeployment: sample-job
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ JobManager Pod: sample-job-548bffcd7-b2vb6
🔍 Fetching job information...
✅ Found running job: 49a1dfd3890613125656bf07dd2c52ed
🔍 Fetching job details to find vertices...
✅ Vertex ID: bc764cd8ddf7a0cff126f51c16239658

🔬 Triggering Flink Profiler...
   ✅ Profiler triggered successfully
   ⏳ Waiting 60 seconds for profiler to complete...
   📦 Checking for profiler artifacts on TaskManager pods...
   ✅ Found profiler artifact!
   🎯 Artifact for this run:
      ...
   ✅ Profiler completed successfully! Artifacts generated.

   📤 Submitting artifact for analysis...
   📊 Artifact size: 28404 bytes
   ✅ Artifact copied successfully (28404 bytes verified)
   🔨 Building JSON payload...
   ✅ JSON payload verified (30897 bytes, contains artifact marker)
   📡 Sending request to OpenAI API...
   HTTP Status Code: 200
   ✅ Analysis request submitted successfully

After analysis is completed, we'll see the recommendations defined in the log, although you could potentially change things around and write this to cloud storage, email, etc:

Analyzing flame graphs is a detailed task that requires careful examination
of the profiling data. Here's an analysis of the provided Apache Flink job's
performance based on the flame graph content you shared:

Key Bottlenecks (Ranked)
------------------------

Bottleneck 1: User Function - EvenStallingFunction.map()
- Where it is:
  dev/squirrly/SimpleFlinkJob$EvenStallingFunction.map
- How large it appears:
  Approximately 2% of the total samples.
- Why it matters:
  This UDF plays a significant role in your Flink job and shows
  noticeable CPU impact. It may contain expensive operations or waiting
  behavior that affects throughput.

Bottleneck 2: Thread Sleep
- Where it is: java/lang/Thread.sleep
- How large it appears:
  Appears multiple times, each contributing roughly 2–3% of samples.
- Why it matters:
  Frequent use of Thread.sleep may indicate inefficient waiting or
  deliberate delays, both of which reduce processing speed.

Bottleneck 3: Record Writer Flush
- Where it is:
  org/apache/flink/runtime/io/network/api/writer/
  RecordWriter$OutputFlusher.run
- How large it appears:
  Roughly 11% of the samples.
- Why it matters:
  Frequent flushing introduces latency and reduces throughput, especially
  if buffer management is not tuned for the workload.

2. Root Causes
--------------

Bottleneck 1: Inefficient UDF Logic
- Cause:
  EvenStallingFunction.map may include unnecessary computation or complex
  transformations that slow down processing.

Bottleneck 2: Inefficient Waiting Strategy
- Cause:
  Thread.sleep may be creating artificial delays caused by misconfigured
  timeouts or inefficient backpressure handling.

Bottleneck 3: Frequent Flushing
- Cause:
  RecordWriter may be flushing too aggressively or using suboptimal
  configuration, resulting in excessive I/O activity.

3. Actionable Recommendations (Ranked)
--------------------------------------

Recommendation 1: Optimize User Function Logic
- Proposed change:
  Refactor EvenStallingFunction.map to reduce computational overhead and
  eliminate redundant operations.
- Why it helps:
  Reducing CPU usage within the UDF directly improves throughput and
  lowers resource consumption.
- Impact estimate: High
- Trade-offs:
  Ensure that functional correctness is preserved during refactoring.

Recommendation 2: Review Sleep Calls
- Proposed change:
  Reduce or eliminate Thread.sleep. Prefer Flink backpressure and timeout
  mechanisms instead of manual sleeping.
- Why it helps:
  Removing intentional delays results in faster, more responsive job
  behavior and higher throughput.
- Impact estimate: Medium
- Trade-offs:
  Timing and synchronization logic must be handled carefully.

Recommendation 3: Adjust Buffer Flushing Configuration
- Proposed change:
  Tune buffer sizes or flush intervals to reduce how frequently data is
  flushed.
- Why it helps:
  Less frequent flushing lowers I/O overhead and can significantly improve
  throughput.
- Impact estimate: Medium
- Trade-offs:
  Larger buffers may increase memory usage, so monitor accordingly.

4. Additional Observations
--------------------------

- Mailbox Processing:
  MailboxProcessor activity is visible and may become a bottleneck under
  higher message rates. Monitor as the workload scales.

- GC Pressure:
  Be mindful of unnecessary object creation in UDFs or operators, as this
  can increase GC activity and slow processing during heavy load.

This analysis provides a solid baseline for optimizing the Flink job based
on the profiling data. Further iteration and measurement will help refine
performance improvements.

It obviously goes without saying but...

Give It a Whirl

As mentioned earlier in the post – this is really just a proof-of-concept, but I've created a sample GitHub project that show it in action. It leverages Kubernetes, Docker, a sample Flink job, and a series of scripts to demonstrate the process.

If you have the prerequisites installed (e.g., Java 21, minikube, Docker, Maven, Helm, etc.), you should be able to just go through the following steps:

# Clone down the repo
git clone http://github.com/rionmonster/squirrly.git
cd squirrly

# Deploy everything
./scripts/deploy.sh

# Run the profiler (see README for all available options)
./scripts/run-profiler.sh

Since this example uses the OpenAI API, you must have a OPENAI_API_KEY environmental variable set for all of the pieces of this puzzle to work. (e.g., export OPENAI_API_KEY="secret-secret').

Things simply won't work (on the analysis front) if you can't communicate with your preferred AI provider.

What's Next?

Who knows really? This was really just playing around with automating a process to streamline analysis for existing Flink jobs that are running in Kubernetes. The entire codebase is openly available on GitHub, so if you have a specific use-case, want to extend it for your own purposes, or just play around – fire away!

A few improvements that immediately come to mind would be:

• Continuous Evaluation / Cronjob - Extend the ad-hoc profiler to an ad-hoc service or CronJob that would periodically run these types of operations automatically (without user intervention at all).
• Additional AI Provider Support - Add support for additional openly available LLMs and their respective APIs for analysis besides just OpenAI.
• Metrics & Code Context - Potentially incorporating ways to extend the prompt with real-time values (e.g., inject specific currently available metric values into the prompts to assist with context, actual source files/source maps to extend context).