devopsy.kinsta.cloud

Category: Blogs

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
Code Signing in the DevOps Era: Silver Bullet or Security Theater?

In my work with global enterprises modernizing their DevSecOps practices, I’ve repeatedly seen a troubling pattern: Organizations implement code signing with good intentions, but without the controls to support it.

In one recent engagement, a team proudly showcased their secure pipeline – automated builds, signed containers and rapid deployments. But during a code audit, we found a private signing key embedded in a script, committed to version control, with no rotation or monitoring. That key had been used to sign production artifacts. If it had been compromised and we couldn’t be sure it hadn’t – an attacker could have shipped malicious code, fully “trusted” by their infrastructure.

This isn’t rare. Code signing is often deployed as a checkbox, not as part of a robust trust framework. And that creates a dangerous illusion of security.

Signed ≠ Safe: The Hidden Risks Behind the Signature

Digital signatures offer authenticity, not invincibility. Several high-profile attacks, including the SolarWinds breach and the more recent XZ Utils incident, show that attackers don’t need to bypass code signing; they just need to operate within its blind spots.

In the case of XZ Utils, malicious code was introduced over time and eventually signed and distributed legitimately. And in SolarWinds, attackers compromised the build system itself. The code was signed, but that didn’t stop the threat. These incidents make it clear that code signing doesn’t prevent compromise; it merely authenticates it.

Failures often stem from poor key management, inadequate revocation mechanisms, or an uncritical acceptance of signatures without examining the broader context. If your systems automatically trust any signed artifact without checking its provenance, you’ve already lost.

Speed vs. Safety: Why Code Signing Struggles in the DevOps Pipeline

In high-velocity environments, security controls are only effective if they blend seamlessly with development workflows. This is where code signing often stumbles. Signing keys may be embedded in scripts, mismanaged in cloud environments, or shared across teams. Developers, under pressure to release quickly, might bypass signing altogether if the process becomes cumbersome.

Worse, many CI/CD systems lack observability, making it difficult to detect anomalous signing behavior. In an era where pipelines are as critical as the code they deliver, this blind spot becomes a liability.

What Code Signing Actually Delivers—and Where It Falls Short

Despite its limitations, code signing still plays a vital role when treated as one part of a broader software security strategy. It must be tightly integrated with secure key storage, revocation processes and post-deployment monitoring. But that’s not enough.

Security leaders must look beyond signatures. Knowing who wrote the code and how it was built matters as much as the fact that it was signed. This means incorporating Software Bill of Materials (SBOMs), establishing build attestation and tracking dependencies in real time. It also means verifying that the code came from a trusted workflow, not just a trusted key.

Ultimately, security doesn’t stop at the signature — it begins there.

What CISOs Should Prioritize: From Signing to Sustained Trust

Code signing only works as part of a disciplined, layered security model. For CISOs and DevSecOps leaders, the challenge is not merely to introduce code signing into the pipeline but to operationalize it securely and sustainably. That means building a trust framework that spans people, process and platform.

Start with secure key management. Signing keys must be protected with the same rigor as encryption keys or credentials. This means hardware security modules (HSMs), cloud-native key vaults and enforcing granular access control — only authorized systems or identities should be able to sign code, and every usage should be logged.

Next, treat signing as a programmable policy, not an optional step. Integrate automated signing into CI/CD pipelines, using policy-as-code tools that enforce when, where and how signing occurs. All build artifacts should pass through this gate, and any deviation should be flagged for review.

Don’t stop at the signature. Ensure full provenance validation — know what was built, by whom, using which dependencies. Tools like in-toto, SLSA and SBOM generation solutions can help ensure that signatures are tied to a complete, verifiable chain of custody.

Adopt short-lived certificates and revocation mechanisms to reduce the blast radius. If a key is compromised or misused, organizations must be able to respond immediately by revoking trust and rotating credentials.

Crucially, invest in developer enablement. Developers are not cryptographers — and they shouldn’t have to be. Provide simple tooling, templates and education that make secure signing easy and error-resistant.

Finally, implement monitoring and anomaly detection for signing activities. Unusual signing behavior — like signing from an unexpected IP, service, or pipeline — should be treated as a potential breach and escalated accordingly.

These actions form a framework that moves code signing from a check-the-box task to a pillar of software trustworthiness.

The Checkbox Trap: Why Signatures Alone Aren’t Enough

A worrying trend is the “checkbox” mentality that surrounds code signing. Yes, your software is signed. But is it secure? Compliance might require a signature, but true assurance comes from layered validation, runtime introspection and knowing exactly what’s running in production.

As organizations strive to harden their software pipelines, it’s tempting to overvalue cryptographic proof. But trust is not binary. It’s dynamic. It must be earned and reaffirmed at every stage of the development and deployment lifecycle.

Conclusion: Trust, But Verify – and Then Monitor

Code signing, like many security tools, is powerful in theory and dangerous in isolation. It offers trust, but only to the extent that the surrounding processes are trustworthy. In the fast-moving world of DevOps, where builds, packages and deployments happen at breakneck speed, the biggest threat isn’t unsigned code – it’s unquestioned trust.

Security leaders must treat code signing as a control point, not a finish line. Don’t just ask, “Is it signed?” Ask, “Is it signed, tracked, validated and safe to run now and tomorrow?”

Trust begins at the signature. But in modern security, it never ends there.

June 9, 2025
Zero-Trust, Full Stack: Embedding Cybersecurity Principles Into Site Reliability Engineering Culture

These days, with digital threats everywhere, cybersecurity must evolve beyond just being a perimeter measure. Given the rapid delivery of software and the transient nature of infrastructure, security must be built into DevOps. This shift presents both a challenge and an opportunity for site reliability engineers (SREs) to apply zero-trust principles everywhere, starting with infrastructure and services and extending to how developers operate.

Zero-Trust: Beyond the Buzzword

While zero-trust is often associated with network security, many people do not realize it encompasses much more. It involves rethinking how trust is managed in distributed computing. The key idea is to always verify a person’s identity, device status and intent before granting access to any system element — regardless of its location on the network. The principle is ‘never trust, always verify’. Although this concept is used in security, it is still not fully practiced in SRE, as prioritizing availability and performance has usually been more important than focusing on security and telemetry.

With their expertise in systems and automation, SREs have the skills to take zero-trust beyond firewalls and identity solutions (refer to Figure 1). Testing these principles in reliability goals increases teams’ power to reduce the blast radius, secure production environments and deal with incidents more effectively.

Figure 1: High-Level Zero-Trust System.

It includes regular risk assessment with the help of a central analytics engine. Access to data is prevented by default and is granted only after proper verification. After users have been granted access, they can carry out transactions according to the determined risks. It constantly updates its decisions using information from various sources, such as identity, access context, security alerts and the ongoing session’s information.

The Convergence of Reliability and Security

Reliability engineering today focuses on more than just preventing downtime. The challenge is managing complexity and risk with continuous deployment, increasing service meshes and expanding application programming interface (API) surfaces. Changes in how production environments are run typically outpace traditional information system security (InfoSec) boundaries.

SREs fill this space by working with security teams and ensuring that security as well as observability are integrated into development pipelines. In other words, it is ‘security as dependability’ — they ensure there are no unauthorized changes, remove old passwords and ensure that staff have enough access to sensitive systems.

Take, for example, the consequences of using a compromised API token. If zero-trust principles — including strict access rules, regular authentication and control over service identities — are not applied, someone could use that token to move from microservice to microservice. By adopting zero-trust, SRE teams must integrate authentication between services, trusted connections using transport layer security (TLS) and policy checks directly into their workflow.

Policy as Code: Scaling Trust in the Pipeline

One crucial factor supporting zero-trust in SRE is policy as code. Just like infrastructure as code simplifies system creation, policy as code offers a way to automatically set and keep security policies up to date. Enforcing policies dynamically during continuous integration and continuous deployment (CI/CD) steps allows teams to enhance security while continuing at the same speed. SREs should understand policies as helpful guardrails that help maintain secure and proper configuration, access and deployment. Having policies managed and checked like other code enables a team to grow and creates trust among everyone working remotely.

Telemetry, Observability and Security Context

The nervous system of SRE is telemetry. Thanks to logs, metrics and traces, observability platforms help teams spot out-of-the-ordinary events, anticipate problems and understand the cause of any issues. Security signals such as unsuccessful logins, suspicious ways of gaining access and domain name system (DNS) tunneling are often supervised by different security operations center (SOC) teams.

Making cybersecurity part of SRE culture involves having telemetry that supports security observability, bringing security-related events into the same observability systems as those for performance and reliability. A centralized view reduces the time to locate the issue and improves how incidents are handled as a team. In a zero-trust model, each deviation from normal is considered a possible security threat.

Operationalizing Zero-Trust: Practical Steps for SRE Teams

Building a zero-trust culture in SRE does not require organizations to change everything at once. They can start embedding these practices in everyday operations by doing the following:

Enforce Identity Everywhere: Use evanescent keys, workload identity and service mesh for mutual authentication.

Audit by Default: All system changes, attempts to access them and incidents of policy breaches should result in structured logs that both the SRE and security teams have access to.

Integrate Policy Engines: During CI/CD, implement policies to confirm that deployments meet security and setup rules.

Minimize Human Access: Use automation and ephemeral credentials to eliminate shell access or long-lived keys.

Simulate and Test: Treat security risks as another factor that could cause a failure. Using chaos engineering principles, you can simulate attacks and test how to respond to them.

We must remember that the central aspect of zero-trust in SRE is changing the team’s approach to cybersecurity, not only replacing tools. SREs should learn to consider security events as they would other threats to the system’s reliability. In case of an incident, a security-related view should be included in the postmortem, and blameless retrospectives should focus on breaches of trust boundaries. By tying zero-trust with the pursuit of site reliability, groups can create an environment where security is everyone’s responsibility instead of being kept apart. By following these steps, SREs will ensure the systems remain up, running and safe.

June 9, 2025
Cultural Debt vs. Technical Debt in Infrastructure Automation
Infrastructure is humming, deployments are fast and dashboards are green. But something still feels off. Despite the technical efficiency, teams might be slowed down by recurring issues, misalignments, or resistance to change. These aren’t always rooted in code.

While technical debt, the accumulated cost of quick fixes and legacy code, is a familiar concept, cultural debt often goes unnoticed. It surfaces through unclear communication, misaligned incentives, or outdated norms that no longer support evolving goals.

Both forms of debt can quietly undermine DevOps practices, as they limit the very automation and agility they’re meant to enable.

In this article, we’ll explore the differences between technical and cultural debt, how each impacts DevOps and infrastructure automation and practical approaches to identifying and addressing them.

Defining the Terms

Technical debt means the trade-offs made during development to prioritize speed over long-term quality. These shortcuts might be intentional or the result of time pressure, resource constraints, or evolving requirements. While they can accelerate delivery in the short term, they often lead to brittle systems, increased maintenance burden and operational inefficiencies down the line.

Technical debt can manifest in many ways: hardcoded configurations that don’t scale across environments, inadequate or missing monitoring, outdated provisioning scripts, or reliance on manual processes that should have been automated. Over time, these issues can drag on velocity and complicate troubleshooting.

On the other hand, cultural debt is less tangible but equally impactful. It represents the accumulation of unresolved issues in team interactions, which can mean mismatched expectations, ineffective communication and outdated cultural norms that no longer support the team’s goals.

Examples include resistance to adopting new tools, siloed teams with poor cross-functional collaboration and unclear ownership of infrastructure components. Like technical debt, cultural debt builds silently and can impede progress if left unaddressed.

Why Cultural Debt is the Silent Killer in DevOps

DevOps is more than pipelines and automation. At its core, it’s a cultural transformation.

It’s about breaking down silos, fostering collaboration, building fast feedback loops and promoting shared responsibility across development and operations. Even the most advanced tools and workflows struggle to deliver their full value without the right cultural foundation.

This is where cultural debt becomes particularly insidious. Unlike technical debt, which is often visible in logs or performance metrics, cultural debt hides in team dynamics and day-to-day interactions.

It shows up when teams resist adopting new tools, cling to “the way we’ve always done it,” or hesitate to take ownership of shared responsibilities. These patterns create friction, slow onboarding and make scaling CI/CD efforts far more complex than necessary.

Moreover, cultural debt tends to compound quietly. A single unclear decision-making process or a lack of psychological safety can ripple outward, leading to missed handoffs, redundant work, or breakdowns in trust. Over time, this erodes the very principles DevOps relies on: agility, transparency and continuous improvement.

Addressing cultural debt means creating an environment where teams can adapt together. Without this cultural alignment, the technical side of DevOps is left propping up an unstable foundation.

How Technical and Cultural Debt Feed Each Other

A dysfunctional team culture, marked by poor communication, unclear ownership, or fear of failure, often leads to rushed decisions and technical shortcuts. These quick fixes accumulate into brittle systems and fragile automation.

As technical debt grows, so does the hesitation to make changes. Teams avoid touching fragile pipelines, unsure of the impact or who’s responsible. This reluctance reinforces siloed behavior and deepens mistrust, further degrading the culture.

It’s a vicious cycle: bad culture leads to poor code, and poor code makes the culture worse.

Breaking the loop requires tackling both, cleaning up systems while fostering a culture that supports shared responsibility and continuous improvement.

Diagnosing and Measuring the Debts

Recognizing technical and cultural debt early is key to preventing long-term drag on DevOps performance. While technical debt often leaves a visible trail, cultural debt tends to require a more observational, qualitative approach.

Signs of Technical Debt

These indicators often show up in system performance and team workflows:
- Frequent outages or instability after changes
- Long release cycles or painful deployments
- Manual tasks where automation should exist
- High effort to onboard new infrastructure or services
Signs of Cultural Debt

Cultural issues can be more subtle, but they have a tangible impact on collaboration and growth:
- A culture of blame instead of shared accountability
- Knowledge hoarding or unclear documentation
- Avoidance of retrospectives, feedback, or experimentation
- Siloed teams with limited cross-functional interaction
While tools like DORA metrics can help measure delivery performance (e.g., deployment frequency, lead time for changes), cultural debt often requires listening to team dynamics, observing behaviors and surfacing what’s not being said.

Technical problems may flag a deeper cultural issue, and addressing both starts with awareness.

Strategies to Address Both Debts Together

Addressing technical and cultural debt in isolation only offers a temporary fix. Both must be tackled in tandem to build sustainable DevOps practices because culture drives how technology is built, maintained and evolved.

Start with the code, but don’t stop there.

Make space for regular refactoring and cleanup cycles, as they are excellent opportunities to reassert quality standards. Strengthen test coverage and invest in observability, not just for performance but also to reduce fear when deploying changes. And when automating, be deliberate. Automation should solve real problems, not just shift complexity around.

But even the cleanest codebase won’t thrive in a broken culture. Creating psychological safety is foundational: people need to feel safe speaking up, admitting mistakes and asking questions.

Leaders should actively model DevOps values like transparency, shared responsibility and continuous improvement. Practices like cross-functional pairing and meaningful retrospectives help reinforce collaboration across silos.

Tools can support this work, platforms like Terraform Cloud, Spacelift, GitHub Actions, or Jenkins enable better infrastructure management and automation. But tools don’t solve culture; they amplify it. A strong foundation of trust and clear communication is what allows these platforms to truly accelerate delivery.

Wrapping up

Technical and cultural debt both undermine DevOps success, but cultural debt often lays the groundwork for technical shortcuts and long-term inefficiencies. While it’s easier to spot failing pipelines than failing team dynamics, it’s usually the culture that shapes how systems evolve.

Investing in tooling and automation is important, but without a healthy culture to support it, those investments won’t scale. Treat culture as a core part of your infrastructure strategy, as it’s how you build and grow.
June 9, 2025
4 application modernization trends for 2025 and beyond

More and more companies are investing in application modernization (i.e., replatforming, rehosting, re-architecting or rebuilding an app) to align outdated corporate software with current business needs and modern technological standards, thereby securing legacy tech investments. The application modernization services market, which was estimated at $19.82 billion in 2024, is expected to reach $39.62 billion by 2029, according to the report from MarketsandMarkets.

Although legacy application modernization can be driven by various factors, it typically aims to improve software reliability, scalability, or security. In most cases, companies succeed in meeting these objectives with well-planned modernization initiatives. In the 2024 Konveyor.io survey of companies already invested in app modernization, 58% noted it helped enhance software security, 53% reported improved software scalability, and 52% stated that modernization helped increase software reliability.

In this article, experts from the software development company Itransition highlight four trends shaping the app modernization landscape to help you navigate the process more efficiently.

Low-Code and No-Code Development

Low-code and no-code development platforms offer point-and-click and drag-and-drop tools for designing and building apps with minimal or no coding, and an increasing number of companies are utilizing them to develop and modernize their software. For instance, 37% of respondents to Zoho’s 2024 survey held among European companies already consider low-code an essential element of their software development strategy.

What makes low-code and no-code development so popular is that it enables companies to build app prototypes and develop apps much more quickly compared to traditional coding approaches. By switching to these development approaches, companies cannot only reduce the time to market for new solutions but also modernize existing software faster.

Suppose you own a legacy app with functionality and a user interface that do not match current user expectations, leading to negative user experiences. So, you plan to replace this legacy app with a newer, more efficient version. Currently, you have multiple functionality and design ideas for the new app, but you cannot decide which ones to focus on, which slows down the project planning process.

If you had multiple prototypes for a modernized app, each showcasing how it can look and behave with different designs and functionalities, making the right decision would be much easier. And with low-code and no-code tools, even users with limited tech expertise in your organization can build interactive app prototypes within several days or weeks. According to the same Zoho study, 77% of the surveyed companies consider faster prototyping a significant advantage of low-code.

Cloud Computing

The growing use of cloud computing technology is another notable trend influencing the app modernization landscape. Today, we can see more companies migrating their on-premises apps to the cloud, both without or with minor code and architecture changes. At the same time, more businesses are re-architecting their legacy apps as cloud-native, either by adopting containerization or by moving apps to a microservice-based architecture.

By moving legacy apps to the cloud environment, companies can significantly enhance their scalability while making them easier and less costly to maintain. As cloud computing offers such impactful advantages, we can expect this trend to continue. 78% of companies that participated in Lufthansa’s 2025 survey state they are happy with the results of cloud migration, and 72% say they are increasing budgets for cloud technologies and cloud migration projects.

Artificial Intelligence (AI)

Speaking about trends that shape application modernization in companies, we cannot overlook the growing influence of artificial intelligence. The majority (78%) of organizations surveyed by Red Hat in 2024 were already using AI to support their application modernization initiatives or were planning to use the technology in the future.

Many companies, for instance, utilize software intelligence tools at the outset of their modernization projects to automatically collect data about the source code, database structure, and other components of legacy solutions, thereby pinpointing areas for improvement. Additionally, organizations often implement AI coding assistant tools to enhance the productivity of their software engineering teams, thereby accelerating modernization.

Companies are also increasingly complementing their legacy software with AI capabilities (such as intelligent data precaching, which helps accelerate data storage and retrieval processes) to enhance system performance and reliability. They extend legacy app functionality with powerful AI features, ranging from user personalization to predictive analytics, to increase the software’s overall business value.

Progressive Web Applications (PWA)

Another trend we can see is transforming legacy apps into PWAs, solutions at the intersection of mobile and web, which can perform well on any device supporting an Internet browser. Research Nester reveals that the global PWA market has reached $2.2 billion in 2024 and is going to surpass $72.16 billion by 2037, meaning companies are increasingly investing in the technology. According to the same study, many of these companies focus on modernizing their web apps to provide users with native app-like experiences.

From a business perspective, notable advantages of PWA include cross-platform interoperability, enabling companies to convert a single legacy app into a PWA instead of building multiple new apps for different operating systems and devices. Another benefit is that PWAs can store network data in a local cache and reuse it later, resulting in typically requiring less bandwidth compared to standard web apps. This capability allows them to work even offline, which in turn can help companies improve user engagement rates. PWAs are also SEO-friendly, meaning they can help companies attract more traffic and increase global reach.

Final thoughts

The use of legacy apps comes with numerous pitfalls, including performance and security issues, as well as data compliance and user experience concerns, which can hinder the return on your technology investment. Application modernization can help you avoid these issues by aligning software with your current business requirements, ensuring it remains efficient and competitive in the ever-evolving digital landscape.

Nonetheless, companies planning to modernize their apps often find out they lack the necessary skills and competencies to complete projects in-house. If you have similar concerns, you can seek assistance from third-party software experts. An outsourcing software agency can help you handle various aspects of your project, including legacy app assessment, selection of a modernization approach, and execution of modernization.

June 9, 2025
Cloud ROI is Broken. Agentic AI Might Be the Fix.

Enterprises flocked to public cloud infrastructure with the promise of speed, flexibility and efficiency.

But many are now grappling with a different reality: Cloud environments are more complex to manage than anticipated, and the associated costs have spiraled far beyond early projections.

Enterprise IT leaders haven’t been shy about sharing this fact. Last year, 63% of enterprise IT leaders responding to an IDC survey said they actively evaluate hybrid or multi-cloud strategies to regain control over cost and performance. In 2023, a report from Andreessen Horowitz cited examples of companies repatriating workloads to on-premises data centers amid questions about whether the cloud was still worth the cost.

Looking ahead, however, the proliferation of agentic AI could represent a turning point. That is, if enterprises approach it correctly.

The Problem Isn’t the Cloud — It’s the Complexity

The infrastructure challenges dragging down cloud ROI aren’t just about cost per compute hour or storage. They stem from the effort required to translate infrastructure goals into action.

Writing infrastructure code, orchestrating dev and test environments, enforcing governance standards, troubleshooting errors and decommissioning unused resources are all labor-intensive processes. Even teams that have invested in infrastructure-as-code (IaC) and automation often struggle to move fast enough to justify the cost of cloud infrastructure.

When we talk with our customers, we typically see these challenges materialize in two ways: lost productivity and inflated cloud costs. Delays to deliver cloud environments extend timelines, resulting in higher labor costs and slower time to market, while wasted cloud costs leave less budget for other technologies.

Agentic AI has the potential to tackle some of these challenges by performing the day-to-day tasks that hold infrastructure teams back.

Consider a state where infrastructure engineers incorporate AI agents to write infrastructure code, review that code for security and compliance standards before it’s deployed, and monitor the state of that infrastructure to identify risks, perform root-cause analysis on errors, or detect oversized or idle resources.

Some of these tasks require hours of work from skilled infrastructure engineers. Others aren’t even being done today.

What Could Hold Back This Transformation

The economic stakes for this transformation are high.

Enterprises that successfully harness agentic AI to automate and optimize their cloud operations can accelerate time to market, price their products more competitively and show profitability gains.

And that’s in addition to the day-to-day benefits: less monotonous work for DevOps engineers and SREs, happier developers who get what they need on demand and lower turnover as a result.

But despite the promise of agentic AI, adoption is far from guaranteed. These tools often require a significant upfront investment in new platforms, training and change management. For IT leaders already facing budget scrutiny over ballooning cloud bills, the idea of spending even more on a new class of tools may seem like throwing good money after bad — especially if past cloud initiatives failed to live up to expectations. Without clear, measurable short-term wins, they may hesitate to adopt solutions that promise long-term transformation.

And then there’s the psychological hurdle for the teams responsible for integrating agentic AI into legacy processes and platforms. Developers and engineers may be wary of embracing AI tools that appear to threaten job security.

At a time when IT decision makers have started looking for the exits to their cloud strategy, they’ll need to consider whether it makes more sense to modernize how they manage their infrastructure. How this plays out will be interesting to watch.

The cloud, for all its promise, demands a new level of operational maturity to deliver ROI at scale. Agentic AI may be the missing ingredient that finally makes cloud living up to its potential.

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
Managing Day 2 Concerns for Agentic AI Architecture
We’re now in the fifth wave of computing. If that sounds dramatic, that’s because it is—and probably also because someone in marketing really wants to make “agentic AI” stick. For those keeping track at home, the first four waves were mainframes (your granddad’s computer), web (when we were all hopeful), cloud (when we were still kind of hopeful), and mobile (where that hope became a subscription to your attention span).

And now? Agentic AI.

Let’s get the buzzwords out of the way: Agentic AI is a fancy term for giving large language models (LLMs) persistent memory, looping logic, and callbacks to reach out to your APIs. It’s like giving a Roomba a graduate degree and asking it to run your IT department. These “agents” operate independently (ish), have goals (ish), and make decisions (ish) based on prompts, semantic search and however much context you can cram into a vector database.

Sounds fantastic. Until you have to operate and maintain this stuff in production.

Because Day 1 is always a party, demos run great on slide decks. Day 2 is when the ops team walks into the room, sees the cloud bill, and quietly walks back out.

The Scale Problem (a.k.a. We Broke TPS)

Let’s talk about scale. Traditional systems had thousands to millions of users. With mobile, we got billions. Agentic AI? Try trillions. Not just people, though. You’ll have agents helping users, agents helping agents and agents judging the work done by other agents.

Mainframe

Web

Cloud

Mobile

Agentic

Users

thousands

millions

100 million

billions

trillions

TPS

100

500

2,500

10,000

1,000,000

5x

5x

4x

100x

Each one of those agents runs loops. Each loop makes calls. Each call hits an LLM. Every LLM call contributes to Transactions Per Second (TPS). Not all transactions or LLM interactions are the same. Humans have very different behavior than agents.

The types of interaction behavior we might see:
- Human users = finite and sleepy
- Agents = infinite and caffeinated
- LLM inference = expensive, slow, and shockingly unreliable
- Therefore: system load = Who knows? How do we even predict this stuff?
It isn’t unusual for pre-agentic systems to max out around 10,000 TPS. Agentic systems? You’re looking at a million TPS just to hit parity with your company’s Slack usage.

But What About Cost?

Ah yes, the CFO’s favorite section.

Running agents is expensive. Running smart agents is very expensive. Running smart agents 24/7 with high-accuracy LLMs? Welcome to a world where your annual AI ops bill might be an order of magnitude higher than it was before.

Let’s put that in relatable terms:
- GPT-4 32K (86% accuracy): $98 per million tokens
- Open source model (42% accuracy): $0.013 per million tokens
- Database transaction: pocket change by comparison
And don’t let the open-source optimism fool you. A 42% accurate agent might write emails like “Dear Sir/Madman, I have eaten the spreadsheet,” which is cute until it’s running your treasury. Remember that hallucinations and bad responses are so common, we already have patterns for using multiple other LLMs just to judge the work of the first. This means that your cost isn’t just the cost to ask an LLM an innocent question, it’s the cost to resolve tools, cost to make the actual request and cost to make potentially multiple judgment requests.

So now you’re faced with the AI version of the eternal tradeoff: dumb and cheap vs. smart and broke.

Latency, Reliability and Other Sad Stories

LLMs are not built for low-latency, high-throughput work. They’re built for… storytelling. And hallucinating. And sometimes – if you ask nicely and are an expert in prompt engineering – even answering your questions.

Now, imagine your core systems relying on that. Imagine your uptime metrics depending on the whims of an LLM inference API that thinks “return customer data” means “find a retail location where customers can bring and return their data”

Agentic systems aren’t transactional. They’re conversational. They’re unpredictable. They can fail to give you an answer, they can stop answering in the middle of a stream. Don’t listen to what people tell you, you can’t blindly trust an LLM.

And yet, we keep trying to run them like traditional software. We build orchestration platforms, routing layers, retry loops, and cost governors. Why? Because otherwise, these things will try to eat the entire internet in a single for-loop and send us the cloud bill.

Capacity Planning Is Now Chaos Planning

You used to think about load in terms of peak usage. Now? Your agents don’t sleep. They don’t go to lunch. They just keep going, looping away, slamming vector DBs and semantic search engines with relentless, existential enthusiasm. Your system lows are higher, your median times are higher, and your peaks are higher.

This means:
- Your database load goes up 100x
- Your network saturates under constant agent chatter
- Your infrastructure team turns into a stress-testing experiment
- And you still get worse answers than just asking the intern
You don’t plan for “peak load” anymore. You plan for “non-stop Reddit debates between bots.”

The Blueprint (Such as It Is)

In theory, building a sustainable agentic architecture looks like this:
1. Semantic Search – All your domain knowledge gets shoved into a vector DB, ready to be retrieved by semantic similarity.
2. Agentic Sessions – Every agent interaction is logged to provide context, continuity and accountability.
3. LLM Invocation Loops – Prompt, retrieve, augment, call LLM, process, repeat until you get a satisfactory answer, or you run out of usage quota.
4. Orchestration Layer – The puppet master that tells agents what to do, when, and for how long before they bankrupt you.
This is all manageable, assuming you can hire a team of distributed systems engineers who also speak fluent “prompt engineering,” understand vector math, and have no plans for sleep.

What Ops Teams Need to Do (Besides Cry)

If you’re serious about building something in this space—and not just gluing ChatGPT to your CI pipeline, you need to:
- Plan for real-time TPS: Millions of them, all at once, with unpredictable spikes.
- Plan for augmentation (RAG): Simple one-off queries are rare. Instead, your agents will be making multiple round trips to the LLM to resolve tools and multiple passes at a vector database for context augmentation.
- Instrument your agents: Know which model they’re using, how often, and at what cost.
- Design for failure: Assume models will hallucinate, APIs will fail and your agents will suddenly think they’re writing sci-fi.
- Stay modular: You’ll want to swap models faster than your CFO can say “cost optimization.”
Final Thought: The AI Agency Gap

The AI Agency Gap is the chasm between dumb bots and actual autonomous systems. It’s the space where most agents will live—semi-capable, semi-stable, semi-helpful. They’re the interns of the software world: energetic, inconsistent and always one bad prompt away from disaster.

If you want to thrive in this new wave of computing, you’re going to need resilience, observability, guard rails, patience and some really good stress coping techniques. The future isn’t just about building agentic systems, it’s about knowing that you’ve made all of your microservices unpredictable and require 10x more resources.

Good luck.
June 5, 2025