devopsy.kinsta.cloud

Category: Features

Gearset Extends Reach of DevOps Platform for Salesforce Applications

Gearset has extended the scope of the observability of Salesforce applications it provides to include software developed using low-code Flex and object-oriented Apex programming tools.

Busayo Longe, a product manager for Gearset, said Flow is gaining more traction as a tool that is more widely employed to build Salesforce applications, while more complex applications are typically built using Apex.

Gearset, a provider of a DevOps platform for Salesforce applications, is now able to surface and analyze Flow and Apex errors in real time.

Unlike other applications where issues are surfaced using alerts generated via agents embedded in an application, the Salesforce platform generates automated error emails whenever there is a failure. It’s then up to the IT team managing these applications to investigate the root cause.

As a result, IT teams can find themselves being inundated with a high volume of hard-to-interpret messages that lack context about what went wrong, who was affected, or how urgent the issue is.

In addition to providing that context, Gearset errors can be filtered by type and further investigated using a set of visualization tools provided.

IT teams can also configure the automated error emails generated by the Salesforce platform to be automatically routed to Slack or Microsoft Teams messaging platforms if they prefer.

Finally, the alerts generated by Salesforce can also be customized to enable IT teams to only be notified when an issue exceeds a specific threshold.

In general, the need for observability will become much more pronounced as more organizations build and deploy artificial intelligence (AI) agents on the platform. As the interactions between AI agents increase, the chances that there will be issues that IT teams will need to investigate will only continue to increase, noted Longe.

The challenge is that a recent Gearset survey finds 69% of the IT teams managing Salesforce applications don’t have access to an observability platform. According to Gearset, IT teams that have access to an observability platform are 50% more likely to catch bugs within a day and 48% more likely to fix them within a day, compared to teams without these tools. On the plus side, 81% of respondents said they have adopted a continuous integration/continuous deployment (CI/CD) platform. In fact, Gearset claims it added 800 new customers in 2024, bringing its total customer count to 2,900 organizations.

It’s not clear who is building the bulk of the applications deployed on the Salesforce platform. While there are a large number of so-called citizen developers building applications using low-code tools, many enterprises also rely on professional developers to build these applications. As a result, the quality of the applications deployed on a Salesforce platform can vary widely. The one certain thing is that the pace at which organizations are building custom applications that are deployed on the Salesforce platform only continues to accelerate.

The challenge that arises is that the Salesforce platform is based on a proprietary, unique mix of programming languages, formats and metadata that require a separate set of DevOps tools and platforms to manage application development and deployment.

Regardless of who or how Salesforce applications are developed, the one certain thing is that it will eventually fall to a DevOps team to troubleshoot them whenever an issue arises.

June 13, 2025
JFrog Extends Alliance With NVIDIA to Secure AI Software Supply Chain

JFrog and NVIDIA today announced they have expanded the integrations between their software development platforms to now include the Enterprise AI Factory, a set of frameworks and blueprints for building artificial intelligence (AI) applications.

As a result, software artifacts created using the NVIDIA Enterprise AI Factory can be housed in the JFrog Software Supply Chain Platform. The JFrog ML platform, meanwhile, provides a registry for managing the lifecycle for building and deploying AI models by enabling versioning, provenance tracking, model promotion, and enforcement of security policies.

Additionally, JFrog metadata and promotion workflows ensure immutable AI artifacts can only move between stages when all quality, security, and legal checks have passed. AI models can also be cached, continuously monitored and updated to align with regulations. Critical patches and AI model updates can also be centrally managed similarly.

Finally, the JFrog ML platform also enables application development teams to enforce role-based access control (RBAC) to ensure that access to AI artifacts is traceable for compliance purposes.

Collectively, those capabilities ensure all AI software is signed, validated and approved before deployment.

Kristian Taernhed, senior technical alliance manager at JFrog, said the overall goal is to provide a repository that can be deployed in an on-premises IT environment to provide DevSecOps teams with a platform to manage all their software artifacts, including AI agents and models. That capability, for example, enables organizations to leverage scanning tools to prevent malicious AI models from being inadvertently incorporated into an application, he added.

Locking down the software supply chain used for building AI applications is crucial not just for organizations concerned about highly regulated industries but also in countries that have developed policies pertaining to how AI applications are developed, also known as Sovereign AI, he added.

Specifically, Sovereign AI mandates typically require AI data to remain within specified geographic or organizational boundaries and for strict controls across the AI software supply chain to be enforced.

It’s not clear to what degree machine learning operations (MLOps) workflows used to build AI models are being integrated into DevOps workflows, but for all software engineering purposes, those models are simply just another type of artifact that needs to be integrated into a build. Going forward, just about every application being built is going to have some AI capability, so the number of AI models that will need to be incorporated into a DevOps workflow is only going to continue to increase.

The bigger challenge may be melding the cultures of the data science teams that typically build AI models with the DevOps and platform engineering teams responsible for building and deploying software.

In the meantime, there will be no shortage of platforms for building AI models that will need to be integrated into DevSecOps workflows. Some organizations may be able to standardize on a few, but given the pace of innovation, the number of platforms being used to build AI models continues to increase. Most data science teams, much like their DevOps counterparts, prefer to retain control over the tools and platforms used to build those AI models, so enforcing a platform standard across every data science team is in the short term likely to be a challenge.

The good news, of course, is that with each integration, the level of expertise attained should, hopefully, make the next project that much easier.

June 11, 2025
Datadog Adds Raft of Additional AI Agents and Tools to Portfolio

Datadog at its DASH 2025 conference today previewed a raft of artificial intelligence (AI) agents that automate tasks ranging from assessing infrastructure alerts that normally require the expertise of a site reliability engineer (SRE), to fixing code and triaging cybersecurity issues using the company’s security information event management (SIEM) platform.

In addition, Datadog is also adding Proactive App Recommendations that analyze telemetry data to suggest the next best action and APM Investigator to identify and trouble shoot bottlenecks impacting application performance.

At the same time, Datadog is adding data observability tools, along with extensions to its service for monitoring large language models (LLMs), to add support for AI agents and previews of tools to test and validate the impact of prompt changes, model swaps or application changes on the performance of LLM applications. The company has also added an AI Agents Console to make it simpler to discover and invoke its AI agents. Datadog LLM Observability, now generally available, monitors the integrity of AI models and performs toxicity checks that look for harmful behavior across prompts and responses, while Datadog Workload Protection monitors interactions between LLMs and their host platforms. A Datadog Cloud Security and Sensitive Data Scanner (SDS) also enables organizations to meet compliance requirements.

Datadog is also making generally available Datadog Code Security, a service that leverages AI to detect, prioritize and remediate vulnerabilities in their custom code and open-source libraries based on runtime threat activity and business impact. It has also extended the capabilities of its log management suite to run in an on-premises IT environment—meeting data sovereignty requirements in regulated industries—and to help reduce costs with a lower-cost archive tier of storage.

Finally, Datadog has added a managed internal developer portal (IDP) that is integrated with the company’s core application performance monitoring platform. It provides a live system of record for telemetry data to surface what software is running, who is responsible for it, and how it is performing. There are also templates powered by Datadog’s App Builder and Workflow Automation to automate tasks such as creating the scaffolding for a new service along with engineering reports and scorecards to track compliance, reliability, security, observability, cost and other metrics.

In general, Datadog is making use of a range of proprietary and open source LLMs, including one optimized for time-series data that it has developed. Over time, Datadog plans to mix and match LLMs to address specific use cases as additional AI advances are made.

Michael Whetten, vice president of product for Datadog, said, for example, the latest Bits AI SRE, Bits AI Dev Agent and Bits AI Security Analyst agents not only extend the range of tasks being automated, but also enables them to query data, analyze anomalies or scale infrastructure using shared memory in a way makes it possible for AI agents to reuse functions. Datadog has also developed a Model Context Protocol (MCP) server to make it simpler for AI agents to consume its data and interoperate with each other. The overall goal is to not, for example, replace SREs, but rather augment their expertise in a way that makes it easier to manage complex IT environments, he added.

It’s still early days so far as adoption of AI technologies across DevOps workflows is concerned, but a recent Futurum Research survey finds 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code. In fact, arguably the challenge now is not so much deciding whether to use AI as much as it is determining where AI will have the biggest impact on improving both software quality and the speed at which applications are deployed.

June 10, 2025
Zencoder Adds AI Agent to Test Code to Portfolio

Zencoder today made available a public beta of an artificial intelligence (AI) agent that extends its platform for writing code into the realm of application testing.

Company CEO Andrew Filev said Zentester in addition to making it simple for application developers to test their own code, will augment DevOps teams by making it possible to validate software works as intended faster.

Zentester sees and interacts with applications in the same ways as an end user who clicks on buttons, fills out forms to validate the state of a user interface and backend responses without having to rely on any scripting framework.

In the same way that Zencoder is integrating its portfolio of AI agents with software engineering workflows, ZenTester can be embedded into an integrated development environment (IDE) or embedded within a DevOps workflow using a command line interface (CLI) tool provided.

The overall goal is to speed the pace of testing in an era where most organizations don’t have the resources to test every update and component, said Filev.

In addition, test results are provided nearly instantaneously, versus requiring developers today to wait days for feedback from application testers, which means they usually have lost some of the context they had when they originally wrote the code being tested. ZenTester is designed to surface issues in minutes.

Finally, integration with AI coding tools will also make it easier for any AI agent that writes code to improve as it learns from Zentester.

Zencoder already makes available a platform for building customizable agents using a mix of open-source and proprietary large language models (LLMs) that can be shared via an open-source marketplace. At the core of those AI agents is a platform capable of analyzing interdependencies, generating documentation and suggesting improvements across service boundaries that Zencoder is now using to build agents trained to automate software engineering tasks.

The company also plans to expand the capabilities of these agents to interoperate with one another using the Model Context Protocol (MCP) developed by Anthropic, in addition to providing analytics and additional administration tools.

Longer term, Zencoder is working toward adding more advanced reasoning capabilities for its AI agents, including providing different classes of AI agents that can be invoked based on the level of complexity of the task, said Filev.

It’s not clear how many organizations are relying on AI to help build applications faster. Most enterprise IT organizations have yet to integrate AI tooling into their software engineering workflows. However, a recent Futurum Research survey finds 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code, while 39% plan to make use of AI models based on machine learning algorithms.

Eventually, the pace at which code is being created using AI tools will overwhelm existing DevOps pipelines and workflows, so the need for AI agents to automate more tasks is becoming self-evident. In fact, there is already no shortage of AI tools and platforms for writing and testing code. Unfortunately, many organizations still lack a cohesive strategy, so many individual developers are naturally experimenting with different tools and approaches on their own. The challenge now is deciding which one of these tools and platforms best suits the needs of any DevOps team trying to determine how best to operationalize these tools at scale.

June 10, 2025
Scaling Vibe-Coding in Enterprise IT: A CTO’s Guide to Navigating Architectural Complexity, Product Management and Governance
Enterprise IT organizations increasingly explore innovative approaches such as vibe-coding, a practice that leverages AI-driven tools and large language models (LLMs) to prototype and develop software with minimal traditional coding rapidly. Vibe-coding prioritizes functionality, user experience and iteration speed over strict adherence to conventional software engineering methodologies.

The timing is no coincidence. The surge in accessible, high-performance LLMs, alongside AI code assistants like GitHub Copilot and integrated APIs from OpenAI and Google, has lowered the barrier to entry for building intelligent applications. What once required full-stack developers can now be initiated by analysts, architects and subject matter experts.

While vibe-coding initially promises accelerated innovation and simplified development, scaling it across broader, less technical audiences introduces significant complexity, governance risks and operational challenges. Using the evolution of the CTO Signal Scanner application as a detailed case study, this report helps CTOs understand the intricate balance required to scale vibe-coding effectively and sustainably.

Initial Exploration: Prototyping With Intent

We didn’t start by chasing a product. We began by exploring a possibility. The goal was simple: Could an AI-enhanced CLI tool help an enterprise IT analyst track vendor signals more effectively?

That first version was exactly what it needed to be: A lightweight proof of concept written in Python with OpenAI integration. A fast way to test value. The command-line interface was the fastest path to signal, and it confirmed what we suspected: Generative AI could add immediate value in surfacing insights from routine vendor updates.

This wasn’t naive code-gen play. It was deliberate prototyping, vibe-coding in its best form: Small, sharp and curiosity-led.

Scaling Delivery: From CLI to Web Interface

Once the initial PoC proved valuable, we needed to expose it to a broader audience. The obvious next step was a web interface. Since we began in Python, extending it with Flask seemed logical, it let us stay close to the original codebase.

But this is where architectural momentum can become architectural friction.

In hindsight, this was the point where a more production-minded architectural lens could have shifted the trajectory: Python + Flask may feel familiar, but modern frontend gravity has clearly consolidated around React and TypeScript. The developer ecosystem, the agentic tooling and even model pre-training patterns align more naturally with the React + Firebase + TypeScript world.

That choice matters because the deeper your AI-assisted dev stack aligns with prevailing patterns, the more you can leverage the weight of pre-trained behavior.

Two Paths of Vibe-Coding: The Architect vs. the Enthusiast

This highlighted something important: Not all vibe-coding is created equal.

There’s the path of the expert system architect or senior SWE, using AI tools as force multipliers, prompting multiple agents, testing architectural forks and evaluating tradeoffs at speed. That’s a fundamentally different mode than a former developer or business analyst casually asking for features via a prompt and shipping the result unchecked.

Both of these approaches wear the same label, vibe-coding, but the workflows, risks and output quality are worlds apart.

It’s time we acknowledge that duality. One path is building the future. The other? Potentially repeating the sins of Lotus Notes and shadow IT with turbocharged tooling.

Enterprise Implication: What’s Actually Changing?

Vibe-coding, in the enterprise context, isn’t about replacing developers. It’s about changing the shape of the developer experience and putting more strategic pressure on architectural leadership.

The real bottleneck is no longer how quickly we can write code. It’s deciding what to build, what shape it should take and what’s operationally sustainable.

In this way, code-gen has revealed a hidden truth: There is now a premium on deep technical experience. Because if machines can write code, the critical skill isn’t the keystroke, it’s the decision tree behind it.

Strategic Pivot: SPA and Serverless Architecture

Acknowledging that microservices were overly complex, the team pivoted towards a React Single Page Application (SPA) with Google’s Firebase backend services, significantly reducing complexity and operational overhead:
- Frontend (React SPA): Leveraged React and Tailwind CSS for responsive, scalable and maintainable frontend development.
- Backend (Firebase): Utilized Firebase Authentication, Firestore and Cloud Functions to simplify backend processes, reduce complexity and improve integration.
- AI Integration (Gemini API): Centralized Cloud Functions optimized API usage, streamlined caching and maintained scalability and reliability.
Architecture Economics: Inference Latency, Unit Costs and Hosting Tradeoffs

As the application matured, the team encountered two major architectural forks — each tied directly to the economics and operational realities of AI at scale.

Inference Model Infrastructure: Hosted vs. Local

Initially, the Signal Scanner leveraged OpenAI’s APIs to rate and summarize articles. However, early tests showed that there was no material quality difference between OpenAI’s responses and outputs from open-source models like LLaMA or Mistral. The key differentiator turned out to be latency.
- OpenAI’s hosted models consistently returned responses in under three seconds.
- Local models, including SoC GPU(M2-Pro)-accelerated, returned results in five to 20 seconds, depending on cold start behavior and load conditions.
Strategic Insight: This is the token economy NVIDIA’s Jensen Huang refers to — AI workloads must be judged not just by compute cost, but by unit economics: latency, reliability and engineering overhead per insight.

For our use case, real-time responsiveness, OpenAI’s hosted infrastructure provided the latency profile we could not match internally without investing in GPU-backed environments in a data center or the public cloud.

Backend Infrastructure: Firebase vs. Kubernetes

The second decision was backend infrastructure. Should the application be deployed on Kubernetes (e.g., GKE, OpenShift) or Firebase?

Kubernetes offered:
- Predictable cost structures via reserved resources.
- Alignment with existing observability and security models.
- Long-term operational control.
Firebase offered:
- High developer velocity for small, fast-moving teams.
- Built-in authentication and real-time database.
- Less predictable costs due to usage-based billing.
Firebase reduced our initial backend development time by over 60% compared to building and securing a Kubernetes deployment, though cost forecasting became significantly more variable beyond the first 10k users.

Enterprise Consideration: Firebase prioritized delivery speed over cost control. It was the right choice for our current maturity level, but came with active monitoring and reversibility planning if costs grew beyond thresholds.

The Hidden Complexity: Backend Infrastructure Considerations

A significant challenge arose from backend infrastructure, often overlooked by vibe coders focused purely on frontend features:
- Non-experienced Vibe-coders rarely consider differences in backend storage (MySQL vs. NoSQL) or orchestrating backend services (API gateways, Kubernetes choices).
- Decisions around OpenShift, VMware Tanzu, or Kubernetes dramatically affect backend integration complexity, operational costs and frontend responsiveness.
Real-world Backend Challenge:
Accurately depicting the real-time processing status of AI article analysis (varying from seconds to minutes) proved difficult within the monolithic Flask setup. Transitioning to a React SPA architecture with Firebase backend seamlessly addressed these complexities, improving user feedback, reducing integration challenges and enhancing operational simplicity.

Product Management: Avoiding “Lotus Notes Syndrome” and Snowflake Complexity

Standing up and scaling vibe-coding centers of excellence for non-traditional application developers in enterprise environments demands rigorous product management discipline. Unchecked expansion of AI tools to general employees can repeat historical enterprise errors, generating fragmented systems, unmanaged technical debt and questionable ROI.

Historical Lessons:
- Lotus Notes Syndrome: Decentralized departmental workflow optimization initially accelerated productivity but eventually resulted in significant operational complexity and technical debt.
- Cloud Sprawl: Developers’ unrestricted cloud usage produced customized “snowflake” environments, hindering central support and operational management.
A Fortune 100 COO underscored that simply providing general employees with AI tools, without structured oversight, often leads to unintended consequences, operational fragmentation and long-term inefficiencies.

Structured Product Management Recommendations:
- Centralized AI Governance: Clearly defined committees or roles responsible for aligning AI tools with enterprise standards and objectives.
- Explicit Architectural Standards: Providing vibe coders with clear guidelines and reference architectures for consistency and interoperability.
- Disciplined Feature Scope Management: Evaluating each requested feature rigorously against strategic business objectives and potential complexity.
- Regular Technical Debt Reviews: Scheduled assessments to explicitly manage and mitigate AI-generated technical debt and maintainability concerns.
Nuanced Governance Challenges at Scale

Scaling vibe-coding practices across broader, non-technical audiences requires proactive governance adjustments:
- Architectural Consistency: Preventing non-technical vibe coders from creating inconsistent interfaces and fragmented backend integrations.
- Technical Debt Management: Explicit processes for reviewing, documenting and managing AI-generated code quality and maintainability.
- Security and Compliance: Comprehensive training and rigorous oversight to ensure adherence to enterprise-grade security and regulatory compliance.
- Ethical AI Use: Clearly communicated ethical guidelines for responsible AI deployment, avoiding inadvertent ethical breaches.
Cultural and Organizational Considerations

Successfully scaling vibe-coding also requires careful attention to organizational and cultural factors:
- Skill Development: Structured training emphasizing foundational software development and AI-specific skillsets (prompt engineering, AI integration best practices).
- Psychological Safety: Cultivating an environment supportive of iterative experimentation, learning from failures without punitive repercussions.
- Managing Cognitive Load: Ensuring developers maintain technical depth and avoid burnout amid rapid AI-assisted iteration cycles.
Key Lessons for CTOs Scaling Vibe-Coding
- Clearly understand operational and financial motivations behind architectural shifts.
- Transition cautiously from local, prototype-driven architectures to centralized, enterprise-grade infrastructures.
- Carefully evaluate architectural decisions based on practical ROI considerations, not just prevailing industry trends.
- Maintain rigorous product management discipline, explicitly managing scope and complexity to avoid operational fragmentation.
- Proactively address governance, security, compliance and technical debt management, particularly when scaling vibe-coding to general or non-technical audiences.
Conclusion

Effectively scaling vibe-coding within enterprise IT requires nuanced decisions regarding architecture, governance, product management and culture. The evolution of the CTO Signal Scanner vividly illustrates the complexities inherent in scaling from simple prototypes to enterprise-ready, centralized applications. By embedding rigorous product management, structured governance, clear architectural guidelines and cultural support, CTOs can harness the rapid innovation potential of vibe-coding without repeating historical enterprise pitfalls. This strategic, disciplined approach ensures long-term operational efficiency, technical stability and sustainable ROI for enterprise IT organizations.
June 9, 2025
Five Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it tends to create opportunities for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration.

Indeed.com

Rivian/VW Group Technology
Palo Alto, CA
Staff Cloud DevOps Engineer – Over the Air (OTA)
$186,000 to $232,000

The Job Network

Murmuration Research
New York City
Lead Data Engineer
$174,306

SimplyHired.com

Citi
Irving, TX
Senior Group Manager/Director for Infrastructure/DevOps
$170,000 to $300,000

Dice.com

Barclays
Whippany, NJ
DevOps/Infrastructure Engineer
$120,000

LinkedIn

Tucows
Remote
DevOps Engineer (Amazon Web Services)
$94,400 to $122,9000

June 9, 2025
Ciroos.AI Preps AI SRE Agents Trained to Automate Incident Management

Ciroos.AI this week emerged from stealth to provide early access to a set of artificial intelligence (AI) agents that have been trained to augment site reliability engineers (SREs).

Fresh off raising $21 million in additional funding, Ciroos.AI CEO Ronak Desai said the SRE Teammate provides access to multiple extensible AI agents that have been trained to proactively investigate anomalies without necessarily having to be directed.

There is already a chronic shortage of SREs, so any tasks that can be assigned to AI agents is only going to reduce the stress level of existing teams, noted Desai. AI agents, for example, are already capable of reducing incident response times by up to 90% to enable SRE, he added.

That capability will prove critical as the overall volume of applications deployed in production environments continues to steadily increase in the age of AI, noted Desai.

The SRE Teammate platform makes use of the Model Context Protocol (MCP) developed by Anthropic and Agent2Agent (A2A) architecture defined by Google to enable AI agents to interact with each other.

Ultimately, DevOps teams will soon consist of multiple autonomous agents that are supervised by software engineers to ensure tasks are completed as expected, said Desai.

It’s not clear how quickly DevOps teams are embracing AI to manage workflows, but Futurum Group research finds 41% of survey respondents expect generative AI tools and platforms will be used to generate, review and test code.

Even less apparent is the extent to which organizations will adopt AI copilots and agents that have been added to their existing platforms versus opting to acquire new platforms developed from the ground up for AI agents that are supervised by software engineers.

Regardless of approach, many of the manual tasks that today conspire to make DevOps workflows more tedious will be eliminated. There is no doubt that will also change the role of software engineers, but the primary goal remains finding ways to leverage automation to enable organizations to deploy more applications in production environments that can run at higher levels of scale.

Additionally, AI technologies should make DevOps tools and platforms more accessible to a wide range of organizations that previously could not afford the level of investment required.

Each organization will, of course, need to determine the level of faith they are willing to place in AI. The challenge is that, given the current pace of innovation, the capabilities of an AI tool that might be made available in a few short months will be substantially higher than the current iteration. As such, DevOps teams need to base their overall strategy not just on what AI tools can do today but, more importantly, what kinds of capabilities will be available in the near future.

In the meantime, DevOps teams would be well-advised to start making a list of tasks that are likely to be assigned to an AI agent with an eye toward determining how the role of software engineers will evolve from there.

June 6, 2025
This Bankrupt AI Startup Was More Artificial Than Intelligent

It turns out Builder.ai was more artificial than intelligent.

The $1.5 billion artificial intelligence (AI) company backed by Microsoft Corp. recently shuttered operations after its neural network was exposed to actually be 700 engineers in India.

Builder.ai, which has begun formal bankruptcy proceedings in jurisdictions where it operated, including India, the U.K., and the U.S., said on LinkedIn it would be “entering into insolvency proceedings.”

“Despite the tireless efforts of our current team and exploring every possible option, the business has been unable to recover from historic challenges and past decisions that placed significant strain on its financial position,” the company wrote.

The company’s Natasha, an AI app-building service, helped it land a strategic collaboration and “significant” investment with Microsoft two years ago. At the time, Builder.ai CEO Sachin Dev Duggal said, “From my first meeting with Microsoft to the moment we agreed to collaborate more strategically, one thing has been really clear — Microsoft’s commitment to helping everyone unlock their true potential.”

Documents reviewed by Bloomberg showed Builder worked with VerSe, an India-based social media startup, to falsely increase its sales numbers, regularly billing each other for similar amounts between 2021 and 2024. “We’re not the kind of company that is in the business of inflating revenues,” VerSe co-founder Umang Bedi told Bloomberg, calling the accusations “baseless and false.”

The sudden rise and fall of Builder.ai serves as a cautionary tale in an industry overflowing in hype, and one susceptible at times to scams. Since it was founded in 2016, the company originally known as Engineering.ai has been embroiled in scandal. It promised to make software creation “as easy as ordering pizza” and marketed its AI assistant, Natasha, as a breakthrough in building software with minimal human input.

At its peak, Builder.ai raised more than $450 million from the likes of Microsoft, SoftBank’s DeepCore, and IFC to reach a valuation of $1.5 billion.

But there were cracks in the corporate facade.

Employees and outsiders pointed out Builder.ai relied on about 700 engineers in India who manually wrote code for client projects while the company misrepresented the work as AI-generated.

Former employee Robert Holdheim sued the company for $5 million, alleging he was fired after flagging concerns over deceptive practices. Legal filings subsequently revealed Builder.ai misled investors by claiming apps were “80% built” by AI though the supporting tech was barely functional. A 2019 investigation by the Wall Street Journal found most of the coding was done manually.

And the saga of Builder.ai is far from over: The company reportedly owes $85 million to Amazon.com Inc. and $30 million to Microsoft in unpaid cloud services. A U.S. federal probe is underway, with investigators seeking access to its financial and client data.

June 5, 2025
Logz.io Unveils Observability Platform Designed First for AI Agents

Logz.io today launched an edition of its observability platform that is intended to be primarily used by artificial intelligence (AI) agents rather than DevOps engineers.

Company CEO Tomer Levy said that as DevOps continues to evolve it’s become apparent that most tasks pertaining to observability will soon be assigned to AI agents. This edition of the Open 360 observability platform exposes machine-readable schemas alongside every panel, allowing AI agents to autonomously create charts, interpret anomalies and modify entire dashboards.

Rather than simply adding a chat bot interface to an existing observability platform, Logz.io is moving to make it possible for DevOps engineers and AI agents to collaboratively observe complex IT environments using a common set of dashboards, said Levy.

That approach still produces insights via a dashboard that can still be read by humans, but the assumption is that AI agents will be the primary end user of those dashboards, he added.

Tasks assigned to those AI agents include executing custom playbooks created by DevOps teams, reviews of new application deployments, cost analysis and security assessments. AI agents can also automatically generate visualizations based on natural language requests, interpret and analyze anomalies in real time and interact with other agents to automate more complex tasks.

Logz.io has already tested this AI agent-first approach with more than 200 IT organizations that have deployed more than 2,000 Logz.io AI Agents, resulting in saving a total of approximately 25,000 engineering hours this month alone—equivalent to 12 full-time SRE positions. At the current adoption rate, Logz.io projects customers will recover roughly 300,000 hours of engineering time over the next year.

It’s not clear how extensively AI agents will change the way DevOps workflows are managed, but it is apparent that with the rise of AI coding tools, the number of applications being deployed by any organization is about to significantly increase. Most existing DevOps teams are not going to be able to keep pace with that rate of application development and deployment without being augmented in some way by AI agents.

The challenge then becomes determining which tasks are best assigned to an AI agent versus those that still require the expertise of a DevOps engineer. Over time, however, DevOps engineers will find themselves supervising a small army of AI agents that have been trained to perform a range of specific tasks.

Ultimately, AI agents should make applications both more resilient and secure as anomalous behavior is identified sooner. Armed with those insights, it then becomes feasible for application developers that are similarly augmented by AI agents to troubleshoot applications in a way that results in more issues being resolved long before they have any meaningful impact on the organization.

In fact, AI agents should make it possible for more organizations to benefit from observability by proactively addressing application issues rather than simply continuing to monitor a set of pre-defined metrics that provide limited actionable intelligence. That, of course, might take some time for IT professionals to accept and fully trust, but in time, many of the tasks that conspire to make managing DevOps workflows more tedious will, like it or not, be increasingly performed by AI agents.

June 5, 2025
Postman Adds AI Agent Mode to Design, Build and Deploy APIs

Postman today revealed it has developed artificial intelligence (AI) agents for its platform for designing and building application programming interfaces (APIs).

Announced at the POST/CON 2025 event, the Agent Mode enables developers to, via a natural language interface, automate entire multi-step workflows spanning the designing, testing, documenting and monitoring of a single API or a logical group of APIs, known as collections.

Postman CEO Abhinav Asthana said unlike an AI copilot, Agent Mode natively executes tasks in a way that understands the actual intent of an API developer.

The overall goal is to reduce the amount of time required to build and deploy an API from weeks to a few hours using a set of repeatable workflows created by an AI agent, he added.

Additionally, developers will be able to integrate the Postman agent with other AI agents via a model context protocol (MCP) server that Postman added last month.

Finally, Postman is also committing to make it possible for developers to alternatively employ AI agents they create to build, develop and test APIs. Postman Insights, now available in a more open beta, will then provide the tools required to track usage of any API created in real time, noted Asthana.

It’s still early days so far as usage of AI tools to build APIs is concerned, but reliance on them within AI applications is already pervasive. Based on data collected from the Postman API Platform between May 2023 and April 2025, developers made more than 7 million API requests involving AI. The OpenAI platform accounted for 60% of that activity, but API traffic involving Meta Llama and Google Gemini grew by a factor of seven and five, respectively.

In total, there are more than 40 million developers that make use of Postman tools to build APIs for 500,000 organizations. The Postman API Network is being used to expose more than 100,000 of those APIs to drive multiple application services. As AI agents make it simpler for both developers and now non-technical end users to build and deploy APIs, the volume of activity is only going to continue to exponentially increase, noted Asthana.

Each organization will need to determine how extensively to rely on AI agents to build and deploy APIs, but it will, if necessary, be possible to rollback any tasks completed by an AI agent, said Asthana.

The one thing that is certain is that API documentation should substantially improve. Most application developers don’t especially enjoy creating documentation, which can be a significant issue whenever a DevOps team needs to troubleshoot an application.

Hopefully, an AI agent trained to develop APIs will lead to higher quality. APIs, in particular, have become the focal point for cybersecurity attacks because in addition to enabling the exfiltration of data they can also be a vehicle for corrupting business logic.

In the meantime, however, IT leaders in the months ahead might want to revisit not just how APIs are created, but also managed, secured and updated in the age of AI.

June 4, 2025