The Workflow Problem Behind the Agent

The idea came from the kind of delivery friction developers often feel before it becomes visible to the wider team.

Requirements rarely move cleanly from discussion to development, and sprint work can change while the code is already moving. 

Feature context often arrives through meetings and messages, which means one developer may understand the full picture while others work from partial knowledge.

That uneven understanding makes testing harder to trust.

Saiman wanted to solve the context problem that appears before test writing begins. Strong tests need feature clarity. 

The developer needs to understand the feature boundary, the relevant code path and the existing coverage before adding more tests to the suite.

That became the core insight behind the agent.

AI needed project context before test generation could become useful. 

Any coding assistant can produce a test from a prompt, but a useful testing agent needs project memory before it touches the test suite. That principle shaped the agent from the ground up.

Why the Agent Learns the Project Before It Writes Tests

The agent starts with codebase discovery.

It reads the application through feature boundaries and builds a working memory for each feature. That memory connects the feature to the code that supports it and the coverage that already exists around it.

This gives the agent a usable map of the project before test generation begins.

When a developer selects a feature, the agent already understands the scope it needs to work inside. 

It can create a test plan from the right project context rather than treating the codebase as one large surface.

That control matters because AI-generated tests become harder to trust when the model has too much room to guess. 

It may invent behavior the application never had. It may bring unrelated files into the testing path. It may produce clean-looking tests that misunderstand the feature.

Saiman reduced that risk by making project knowledge the guardrail.

The feature-based knowledge base gives the agent a controlled working area before it plans or validates tests. That makes the output more grounded and easier for developers to trust.

Making the Agent Usable in Real Project Work

Once a feature is selected, the agent turns project context into a test plan before writing any test code. 

Saiman kept developer approval inside the workflow because AI-generated tests still need engineering judgment before they become part of the suite.

C# became the first test bed because it gave the agent a real Proshore environment to prove itself. 

Saiman’s .NET background made that starting point practical, while real project constraints exposed details a clean demo would miss.

In .NET projects, small setup differences can decide whether the workflow works at all. Version differences, xUnit behavior and command setup all shaped how reliable the agent had to become.

The first version proved the core pipeline. Version two made it more usable by tightening the connection between project context and validation.

Turning AI From Experiment Into Delivery Output

The first measurable impact showed up in test coverage. 

In one project, coverage moved from about 5% to 25–30% per sprint while developers still reviewed the work. That took the agent out of demo territory and tied AI directly to delivery output.

The larger value is what the result signals for Proshore. Saiman’s agent shows how internal AI can strengthen the engineering system by removing the context work that slows delivery. 

Testing became the first strong use case because the friction was visible and the progress could be measured.

The same principle now extends into code review and bug fixing. It also applies to stakeholder communication where project context often breaks before it reaches development. 

DevOps fits the same pattern through setup work and secret management.

Proshore is using AI to find the points where delivery slows, then turning those pressure points into practical engineering capability.

What Comes Next for AI at Proshore

The strongest part of Saiman’s agent is where it came from. It was built from the developer side of the workflow, where the testing problem was already visible in real project work.

Saiman focused on a specific engineering problem. Testing is needed for a stronger project context before it can become faster and more reliable.

That makes the agent valuable as more than an AI experiment. It behaves like a workflow layer. It understands the project before planning tests. 

It keeps developer approval inside the process. It feeds validated results back into project memory.

The current build lives in C# because that was the clearest place to prove the approach. 

The next step is expansion into Python and PHP, which would make the same testing flow useful across more Proshore teams.

This is the larger value of the project. Proshore is using AI to improve its own engineering system from the inside, and Saiman’s testing agent is one concrete proof point of that direction.