<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Safiya</title>
    <description>The latest articles on DEV Community by Safiya (@safiya_k).</description>
    <link>https://dev.to/safiya_k</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2940041%2F9ea5441c-f8af-424f-afd0-9219868bc0e1.png</url>
      <title>DEV Community: Safiya</title>
      <link>https://dev.to/safiya_k</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/safiya_k"/>
    <language>en</language>
    <item>
      <title>Bringing AI into AWS Developer and CI/CD Tooling : A Practical View</title>
      <dc:creator>Safiya</dc:creator>
      <pubDate>Tue, 23 Dec 2025 00:44:43 +0000</pubDate>
      <link>https://dev.to/aws-builders/bringing-ai-into-aws-developer-and-cicd-tooling-a-practical-view-1kje</link>
      <guid>https://dev.to/aws-builders/bringing-ai-into-aws-developer-and-cicd-tooling-a-practical-view-1kje</guid>
      <description>&lt;p&gt;Over the last year, the most meaningful changes I’ve seen in AWS development workflows have not come from new pipeline services or shiny dashboards. They have come from quietly introducing AI into places where engineers already make decisions.&lt;/p&gt;

&lt;p&gt;Not as a replacement for judgement, but as a second set of eyes that never gets tired.&lt;/p&gt;

&lt;p&gt;For AWS teams running real workloads, this distinction matters.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;AI Works Best at Decision Boundaries&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;In most AWS setups, CI/CD pipelines are already well defined. Source control triggers a pipeline.Builds run.Tests execute. Infrastructure gets deployed.&lt;/p&gt;

&lt;p&gt;AI does not need to run the pipeline. It needs to sit at the boundaries where engineers ask questions.&lt;/p&gt;

&lt;p&gt;Questions like:&lt;br&gt;
    • Is this change safe?&lt;br&gt;
    • Have we broken this before?&lt;br&gt;
    • Are we about to ship something we will regret tomorrow?&lt;/p&gt;

&lt;p&gt;Those questions appear repeatedly in CodeBuild logs, pull request comments, and deployment approvals. That is where AI fits naturally.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Using AI in AWS Build Pipelines Without Losing Control&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;In AWS-native pipelines, CodeBuild is often the most flexible insertion point.&lt;/p&gt;

&lt;p&gt;Instead of adding yet another static check, AI can be used to:&lt;br&gt;
    • Review code changes with awareness of the repository’s history&lt;br&gt;
    • Highlight risky patterns that passed unit tests but failed in the past&lt;br&gt;
    • Explain failures in plain language rather than raw logs&lt;/p&gt;

&lt;p&gt;The key is visibility. Outputs should appear in build logs or as pull request feedback. Engineers should be able to agree or disagree with the recommendation.&lt;/p&gt;

&lt;p&gt;When AI becomes silent or authoritative too early, trust is lost.&lt;/p&gt;

&lt;p&gt;Infrastructure Reviews That Understand Context&lt;/p&gt;

&lt;p&gt;Infrastructure as code is where many AWS outages quietly begin.&lt;/p&gt;

&lt;p&gt;Traditional tools are good at rule enforcement. They struggle with intent.&lt;/p&gt;

&lt;p&gt;AI-assisted reviews can look at CloudFormation or Terraform changes and ask:&lt;br&gt;
    • Is this change unusual for this environment?&lt;br&gt;
    • Does it affect stateful resources during peak traffic?&lt;br&gt;
    • Have similar changes caused rollbacks before?&lt;/p&gt;

&lt;p&gt;This is not about replacing linting or policy-as-code. It is about adding context that static tools do not have.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Security Signals That Engineers Can Act On&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;AWS already provides strong security services. The challenge is not detection. It is prioritisation.&lt;/p&gt;

&lt;p&gt;When AI analyses findings from services like Inspector or Guard Duty, it can:&lt;br&gt;
    • Reduce duplicate or low-impact alerts&lt;br&gt;
    • Connect vulnerabilities to actual deployed services&lt;br&gt;
    • Surface risks in terms engineers understand, not just CVE scores&lt;/p&gt;

&lt;p&gt;When these insights are pushed into the pipeline, security stops being something teams “deal with later”.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Learning from Production, Not Just Testing&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The most interesting shift happens when CI/CD starts learning from runtime data.&lt;/p&gt;

</description>
      <category>devops</category>
      <category>cicd</category>
      <category>ai</category>
      <category>aws</category>
    </item>
    <item>
      <title>DevOps Engineer vs SRE Engineer</title>
      <dc:creator>Safiya</dc:creator>
      <pubDate>Wed, 02 Jul 2025 21:45:40 +0000</pubDate>
      <link>https://dev.to/safiya_k/devops-engineer-vs-sre-engineer-3mc5</link>
      <guid>https://dev.to/safiya_k/devops-engineer-vs-sre-engineer-3mc5</guid>
      <description>&lt;p&gt;The purpose of this article is to provide insight into both the distinctions and the similarities among the five prominent positions in modern technology companies: dev operations engineer (DevOps engineer), and SRE (site reliability engineer). Although these positions have a similar goal of creating dependable and effective systems, their main areas of responsibility, skill sets, and concentration are distinct from one another. Comprehending these subtle differences is essential for both job seekers and companies looking at recruiting productive engineering teams.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;DevOps Engineer&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Objective: Streamlining the software delivery lifecycle by bridging the gap between development and operations. &lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;Responsibilities:&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Automation: Employing CI/CD pipelines to automate the build, test, and deployment processes.&lt;/p&gt;

&lt;p&gt;Collaboration: Promoting communication and collaboration throughout operations, development, and other teams.&lt;/p&gt;

&lt;p&gt;Infrastructure as Code (IaC): Managing of infrastructure through code using tools like Terraform or CloudFormation.&lt;/p&gt;

&lt;p&gt;Monitoring and Logging: To continuously track the operational effectiveness of applications and infrastructure, monitoring and logging solutions should be put into place.&lt;/p&gt;

&lt;p&gt;Configuration Management: Management of system configurations using tools like Ansible, Chef, or Puppet.&lt;/p&gt;

&lt;p&gt;Culture: Encouraging a DevOps culture of shared responsibility, continuous improvement, and automation. &lt;/p&gt;

&lt;p&gt;Skills:&lt;/p&gt;

&lt;p&gt;Scripting (Python, Bash, etc.)&lt;br&gt;
CI/CD tools (Jenkins, GitLab CI, CircleCI)&lt;br&gt;
Containerization (Docker, Kubernetes)&lt;br&gt;
Configuration management tools (Ansible, Chef, Puppet)&lt;br&gt;
Cloud platforms (AWS, Azure, GCP)&lt;br&gt;
Monitoring tools (Prometheus, Grafana, ELK stack)&lt;br&gt;
Version control (Git)&lt;br&gt;
Strong communication and collaboration skills&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Unique Selling Point:&lt;/strong&gt; DevOps engineers are generalists who emphasize on the culture of DevOps and the software delivery pipeline as a whole. They are responsible for putting in place and keeping up the procedures and instruments that allow for continuous delivery and integration.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;SRE (Site Reliability Engineer)&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;u&gt;Objective&lt;/u&gt;: Assuring the performance, availability, and reliability of services and systems.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;Responsibilities:&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Service Level Objectives (SLOs): Establishing and tracking (SLOs) is a way of evaluating service trustworthiness. &lt;/p&gt;

&lt;p&gt;Incident Management: Responding to incidents, fixing problems, and establishing preventative measures into effect.&lt;/p&gt;

&lt;p&gt;Automation: The method of automating tasks to boost reliability and minimize manual labor.&lt;/p&gt;

&lt;p&gt;Capacity Planning: The procedure of estimating capacity requirements while making sure there are sufficient resources available.&lt;/p&gt;

&lt;p&gt;Performance Optimization: The identification and resolution of performance bottlenecks.&lt;/p&gt;

&lt;p&gt;Monitoring and Alerting: In order to detect and fix problems early on, strong monitoring and alerting systems should be put in place. &lt;/p&gt;

&lt;p&gt;Postmortems: Are carried out to investigate incidents and determine areas that require improvement.&lt;/p&gt;

&lt;p&gt;Skills:&lt;/p&gt;

&lt;p&gt;Strong programming skills (Python, Go, etc.)&lt;br&gt;
System administration (Linux, Windows)&lt;br&gt;
Networking&lt;br&gt;
Cloud platforms (AWS, Azure, GCP)&lt;br&gt;
Monitoring tools (Prometheus, Grafana, ELK stack)&lt;br&gt;
Incident management tools (PagerDuty, Opsgenie)&lt;br&gt;
Troubleshooting and problem-solving skills&lt;br&gt;
Understanding of distributed systems&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Unique Selling Point&lt;/strong&gt;: The operational attributes of performance and reliability are the primary objective of SREs. They automate active chores, keep an eye on the health of the system, and address incidents utilizing the principles of software engineering. They serve an important role in establishing and accomplishing SLOs.&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
