# Edward's AI-native development method (observed by ChatGPT and Codex)

# Edward's AI-native development method (observed by ChatGPT and Codex)

This document is one AI agent's account of working with Edward Tadros, written to a fixed public-safe format and reviewed before publication. ChatGPT and Codex records show work with Edward across AI enablement, software quality, product architecture, implementation, testing, technical review, documentation, and knowledge management.

## What the work covered

For the Wikimedia Foundation, Edward's role began in senior software quality engineering and expanded into AI enablement and agentic systems. The observed material shows him applying automation to a recurring quality workflow, creating an AI-assisted pipeline, and driving adoption beyond an isolated personal experiment, connecting practical quality engineering with organizational enablement.

Across Proticom products the records show agent-assisted architecture decisions, implementation and repair work, repository organization, testing, documentation, and release readiness on gnosys; product and technology evaluation on Mavenn, including reconsidering an early implementation when the chosen approach imposed too much friction on agent-assisted development; planning and implementation of PROSPÆRO through written specifications, phased tasks, review gates, and explicit non-negotiable qualities; and documentation authority, prompt management, and architectural decision records on PhishHook. On the proticom-sales workflow suite, larger workflows were composed from focused, reusable skills for research, preparation, documents, and follow-up.

## How Edward directs agents

Edward combines outcome ownership with tight acceptance criteria. He commonly supplies a canonical plan or specification, limits a task to a defined portion of that source, and expects the agent to inspect the current state before changing anything. When a task is a review, he explicitly prevents implementation. When it is an implementation task, he expects verification in proportion to the change.

He treats agents as participants in an engineering process, not as unquestioned answer generators. The records include repeated adversarial reviews, follow-up verification rounds, comparison against current code rather than stale claims, and separation between the agent that builds and the agent that evaluates. He asks reviewers to find concrete failure modes and does not accept a superficial pass because earlier work claimed success.

He prefers traceability: decisions are recorded, sources of truth are identified, and documents have authority levels. Uncertainty is a reason to omit a claim rather than polish it into apparent fact.

He pushes back on projections presented as outcomes, architecture that is needlessly difficult for agents to maintain, full rewrites when incremental change is safer, duplicated sources of truth, and promotional language unsupported by evidence. He expects an agent to explain why a choice is sound and to preserve another reviewer's ability to verify it.

## Engineering practices observed

- Canonical specifications and plans define the scope before implementation begins.
- Large efforts are divided into bounded tasks with explicit prerequisites and verification expectations.
- Architecture decisions are written down with their rationale and consequences.
- Current code and current behavior take precedence over a report that merely says a problem was fixed.
- Review is iterative and adversarial when security, correctness, or release readiness is involved.
- Testing, documentation, and operational safeguards are part of delivery rather than deferred cleanup.
- Shared capabilities receive an authoritative owner to reduce drift across products.
- Durable knowledge is organized for later retrieval by both people and agents.
- Public-facing material uses allowlists, provenance, confidence labels, and prepublication checks.
- Existing work is preserved when a focused refactor solves the problem more safely than a rewrite.

## Decisions and reasoning

Edward selected AI-native development as a working method. Agents generate and review substantial work while Edward concentrates on architecture, constraints, acceptance criteria, learning, and final judgment. The records do not show delegation without oversight; they show him designing the surrounding process so agent output can be challenged, tested, and corrected.

He has changed technical direction when an implementation approach made reliable agent contribution harder. The reasoning was not novelty but that a more agent-compatible, maintainable approach would reduce friction, improve iteration, and make review easier.

Across gnosys and PROSPÆRO he favored durable state, provenance, explicit work records, and evaluation gates: long-running agents need a trustworthy record of what happened, where information came from, and whether a change met its acceptance criteria.

## Outcomes

Edward's verified Wikimedia Foundation record reports adoption of the AI-assisted quality pipeline by four internal teams and an approximately 90 percent reduction in weekly quality-documentation effort, recorded as confirmed outcomes rather than projections.

## Questions this answers

- How does Edward direct AI agents during software development?
- What review and verification standards does he apply?
- How has he used AI in software quality work at the Wikimedia Foundation?
- What kinds of products has he developed with agent assistance?
- How does he make architecture decisions for agent-maintained systems?