DEV Community: Nir Berko

How I Built an AI-Powered PR Reviewer in 15 Minutes Using Agentform

Nir Berko — Mon, 19 Jan 2026 06:07:11 +0000

How I Built an AI-Powered PR Reviewer in 15 Minutes Using Agentform

No Python. No complex orchestration. Just declarative configuration.

There are plenty of AI-powered PR review tools out there, but I wanted to build my own - partly for more control over the review process, and partly just for fun and to learn a new technology. The challenge? Building one traditionally meant writing a lot of imperative code: managing API calls, handling retries, orchestrating workflows, and dealing with error handling. That's a lot of boilerplate for what should be a simple task.

Using Agentform, I built a fully functional AI PR reviewer in just 15 minutes that runs automatically on GitHub Actions. Here's how I did it.

What is Agentform?

Agentform is Infrastructure as Code for AI agents. Instead of writing imperative Python or JavaScript to manage agent state, retries, and tool wiring, Agentform lets you describe your AI agents declaratively using a native schema format.

Think of it like Terraform, but for AI workflows. You define what you want, not how to do it.

Agentform is an emerging technology currently in active development and early stages, so expect rapid evolution and potential breaking changes. However, it's already powerful enough to build real-world applications like this PR reviewer, and the declarative approach makes it worth exploring even at this stage.

Why Agentform?

Traditional approach:

# Lots of boilerplate, error handling, retry logic...
async def review_pr(pr_number):
    try:
        pr = await fetch_pr(pr_number)
        files = await fetch_files(pr_number)
        review = await llm.review(code=files)
        await post_review(pr_number, review)
    except Exception as e:
        # handle errors, retries, etc...

Agentform approach:

workflow "review_pr" {
  step "fetch_pr" { ... }
  step "analyze" { agent = agent.reviewer }
  step "submit_review" { ... }
}

Clean, readable, and version-controlled.

The Setup

Prerequisites

Python 3.12+
GitHub repository with Actions enabled
OpenAI API key
GitHub Personal Access Token (with repo scope)

Step 1: Install Agentform CLI

pip install agentform-cli

Step 2: Create the Project Structure

I organized my Agentform configuration into numbered files for clarity:

.af/
├── 00-project.af      # Project metadata
├── 01-variables.af    # Input variables
├── 02-providers.af    # LLM provider config
├── 03-servers.af      # MCP server connections
├── 04-capabilities.af # Tool capabilities
├── 05-policies.af     # Budgets and limits
├── 06-agents.af       # AI agent definitions
└── 07-workflows.af    # Workflow orchestration

Step 3: Define Variables

First, I defined what inputs my workflow needs:

// .af/01-variables.af

variable "openai_api_key" {
  type        = string
  description = "OpenAI API key"
  sensitive   = true
}

variable "github_personal_access_token" {
  type        = string
  description = "GitHub Personal Access Token"
  sensitive   = true
}

variable "owner" {
  type        = string
  description = "GitHub repository owner"
}

variable "repo" {
  type        = string
  description = "GitHub repository name"
}

variable "pr_number" {
  type        = number
  description = "Pull request number to review"
}

Step 4: Configure the LLM Provider

I set up OpenAI with GPT-4o:

// .af/02-providers.af

provider "llm.openai" "default" {
  api_key = var.openai_api_key
  default_params {
    temperature = 0.3
    max_tokens  = 4000
  }
}

model "gpt4o" {
  provider = provider.llm.openai.default
  id       = "gpt-4o"
  params {
    temperature = 0.2
  }
}

Step 5: Connect to GitHub via MCP

Agentform uses Model Context Protocol (MCP) to connect to external services. I configured the GitHub MCP server:

// .af/03-servers.af

server "github" {
  type      = "mcp"
  transport = "stdio"
  command   = ["npx", "@modelcontextprotocol/server-github"]
  auth {
    token = var.github_personal_access_token
  }
}

Step 6: Define Capabilities

Capabilities are the tools my agent can use. I defined three GitHub operations:

// .af/04-capabilities.af

capability "get_pr" {
  server      = server.github
  method      = "get_pull_request"
  side_effect = "read"
}

capability "list_pr_files" {
  server      = server.github
  method      = "get_pull_request_files"
  side_effect = "read"
}

capability "create_review" {
  server      = server.github
  method      = "create_pull_request_review"
  side_effect = "write"
}

Step 7: Set Policies

I added budget controls to prevent runaway costs:

// .af/05-policies.af

policy "review_policy" {
  budgets { max_cost_usd_per_run = 1.00 }
  budgets { max_capability_calls = 10 }
  budgets { timeout_seconds = 300 }
}

Step 8: Create the Reviewer Agent

Now for the fun part - defining the AI agent:

// .af/06-agents.af

agent "reviewer" {
  model = model.gpt4o

  instructions = <<EOF
You are an expert code reviewer. Review pull requests thoroughly.

Focus on:
- Code quality and best practices
- Potential bugs or edge cases
- Performance implications
- Security concerns
- Documentation and readability

Be constructive and specific in your feedback.
Suggest improvements where possible.
EOF

  allow  = [capability.get_pr, capability.list_pr_files, capability.create_review]
  policy = policy.review_policy
}

Step 9: Orchestrate the Workflow

Finally, I wired everything together in a workflow:

// .af/07-workflows.af

workflow "review_pr" {
  entry = step.fetch_pr

  step "fetch_pr" {
    type       = "call"
    capability = capability.get_pr

    args {
      owner       = input.owner
      repo        = input.repo
      pull_number = input.pr_number
    }

    output "pr_data" { from = result.data }
    next = step.fetch_files
  }

  step "fetch_files" {
    type       = "call"
    capability = capability.list_pr_files

    args {
      owner       = input.owner
      repo        = input.repo
      pull_number = input.pr_number
    }

    output "pr_files" { from = result.data }
    next = step.analyze
  }

  step "analyze" {
    type  = "llm"
    agent = agent.reviewer

    input {
      pr    = state.pr_data
      files = state.pr_files
    }

    output "review" { from = result.response }
    next = step.submit_review
  }

  step "submit_review" {
    type       = "call"
    capability = capability.create_review

    args {
      owner       = input.owner
      repo        = input.repo
      pull_number = input.pr_number
      body        = state.review.response
      event       = "COMMENT"
    }

    output "result" { from = result.data }
    next = step.end
  }

  step "end" { type = "end" }
}

Notice how clean this is? Each step:

Fetches PR data from GitHub
Gets the changed files
Asks the AI agent to review (with access to PR and file data)
Submits the review as a comment

The data flows naturally through state, and each step explicitly references the next.

Step 10: Set Up GitHub Actions

To automate this, I created a GitHub Actions workflow:

# .github/workflows/agentform-pr-review.yml

name: PR Review

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    name: AI PR Review
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: "3.12"

      - name: Install agentform-cli
        run: pip install agentform-cli==0.0.3

      - name: Run PR Review
        working-directory: .af
        run: |
          agentform run review_pr \
            --var openai_api_key=${{ secrets.OPENAI_API_KEY }} \
            --var github_personal_access_token=${{ secrets.GITHUB_TOKEN }} \
            --var owner=${{ github.repository_owner }} \
            --var repo=${{ github.event.repository.name }} \
            --var pr_number=${{ github.event.pull_request.number }}

I added two secrets in GitHub:

OPENAI_API_KEY: My OpenAI API key
GITHUB_TOKEN: Automatically provided by GitHub Actions

That's it! Now every PR automatically gets reviewed.

How It Works

When a pull request is opened or updated:

GitHub Actions triggers the workflow
Agentform fetches the PR data using the GitHub MCP server
Agentform gets the list of changed files
The AI agent reviews the code with access to both PR metadata and file contents
The review is posted as a comment on the PR

All orchestration, error handling, and state management is handled by Agentform. I just defined the workflow declaratively.

Testing Locally

You can test the workflow locally before pushing:

cd .af

agentform run review_pr \
  --var openai_api_key="your-key" \
  --var github_personal_access_token="your-token" \
  --var owner="your-username" \
  --var repo="your-repo" \
  --var pr_number=1

What I Love About This Approach

No boilerplate code: Everything is declarative configuration
Version controlled: Agent logic is in .af files, making changes reviewable
Type safe: Agentform validates the schema before execution
Composable: Agents and workflows can be reused and combined
Cost controlled: Built-in budget limits prevent surprises
Multi-provider: Easy to switch between OpenAI, Anthropic, etc.

Reusability: Using as a Module

One of the coolest features of Agentform is that you can package your agent configuration as a reusable module. You can easily import this PR reviewer workflow into your own Agentform project using Agentform modules - no need to copy files or duplicate configuration!

Just reference it directly from your Agentform project:

module "simple-agentform-module" {
  source  = "github.com/nirberko/agentform-pr-reviewer-example//.af"
  version = "main"  // Git branch name

  // Required parameters - pass through our project variables
  openai_api_key               = var.openai_api_key
  github_personal_access_token = var.github_token
  owner                        = var.owner
  repo                         = var.repo
  pr_number                    = var.pr_number
}

That's it! Agentform modules make it incredibly easy to share and reuse agent configurations across projects or teams, ensuring everyone is using the same, tested workflow.

Customization

Want to change the review style? Edit the agent instructions in 06-agents.af. Need different budget limits? Update 05-policies.af. Want to use a different model? Modify 02-providers.af.

All changes are in configuration files - no code changes needed.

The Result

I now have an AI-powered PR reviewer that:

✅ Runs automatically on every PR
✅ Provides intelligent, constructive feedback
✅ Is fully version-controlled and maintainable
✅ Took me 15 minutes to set up

Next Steps

You can extend this further:

Add support for different review criteria
Create multiple reviewer agents for different aspects (security, performance, style)
Integrate with other MCP servers (databases, APIs, etc.)
Build more complex multi-agent workflows

Resources

Have you tried Agentform? What AI workflows would you build with it? Let me know in the comments! 🚀

Building a Production-Grade Scraper with Playwright, Chromium, Kubernetes, and AWS

Nir Berko — Fri, 16 Jan 2026 11:21:00 +0000

Introduction

Recently, I worked on scraping an off-market real estate platform that required authentication, session handling, and dynamic rendering.

This was not a simple HTTP scraper.

The site is a single-page application, protected by login, session cookies, and active blocking mechanisms. To make it work reliably in production, I had to combine headless browser automation, Kubernetes, AWS-managed infrastructure, and a deliberate proxy strategy.

This post walks through the architecture, the key technical decisions, and the lessons learned for anyone building scrapers that need to survive real-world constraints.

High-Level Architecture

The system was split into two microservices running inside Kubernetes on AWS:

Scraper Service (Node.js / NestJS)

Responsible for:
- Orchestrating login
- Managing session state
- Fetching listing and detail data
- Parsing and normalizing results
Chromium Service

A dedicated headless Chromium instance running as a separate pod using the browserless/chrome image.

The scraper service connects to Chromium over CDP via WebSocket, exposed through an internal Kubernetes Service. This separation kept browser concerns isolated and made the system easier to reason about and evolve.

Why a Headless Browser Was Required

A headless browser was unavoidable for two reasons:

The platform requires authentication and session cookies
The site is a SPA that relies heavily on client-side rendering

Pure HTTP scraping could not reliably establish or maintain a valid session. Playwright was used to perform login, manage cookies and local storage, and act as the source of truth for the authentication state.

Why Playwright

Playwright turned out to be a strong fit for this use case:

Reliable handling of modern SPAs
Clean APIs for waiting on navigation and DOM readiness
Stable session and cookie management
Native support for connecting to a remote Chromium instance over CDP

Most importantly, it significantly reduced flakiness around login flows and dynamic rendering.

Connecting to Remote Chromium in Kubernetes

Chromium ran behind an internal Kubernetes Service.

The scraper connected using:

chromium.connectOverCDP(ws://<chromium-service>:<port>)

The host and port were injected via environment variables, which allowed:

Clean separation between dev, staging, and production
No hard-coded endpoints
Easy switching between local and remote browser execution

This setup was stable and did not require reconnect logic or special handling.

AWS Infrastructure Choices

Although this system was Kubernetes-first, AWS services played a key role in making it production-ready.

Amazon EKS

The entire system ran on Amazon EKS, which provided:

A managed Kubernetes control plane
Predictable networking and service discovery
Clean separation between scraper and browser workloads

EKS made it straightforward to run a browser-heavy workload while still benefiting from Kubernetes primitives.

AWS Secrets Manager

All sensitive configurations, including:

Platform credentials
Proxy credentials
Environment-specific secrets

was stored in AWS Secrets Manager and injected into pods via environment variables. This avoided hardcoding secrets into images or manifests and enabled clean separation between environments.

IAM Roles for Service Accounts (IRSA)

Pods accessed AWS resources using IAM roles attached to Kubernetes service accounts. This eliminated static AWS credentials and followed least-privilege principles.

Amazon CloudWatch

Logs from the scraper service were shipped to CloudWatch. This was critical for:

Debugging silent failures
Identifying where blocking occurred (login vs data fetch)
Understanding retry behavior over time

Scraping systems fail quietly. Centralized logging was essential.

The Reality of Scraping Blocked Websites

In production scraping, parsing data is rarely the hard part.

Getting access is.

Modern platforms actively block automated traffic using:

Rate limiting
IP reputation checks
Blocking cloud datacenter IP ranges
Flagging abnormal login or navigation patterns

Without mitigation, even a well-written scraper may work once and then silently stop.

This is where proxies become unavoidable.

Proxy Strategy: Necessary but Expensive

For authenticated and high-value platforms, proxies are not about scale. They are about survival.

Without proxies:

Login attempts get blocked quickly
Sessions are invalidated
Requests return partial or empty responses

Residential or ISP-grade proxies improve:

IP reputation
Session stability
Retry success rates

The tradeoff is cost and operational complexity.

Use Proxies Only Where You Must

One key lesson was to treat proxies as an expensive resource, not the default path.

In this setup:

Proxies were mainly used for browser-based actions, especially login
Once a valid session was established, most data fetching was done via direct HTTP requests using session cookies

This approach:

Reduced proxy traffic and cost
Improved speed
Lowered exposure to unnecessary blocking

A Key Optimization: Browser for Login, HTTP for Data

After login, cookies were extracted from the browser context and reused for direct HTTP requests from Node.js.

This allowed:

Fetching JSON listing data without rendering pages
Fetching HTML detail pages directly
Full control over headers, retries, and backoff logic

Benefits:

Much faster than rendering each page in Chromium
More stable than page-by-page navigation
Lower proxy and browser costs
Easier retry handling

The browser became an authentication tool, not a data-fetching bottleneck.

Single-Tenant Design (By Choice)

The scraper was intentionally designed as single-tenant:

One browser instance
One context and page
Shared login state

This is optimized for speed and simplicity.

If scaling to multi-tenancy, the next steps would be:

Introducing a job queue (for example, SQS)
Explicit concurrency limits
Separate browser contexts per job
Tighter resource control per pod

For this use case, simplicity was the right tradeoff.

Kubernetes Resource Considerations

Chromium ran reliably without explicit CPU or memory tuning.

For higher load, best practices would include:

Explicit CPU and memory requests and limits
Increasing /dev/shm using emptyDir
Monitoring browser memory growth over time

These become critical as concurrency increases.

Scraping Is an Arms Race

There is no “set it and forget it” scraper.

Sites change:

Login flows
Required headers
JavaScript behavior
Bot detection rules

A scraper that works today can break tomorrow without any code changes.

Scraping should be treated as a system, not a script:

Expect failures
Build retries
Monitor success rates
Adapt proxy strategy over time

Final Thoughts

Scraping modern web applications is less about HTML parsing and more about system design.

Using a headless browser only where it is truly required, combined with direct HTTP requests wherever possible, provides the best balance between reliability, speed, and cost.

If scraping is a core dependency, the real question is not can you scrape the data, but whether the data is valuable enough to justify the ongoing operational complexity.

That question should be answered early.

Authentication using AuthGrid

Nir Berko — Fri, 05 Feb 2021 18:11:05 +0000

Notice that AuthGrid is not yet ready for production environment and is still in progress!

What is AuthGrid

AuthGrid is an end-to-end open source authentication provider (both server-side and client-side) that lets you focus on your app and skip the boring and time-wasting authentication development. Forget about creating that login and register pages again and again. forget about creating a profile page, user settings, webhooks, integrations, audits, and more!

How to use AuthGrid?

First of all, AuthGrid currently supporting only express.js for the backend, React in the frontend, and mongoose as a database, but more frameworks and databases will be supported in the future!

for our example, I'll be building a dashboard application using the express.js framework for my backend, MongoDB (using mongoose) for the database, and React for the client-side.

installing AuthGrid for backend

we need to add AuthGrid middleware to our express backend, and also to install the database driver that matches our needs, in that case, we need to install the AuthGrid mongoose driver

Let's install both AuthGrid client the mongoose driver to our express backend

npm install @authgrid/client @authgrid/mongoose-driver

or using yarn

yarn add @authgrid/client @authgrid/mongoose-driver

Usage

first of all, we need of course to configure mongoose with our mongodb database connection uri, for example:

await mongoose.connect(String('mongodb://localhost:27017/my_dashboard'));

then, implementing AuthGrid is very simple, just add AuthGrid client middleware at the beginning of your express app:

import AuthGrid from '@authgrid/client';
import MongooseDriver from '@authgrid/mongoose-driver';

.....

app.use(  
  '/authgrid',  
  Authgrid({  
    driver: MongooseDriver(),  
    tokenSecret: ...,  
    refreshTokenSecret: ...,  
    mailer: ...,  
  })  
);

notice that AuthGrid requires some options, so let's explore than now:

Driver is the way AuthGrid client communicating with our database. in our example, we are using MongoDB, so we need to import @authgrid/mongoose-driver
tokenSecret and refreshTokenSecret are very important and are using by AuthGrid to create hashed tokens for authenticating the users.
mailer is the way AuthGrid can send emails, this function will be called everytime AuthGird wants to send an email, for example, this is how im using SendGrid as my email provider:

const mailer = async ({ to, subject, html }) =>  
  sgMail.send({  
    to,  
    from: 'myemail@gmail.com',  
    subject,  
    html,  
  });

we almost done,
last thing we need to do is to protect our api using the withAutentication middleware provided by AuthGrid.
this is how we do it:

app.get('/get-user-details', withAuthentication(), (req, res) => {  
  res.json(req.user);  
});

installing AuthGrid for React.js

So now that our express.js backend is ready and protected, lets move to the client-side.
AuthGrid providing us also a very powerful client-side authentication components and state management.
let's see how we can use those pre-made components by AuthGrid.

First, we need to install the AuthGrid package for react

npm install @authgrid/react-core

or using yarn

yarn add @authgrid/react-core

usage

so now that we have the AuthGrid react-core package installed, we need to warp our whole component with the AuthGrid provider.

import React from 'react';  
import ReactDOM from 'react-dom';  
import { BrowserRouter, Switch } from 'react-router-dom';  
import { AuthgridProvider, ProtectedRoute, useAuth } from '@authgrid/react-core';  

const context = {  
  baseUrl: 'http://localhost:8080',  
};  

const Home = () => {  
  const { user } = useAuth();  

  return <div>{user?.email}</div>;  
}; 

ReactDOM.render(  
  <BrowserRouter>  
    <AuthgridProvider context={context}>  
      <Switch>
        <ProtectedRoute path="/" component={Home} />  
      </Switch>
    </AuthgridProvider>
  </BrowserRouter>,  
  document.getElementById('root')  
);

as you can see, we need to provide AuthGrid the base URL for our server-side, this is very important so AuthGrid can know where to send the fetch requests.

also, for protecting routes only for authenticated users we can import the ProtectedRoute component. now, when a user wants to enter that route, he must log in before.

That's it, we are done!, now, let's check our application and see that everything is working.
when you enter your app, you should see the AuthGrid login screen (don't forget to use the ProtectedRoute component)

You can now register and login into your application!

Keep in mind that AuthGird is still at work and can be a bit buggy, and a lot of features are missing and will be added in the future with the help of the community.
so I'm not recommending using this package yet, follow the repo to be updated when AuthGrid is ready to use in production environments

AuthGrid is looking for contributors (and that also the reason I published this post :)) so contact me if you are interesting :)

https://github.com/authgrid/authgrid

A lot of features are yet to come!:

Profile and settings page
Audits logs
Webhooks
Integrations
User management
and much more...