What Building PPI.Studio Taught Me About Governing AI Coding Agents

Viren S — Sun, 30 Aug 2026 07:56:38 +0000

Hackathon disclosure: This article was created for the purpose of entering Google’s All Things Agentic Hackathon on Devpost (https://allthingsagentichackathon.devpost.com/). It describes the architecture, development experience, current limitations, and engineering controls behind PPI.Studio. #AllThingsAgentic

AI (Artificial Intelligence) coding agents can produce code astonishingly quickly. They can also compress an accurate technical distinction into a dangerously misleading answer, propose incomplete framework changes, and describe intended architecture as though it already exists.

While building PPI.Studio, I learned that the central challenge is not making an AI agent generate more code. It is building a development process in which every important claim, decision, and change remains traceable to evidence.

The scientific problem

PPI.Studio is being built as a closed-loop operating system for PPI (Protein–Protein Interaction) inhibitor discovery. Its first deep demonstration focuses on the MDM2–p53 oncology pathway. This is a useful proof case because the interaction is structurally understood, experimentally important, and difficult to inhibit with small molecules.

Our product principle is BYOF (Bring Your Own Friction):

Bring an unresolved scientific decision.
Bring papers, supplementary material, patents, and internal notes.
Bring messy assay tables, protein sequences, structures, and compound data.
Bring existing models, scoring functions, containers, or endpoints.

The objective is not to produce another scientific chatbot. The target system must convert heterogeneous evidence into the next defensible experiment, preserve its provenance, require scientist review, and learn from assay feedback.

The SDK incident: what actually happened

One early discussion evaluated the language support available across several Google technologies. OpenAI Codex initially produced an accurate table showing that Google Cloud Pub/Sub provided client libraries for several languages, including C++, C#, Go, Java, JavaScript, Python, PHP, and Ruby.

The conversation then narrowed to a different question:

Which of the listed technologies has an official C, C++, or Objective-C client library?

Codex answered:

“Among the listed options, only Pub/Sub has an official C++ SDK/client library.”

That statement referred to the presence of a C++ client library among the options being compared. It did not mean that Pub/Sub was available only from C++.

Seconds later, however, the answer was compressed into:

“Only Pub/Sub has C++.”

That wording erased the original qualification. It blurred three different concepts:

A service offering a dedicated language-specific client library.
A platform being able to run a program written in that language.
A project choosing a language for one particular component.

The ambiguity soon produced another mistake. Cloud Run had initially been excluded from the C++ answer because it is a container execution platform rather than a C++ SDK (Software Development Kit). But Cloud Run can host C or C++ applications packaged as Linux containers.

The correction was therefore not, “Pub/Sub secretly supports Java.” Java support had already been listed. The correction was:

Runtime support, client-library support, protocol accessibility, and project-language selection are different questions.

Google Cloud Pub/Sub has an official Java client library, published as com.google.cloud:google-cloud-pubsub, alongside libraries for several other languages. The official language instructions are documented in the Google Cloud Pub/Sub client-library reference (https://docs.cloud.google.com/pubsub/docs/reference/libraries). Go also entered the project discussion separately through Google ADK (Agent Development Kit). It was not required by Pub/Sub.

The real lesson

The failure was not a fabricated SDK boundary. It was semantic compression. A qualified technical answer was shortened until it conveyed something materially different.

This is a dangerous failure mode because the final sentence still sounds confident and technically plausible. Without returning to the original question and official documentation, a developer can make an architectural decision based on a distinction that has silently disappeared.

A second incident: framework theory without a complete implementation

A later incident occurred during Spring Boot integration. The production entry point called PPIAppStarter.start(). An agent correctly noticed that the surrounding startup structure risked bootstrapping Spring twice and shutting the application down incorrectly.

The recommended simplification was to call SpringApplication.run(...) directly.

The problem was that the recommendation removed the visible startup callback without simultaneously presenting the complete replacement mechanism. The agent explained that Spring Boot could invoke the callback through a CommandLineRunner, but the physical source file did not contain the required registered bean.

The proposal was conceptually possible but operationally incomplete. The developer caught the disconnect before treating the recommendation as finished production code. The incident still consumed approximately 36 minutes of concentrated engineering time.

Its root cause was simple:

The agent answered from framework theory before reconciling that theory with the exact file on disk.

That led to a new rule: whenever startup, initialization, lifecycle, persistence, or security code is removed, the complete replacement path must be shown at the same time. “Spring handles it” is not an implementation. The responsible answer must identify the exact class, method, registration mechanism, and execution path that makes it happen.

The controls we introduced

These incidents changed how we work with coding agents.

1. The human owns production architecture

Production code under src/main/ is human-owned. An agent may inspect it, test it, critique it, and propose changes. It cannot silently convert a suggestion into an architectural decision. Tests under src/test/ are the agent-maintained proving ground. This division keeps the agent useful without allowing generated code to outrun human understanding.

2. Interfaces and contracts are treated as change-control boundaries

Changing an interface can affect implementations, callers, tests, persistence formats, and external integrations. Any proposed interface change must therefore begin with an explicit API (Application Programming Interface) impact and blast-radius assessment. The question is not merely, “Does this compile?” It is:

Which promises change, and who depends on them?

3. Constructors perform dependency assignment

For this project, constructors are deliberately kept free of hidden object creation and startup behavior. Dependencies are passed explicitly rather than silently allocated inside constructors. This supports DIP (Dependency Inversion Principle), improves test control, and makes lifecycle ownership visible. This is a project-specific engineering constraint, not a universal claim that every Java project should prohibit new inside constructors.

4. Simplicity is a design requirement

The governing principle is:

Make it work first, then optimize it.

We avoid speculative abstractions, nested lambda pyramids, unnecessary wrappers, disconnected Maven builds, and packages created without an approved responsibility. Code that is easy to generate but difficult to debug is not an acceleration.

5. Every important claim needs an evidence class

We distinguish among:

Implemented: Present in the active source tree.
Tested: Executed successfully under stated conditions.
Local proof of concept: Demonstrated locally but not established in production.
Documented: Described in specifications or plans.
Proposed: Awaiting an architectural decision.
Unverified: Plausible, but not yet supported by direct evidence.

This vocabulary prevents a module name, interface, passing mock, or architecture diagram from being mistaken for a working system.

The current PPI.Studio foundation

PPI.Studio has been consolidated into an 18-child-module Java 21 Maven reactor. The current platform includes modules covering:

Agent contracts and deterministic state-machine foundations.
Virtual actor and supervision concepts.
Authentication and API boundaries.
Google Cloud Spanner event-store and CQRS (Command Query Responsibility Segregation) foundations.
CDC (Change Data Capture) and Pub/Sub integration.
Logging and observability foundations.
Sandboxed execution routing.
Protein, drug, in-silico, and oncophore scientific domains.

An August 29 audit recorded a successful reactor build across the declared child modules. That is useful mechanical evidence, but it is not equivalent to end-to-end product readiness.

The same audit identified an important boundary:

The protein specialist remained a skeleton.
The drug specialist remained a skeleton.
The in-silico specialist remained a skeleton.
Several production paths still contained placeholders or incomplete behavior.
Complete scientific-agent execution and live Google Cloud validation had not yet been established.

That distinction matters. The platform foundation is real. The complete scientific loop is still the target being built and verified.

The intended closed-loop workflow

The intended MDM2–p53 workflow is:

User-owned papers, structures, models, and assay data
↓
Evidence normalization with provenance and uncertainty
↓
Conflict, quality, and train/test-leakage detection
↓
Scoped protein, drug, and in-silico analysis
↓
Ranked next-experiment recommendation
↓
Explicit scientist review gate
↓
Assay feedback ingestion
↓
Updated evidence and future recommendations

The most important part is not the generated code. It is the preservation of decision authority.

Final verdict
AI coding agents are not reliable substitutes for accountable software architects. They can misunderstand questions, compress away crucial distinctions, and offer framework-correct advice that is incomplete for the physical codebase.

But under disciplined human control, they can still be formidable engineering accelerators.

PPI.Studio does not prove that autonomous coding has arrived. It demonstrates a more practical lesson:

Serious agent-assisted engineering requires explicit contracts, evidence labels, complete replacement paths, independent verification, and a human who remains responsible for every consequential decision.

The future is not autonomous code generation without friction. The future is governed acceleration.

DEV Community: Viren S