Reverse-Engineering-Driven Harness Engineering for Existing Applications

AI-driven legacy modernization is often discussed in terms of understanding, refactoring, or rewriting existing codebases.

But with AI coding agents such as Claude Code and Codex, another direction is becoming increasingly practical: enabling agents to operate and extend existing applications through their existing interfaces, without necessarily rewriting their code.

This is especially relevant to low-code platforms and enterprise systems, where business logic is often distributed across GUI configurations, workflows, metadata, and operational procedures.

Recently, I've been applying an approach that combines reverse engineering, harness engineering, operations research (OR), and runtime engineering to this problem.

The idea is straightforward: discover how an application behaves, convert that knowledge into reusable operational capabilities, and provide an execution environment in which AI agents can achieve business goals while respecting the application's constraints.

This article describes the approach as a practical system design and implementation framework.

1. The Problem Is Not Just GUI Automation

Consider adding an approval workflow to an existing low-code application.

A developer would need to inspect the current application, understand its data and workflow structures, identify the relevant configuration screens, make changes, and verify the result.

An AI agent needs to do essentially the same work.

Providing GUI automation alone does not solve this problem. The agent may be able to click buttons and enter values, but it still needs to understand:

• Which operations are available and when they are valid.
• Which application states and permissions are required.
• How a change affects existing functions.
• Whether an operation actually persisted its intended result.
• How to verify that the business requirement has been satisfied.

This requires more than tools. It requires application-specific operational knowledge.

GUI automation provides actions. Harness engineering provides the knowledge and controls needed to use those actions reliably.

The objective is not merely to automate an existing workflow. It is to enable AI agents to operate, configure, and extend existing applications through supported interfaces.

2. The Architecture

I've been organizing this work into five connected phases:

1. Goal Definition: Define the required business outcome and acceptance criteria.
2. Reverse Engineering: Discover application behavior, states, dependencies, and constraints.
3. Harness Construction: Convert discovered knowledge into executable operational capabilities.
4. Agent Execution: Plan, operate, observe, verify, and recover.
5. Goal Evaluation: Determine whether the business outcome has been achieved.

The system architecture looks like this:

flowchart TB
    G["Business Goal<br/>Acceptance Criteria"]
    A["AI Agent<br/>Claude Code / Codex"]

    subgraph H["Agent Harness"]
        direction TB
        E["Executable Operational Model<br/>States · Actions · Effects · Constraints"]
        P["Planner<br/>Strategy Selection"]
        R["Runtime<br/>Execution · Observation · Recovery"]
        V["Evaluator<br/>Business Rules · Regression"]
    end

    S["Existing Application<br/>GUI · Configuration · Metadata"]
    RE["Reverse Engineering<br/>Observe · Analyze · Validate"]

    G --> A
    A --> E
    E --> P
    P --> R
    R --> S
    S --> RE
    RE --> E
    R --> V
    V --> G

The four engineering disciplines are not separate systems. They represent different responsibilities within this process.

• Reverse Engineering discovers and validates application behavior.
• Harness Engineering organizes that knowledge into reusable capabilities and controls.
• Operations Research supports action selection under cost, risk, and operational constraints.
• Runtime Engineering handles reliable execution, state tracking, verification, and recovery.

The key artifact connecting these activities is what I call an Executable Operational Model (EOM).

3. From Reverse Engineering to Executable Operational Knowledge

Traditional reverse engineering often produces documentation, design models, or recovered specifications.

Here, the goal is different.

The discovered knowledge must be usable by an AI agent during execution.

For low-code applications, reverse engineering may involve GUI observation, operation recording, input/output comparison, state-transition analysis, and inspection of available metadata or generated code.

For example, while exploring an approval workflow designer, the agent might discover that:

• A workflow must be unlocked before modification.
• Saving a change does not automatically activate it.
• Certain configuration changes affect dependent workflows.
• Validation errors become visible only after a specific operation.

These observations can be converted into structured operational knowledge.

An EOM describes not only how to perform an operation, but also its expected effects, constraints, and verification conditions.

Element	Purpose
State	Current or inferred application state
Action	An operation available through a supported interface
Preconditions	Conditions required before execution
Effects	Expected changes resulting from the operation
Invariants	Conditions that must remain true
Verification	How actual effects are confirmed
Recovery	How failures or uncertain outcomes are handled
Confidence	Whether knowledge is observed, hypothesized, or validated

Consider a workflow configuration operation:

operation: update_approval_workflow

preconditions:
  - design_is_unlocked
  - user_has_permission

actions:
  - inspect_current_configuration
  - update_approval_rules
  - save_configuration

expected_effects:
  - workflow_configuration_updated

invariants:
  - existing_records_preserved
  - unrelated_workflows_unchanged

verification:
  - reopen_configuration
  - compare_with_expected_rules
  - run_workflow_tests

recovery:
  - inspect_actual_state
  - restore_previous_configuration_if_safe

knowledge_status: validated

This is a simplified example, not a required schema.

A conventional Skill may describe how to perform a task. The EOM provides the broader operational context: when actions are valid, how they change state, what must remain unchanged, and how correctness is established.

In practice, the EOM does not need to exist as a single file or formal modeling engine. It can be distributed across Skills, configuration files, tools, state models, and test definitions.

The important transformation is:

Reverse engineering discovers application behavior. Harness engineering converts that knowledge into executable operational capabilities.

4. Harness Engineering: Building the Execution Environment

The harness connects the AI agent to the existing application.

For Claude Code or Codex, it may include application instructions, Skills, GUI tools, CLI commands, MCP integrations, state inspection utilities, evaluators, and recovery procedures.

These components serve different purposes.

Instructions and Skills provide reusable operational knowledge. Tools expose supported application interfaces. State models and policies determine which actions are valid. Evaluators establish whether the intended results were achieved.

The harness should also distinguish between observing an application and modifying it.

For example, generated code or metadata may be useful for understanding structure and dependencies. However, directly modifying generated code may bypass a low-code platform's supported configuration mechanisms.

In such systems, I prefer using code analysis for understanding and impact review while performing changes through the platform's supported design interfaces.

The harness therefore becomes an application-specific engineering environment, rather than just a set of commands available to an LLM.

5. Planning: Choosing What to Do and What to Investigate

Once the agent has operational capabilities, it must decide how to use them.

There may be several ways to reach the same goal.

For example, changing approval rules might involve a known GUI procedure, a shorter but less-tested sequence, or a supported administrative interface.

The shortest procedure is not always the best choice.

Operations research provides useful concepts for selecting strategies under constraints.

In practice, planning can consider:

• Expected execution time and tool cost.
• Dependencies between operations.
• Reliability of previously observed procedures.
• Risk of unintended changes.
• Required permissions and approval boundaries.
• Uncertainty about the current application state.

A known procedure may be preferable for production changes, while an unfamiliar but potentially faster approach may be worth exploring in a sandbox.

There is also another decision: whether to act immediately or gather more information first.

Suppose the agent does not know whether saving a workflow also activates it.

It could proceed based on an assumption, inspect the current configuration, or test the behavior in an isolated environment.

Investigation has a cost, but it can reduce the risk of an incorrect change.

This connects the approach to ideas such as value of information, exploration versus exploitation, and planning under partial observability.

I do not assume that every implementation needs a mathematical optimizer or a POMDP solver. Dependency graphs, policy checks, heuristic scoring, and risk-based replanning are often more practical starting points.

The important design principle is to separate responsibilities:

The LLM interprets goals and reasons about unfamiliar situations. The EOM supplies application-specific knowledge. Planning logic selects feasible strategies, while policies enforce hard constraints.

This makes action selection more explicit and easier to evaluate.

6. Runtime Engineering: Handling Uncertain Execution

Even a well-planned operation can fail.

GUI interfaces are often asynchronous, stateful, and difficult to control precisely.

Consider a simple example.

The agent updates an approval rule and clicks Save. The application times out.

At that moment, the agent does not know whether the change failed, succeeded, or partially completed.

Blindly repeating the operation may be unsafe.

This illustrates a fundamental distinction:

Action completed ≠ State changed ≠ Business goal achieved.

A reliable runtime needs to handle these as separate conditions.

Execution state and checkpoints

The runtime should record the intended action, application state before execution, observed result, and subsequent verification.

If execution is interrupted, the agent should be able to determine what has already happened before continuing.

Effect reconciliation

When an operation produces an uncertain result, the runtime should inspect the actual application state before retrying.

For example, after a save timeout, it may reopen the workflow configuration and compare the stored values against the intended changes.

The principle is simple:

Observe the actual state before repeating an uncertain operation.

Recovery and compensation

GUI-driven changes may not support atomic transactions or reliable rollback.

Recovery may require compensating operations, such as restoring a previous configuration through the supported interface.

Such recovery must also be verified, since compensation is not necessarily equivalent to reverting a database transaction.

Approval boundaries

Not every operation should be fully autonomous.

Read-only inspection and sandbox exploration may require little supervision. Production configuration changes, destructive operations, or irreversible actions may require explicit human approval.

The runtime must enforce these boundaries rather than relying on the LLM to remember them.

Together, these mechanisms provide the reliability needed for application engineering through existing interfaces.

7. A Practical Example: Extending a Low-Code Application

To see how the components fit together, consider adding a new approval workflow to an existing order-management application.

This is an illustrative scenario, not a claim of measured experimental results.

Step 1 — Define the goal

The new workflow must allow authorized users to submit orders for approval, apply routing rules, preserve approval history, and avoid breaking existing order processing.

These become explicit acceptance criteria.

Step 2 — Discover the application

The agent inspects the existing forms, data objects, workflow designer, and approval settings.

Through controlled operations, it identifies relevant dependencies and discovers that workflows must be unlocked before editing and separately activated after saving.

These findings are recorded with their validation status.

Step 3 — Update the EOM and harness

The discovered operations become reusable procedures.

The harness records editing prerequisites, expected configuration changes, validation steps, and recovery options.

It also provides tools to inspect the current workflow state and compare configurations before and after modification.

Step 4 — Plan and execute

The agent selects a modification sequence based on dependencies, known procedures, and operational constraints.

It uses the low-code designer to create or update the required workflow.

After each significant change, the runtime checks whether the expected state was reached.

If an operation fails or produces an uncertain result, the agent reconciles the actual state before retrying or replanning.

Step 5 — Evaluate the business outcome

The evaluator checks whether approval routing works, permissions are enforced, approval history is retained, and existing order-processing tests still pass.

If a test fails, the agent investigates the difference between expected and observed behavior.

Newly discovered constraints or successful recovery procedures can then be proposed as improvements to the harness.

The artifacts produced at each step are:

Step	Engineering artifact
Goal Definition	Business acceptance criteria
Reverse Engineering	Observations, state knowledge, dependencies
Harness Construction	Operational model, Skills, policies, evaluators
Execution	Action history, state evidence, recovery records
Evaluation	Test results and validated improvement candidates

This is what makes the approach more than GUI automation.

The agent is not following a fixed script. It is performing application engineering using accumulated operational knowledge, feedback, and explicit verification.

8. Continuous Improvement of the Harness

Reverse engineering does not end when the initial harness is built.

Every execution can reveal new information.

A failed operation may expose an unknown precondition. An unexpected configuration state may reveal a missing dependency. A more reliable procedure may emerge from repeated execution.

These findings can improve the EOM, Skills, evaluators, and recovery logic.

However, learning must be controlled.

An observed behavior should not automatically become a business rule. A successful workaround should not immediately replace a validated procedure.

Changes to operational knowledge need evidence, validation, versioning, and appropriate review.

This is particularly important when the harness supports application modifications rather than read-only operations.

The central idea is:

The harness is not merely built from reverse engineering. It becomes the mechanism through which reverse engineering continues.

Over time, this can make application-specific knowledge reusable across tasks and agent sessions instead of requiring the agent to rediscover everything from the GUI.

9. Scope, Limitations, and Evaluation

The framework primarily targets three kinds of work:

• Operation: Using existing application functions.
• Configuration: Modifying supported settings and workflows.
• Extension: Building new functionality through existing design interfaces.

It does not require rewriting the application's implementation. However, it cannot create functionality that the underlying platform does not support.

Several limitations remain.

GUI observation provides only a partial view of application behavior. Interface changes can invalidate previously discovered procedures. Some operations are difficult to make idempotent, and business correctness may require domain experts or independent test systems.

The approach also introduces an initial engineering cost: discovering application behavior, defining operational knowledge, building tools, and implementing evaluators.

Whether this investment produces a net benefit depends on how frequently the harness is reused and how effectively it improves execution.

A useful evaluation would compare three configurations:

1. A general-purpose GUI agent.
2. A GUI agent with manually defined Skills.
3. An agent using discovered operational knowledge, constrained planning, and a reliability-oriented harness.

Relevant metrics include goal completion rate, acceptance-criteria coverage, recovery success, regression violations, execution cost, and adaptation effort after application changes.

Such comparisons are needed to quantify the benefits. The architecture itself does not establish performance improvements.

Conclusion

AI-driven modernization does not always need to begin with rewriting existing code.

For many applications, another useful direction is to build the knowledge and execution environment that allows AI agents to operate and extend them through supported interfaces.

The approach I've been applying connects four engineering concerns:

Reverse Engineering discovers application behavior and constraints.

Harness Engineering converts that knowledge into reusable operational capabilities.

Operations Research supports decisions about which actions to take and when to gather more information.

Runtime Engineering provides reliable execution, state verification, and recovery.

The common foundation is an Executable Operational Model: a reusable representation of application states, operations, expected effects, constraints, and verification procedures.

The most important change is not simply that an AI agent can interact with an existing application.

It is that knowledge discovered from the application becomes an engineering asset that can guide future operations, support application changes, and improve through verified execution.

That creates another path for evolving existing systems: not necessarily by replacing their implementation, but by engineering how AI agents can understand, develop, and operate them.