DEV Community: Nachiket Joshi

Agentic Engineering #0: Beyond Chat – The Foundation of Agentic Engineering

Nachiket Joshi — Wed, 15 Jul 2026 01:11:11 +0000

Welcome to Agentic Engineering — a series exploring how AI agents are transforming modern software engineering by automating repetitive workflows, orchestrating developer tools, and allowing engineers to focus on solving meaningful problems.

Why Another AI Series?

Over the past few years, Artificial Intelligence has rapidly become part of every software engineer's daily workflow.

We ask ChatGPT to explain unfamiliar code, rely on GitHub Copilot to autocomplete functions, generate unit tests with Claude, and summarize documentation using Gemini. These tools have fundamentally changed how we write software, and there's no doubt they have made us more productive.

But after months of using these tools, I noticed something interesting.

Most of my interactions still looked like this:

Copy some code.
Paste it into an LLM.
Explain the repository.
Provide business context.
Ask a question.
Copy the answer back into my IDE.

The AI wasn't doing my work.

I was doing all the work required to let the AI help me.

That realization led me to a much bigger question.

What if the AI could gather the context itself?

That question became the starting point for this series.

What Is Agentic Engineering?

Agentic Engineering is the practice of building intelligent software systems that can understand engineering workflows, gather their own context, interact with developer tools, make decisions, and execute meaningful tasks with minimal human intervention.

Instead of asking an AI to answer isolated questions, we give it an objective.

Rather than saying:

"Review this pull request."

We simply say:

"Review every open pull request assigned to Team Alpha."

The agent figures out the rest.

It discovers the pull requests, retrieves the code changes, understands the associated Jira stories, gathers the acceptance criteria, invokes the appropriate reasoning model, and produces a structured review.

The engineer no longer acts as the bridge between every tool.

The agent becomes that bridge.

Automation Has Been Around for Decades

At this point, it's fair to ask:

"Haven't we been automating software engineering for years?"

Absolutely.

Software engineering has always relied on automation.
Build servers compile our applications.
CI/CD pipelines deploy our services.
GitHub Actions execute workflows.
Scripts automate repetitive commands.
Infrastructure as Code provisions cloud environments.

So what makes AI agents different? The answer lies in how decisions are made. Traditional automation follows predefined instructions.

Agents pursue goals.

Understanding the Evolution of Automation

Let's look at how software engineering automation has evolved.

Scripts

Scripts are the simplest form of automation.

They execute a fixed sequence of commands.

Install dependencies

    ↓

Run tests

    ↓

Deploy application

Scripts are fast and predictable, but they only perform exactly what the developer programmed them to do.

There is no reasoning.

CI/CD Pipelines

CI/CD systems extend this idea.

They orchestrate multiple automation steps in response to predefined events.

Push Code

   ↓

Build

   ↓

Run Tests

   ↓

Deploy

Pipelines automate delivery extremely well. However, every possible path must still be explicitly defined.

The pipeline never asks:

"Should I perform another security scan?"

It simply follows instructions.

GitHub Actions

GitHub Actions introduced event-driven automation.

A pull request opens.

      ↓

A workflow starts.

      ↓

Tests execute.

      ↓

Comments are posted.

      ↓

Artifacts are published.

Although tremendously powerful, GitHub Actions remain deterministic. Every workflow is authored in advance.

If a new situation appears that wasn't anticipated, the workflow stops.

Robotic Process Automation (RPA)

RPA brought automation into business processes.

Bots imitate human interactions.

      ↓

They click buttons.

      ↓

Fill forms.

      ↓

Move files.

      ↓

Read spreadsheets.

This eliminated countless repetitive business tasks. Yet the automation still followed carefully scripted behavior.

If the screen changed unexpectedly, many bots simply failed.

LLM Assistants

Large Language Models changed the conversation.

Instead of executing predefined logic, they could reason about information.

Developers suddenly had assistants capable of:

Explaining code
Writing documentation
Generating tests
Refactoring functions
Summarizing requirements

But there was still one limitation. The assistant depended entirely on the context supplied by the human.

It couldn't fetch missing information on its own.

Agentic Workflows

Agentic workflows represent the next step.

Instead of giving an AI isolated pieces of information, we give it access to tools and a goal.

For example:

Review every pull request merged into the release branch today.

An agent might decide to:

Search GitHub for merged pull requests
Retrieve each code diff
Locate the associated Jira stories
Read acceptance criteria
Review implementation quality
Identify testing gaps
Generate release notes
Publish a report

Notice something important. The engineer never described how to perform these steps. Only what needed to be accomplished.

That distinction is what makes agentic workflows fundamentally different from traditional automation.

So... What Exactly Is an AI Agent?

The term "AI Agent" has become incredibly popular. Unfortunately, it has also become incredibly vague.

Today, almost every application that calls an LLM markets itself as an AI agent.

Personally, I think we need a higher standard. An engineering agent should possess several characteristics.

1. It Has a Goal

Agents work toward objectives.

Not prompts.

2. It Can Gather Context

Agents retrieve information without requiring humans to manually assemble everything.

3. It Uses Tools

GitHub.

Jira.

Slack.

Docker.

Kubernetes.

Databases.

REST APIs.

The LLM is only one component.

4. It Makes Decisions

Rather than executing one fixed sequence, the agent chooses which tools to invoke and when.

5. It Produces Useful Outcomes

The goal isn't conversation.

The goal is to accomplish work.

The Philosophy Behind This Series

Every article in this series follows one simple principle. We're not building chatbots. We're building engineering teammates.

Each article explores a practical workflow that software engineers perform every day and asks a simple question:

Can an AI agent take care of the repetitive parts while leaving the engineering decisions to humans?

Some examples include:

Reviewing pull requests
Generating release notes
Creating project scaffolding
Automating developer onboarding
Building engineering knowledge assistants
Producing technical documentation
Responding to production incidents

Each solution will be built using practical technologies that engineering teams already use every day, including GitHub, Jira, GitHub Copilot, REST APIs, Python, Docker, and cloud-native tooling.

No proprietary frameworks. No magical abstractions.

Just practical engineering.

Why This Matters

I don't believe AI will replace software engineers.

I do believe it will replace a significant amount of repetitive engineering work.

As software systems continue to grow in complexity, engineers spend an increasing amount of time gathering information rather than solving problems.

Agentic Engineering isn't about removing humans from the software development lifecycle.

It's about removing unnecessary friction.

When agents handle repetitive work, engineers have more time to focus on architecture, system design, reliability, security, performance, and innovation.

Those are the problems humans are exceptionally good at solving.

What's Next?

In the next article, we'll build our first engineering agent—one that understands pull request workflows by combining GitHub CLI, Jira, and GitHub Copilot into a single autonomous review process.

This isn't just another AI assistant.

It's the beginning of a new way of thinking about software engineering.

About the Author

Hi, I'm Nachiket Joshi.

I'm a software engineer focused on AI systems, distributed platforms, and developer productivity workflows. I share practical implementations of AI-powered engineering systems.

Agentic Engineering #2: Generating Release Notes Automatically with AI Agents

Nachiket Joshi — Wed, 15 Jul 2026 00:45:34 +0000

Why Preparing Release Notes Still Is a Cumbersome Task?

Every engineering team eventually reaches the same point before a release.

Someone has to answer a seemingly simple question: "What changed?"

Unfortunately, answering that question is rarely simple.

Developers begin searching merged pull requests. Someone opens Jira to understand the business context. Another engineer scans commit messages. Product managers ask for customer-friendly summaries. QA wants a technical changelog. Leadership wants release highlights.

The information already exists—it is simply scattered across multiple systems. The result is a manual process that often takes hours before every release.

The Problem

A typical release note preparation looks something like this:

Search merged Pull Requests
Read every PR description
Open corresponding Jira stories
Understand business requirements
Read commit history
Group related features
Rewrite technical language for business users
Prepare release documentation

The larger the release, the longer this process becomes. Ironically, none of this work creates software. It is documentation built from information that already exists.

What If the Agent Did the Context Gathering?

Instead of asking an engineer to manually assemble release notes, I wanted an AI agent that could automatically collect all the necessary context.

The workflow becomes:

Merged Pull Requests
        │
        ▼
GitHub CLI
        │
        ▼
Linked Jira Stories
        │
        ▼
Acceptance Criteria
        │
        ▼
AI Analysis
        │
        ▼
Customer Release Notes/ Engineering Changelog/ Internal Summary

The engineer simply specifies the release range. The agent performs the rest.

Building the AI Release Notes Agent

The implementation follows the same design philosophy introduced in the previous article. I highly recommend looking up the article.

Instead of creating custom integrations everywhere, the agent orchestrates existing developer tools.

Current implementation:

GitHub CLI
GitHub Copilot CLI
Jira REST API
Python 3.11+

High-Level Architecture And Design

                Engineer

                    │

                    ▼

          Release Notes Agent

        ┌───────────┼──────────────┐
        │           │              │
        ▼           ▼              ▼

 GitHub CLI     Jira REST API   Copilot CLI

        │           │              │
        └───────────┼──────────────┘
                    │

                    ▼

        Customer Release Notes

        Engineering Changelog

        Internal Release Summary

What Information Does the Agent Collect?

Unlike a traditional script that simply concatenates commit messages, the agent gathers context from multiple sources.

From GitHub:

Pull Requests
Merge commits
Changed files
Authors
Labels

From Jira:

Story descriptions
Acceptance criteria
Business requirements
Epic information

This richer context allows the generated release notes to describe why features were implemented rather than simply what files changed.

Leveraging GitHub CLI

The implementation relies heavily on GitHub CLI.

For example,

Retrieve merged pull requests:

gh search prs --state merged

Retrieve PR information:

gh pr view

Retrieve commits:

gh pr view --json commits

GitHub CLI handles authentication and repository context, allowing the Python code to remain focused on orchestration.

Agent Workflows

I designed the agent to generate multiple types of Release Notes.

One of the biggest advantages of using AI is that the agent can produce multiple outputs tailored to different audiences in the same release.

Customer Release Notes

Designed for end users.

Example:

Added support for configurable notification preferences.

Improved dashboard performance for large datasets.

Resolved intermittent login issues affecting SSO users.

Engineering Changelog

Designed for developers.

Includes:

PR numbers
Technical implementation
Breaking changes
Dependency updates

Internal Management Summary

Focused on delivery.

Example:

24 Pull Requests merged
18 Jira stories completed
2 Bug fixes
4 Enhancements
No breaking changes

Expected Output Structure

Executive Summary

New Features

Enhancements

Bug Fixes

Performance Improvements

Breaking Changes

Known Limitations

Deployment Notes

Why This Is Better Than Commit Messages

Commit messages are written for developers. Release notes are written for people. Those are fundamentally different audiences. Instead of exposing implementation details, AI can rewrite technical work into language that customers, product managers, QA teams, and leadership can immediately understand.

Why I Consider This an Agent

Today, many applications wrap an LLM and call it an "AI Agent." I think the definition should be a little stricter.

A useful engineering agent should be able to:

Gather information independently
Invoke external tools
Combine information from multiple systems
Make workflow decisions
Produce meaningful outputs without requiring constant human guidance
This project isn't just sending prompts to an LLM. It's orchestrating GitHub, Jira, and Copilot into a workflow that removes repetitive engineering work.

That, to me, is where agents become genuinely useful.

Security Considerations

The current implementation follows the same guardrails as the Pull Request Review Agent.

Read-only GitHub operations
Read-only Jira queries
No automatic repository writes
Temporary file cleanup
Explicit report generation

The agent never modifies source code or deployment artifacts.

Future Enhancements

This is only the first iteration.

Future improvements include:

Automatic release detection
Slack announcements
Confluence publishing
Markdown generation
PDF release reports
Email distribution
Semantic grouping of related features
Multi-repository release aggregation

Looking Ahead

Over the next several articles in this series, we'll continue building practical engineering agents to automate other parts of the software development lifecycle, including:

From Jira Story to the First Pull Request

The goal isn't to replace engineers. It's to eliminate repetitive work so engineers can spend more time solving meaningful problems.

If you're building similar workflows—or have ideas for engineering tasks that could be automated—I'd love to hear about them in the comments.

About the Author

Agentic Engineering #1: Building an AI Agent That Understands Your Pull Request Workflow

Nachiket Joshi — Tue, 14 Jul 2026 01:50:59 +0000

Why Reviewing PRs is Still A Cumbersome Task

Artificial Intelligence has quickly become an integral part of a software engineer's toolkit.

We ask ChatGPT to explain unfamiliar code, use GitHub Copilot to autocomplete functions, and occasionally paste a pull request into an LLM for feedback. These tools undoubtedly improve productivity, but they still depend heavily on one thing: us.

We gather the pull request.
We search for the Jira story.
We copy the acceptance criteria.
We summarize the business requirements.
We explain the repository structure.
Only then do we ask the AI to help.

That isn't automation. It's simply moving manual work into a chat window.

Over the past few months, I've become increasingly interested in a different approach—building AI agents that can understand engineering workflows, gather their own context, interact with developer tools, and complete meaningful tasks with minimal human intervention.

This article marks the beginning of a new series called Agentic Engineering, where I'll share practical implementations of AI-powered workflows that automate repetitive engineering tasks across the software development lifecycle.

The Problem

Let's look at a typical pull request review. A reviewer usually needs to:

Open the Pull Request
Read the code changes
Find the corresponding Jira story
Understand the business requirements
Read the acceptance criteria
Compare implementation against requirements
Check coding standards
Leave review comments

Depending on the complexity of the change, simply gathering context can consume 15–30 minutes before any real technical review even begins. As repositories grow larger and development teams become more distributed, this overhead becomes increasingly expensive.

What If the Agent Did the Context Gathering?

Instead of asking an AI:

Review this pull request.

I wanted to build an agent that already knows:

Which repository to inspect
Which Pull Request to analyze
Which Jira story is associated with the PR
What are the acceptance criteria
What files changed
How to generate a structured review

The objective isn't to replace software engineers. It's to eliminate repetitive work so reviewers can focus on architecture, business logic, security, and edge cases.

Building My First AI Productivity Agent

To explore this idea, I built a simple command-line agent that orchestrates multiple developer tools into a single workflow.

The implementation currently uses:

GitHub CLI (gh)
GitHub Copilot CLI
Jira REST API

Rather than treating these as independent tools, the agent combines them into a single engineering workflow.

Getting Started

Prerequisites

The agent is intentionally lightweight and relies on existing developer tooling rather than custom integrations.

Python

Python 3.11+ is recommended.

python --version
Python 3.13.3

Python Packages

Install the required dependencies:

python-dotenv jira urllib3

GitHub Copilot CLI

Run:

gh copilot -p "what is 2+2"
4

GitHub CLI

Install GitHub CLI from:

https://cli.github.com

gh --version
gh version 2.95.0 (2026-06-17)
https://github.com/cli/cli/releases/tag/v2.95.0

Authenticate with GitHub

gh auth login
gh auth status
github.com
✓ Logged in to github.com account johndoe
✓ Git operations for github.com configured to use https
✓ Token: ****************
✓ Token scopes:
  - repo
  - read:org
  - gist

Architecture And Design

Leveraging GitHub CLI

One design decision I made was to avoid writing custom GitHub API wrappers wherever possible. Instead, the agent delegates repository operations to GitHub CLI.

Search Pull Requests

gh search prs

Used by:

get_prs()

Retrieve Pull Request Diff

gh pr diff

Used by:

get_diff()

GitHub CLI handles authentication, repository context, pagination, and formatting, allowing the Python code to remain focused on orchestration rather than API plumbing.

High-Level Architecture

                  Developer

                     |
                     v

             Agent Orchestrator

        +------------+-------------+
        |            |             |
        v            v             v

    GitHub CLI    Jira API    Copilot CLI

        |
        v

 Context Builder

        |
        v

 Review Decision Engine

        |
        v

 Structured Report

The agent collects information from GitHub and Jira, builds the necessary context, and asks Copilot CLI to perform a structured review. Instead of manually assembling prompts, the engineer simply invokes the workflow.

Code Design Overview

run()
│
├── Wrapper around subprocess.run()

get_prs()
│
└── Executes:
    gh search prs

get_diff()
│
└── Retrieves PR diff

write_temp_diff()
│
└── Creates a temporary .diff file

review_with_copilot()
│
└── Invokes GitHub Copilot CLI

get_jira_client()
│
└── Creates an authenticated Jira client

post_jira_comment()
│
└── Posts review back to Jira

write_report()
│
└── Generates Markdown report

review_pr()
│
└── Main orchestration method

Agent Workflows And Expected Output

The current version exposes three workflows.

List Pull Requests

agent --list

Displays pull requests that are available for review.

Review All Pull Requests

agent --review-all

Reviews every eligible pull request automatically.

This is useful before a release or during periods when multiple PRs are waiting for review.

Review a Single Pull Request

agent review-pr \
    --repo engineering-service \
    --pr 248 \
    --jira ENG-542

The agent:

Retrieves PR details from GitHub
Retrieves the Jira story
Reads acceptance criteria
Collects changed files
Sends the complete context to Copilot CLI
Produces a structured review

The engineer no longer needs to gather all of this information manually.

PR Review Report

The generated review follows a consistent structure.

Summary

High Severity Findings

Medium Severity Findings

Low Severity Findings

Testing Gaps

Suggestions

This predictable format makes reviews easier to consume and simplifies future automation.

Why These Technologies

Why GitHub CLI?

GitHub CLI already solves authentication and repository access elegantly. Instead of writing custom integrations for every GitHub API endpoint, I can retrieve:

Pull Request metadata
Changed files
Commit history
Repository information

with simple CLI commands.

This keeps the implementation lightweight while still providing everything the agent needs. Moreover, no more token handling.

Why Jira?

Git tells us what changed.

Jira tells us why it changed.

Without the Jira story, an AI review can evaluate syntax, formatting, and code quality—but it cannot determine whether the implementation actually satisfies the original business requirements.

Retrieving the Jira story and its acceptance criteria makes the review much more meaningful.

Why Copilot CLI?

Copilot CLI acts as the reasoning engine.

Instead of manually crafting prompts, the agent prepares all of the required context and delegates the analysis to Copilot.

The result is a review that's aware of:

Code changes
Business requirements
Acceptance criteria
Repository context

rather than just isolated code snippets.

Why I Consider This an Agent

Today, many applications wrap an LLM and call it an "AI Agent." I think the definition should be a little stricter.

A useful engineering agent should be able to:

Gather information independently
Invoke external tools
Combine information from multiple systems
Make workflow decisions
Produce meaningful outputs without requiring constant human guidance

This project isn't just sending prompts to an LLM. It's orchestrating GitHub, Jira, and Copilot into a workflow that removes repetitive engineering work.

That, to me, is where agents become genuinely useful.

Security Considerations

Since the agent interacts with production engineering systems, a few guardrails were built into the design.

Read-only GitHub Operations

The current implementation never performs GitHub write operations. It only retrieves repository information and pull request data.

Temporary File Cleanup

Pull request diffs are written to temporary files before analysis. These files are automatically deleted after the review completes.

Explicit Jira Updates

Review results are only posted back to Jira when explicitly requested. The agent never modifies tickets automatically.

Looking Ahead

Pull request reviews are only the beginning.

Over the next several articles in this series, we'll continue building practical engineering agents to automate other parts of the software development lifecycle, including:

Agentic Engineering #2: Generating Release Notes Automatically with AI Agents

The goal isn't to replace engineers. It's to eliminate repetitive work so engineers can spend more time solving meaningful problems.

If you're building similar workflows—or have ideas for engineering tasks that could be automated—I'd love to hear about them in the comments.