CI/CD & delivery pipelines
CI/CD design, release workflows, build performance, test gates, rollback, and deployment automation.
58%
Best tweets about DevOps
50 Best Tweets About DevOps (2026)
Find the best tweets about DevOps, covering deployments, CI/CD, infrastructure, observability, reliability, incidents, automation, and platform engineering.
Production DevOps systems, deployment pipelines, infrastructure, observability, incidents, reliability, automation, and engineering tradeoffs.
- Creators
- 39
- Updated
Original Xholic analysis
What 50 top DevOps posts reveal
The posts portray DevOps as a combination of delivery automation and production judgment: operational fundamentals, safety controls, observability, security, rollback planning, and release ownership recur alongside AI-assisted workflows. [2039591156955459751, 2082567392266207533, 2057755931354534025]
- Dominant tone
- Positive
- Median score
- 10.3
- Leading format
- Other
- Recent posts
- 56%
52% of posts
All-time engagement
100% of posts
Published in 90 days
Conversation map
The themes creators return to
DevOps foundations & career skills
Linux, networking, Git, scripting, Docker, cloud, and other foundational DevOps skills, learning paths, and practitioner resources.
28%
Infrastructure as code & cloud automation
Terraform, CloudFormation, GitOps, repeatable provisioning, infrastructure lifecycle management, and cloud platform automation.
24%
Platform engineering & operating models},{
Platform engineering, internal developer platforms, team ownership, self-service workflows, and organizational delivery tradeoffs.
24%
DevSecOps & software supply chain security
CI/CD supply-chain risks, secrets, IAM, dependency vulnerabilities, CVEs, isolated runners, security scanning, and secure defaults.
18%
Observability, incidents & reliability
Metrics, logs, traces, dashboards, alerting, SLOs, production debugging, incident response, postmortems, and reliability practices.
18%
Containers & Kubernetes operations
Containers, Kubernetes operations, cluster primitives, workload failures, resource management, and orchestration troubleshooting.
10%
Progressive delivery & safe rollouts
Production rollout patterns including canaries, blue-green deployments, feature flags, dark launches, previews, and controlled exposure.
6%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 27
- Median reposts
- 4
- Median replies
- 3
- Median views
- 1.6K
Posts with media make up 48% of this collection. Their median all-time score is 22.0, compared with 7.12 for text-only posts.
Format mix
- Other 100% · score 10.3
Consensus and debate
Where creators agree, and where they do not
Shared view
Fundamentals remain central to practice
Posts repeatedly frame DevOps around Linux, networking, containers, CI/CD, infrastructure as code, observability, security, and operational judgment.
Shared view
Safe delivery needs deliberate guardrails
Delivery posts emphasize safeguards including canaries, rollback capability, controlled exposure, patching known CVEs, separating staging and production secrets, and clear release ownership.
Shared view
Reliability is practiced through diagnosis
Production-oriented posts focus on diagnosing workload failures, querying logs and telemetry, using runbooks, and testing configurations when systems fail.
Open debate
How much end-to-end testing is useful?
One post argues that shared staging and broad end-to-end tests become liabilities at scale. Another argues that agents need comprehensive CI, evaluations, and end-to-end environments to self-validate. The posts differ on the role of shared versus isolated validation environments.
Open debate
When does DevOps specialization pay off?
A startup-focused post argues that early companies may not need a DevOps specialist, while a platform-engineering post argues that fast-growing teams eventually need infrastructure, tooling, and self-service capabilities.
What performs
Patterns behind standout posts
Outliers span AI, skills, incidents, and pipelines
The deterministic analytics identify these five posts as score outliers. Their topics include AI-assisted AWS operations, agent-oriented engineering practices, a DevOps learning path, Kubernetes troubleshooting, and ML-aware CI/CD.
Progressive delivery has the highest listed theme median score
Progressive delivery is the smallest listed theme by share (6%) but has the highest supplied theme median all-time score (30.778). Its evidence posts address rollout patterns, an auto-deploy learning journey, and controlled agent delivery.
Statistical standouts
- View standout post 1 Score 943.5 · 91.87× median
- View standout post 2 Score 725.4 · 70.63× median
- View standout post 3 Score 561.0 · 54.62× median
- View standout post 4 Score 171.2 · 16.67× median
- View standout post 5 Score 164.2 · 15.99× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. Emmy Codes 🪖🚀👨💻
@_devEmmy
2 posts
-
2. Jaydeep
@_jaydeepkarale
2 posts
-
3. Vaishnavi
@_vmlops
2 posts
-
4. Abhishek Singh
@0xlelouch_
2 posts
-
5. Bilgin Ibryam
@bibryam
2 posts
-
6. Branko
@brankopetric00
2 posts
AI enters the operational workflow
These posts present AI assistance in pipeline generation, deployment debugging, incident investigation, and engineering workflows, while emphasizing the importance of operational context.
Judgment is presented as a key practitioner skill
Career- and interview-focused posts prioritize systems reasoning, ownership, and explaining tradeoffs over command memorization, certifications, or tutorial-following.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best DevOps tweets
Top DevOps tweets from 39 creators
Ranked 01–50
- 01
@twtayaan ·
🚨 AWS DevOps Agent is finally here! On March 31, 2026, AWS DevOps Agent became generally available. This is actually a big deal. It can: → Generate CI/CD pipelines → Debug failed deployments → Suggest infrastructure changes → Analyze logs and incidents → Help with Terraform & CloudFormation → Recommend cost optimizations → Explain AWS architecture issues Basically, it’s like having a junior DevOps engineer inside AWS. DevOps is slowly becoming AI-assisted operations. Source: https://t.co/PMNbPPF4lW
- 02
@bibryam ·
Really like this from @addyosmani 👌 🤩 Google engineering practices as agent skills🤩 -> organized into 19 skills & 7 commands for AI agents. → Plan - decompose into small, verifiable tasks → Build - incremental implementation, context engineering, clean API design → Verify - TDD, browser testing with DevTools, systematic debugging → Review - code quality, security hardening, performance optimization → Ship - git workflow, CI/CD, ADRs, pre-launch checklists https://t.co/JOPAOVvwLy
- 03
@techyoutbe ·
Don't overthink....just start Step-1: Learn Linux Fundamentals Step-2: Master Git and Version Control Step-3: Understand Networking Basics Step-4: Learn Scripting (Bash, Python) Step-5: Master CI/CD Concepts (Jenkins, GitLab) Step-6: Learn Containerization (Docker) Step-7: Master Orchestration (Kubernetes) Step-8: Learn Cloud Platforms (AWS, Azure, GCP) Step-9: Understand Infrastructure as Code (Terraform, Ansible) Step-10: Learn Monitoring and Logging Tools (Prometheus, ELK) Step-11: Practice Automation Everywhere! Step-12: Stay updated on DevOps best practices 🏆 Congratulations, you're a DevOps Engineer!
- 04
@_vmlops ·
Kubernetes troubleshooting is a core skill for DevOps engineers, especially in production where issues like CrashLoopBackOff, Pending pods, ImagePullBackOff, OOMKilled errors, DNS failures, ingress issues, volume mount problems, resource pressure, restart loops & networking glitches are common Deploying applications is often straightforward the real challenge begins when things break & diagnosing those failures quickly & effectively is what separates experienced engineers from the rest
- 05
@Aurimas_Gr ·
As an 𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿 you should also care about regular, non LLM-based ML models, productionising them comes with its own challenges. For example, 𝗖𝗜/𝗖𝗗 process is 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗳𝗼𝗿 𝗠𝗮𝗰𝗵𝗶𝗻𝗲 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 compared to regular software. The important difference that the Machine Learning aspect of the projects brings to the CI/CD process is the treatment of the Machine Learning Training pipeline as a first class citizen of the software world. ➡️ CI/CD pipeline is a separate entity from Machine Learning Training pipeline. There are frameworks and tools that provide capabilities specific to Machine Learning pipelining needs (e.g. KubeFlow Pipelines, Sagemaker Pipelines etc.). ➡️ ML Training pipeline is an artifact produced by Machine Learning project and should be treated in the CI/CD pipelines as such. What does it mean? Let’s take a closer look: Regular CI/CD pipelines will usually be composed of at-least three main steps. These are: 𝗦𝘁𝗲𝗽 𝟭: Unit Tests - you test your code so that the functions and methods produce desired results for a set of predefined inputs. 𝗦𝘁𝗲𝗽 𝟮: Integration Tests - you test specific pieces of the code for ability to integrate with systems outside the boundaries of your code (e.g. databases) and between the pieces of the code itself. 𝗦𝘁𝗲𝗽 𝟯: Delivery - you deliver the produced artifact to a pre-prod or prod environment depending on which stage of GitFlow you are in. What does it look like when ML Training pipelines are involved? 𝗦𝘁𝗲𝗽 𝟭: Unit Tests - in mature MLOps setup the steps in ML Training pipeline should be contained in their own environments and Unit Testable separately as these are just pieces of code composed of methods and functions. 𝗦𝘁𝗲𝗽 𝟮: Integration Tests - you test if ML Training pipeline can successfully integrate with outside systems, this includes connecting to a Feature Store and extracting data from it, ability to hand over the ML Model artifact to the Model Registry, ability to log metadata to ML Metadata Store etc. This CI/CD step also includes testing the integration between each of the Machine Learning Training pipeline steps, e.g. does it succeed in passing validation data from training step to evaluation step. 𝗦𝘁𝗲𝗽 𝟯: Delivery - the pipeline is delivered to a pre-prod or prod environment depending on which stage of GitFlow you are in. If it is a production environment, the pipeline is ready to be used for Continuous Training. You can trigger the training or retraining of your ML Model ad-hoc, periodically or if the deployed model starts showing signs of Feature/Concept Drift. Let me know your thoughts. 👇
- 06
@_avichawla ·
DevOps vs. MLOps vs. LLMOps: Many teams are trying to apply DevOps practices to LLM apps. But DevOps, MLOps, and LLMOps solve fundamentally different problems. DevOps is software-centric. You write code, test it, and deploy it. The feedback loop is straightforward: Does the code work or not? MLOps is model-centric. Here, you're dealing with data drift, model decay, and continuous retraining. The code might be fine, but the model's performance can degrade over time because the world changes. LLMOps is foundation-model-centric. Here, you're typically not training models from scratch. Instead, you're selecting foundation models and then optimizing through three common paths: - Prompt Engineering - Context/RAG Setup - Fine-Tuning But here's what really separates LLMOps: The monitoring is completely different. In MLOps, you track data drift, model decay, and accuracy. In LLMOps, you're watching for: - Hallucination detection - Bias and toxicity - Token usage and cost - Human feedback loops This is because you can't just check if the output is "correct." You need to ensure it's safe, grounded, and cost-effective. The evaluation loop in LLMOps also feeds back into all three optimization paths simultaneously. Failed evals might mean you need better prompts, richer context, OR fine-tuning. So it's not a linear pipeline anymore. One more thing: prompt versioning and RAG pipelines are now first-class citizens in LLMOps, just like data versioning became essential in MLOps. And the ops layer you choose should match the system you're building. 👉 Over to you: What does your LLM monitoring stack look like right now? ____ Find me → @_avichawla Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.
Watch video
- 07
@arpit_bhayani ·
End-to-end tests do not work at scale, nor does staging infrastructure. Past a certain number of services, both turn into a liability, and a big one at that. It is nearly impossible to run a "company-in-a-box" environment at scale. Staging is meant to be a smaller, calmer copy of production. In practice, it becomes its own fragile system. A shared database, shared services, and everything around them all need to be up, on the right version, and in the right state at the same time. Running tests across services on top of that staging infrastructure is even more fragile. Test for service A now depends on service B being deployed, service C having the right data, and the staging database not being mid-migration because of someone else's change. One flaky service and the whole suite goes red, for a reason that has nothing to do with the code being tested. When that happens, nobody owns the failure, and it somehow becomes the responsibility of a central team (most likely DevOps, SRE, or Platform. Yesss... been in the same situation a decade ago). What works instead is each service owning its own tests and mocking the responses of the services it depends on. No shared staging database. No waiting on five other teams to deploy before you can run a single test suite. This gives you a clear separation of concerns. A service is responsible for its own contract and its own correctness, nothing more. Cross-service behavior gets verified through contract tests between two teams, not through a shared environment that everyone touches and no one owns. It also shifts accountability to the left because there is no one to blame. If a mock does not match reality, that is a contract problem between two teams, caught early by the team that owns the code. Fewer moving parts, less shared infrastructure to babysit. Somehow, every company struggles with, there is no end to this problem, and there is probably a billion-dollar business to be built solving it :) Hope this helps.
- 08
@goyalshaliniuk ·
Choosing the right deployment strategy can make or break the rollout of new microservices. This guide breaks down five popular deployment patterns every DevOps and backend engineer should understand: 1. Blue-Green Deployments Switch traffic between two identical environments (Blue and Green) to minimize downtime and risk. Great for seamless rollbacks. 2. Canary Releases Gradually expose new features to a small subset of users before full rollout. Monitor performance and catch issues early. 3. Feature Toggles Enable or disable features at runtime for specific user segments—without redeploying code. Ideal for staged rollouts and A/B testing. 4. Dark Launches Deploy features in production but keep them hidden from end users. Used for internal testing, performance tuning, and readiness checks. 5. A/B Testing Run controlled experiments by comparing two feature versions with different user groups. Use data to guide product decisions. Takeaway: These strategies help you ship fast, reduce risk, and gather real-world feedback—without breaking your production environment. Which strategy do you use the most?
Watch video
- 09
@twtayaan ·
The ultimate DevOps cheat sheet for your daily workflow: ➔ Foundations: Master CI/CD, IaC, and monitoring to build a solid DevOps culture. ➔ Git: Essential commands for version control, from initializing repos to pushing code. ➔ Docker: Quick reference for building images, running containers, and managing services. ➔ Kubernetes: Core kubectl commands to list pods, describe resources, and view logs. ➔ Terraform: The standard workflow for initializing projects and applying infrastructure changes. ➔ Multi-Cloud: CLI snippets for managing resources across AWS, Azure, and Google Cloud. ➔ Ansible: Simplified syntax for managing inventories and executing automation playbooks. ➔ Security: Critical best practices for secret management and rotating access keys.
- 10
@Njuchi_ ·
Entry-level hiring at big tech is down roughly 50% compared to pre-pandemic levels. Junior roles are getting absorbed into smaller, more senior teams. Here's my take 👇 The job market is really harder right now. If you've been applying and hearing nothing back — you're not imagining it. But it doesn't mean that the opportunity has disappeared. It has simply shifted. The reason companies are hiring fewer engineers, is NOT because they need less done. They're hiring fewer engineers because they need more from each one. The times of getting paid to tick off a task list are ending. What they actually need — and can't find enough of — are engineers who understand systems deeply, take ownership, and make real decisions. A quick note on DevOps specifically: DevOps is not an entry-level path. Most job postings implicitly target mid-level or senior people — because a strong DevOps skillset means you already understand software development, operations, cloud, K8s, CI/CD, and observability. In many companies, DevOps isn't even a separate role. It's just what a senior engineer looks like. Now about AI. Because I know everyone's thinking it. Nobody actually knows what it means for jobs in 5 years. Not me. Not the LinkedIn thought leaders. Not the tech CEOs doing podcast rounds about it. Both extremes are wrong: "AI will replace all engineers" — wrong. "AI won't affect engineering at all" — also wrong. The roles that are under real pressure the most are ones doing narrow, siloed work — low-context, repetitive. AI is very good at those tasks. Including some of the specific DevOps automation stuff actually. The engineers I believe aren't going anywhere? The ones who can connect code, infrastructure, security, and business outcomes. And who can look at what AI produces and say "that's wrong — here's why" or "that's correct - and here's why" So what do you actually do right now? Not this → wait and see how it all turns out. Not this → skip fundamentals and just learn AI tools, hoping that's enough. Both lead nowhere good. My honest take: Broaden your skillset. Understand how the full system works — not just your piece of it. Cloud, CI/CD, K8s, observability, security — these keep showing up in job postings for a reason. And here's something people keep forgetting: every AI model you use runs on infrastructure that needs to be deployed, scaled, and maintained — that's Cloud and DevOps. Don't learn these things just enough to copy-paste from a tutorial. Learn them properly, to the point where you can design, debug, and explain what's going on. And yes — learn AI tools too. 🟢 Powerful when you know what you're doing. 🔴 Dangerous shortcuts when you don't. The best thing you can do in an uncertain market is become more skilled than the people around you. But skill alone isn't enough anymore. You could be the best engineer in the room. If nobody knows you exist, it doesn't matter. Visibility is part of the job now. That's what LinkedIn is actually for — and it matters more than ever right now. Bottom line is: the door hasn't closed. But it became higher and more competitive. What's your take?
- 11
@_jaydeepkarale ·
DevOps in Plain English (Concept Edition): • Containerization (Docker, Podman) → Package apps with their dependencies • Orchestration (Kubernetes) → Keep containers running at scale • CI/CD (Jenkins, GitHub Actions) → Ship changes automatically • Infrastructure as Code (Terraform, CloudFormation) → Provision infra using code • Cloud Computing (AWS/Azure/GCP) → On-demand scalable infrastructure • Observability (Prometheus, Grafana, ELK) → See metrics, logs, traces • Reliability Engineering (SRE, SLOs) → Make uptime measurable
- 12
@mischavdburg ·
AI won't replace the DevOps engineer. AI will replace the DevOps engineer who only knows how to follow tutorials. 64% of people exploring a DevOps career change say AI job displacement is their #1 concern. But Kubernetes clusters don't prompt themselves into existence. Someone still has to design the networking, debug the CrashLoopBackOff mid-incident, and explain to the CTO why the architecture won't scale. The infrastructure layer is where AI runs. Not where AI replaces.
- 13
- 14
@ennycodes ·
How CI/CD pipelines work (explained in 2 mins or less): A CI/CD pipeline is an automated workflow that facilitates continuous integration (CI) and continuous delivery or deployment (CD) by managing code building, testing, and release processes. It integrates the various stages of the software development lifecycle (SDLC) into a seamless, repeatable process. These stages include source code management, automated testing, artifact creation, and deployment orchestration. Continuous ‘delivery’ and ‘deployment’ are sometimes used synonymously. But there is a clear and important distinction between the two. Delivery is about ensuring the software can be released at any time. It requires manual intervention to deploy to production. Deployment, on the other hand, does the release through automated workflows.
- 15
@Daviowhite ·
Pushed my First Commits last night These are the steps I followed 1. I started building in Google AI studio for the first time then faced a challenge with testing on my device 2. I downloaded the react codes to my device and created a repo in GitHub after chatting with macOS built in terminal 3. Making updates was slow so I got VS code to make it faster 4. Discovered it was better so I shutdown macOS terminal, created a new terminal inside vs code 5. Imported my project file folder into it and started making updates directly 6. Learned to pause and restart vite server using control C so I can push new build and test it 7. To test the app on my phone, I created an account with Vercel with my GitHub connected 8. Went back to terminal to test that all integrations are working including GitHub branch “main” and status 9. Pushed my first commit at 4AM, added the commit message, sync with terminal to allow build go through 10. It auto deployed in Vercel and was live on my localhost and phone with the Vercel url 11. I discovered copilot agent was in vs code so I tried it to make a small update to the bottom navigation since 50% of it was hiding behind the browser url Copilot completely moved the bottom navigation below the page 🥲 so I asked my buddy gpt for help 12. It taught me how to undo deployments using a set of codes including git reset —hard HEAD~1 git push —force These commands brought back my previous build but it didn’t push to Vercel so I updated the bottom navigation using “100dvh” instead of “100vh” 13. New commit was available now in Source control so I pushed and it was fixed Made some few adjustments turning the web app into a progressive web app on my phone so it can live as an app icon hiding web browser This process taught me a lot, I went from Hello World to a commit super fast My Complete Tool Stack Core Tech - React + TypeScript - Vite - Tailwind CSS Version Control & Deployment - Git (version control) - GitHub (repository + source control integration) - Vercel (CI/CD + auto deployment) Development Environment - VS Code AI / Assistance Tools - ChatGPT (architecture, debugging, guidance, decision support) - GitHub Copilot (inline code assistance) - Google AI Studio (experimentation, alternative code generation) My workflow - Develop locally - Commit changes - Push to GitHub - Auto-deploy via Vercel - Test on mobile - Iterate
- 16
- 17
@milan_milanovic ·
𝗔𝘇𝘂𝗿𝗲 𝗥𝗼𝗮𝗱𝗺𝗮𝗽 𝗳𝗼𝗿 𝗡𝗘𝗧 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 As a .NET Developer, you probably already know C#, ASP .NET, and other technologies, but in today's cloud-first world, knowing Microsoft Azure is essential for running and deploying your apps. This article provides a step-by-step roadmap for .NET developers who want to master Azure, from the basics to advanced DevOps and architecture. 1) Cloud Fundamentals Lay the foundation so nothing feels mysterious later • IaaS / PaaS / SaaS distinctions • Regions & Availability Zones • SLAs & cost basics 2) Azure Basics Learn how Azure is organized and controlled • Azure Portal, CLI & PowerShell • Microsoft Entra ID & RBAC (access control) • Resource groups & tags • Azure Policy fundamentals 3) .NET Compute + Hosting Deploy your services reliably • App Service (web app deployment patterns) • Azure Functions (triggers & bindings) • Containers fundamentals + Azure Container Registry • AKS basics (container orchestration) 4) Data Services Store and connect data with patterns that scale • Azure SQL + EF Core practices • Cosmos DB (multi-model, partitioning) • Blob & Queue Storage essentials • Service Bus & Event Grid (async/eventing) 5) DevOps & Automation Shift from manual to repeatable, safe workflows • GitHub Actions / Azure DevOps pipelines • Infrastructure as Code: Bicep (Terraform optional) • Automated builds, tests & gates • Deployment strategies (canary, blue/green) 6) Security & Identity Security isn’t optional once you’re live • Azure Key Vault & secret management • Managed identities for services • App security patterns & best practices 7) Observability & Ops Run it healthily in production, not just launch it • Application Insights (traces + metrics) • Log Analytics & KQL basics • Alerts + dashboards that teams use • Resilience patterns (retry, circuit breaker) 8) Architecture & Ops Make systems that tolerate stress and evolve • Scalability patterns (CQRS, event-driven, partitioning) • Microservices vs modular monolith thinking • Cost optimization in design decisions • Multi-region distribution fundamentals Cert milestones you can align with: AZ-900 → AZ-204 → AZ-400 → AZ-305 #dotnet #csharp #azure #cloud #devops
- 18
@manthanguptaa ·
Security has completely gone off the rails! And most might not even realize it, because if you look at just the last month, the number of serious incidents across the AI dev ecosystem is honestly insane. Axios, a package with over 100M weekly downloads, was allegedly hijacked and used to ship a RAT. LiteLLM, which sits deep inside many modern AI stacks, was backdoored on PyPI with a multi-stage credential harvester across ~97M monthly installs. Railway ended up leaking authenticated user data due to a CDN misconfiguration. There’s now a disclosure around command injection in OpenAI Codex via branch names, which should make anyone building agentic coding systems pause for a second. And it doesn’t stop there because Mercor AI allegedly had ~939GB of source code and ~4TB of total data exfiltrated! There are claims around Copilot injecting ads into 1.5M+ GitHub PRs without developer consent, and even the Claude Code source code has been leaked! If you zoom out instead of looking at these as isolated incidents, the pattern becomes very obvious. Core infrastructure packages are getting compromised, supply chains are being poisoned, CI/CD pipelines are being used as entry points, and even the systems that are supposed to guarantee trust are failing. We have effectively built an ecosystem where installing a dependency is equivalent to running arbitrary code, dependencies are just layers of transitive blind trust, and all of this is happening inside environments that are loaded with high-value secrets like cloud credentials, API keys, and production access, and then we casually stack hundreds of these dependencies without questioning it. The attack surface is no longer your application or your infrastructure, it’s your dependency graph, and that’s what makes this so dangerous because it scales insanely well for attackers. You don’t need to break into systems anymore, you just compromise one package, one maintainer, or one pipeline, and the blast radius takes care of itself. Focus on security!
- 19
@_jaydeepkarale ·
DevOps in Plain English • Docker → Package your app so it runs anywhere • Kubernetes → Keep containers running reliably at scale • CI/CD (Jenkins / GitHub Actions) → Ship changes safely & automatically • Terraform → Provision infrastructure using code • Cloud (AWS/Azure/GCP) → Run infra without owning hardware • Monitoring (Prometheus / Grafana / Logs / Traces) → Know when things break • SRE mindset → Measure reliability, reduce toil, automate everything • Security (IAM, secrets, policies) → Don’t get hacked while scaling Master these → you understand 80% of practical DevOps.
- 20
@_devEmmy ·
Day 36 of Coding – AI | Machine Learning 🚀 Hi guys, Today was mostly about preparing my FastAPI project for real-world deployment. I learned how to handle database migrations using Alembic, which allows me to automatically detect changes in my SQLAlchemy models and generate the proper database tables or updates without manually recreating the database. I also added CORS configuration and finally deployed the API on Render. Next up I’ll be diving deeper into the deployment side of things: • Setting up an Ubuntu server environment • Configuring NGINX • Connecting a custom domain • Setting up firewalls • Writing a Dockerfile • Running proper tests • Automating workflows with GitHub Actions And a lot more. Slowly moving from just building APIs to learning how to ship and run them in production. I’m also noticing that I’m picking up some DevOps knowledge, which will definitely help when I start deploying AI agents.
- 21
@0xlelouch_ ·
Top 10 practical DevOps resources (for working devs): 1) Google SRE Book (free online): SLOs, error budgets, incident response, and why toil kills teams. 2) The Phoenix Project: good mental model for flow, constraints, and why approvals and batching wreck delivery. 3) Kubernetes docs + kubebuilder tutorial: skip courses until you can read the upstream docs and ship a controller. 4) Terraform docs + a real module repo: learn state, drift, import, and how to not brick prod with a plan. 5) AWS Well-Architected Framework: concrete checklists for reliability, cost, security, and ops tradeoffs. 6) Linux Upskill Challenge: the unsexy stuff that pays off at 2am (systemd, networking, logs, disks). 7) Brendan Gregg’s blog (perf): flame graphs, CPU/memory/IO debugging, and how to stop guessing. 8) Grafana + Prometheus docs: build RED/USE dashboards, alerts that page for symptoms not causes. 9) GitHub Actions or GitLab CI docs: write a pipeline with caching, artifacts, env promotion, and rollback. 10) Practice project: build + ship a tiny service - Dockerfile, helm/kustomize - CI to deploy to a test cluster - metrics/logs/traces - chaos test: kill pods, drop DB, rotate secrets
- 22
@freeCodeCamp ·
Cloud-native .NET apps need more than just code: think automated builds, containerized deployments, and reliable release workflows. In this tutorial, Gopinath teaches you how to build Azure DevOps CI/CD pipelines for enterprise .NET apps using Docker, Kubernetes, and Azure Kubernetes Service. You'll learn about deployment stages, infrastructure as code, security checks, & lots more. https://t.co/h3DnfVNwIF
- 23
@0xlelouch_ ·
90% of DevOps in 2026 is still 10 boring concepts executed under pressure: 1) Linux + networking basics. DNS vs TCP timeouts, conntrack, MTU, and why it works on the node but not in the pod. 2) Containers are packaging, not isolation. Know cgroups limits, file descriptors, PID 1, and how OOMKill looks in metrics and logs. 3) Kubernetes primitives. Deployments/Jobs, probes, requests vs limits, PDBs, and how rollouts actually fail (and wedge). 4) CI/CD with safety rails. Small diffs, fast rollback, canaries, and stopping a bad deploy automatically instead of paging humans. 5) State and data ownership. Backups you have restored, schema migrations with rollback plans, and the cost of cross-region replication. 6) Incident response as a system. Clear severity, runbooks that match reality, and postmortems that fix triggers not people. 7) Observability you can query. RED/USE, high-cardinality tradeoffs, traces for async hops, and sampling that doesn’t hide the bad tail. 8) Debugging production. Reproduce with real inputs, diff configs, check last change, and avoid SSH-driven fixes that never land in git. 9) Security as defaults. Least-privilege IAM, secret rotation, SBOMs, patch windows, and blocking outbound egress until needed. 10) Cost and capacity tradeoffs. Right-size, autoscale with guardrails, know p95 vs p99, and don’t confuse load tests with steady state traffic.
- 24
@zavxai ·
Everyone wants to become a Software Engineer. Very few are talking about Platform Engineering. But every fast-growing engineering team eventually needs a platform that helps developers build, test, deploy, and scale software efficiently. If I were starting in 2026, this is the roadmap I’d follow: 1.Learn Linux, networking, and Git. 2.Master Docker and Kubernetes. 3.Learn cloud platforms like AWS, GCP, or Azure. 4.Understand Infrastructure as Code with Terraform. https://t.co/qkLetEEN51 CI/CD pipelines using GitHub Actions or GitLab CI. 6.Learn observability with Prometheus, Grafana, and OpenTelemetry. 7.Understand service meshes, API gateways, and microservices. 8.Learn scripting with Python, Go, or Bash. https://t.co/rmG6tL4CXL security fundamentals, secrets management, and IAM. https://t.co/8mKKEgw7vF internal developer platforms and automate repetitive workflows. Your portfolio should include: • A Kubernetes deployment from scratch. • A complete CI/CD pipeline. • Infrastructure managed with Terraform. • A monitoring dashboard with Prometheus and Grafana. • A self-service developer platform or deployment portal. Platform Engineers don’t just keep servers running. They build the infrastructure, tooling, and automation that enable developers to ship software faster, more reliably, and at scale. As engineering organizations continue to grow, Platform Engineering is becoming one of the most valuable and high-impact careers in software.
- 25
@Hartdrawss ·
This reddit engineer's company got HACKED in <1 week here's what they missed ( the mistake was not the code ) : 1/ they shipped before owning the release > first basic version was ready to deploy > another dev handled it like routine work > founder believed vibe coding was “good” > nobody treated release as a risk point 2/ the exploit was sitting in plain sight > AI chose Next 16.0.0 > critical CVEs were already reported > the issue was raised, then ignored > server got hacked a week later 3/ “only staging” still cost them > staging used production credentials > less important services still had real keys > team had to rotate keys after damage > weak environments create real blast radius 4/ the actual failure was ownership > vibe coding wasnt the full problem > no one owned patching before deploy > no one owned security after warning > no one owned the deployment pipeline 5/ every founder needs this launch rule > check framework versions before deploy > separate staging and production secrets > assign one person release responsibility > patch known CVEs before users arrive the real takeaway: > fast builds still need slow checks > staging still needs real discipline > AI output still needs one owner vibe coding gives you speed. it doesnt give you responsibility.
- 26
@_devEmmy ·
Day 37 of Coding – AI | Machine Learning 🚀 Hi guys, Just wrapped up Day 37. I was on seat for about 8 hours today working on deploying my FastAPI application on a real server. I walked through the full deployment pipeline on an AWS EC2 server running Ubuntu, which helped me understand what actually happens when you move a backend app from local development to the internet. I worked with nano to edit server configs, set up NGINX as a reverse proxy to forward traffic from port 80 to my FastAPI app on port 8000, and ran the app using Gunicorn with Uvicorn workers for production. I also created a systemd service so the app runs in the background and restarts automatically if the server reboots. Along the way I practiced debugging with logs and testing configs using nginx -t, which helped me catch and fix configuration errors. So the deployment flow now makes a lot more sense to me: Browser → NGINX → Gunicorn → FastAPI It’s interesting realizing this is the same pattern many real backend services use in production.
- 27
@Techjunkie_Aman ·
Most people think Docker is complicated. It’s not. You’re just missing the point. Docker: • Packages your app + dependencies • Runs the same everywhere • Lightweight vs VMs • No “works on my machine” Think: Portable app box 📦 Why devs rely on it: • Faster setup (no manual installs) • Consistent environments • Easy testing (prod = local) • One-command deployment Core pieces: • Image → blueprint (layered, reusable) • Container → running instance • Dockerfile → build instructions Power features: • Docker Compose (multi-container apps) • Volumes (persistent data) • Networks (service communication) • Registries (share images) • BuildKit (faster builds) Infra benefits: • Works on local, cloud, CI/CD • Easy scaling (spin up/down) • Better resource usage • Isolation without heavy VMs Docker = dev → test → deploy Same environment. Zero surprises.
Watch video
- 28
@DivyanshT91162 ·
Your AI coding agent won't help much when production goes down at 3 AM. OpenSRE is building AI agents for the problems that start after the code ships. It investigates incidents across logs, metrics, traces, cloud infrastructure, runbooks, and incident platforms to find the actual root cause instead of throwing guesses at the wall. The interesting part? They're not just building an agent. They're building the benchmark, training environment, and failure simulations needed to make AI SRE agents better over time. Think SWE-Bench for infrastructure incidents. 60+ integrations already supported, including Kubernetes, AWS, Datadog, Grafana, CloudWatch, PostgreSQL, Kafka, PagerDuty, Slack, OpenAI, Anthropic, Gemini, Ollama, and more. One of the more ambitious open-source AI infrastructure projects I've seen recently. Repo: https://t.co/h3YlfA6Pzk
- 29
@uday_devops ·
Cloud Engineer != DevOps Engineer📚 Let me clear this up once and for all. They're not interchangeable roles, no matter what those job descriptions tell you. Cloud Engineers own: ✔️Cloud infrastructure architecture, maintenance, Resource provisioning and management ✔️Migrations to cloud environments ✔️Security & Network Implementation ✔️Cost optimization strategies ✔️AI/ML infrastructure setup and scaling ✔️Managing GPU resources for AI workloads and more, depending on your cloud stack and niche DevOps Engineers drive: ✔️Development workflow optimization ✔️CI/CD pipelines and Infrastructure as Code (IaC) ✔️Deployment automation ✔️Breaking down dev–ops silos ✔️Monitoring, alerting, and logging ✔️Automating ML model deployment pipelines (MLOps) ✔️Building CI/CD for AI/ML experimentation and production Here's the interesting part: Modern cloud platforms are built with DevOps in mind. Think AWS CodePipeline, Azure DevOps, or Google Cloud Build ~ they're all devops services in the cloud.
- 30
@anuraggoel ·
The best infrastructure shifts happen when a new application pattern breaks old assumptions. Agents are breaking a lot of them. They still need the basics: CI/CD, databases, caches, networking, previews, autoscaling, and IaC. But they also need isolated compute, long-running execution, disk-as-memory, and stateful workflow orchestration. Let's make agents boring to ship.
- 31
- 32
@brankopetric00 ·
I've watched a lot of people prep for DevOps interviews over 2 years of sharing free content. Most of them prep for the wrong exam. They grind commands and trivia. But interviewers are not testing your memory. They're testing one thing: Can you reason under pressure when there is no clean answer? Here's what they actually poke at: 1. Do you jump to a fix, or diagnose first? 2. Can you name the tradeoff you're accepting, out loud? 3. When I push back, do you cave, or defend with logic? 4. Do you know when the "best practice" is wrong for this context? 5. Can you separate "stop the bleeding" from "fix the root cause"? None of that is on a flashcard. You build it by making real calls and getting challenged on them. Repeatedly. Until defending your reasoning feels natural. That's the difference between someone who read about incidents, and someone you'd actually want on call. Be the second one.
- 33
@ankit_ops2799 ·
If your CI/CD pipeline takes more than 15 minutes to run, your developers aren't building software. They're context-switching into oblivion waiting for a green checkmark. Slow feedback loops are the hidden productivity killer in modern engineering teams. Here's how to shrink build and test times from 20+ minutes down to under 3. 1. Cache your dependency layers aggressively: Stop re-downloading the same packages on every single run. Build and application layers should be cached separately, so a code change doesn't force a full dependency reinstall every time. 2. Parallelize your test suites: Running thousands of unit tests sequentially is an anti-pattern. Split them across parallel jobs instead of grinding through everything on one runner. 3. Spin up ephemeral test environments per PR: Don't queue pipelines waiting on a shared staging environment everyone's fighting over. Isolated environments created on-demand and destroyed after the PR closes remove that bottleneck entirely. 4. Move off resource-constrained default runners: Auto-scaling, properly resourced runner pools finish the same job in a fraction of the time. Fast CI/CD isn't a luxury. It's the difference between shipping 10 times a day or twice a week.
- 34
- 35
@hamidships ·
the real "software factory" isn’t everyone using coding agents. that’s the 2x. the 10x is a different thing entirely. the loop starts closing on its own. 2x = every engineer using agents, ~100% AI-generated code. soon, that’ll be table stakes. you made the same loop faster, but the bottleneck is still human attention at every gate. 10x = the loop self validates. agents stop waiting on you. but it only works if the scaffolding is real: comprehensive CI, evals that actually catch regressions, and end-to-end test environments agents spin up to check their own work. to be clear, 10x is not "fewer humans." it is humans on the decisions that carry real risk and off the rote gates. we still need to hire exceptional engineers, their judgment is the scarce input now, so you spend it where it actually counts. but here is what breaks traditional SaaS instincts: building agents is divergent. fix one thing and 10 new things need evaluating. converging on that locally is a trap. so ship the 80/20 fast, but through controlled early access: opt-in design partners, clear guardrails, tiered rollout. never unfinished work dumped on people who did not sign up for it. then close the loop. feedback-loop agents take that signal, implement it, merge it, validate post-deploy, continuously. and because CI/CD is fast, the gap between "customer said X" and "X is live and validated" collapses. coding at the speed of thought. give agents the same context a human uses to make the call, user feedback, docs, prod monitoring, ephemeral test clusters. encode your review standards as rules the reviewer agent reads. auto-merge the low-risk stuff classified by your reviewer agent. reserve human eyes for billing, auth, the paths where a mistake is expensive. humans do not disappear, they concentrate. incidents stay human-led, business impact's too high to hand off, though agents now dig datadog + telemetry + code and hand you impact + root cause + mitigation in minutes. and someone guards the critical paths: as agentic volume climbs you risk losing deep understanding of your own codebase. the fix isn't to slow down — it is to lock down what's expensive to get wrong. Not all code carries equal risk. at Ramp, this is Inspect, our internal coding agent: deep Ramp context, MCP integrations, CI visibility, and self-validation that boots the UI and tests real workflows. On a recent UI change, it deployed a preview, authenticated as a fixture user, validated desktop and mobile behavior, and attached visual evidence to the PR. the metric I actually care about: fewest human touches per safely merged PR. not lines, not PR count. how much can the loop close on its own without breaking the things that matter and do it super fast? that's the edge.
- 36
@Njuchi_ ·
10 years of infrastructure management evolution, explained in 25 minutes 👇 Every engineer who's managed cloud infrastructure has hit the same wall at some point. They set up production. It works. Then they need to recreate the same setup for staging — and suddenly realize they can't remember exactly what they configured, in what order, with what settings. Because they clicked through it manually and there's no record. That moment is where most engineers realize: there has to be a better way. And there is. But it's not just "stop using the console, use IaC." There's a whole journey in between — 5 stages that most people either rush through or skip entirely. And 𝗲𝗮𝗰𝗵 𝘀𝘁𝗮𝗴𝗲 𝘁𝗲𝗮𝗰𝗵𝗲𝘀 𝘆𝗼𝘂 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘁𝗵𝗲 𝗻𝗲𝘅𝘁 𝗼𝗻𝗲 𝗮𝘀𝘀𝘂𝗺𝗲𝘀 you already know. In our new tutorial video, I walk through all 5: Console → CLI & Scripts → Infrastructure as Code → GitOps → AI-Assisted 10 years of infrastructure management evolution, explained in 25 minutes 🚀 Watch here: https://t.co/F9bvQ31QEY The part most people skip is understanding 𝒘𝒉𝒚 each stage exists — what specific pain it solves. Because if you don't feel the pain of manual scripts, you won't truly understand why Terraform's state management is such a big deal. And if you don't understand IaC, AI generating Terraform code for you is actually dangerous. 💬 Which stage are you at right now?
- 37
@TosinOlugbenga ·
I just moved a production app off an online AI builder onto full local dev. Clone → configure → full stack running on any machine. Hosted builders are great for MVPs. Serious products need local-first. Why local matters If your app only runs in a hosted builder, you don't own your workflow.Local dev = faster loops, real debugging, reproducible envs, and confidence you're not shipping environment magic. The boring work The unglamorous migration work that actually pays off:• Docker Compose for one-command stack • Pinned tooling so builds don't drift • Split env files by concern • One onboarding doc, not five READMEsBoring = reliable. CI/CD angle Local working is step 1.Step 2: every PR gated, branch flow develop → staging → prod, images via GitHub Actions, DB migrations manual + confirmed.DevOps isn't flashy. It's how you ship without praying. Hot take Online AI building tools are brilliant for prototyping.But "works in the builder" ≠ "works for the team."Invest early in local-first + pipeline-first, or pay later. Punchy Moved off a hosted AI builder this week.Full stack runs locally. CI/CD owns deploy. No platform lock-in.Worth the migration pain.
- 38
@tristanbob ·
Software developers, how many of you perform security stages in your CI/CD pipeline, including secret leak detection, static application security testing (SAST), and dependency vulnerability scanning? My guess is that indie devs don't do these steps and enterprise does... but I'm not sure. (They are quite easy to add, FYI. It seems like a no-brainer, the only downside is the increased cost of runners)
- 39
@lucamezzalira ·
The most expensive belief in our industry is that a new architecture will fix the rest of the company. Unless you also decentralise the decision making, reassess who owns what, and rethink the team boundaries, the architecture will start raising friction instead of removing it. Pipelines slow down, deployments need coordination across three teams, bundle sizes creep up. The blame goes to the architecture when the architecture is just doing its job, which is surfacing the fact that something deeper isn't working. Most of the time it's not a tech problem at all. It's how communication flows inside the teams, it's the engineering culture, it's the org chart. The architecture is the messenger. This is the triangle I always come back to when I design distributed systems: architecture, organisational structure, and engineering culture, all three linked together. You cannot pull on one and ignore the other two and expect the system to work. At @ReactAdvanced in November I sat down to talk through all of this, plus the Tokyo flight that led to the first micro-frontend PoC at @DAZN, the 25-deployments-a-day teams I worked with, and why a CI/CD pipeline taking more than 15 minutes should stop everything else in the team until it's fixed. Check it out: https://t.co/DlYssTs7FJ
- 40
@HotAisle ·
i noticed today that our github actions usage over the last month cost us a whopping $0.88 to build our software. so, i decided to move it in-house onto an actions runner. setting this up properly is a pain because you really need to build your own isolation. for safety, your builds should run in ephemeral VMs, similar to how github actions works. i used Codex to build the whole thing for me. it gave me step-by-step instructions for setting up the GH App and private key, wrote the shell scripts, configured the systemd units, then debugged everything over ssh directly on the server. what would have taken me hours or days, along with filling my brain with a bunch of esoteric devops knowledge that i really don't care about, was done in under 30 minutes. now we have two idle runners. one takes a build job, runs it, then dies and gets reaped. the second takes over while the first resets. my mind is blown. if you're not all in on AI, i feel for you.
- 41
@_vmlops ·
GOOGLE ENGINEERS WERE TIRED OF WRITING BASH so they built a tool that changed how developers script forever every developer has been there you start with a "simple" bash script 20 lines in, you're googling how to split a string 40 lines in, you're debugging why a variable has a space in it 60 lines in, you've rage-quit and called a python script from inside bash bash is powerful bash is also a special kind of torture → no JSON support → array handling that makes you question your career choices → error handling that silently fails and takes your sanity with it → string escaping that requires a computer science degree to understand google engineers felt this too so someone just... snapped. and built zx the idea was simple: what if you could write shell scripts in javascript...? that's it... real shell commands... real javascript... no glue code → async/await built in → full npm ecosystem access → try/catch for error handling like a normal human → JSON parsing without crying devops engineers, platform teams, and solo devs all said the same thing at the same time: "finally." the repo is google/zx. still actively maintained. still saving developers from bash-induced breakdowns daily the best tools aren't invented... they're born from frustration https://t.co/CETjGtIA8o
- 42
- 43
@Lockhead ·
Infrastructure-as-Code meets the AI Agent era 🚀 If you're serious about deploying GenAI agent workflows in production, you need more than just a model — you need a robust infrastructure layer. That's exactly what AWS AgentCore delivers, and in this video, Tarlan (AWS Community Builder & DevOps/AI professional from Baku) shows you how to automate the entire stack with Terraform. 🏗️ Here's what the architecture looks like: 1️⃣ AgentCore Runtime — Handles the execution environment for your agents 2️⃣ AgentCore Memory — Enables agents to retain and recall context across sessions 3️⃣ AgentCore Gateway — Manages how agents communicate internally and externally 4️⃣ AgentCore Identity — Enforces who agents are and what they're allowed to do Combine all four with Terraform automation and you have a repeatable, scalable, production-ready GenAI agent platform. This is the kind of end-to-end technical walkthrough that bridges the gap between AI experimentation and real production deployments. 🎬 Watch the full session: https://t.co/3oYMI62iXs #Terraform #AWS #AgentCore #InfrastructureAsCode #GenAI #MLOps #DevOps #CloudEngineering #AIInfrastructure
- 44
@HotAisle ·
I used AI to build this awesome self-hosted ephemeral GH runner solution on one of our extra servers. Crazy enough, as a test, I let Codex run remotely with ssh/sudo access (through Zed!). I gave specific instructions to ask for permission when it needed to do anything destructive or write data. That part worked flawlessly. The implementation wasn't perfect out the gate. I've tuned it over time. For example, AI missed some of the cleanup tasks that need to happen, but it was also no big deal to prompt it to fix things. Again, running amok as root. I baked all of our tooling (golang, etc...) into the base VM image, so that it just grabs the source and everything is already installed and ready to go. There is an AI generated 7400 line bash script that will rebuild the image with whatever versions we want. Cut our build times in half. Every build is done in a fresh VM, just like GH does. The script keeps 2 VM's running at all times and cleans up after itself, including telling GH to updates its state as well. It even keeps the GH App Access token refreshed. I'd love to document it as a blog post, but I can't figure out the best way to do that. It is kind of a gnarly set up with several bash scripts. I doubt anyone would read this and think to themselves: "Yea, I'll get right on that." Probably the best takeaway is that AI is really good at this stuff now and don't be afraid to try it. Something that would have taken expert devops a week+ of effort, is now minutes. Give it a try.
- 45
- 46
@chrsaravia ·
Day 40 of building Sara, my personal AI agent. "Sara, take the HTML file we built yesterday, add a draggable tennis ball that moves the ASCII art, push it to production. Add something to track visit analytics." This is where things start getting interesting. Not because of any single tool, but because multiple capabilities are compounding together. First, Sara taking on the coder role... She picked up yesterday's pretext project (from Day 39 post, shoutout to @_chenglou) and kept building. The page is a single HTML file with zero frameworks. "SARA" is rendered in ASCII characters on a canvas, each one flickering through a color wave. She drew a tennis ball entirely with canvas APIs (no image file), added gravity and bounce physics, and built a water-like effect where dragging the ball through the text displaces the characters and they spring back like a finger through water. All running Codex on my Mac Mini while I gave feedback over Telegram from my phone. Then, Sara the DevOps engineer... After my Day 38 post about Stripe Projects, @jeff_weinstein from Stripe's Product team replied on X and got me early access (thx jeff!)... I pointed Sara at the docs and told her to figure it out. She ran: → stripe projects init → stripe projects link vercel → stripe projects add posthog/analytics Linking my existing Stripe and Vercel accounts was straightforward. But that last command is the one worth paying attention to. I didn't have a PostHog account. Sara ran one command and Stripe Projects created the account from scratch, provisioned a project, and injected the environment variables into .env automatically. No signup form. No dashboard. No copy-paste. She added the analytics snippet, deployed to Vercel, and it was live. I opened PostHog and watched my own pageview events arrive in real time. Try it → https://t.co/yFDZ7G8vjh (drag the tennis ball through the text, or drop it and watch it bounce... silly project but useful to show the capabilities) One agent. One conversation. Code, infrastructure, deployment, analytics. All done by Sara, my ai agent. I'm convinced this is the future of how software gets built. Not just AI writing code, but AI provisioning the infrastructure the code needs to run. Hosting, analytics, databases, authentication... in this example, @stripe Projects makes all of it programmable from the command line. When infrastructure is programmable, agents can own the full loop from code to prod... Tiny bumps along the way still (some of these tools are in developer preview), but directionally this is where I see everything is heading... The human says what they want. The agent either builds it or picks the best provider for the job (e.g. vercel, posthog, yalo), sets it up, ships it, and tracks it. Exciting times...
Watch video
- 47
@alexanderOpalic ·
Everyone's asking which jobs AI will replace. Wrong question. The real shift isn't roles disappearing. It's roles merging, and the unit of accountability getting bigger per person. The teams that win will look like startups inside big companies. Fewer people, each owning more of the value chain end to end. Here's how I think it plays out. Most roles will either merge or become obsolete. Take business development and design. A designer will use agents to implement features directly, and the business person will do the same from their side. The handoffs that used to separate these roles start to disappear when anyone can turn intent into a working feature. Developers shift too. Less time writing every line by hand, more time managing the codebase, setting guardrails, and making sure the agents are actually doing the right thing. They'll still build their own features, but babysitting the agents becomes part of the job. Scrum is where I expect the biggest break. All the scrum related roles will fade out. Scrum was built for a world where humans had to write code by hand and coordinate every step. That world is ending. The coordination problem doesn't vanish, but it gets so much lighter that the heavy ceremony around it stops earning its keep. We need a new framework, not a faster version of the old one. So what stays fixed while everything else consolidates? Two things: security and devops. Not because AI can't touch them, but because they're where accountability concentrates. When agents write most of the code, the scarce skill becomes verifying, constraining, and securing what gets shipped. These roles don't shrink. They become the platform that everything else stands on. That's the shape I see coming. Small autonomous teams that operate like startups, each owning a slice of the product, supported by a platform team of security and devops that keeps the whole thing safe and running. Two questions I keep coming back to. How do you think roles will actually change as this lands? And would you still tell someone to start their career as a scrum master today?
- 48
- 49
- 50
Best Tweets by Topic