DEV Community: Piyush Atghara

AI Coding Changed the Bottleneck. It Isn't Writing Code Anymore.

Piyush Atghara — Fri, 02 Oct 2026 04:56:00 +0000

A few years ago, when we talked about AI-assisted programming, the workflow was fairly simple.

Open your editor.

Write some code.

Ask the AI to complete it.

Accept the suggestion.

Maybe ask it to write a test.

That model is changing.

Today's coding agents can inspect a repository, understand relationships between files, run commands, modify multiple files, execute tests, investigate failures, and continue working based on the results.

The interesting problem is no longer:

"Can AI write this code?"

Increasingly, the problem is:

"Does the AI have enough context to write the right code?"

That distinction matters.

And it has led us to think about AI-assisted development less as a prompting problem and more as a harness engineering problem.

The bottleneck moved

Consider a fairly ordinary backend task.

You receive a Jira ticket:

Add support for a new API parameter.

A human engineer doesn't immediately start typing.

They usually do something like:

Understand the requirement.
Find the relevant service.
Understand the architecture.
Find similar implementations.
Check API conventions.
Understand validation rules.
Look at existing tests.
Implement the change.
Run tests.
Review the resulting diff.
Fix anything that doesn't fit the existing system.

A capable coding agent can perform many of these steps.

But there is a catch.

The agent doesn't automatically know all the things that an experienced engineer has accumulated through months of working on the project.

It may not know that:

a particular module should never be modified directly
a certain abstraction exists for a reason
the project prefers one library over another
a particular test pattern is mandatory
an API must remain backwards compatible
a seemingly redundant validation step is intentional
a Jira description doesn't capture an important implementation constraint

This is where context engineering becomes important.

From prompts to a coding harness

Instead of giving an AI agent a giant prompt every time we start a task, we can make the repository itself provide much of the context.

Think of the repository as having a layer specifically designed for AI-assisted development.

For example:

repository/
│
├── AGENTS.md
├── CLAUDE.md
├── .github/
│   └── copilot-instructions.md
│
├── specs/
│   ├── JIRA-1234.md
│   ├── JIRA-1278.md
│   └── JIRA-1302.md
│
├── src/
├── tests/
├── scripts/
└── README.md

The exact filenames aren't important.

The important idea is that the agent has access to the same engineering context that a human engineer would need.

Modern coding tools increasingly support this pattern. GitHub's current documentation supports repository-wide instructions through .github/copilot-instructions.md, path-specific instructions, and agent instructions such as AGENTS.md and CLAUDE.md.

Claude Code similarly uses CLAUDE.md as project-level context that is automatically read when working in the repository.

So these files aren't just documentation.

They can become part of the development interface between the codebase and the coding agent.

1. AGENTS.md / CLAUDE.md: teach the agent how the repository works

The first layer is project-level instructions.

For example:

# Project Instructions

## Architecture

This repository contains:
- API service
- Business logic layer
- Data access layer
- Background workers

Do not put business logic inside API handlers.

## Python

- Python 3.12
- Use async APIs where the surrounding code is async
- Use existing project dependencies before introducing new ones

## Testing

- Every new behaviour requires tests
- Run pytest before considering a task complete
- Do not modify existing tests simply to make a new implementation pass

## API changes

- Maintain backwards compatibility
- Follow existing response and error formats

## Before finishing

- Run relevant tests
- Review the git diff
- Do not modify unrelated files

Notice what isn't particularly useful:

Write clean code.
Follow best practices.
Use good naming.
Write maintainable software.

An AI agent already knows these phrases.

The useful information is the stuff it cannot reliably infer from the code alone.

For example:

"This service uses X for authentication because Y depends on it. Do not replace it with Z."

That's valuable.

VS Code's current guidance makes essentially the same point: project instructions are most useful when they document decisions an agent cannot reliably infer from the codebase.

2. Don't turn the instruction file into a novel

There's a temptation to keep adding everything to CLAUDE.md.

That can become counterproductive.

A good instruction file should answer:

"What does an engineer need to know before touching this repository?"

Not:

"Can we document the entire repository in one Markdown file?"

Keep stable, high-value information there:

architecture
conventions
commands
important constraints
testing requirements
things that frequently go wrong

Put task-specific information somewhere else.

That's where specs/ becomes useful.

3. Turn Jira tickets into machine-readable context

One of the biggest problems with AI coding is that the prompt often contains too little information.

A Jira ticket might contain the actual requirement, but the agent doesn't necessarily have convenient access to the entire ticket conversation, linked issues, acceptance criteria, or decisions made during refinement.

One approach is to maintain a Markdown representation of the relevant specification.

For example:

specs/
├── JIRA-1234.md
├── JIRA-1235.md
└── JIRA-1236.md

A specification might look like:

# JIRA-1234

## Summary

Add support for X to the Voice Gateway.

## Requirements

- Accept X through the websocket API
- Preserve existing clients
- X must be optional
- Default behaviour must remain unchanged

## Acceptance Criteria

- Existing requests continue to work
- New requests support X
- Invalid X values return the existing validation error
- Unit tests cover both paths

## Technical Notes

The downstream NLU service already supports X.

Do not modify the NLU integration.

## References

- JIRA: JIRA-1234
- Related: JIRA-1189

Now the agent isn't starting with:

"Implement JIRA-1234."

It starts with an actual specification.

That's a huge difference.

4. Context should be layered

One of the mistakes I see with AI-assisted development is treating context as one enormous prompt.

I'd rather think of it as layers.

                 ┌──────────────────────┐
                 │       Task Spec      │
                 │       specs/*.md     │
                 └──────────┬───────────┘
                            │
                 ┌──────────▼───────────┐
                 │   Project Context    │
                 │ AGENTS.md / CLAUDE.md│
                 └──────────┬───────────┘
                            │
                 ┌──────────▼───────────┐
                 │     Codebase         │
                 │ source + tests       │
                 └──────────┬───────────┘
                            │
                 ┌──────────▼───────────┐
                 │   Agent + Tools      │
                 │ shell / git / tests  │
                 └──────────────────────┘

Each layer answers a different question.

Project instructions

How should I work?

Specification

What am I supposed to build?

Codebase

How does the existing system work?

Tools

How can I verify that my changes work?

This is much closer to how a human engineer actually works.

5. Give the agent tools, not just text

The next step is important.

An AI coding agent becomes significantly more useful when it can interact with the development environment.

For example:

Read files
   ↓
Understand architecture
   ↓
Modify code
   ↓
Run tests
   ↓
Read failures
   ↓
Modify code
   ↓
Run tests again
   ↓
Review diff

The agent isn't simply generating text anymore.

It's participating in a feedback loop.

That's why modern coding agents are fundamentally different from autocomplete.

The agent can execute commands, inspect their output and use that output to determine the next action.

This also changes how we should evaluate AI-generated code.

The question shouldn't simply be:

"Did the model generate good code?"

It should be:

"Can the system reliably detect when the generated code is wrong?"

6. Verification becomes more important than generation

This is probably the most important change in my own thinking about AI-assisted development.

If generating code becomes cheap, verification becomes expensive.

Suppose an agent writes 300 lines of code in a few minutes.

That's great.

But if reviewing those 300 lines takes an engineer 45 minutes, the bottleneck has moved.

And if the engineer doesn't have good tests, the problem becomes even worse.

So the coding harness should provide strong feedback loops.

At minimum:

Implementation
     ↓
Lint
     ↓
Unit tests
     ↓
Integration tests
     ↓
Type checks
     ↓
Build
     ↓
Diff review

The agent should be able to run these checks itself.

More importantly, failures should be useful.

Compare:

Tests failed.

with:

test_api_returns_existing_error_format
AssertionError:
Expected HTTP 400
Received HTTP 500

Response:
{"error": "..."}

Expected:
{"code": "INVALID_PARAMETER", ...}

The second output gives the agent something it can reason about.

Good engineering infrastructure becomes feedback infrastructure for the AI agent.

7. The coding harness should constrain the agent

There's another important idea here.

We don't actually want an autonomous agent with unlimited freedom.

We want an agent operating inside a set of boundaries.

For example:

                    ┌───────────────┐
                    │     Agent     │
                    └───────┬───────┘
                            │
             ┌──────────────┼──────────────┐
             │              │              │
             ▼              ▼              ▼
        Instructions     Tools          Tests
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                       Constraints
                            │
                            ▼
                         Codebase

The harness defines things like:

what files can be modified
what commands can be executed
what tests must pass
what patterns should be followed
what changes require human review
what constitutes completion

This is why I like the term coding harness.

We're not simply asking an LLM to write software.

We're designing an environment in which an AI agent can safely perform software engineering work.

This idea is increasingly being discussed as "harness engineering": designing constraints, feedback loops and quality gates around coding agents rather than focusing solely on the model itself.

8. Make corrections compound

Here's another useful pattern.

Suppose the agent makes a mistake.

For example:

Don't use library X here. This project uses library Y because X doesn't support our async execution model.

You could simply correct the agent and continue.

But that means you'll probably have to make the same correction again.

Instead, turn the correction into durable project knowledge.

## Important

Do not use library X for HTTP requests.

The service uses library Y because the request path is asynchronous.

Now the next agent session starts with that knowledge.

Anthropic itself recommends treating CLAUDE.md as shared project memory and updating it when the agent repeatedly makes a mistake.

This creates an interesting feedback loop:

Agent makes mistake
       ↓
Engineer corrects it
       ↓
Correction becomes project guidance
       ↓
Future agent sessions see it
       ↓
Same mistake becomes less likely

The repository gradually becomes better at working with AI.

9. What should the developer actually do?

This doesn't mean developers disappear.

It changes where their time goes.

Instead of spending most of the time on:

Typing → debugging → typing → debugging

the workflow starts looking more like:

Understand requirement
        ↓
Define constraints
        ↓
Provide context
        ↓
Delegate implementation
        ↓
Review
        ↓
Run verification
        ↓
Correct
        ↓
Capture important learning

The developer increasingly becomes the person designing and supervising the system.

That requires stronger engineering fundamentals, not weaker ones.

You still need to understand:

architecture
APIs
databases
concurrency
security
testing
performance
observability
failure modes

In fact, when an AI can produce code very quickly, understanding whether that code belongs in the system becomes more important.

10. A practical workflow

Here's a workflow that I think works well for an existing engineering team.

Step 1 — Keep project instructions in the repository

For example:

CLAUDE.md
AGENTS.md
.github/copilot-instructions.md

Don't duplicate everything blindly across them. Keep the instructions relevant to the tools your team actually uses.

Step 2 — Keep specifications close to the code

specs/
    JIRA-1234.md
    JIRA-1235.md

Convert important requirements into Markdown that an agent can consume.

Step 3 — Ask the agent to investigate first

Instead of:

Implement JIRA-1234.

Try:

Read specs/JIRA-1234.md.
Inspect the relevant parts of the codebase.
Identify the files that would need to change and explain your proposed implementation.
Don't modify anything yet.

This gives you a chance to catch a misunderstanding before code is generated.

Step 4 — Let the agent implement

Once the approach looks right:

Implement the proposed change. Follow the repository instructions and the specification. Add or update tests.

Step 5 — Let the agent verify

Run tests.
Run linting.
Run type checks.
Review the diff.

Step 6 — Human review

The human still owns the final decision.

The agent can propose.

The agent can implement.

The agent can test.

But the engineer decides whether the change belongs in the system.

11. The real productivity multiplier

I don't think the biggest productivity improvement comes from having a better prompt.

It comes from reducing the amount of information that has to be supplied manually every time.

Imagine two developers.

Developer A

Every task starts with:

Here's the architecture...

Here's how our tests work...

Remember that this module...

We don't use that library...

Here's the Jira description...

Here's the relevant code...

Developer B

Their repository already contains:

AGENTS.md
CLAUDE.md
.github/copilot-instructions.md
specs/
tests/
README.md

The agent can discover most of that itself.

Developer B isn't necessarily using a smarter model.

They're using a better environment.

That's the part I find most interesting.

The bottleneck isn't code generation

We're entering a phase where generating a reasonable first implementation is becoming increasingly cheap.

That doesn't mean software engineering is becoming trivial.

It means the expensive parts are moving.

From:

Writing code

towards:

Understanding the problem

Providing the right context

Making architectural decisions

Defining constraints

Building reliable feedback loops

Reviewing the result

Knowing when the AI is wrong

And perhaps most importantly:

Turning every correction into knowledge that the next AI session can use.

That's why I think the next generation of developer tooling isn't just going to be about better models.

It will be about better coding environments for those models.

The winning setup won't simply be:

Developer + LLM

It will be:

Developer + Codebase + Context + Tools + Tests + AI agent

The model is only one component.

The harness around it is what makes it useful.

And once writing code stops being the bottleneck, that's where the interesting engineering work begins.

FastAPI vs aiohttp vs httpx: A Comparative Guide

Piyush Atghara — Wed, 06 Aug 2025 11:30:53 +0000

When building modern Python web applications, selecting the right asynchronous framework or HTTP client can significantly impact your project’s performance, maintainability, and developer experience. In this article, we'll explore and compare FastAPI, aiohttp, and httpx, analyzing their strengths, use cases, and how they fit different needs within the Python ecosystem.

1. What Are These Tools?

FastAPI

A modern, fast (high-performance), web framework for building APIs with Python 3.7+ based on standard Python type hints. Built atop Starlette and Pydantic, FastAPI aims to help developers quickly build robust APIs with auto-generated docs and validation.

aiohttp

A battle-tested asynchronous HTTP client/server framework. You can use aiohttp to build both web servers and HTTP clients, but it is more low-level compared to FastAPI and doesn’t include many batteries-included features, offering flexibility at the cost of some manual work.

httpx

A next-generation HTTP client for Python. Built for async and sync support, httpx can be a drop-in replacement for requests, but with async support (via asyncio). It’s not a web framework, but a library for making HTTP requests, both to your own APIs or others.

2. Key Feature Comparison

Feature	FastAPI	aiohttp	httpx
Project Type	Web API framework	HTTP Client & Server	HTTP Client
Async Support	Yes	Yes	Yes
Type Hints	Full integration	Optional	Partial
Data Validation	Pydantic-based	Manual/parsing needed	No
API Docs	Automatic (Swagger/OpenAPI)	None	N/A
Use Case	API/services	Custom web servers/clients	HTTP requests
Community & Docs	Mature, growing	Established	Rapidly growing
Learning Curve	Gentle (with hints)	Moderate/Steep	Easy

3. When to Use Each

FastAPI

Best For: Building RESTful APIs, microservices, and data-driven backends.
Why Choose It?
- Automatic docs (Swagger/OpenAPI).
- Fantastic type checking and validation.
- Easy async support baked in.

aiohttp

Best For: Custom, lower-level async servers/clients, websockets, streaming.
Why Choose It?
- Full flexibility for both clients and servers.
- Extensive websocket and streaming support.
- Rich middleware capabilities.

httpx

Best For: Making HTTP requests from Python (both sync and async).
Why Choose It?
- Clean, request-like API with async support.
- Easy migration from requests.
- Used alongside web frameworks, not a replacement.

4. Example Code Snippets

FastAPI Example

from fastapi import FastAPI

app = FastAPI()

@app.get("/hello")
async def hello():
return {"message": "Hello, world!"}

aiohttp Example (Server)

from aiohttp import web

async def hello(request):
return web.json_response({"message": "Hello, world!"})

app = web.Application()
app.router.add_get('/hello', hello)

httpx Example (Client)

import httpx
import asyncio

async def main():
async with httpx.AsyncClient() as client:
resp = await client.get("https://example.com")
print(resp.json())

asyncio.run(main())

5. Performance & Community

FastAPI is recognized for excellent performance, sometimes comparable to Node.js and Go frameworks for API workloads.
aiohttp is robust and has powered many high-concurrency servers, but requires more manual wiring for features.
httpx is widely adopted among Python developers embracing async HTTP calls, especially for services like FastAPI.

6. Conclusion

If you need a modern, productive, batteries-included API framework: FastAPI is the go-to choice.
For both client and server needs with maximum low-level control: aiohttp is great, especially for websockets and streaming.
When making HTTP calls asynchronously or synchronously: httpx should be your preferred choice.

Decide what "layer" of your stack you’re working on, and pick the tool that fits both your needs and your team’s experience.

Feel free to drop your experiences or questions with these frameworks in the comments!

Disclaimer: This is an AI-assisted content!