DEV Community: HyunKi Lee

Why AI Coding Agent Tools Prefer Grep Over LSP Servers

HyunKi Lee — Mon, 05 Oct 2026 05:18:12 +0000

Why AI Agents Prefer Grep Over LSPs

The Context Retrieval Paradox

When designing context retrieval pipelines for autonomous software engineers, the intuitive architectural choice is to integrate a Language Server Protocol (LSP) client. LSPs provide precise Abstract Syntax Tree (AST) parsing, type resolution, and reference tracking. They represent the standard for developer tooling in human-centric integrated development environments. Yet, in production environments, autonomous systems frequently favor line-oriented text search tools over semantic graph queries.

This preference is not a regression in engineering standards. It is a rational adaptation to the constraints of large language model context windows and the realities of intermediate, non-compiling codebases. While an LSP offers deep semantic understanding, it requires a stable, fully configured environment to function. For an autonomous agent operating in a dynamic, sandboxed workspace, the overhead and fragility of maintaining an active language server often outweigh the benefits of semantic precision.

The Fragility of the Compilation Graph

To understand why AI coding agent tools lean toward text-matching utilities, one must examine the lifecycle of code during an automated editing session. A human developer typically writes code in a semi-continuous flow, resolving syntax errors before attempting to compile or run tests. The LSP runs in the background, constantly updating its index based on a mostly valid codebase.

However, when an autonomous agent performs a multi-file refactor, it often leaves the codebase in a broken state across several steps. It might modify a function signature in one file, leaving three other files referencing the old signature while it plans the next edit.

During these intermediate states, the compilation graph is broken. Traditional language servers build their index by parsing files into an AST, resolving imports, and building a global symbol table. If an import is broken because the agent is in the middle of renaming a module, the entire dependency resolution step fails. This cascades down, causing the LSP to lose track of types and symbols across unrelated files. If the system relies on an LSP for context retrieval during this phase, the language server will often return incomplete symbol trees, fail to resolve references, or crash entirely.

A text-search utility, by contrast, operates independently of compilation state. It does not care if a closing brace is missing on line 104 or if a dependency is unresolved in the package manifest. It returns the requested string matches regardless of syntax validity.

Latency, Resource Footprint, and Sandbox Constraints

In a production agent architecture, tasks are executed within isolated sandboxes to ensure security and reproducibility. Spinning up a language server inside a fresh sandbox introduces significant latency.

Initializing a language server for a large project requires several steps:

Installing all project dependencies.
Generating build artifacts or compilation databases.
Running the language server indexer, which can consume gigabytes of memory and take minutes to complete.

For short-lived agent tasks, this initialization phase can take longer than the actual code modification - a clear bottleneck. In contrast, a compiled text-search utility can scan a directory containing thousands of files in milliseconds with a negligible memory footprint, requiring zero configuration or dependency installation.

The Interface Alignment Problem

There is also a fundamental mismatch between the output of an LSP and the input requirements of a language model. An LSP returns structured JSON-RPC responses containing nested AST nodes, URI paths, and character offsets. To make this data useful to an agent, the system must serialize it into a text representation.

This serialization process often introduces noise and consumes valuable tokens. A raw text-search utility returns flat, line-oriented text spans. These spans map directly to the line-by-line format that language models are trained to read and generate.

Below is a pseudo-code implementation illustrating how an agent context retrieval pipeline handles these two approaches, highlighting the robustness differences when encountering broken code.

# Pseudo-code illustrating the difference in robustness between LSP and Grep retrieval

class ContextRetrievalPipeline:
    def __init__(self, workspace_path):
        self.workspace_path = workspace_path
        self.lsp_client = None

    def retrieve_with_lsp(self, query_symbol):
        # LSPs require a running server and a valid compilation state
        if not self.lsp_client or not self.lsp_client.is_healthy():
            try:
                self.lsp_client = self.initialize_lsp_server()
            except Exception as e:
                # If compilation files are missing, initialization fails
                return f"LSP Initialization Failed: {str(e)}"

        try:
            # Querying the LSP for references
            references = self.lsp_client.find_references(query_symbol)
            return self.serialize_lsp_references(references)
        except Exception:
            # If the code is currently broken, the LSP returns empty or inaccurate results
            return "LSP Query Failed: Codebase in non-compilable state"

    def retrieve_with_grep(self, query_pattern):
        # Grep-based search bypasses the compilation graph entirely
        try:
            results = self.execute_text_search(query_pattern)
            return self.format_text_results(results)
        except Exception as e:
            return f"Search Failed: {str(e)}"

    def initialize_lsp_server(self):
        # Simulates the complex setup required for language servers
        pass

    def serialize_lsp_references(self, references):
        pass

    def execute_text_search(self, pattern):
        # Simulates running a fast, line-oriented search tool
        pass

    def format_text_results(self, results):
        pass

The Hybrid Approach in Modern Architectures

While text search is highly robust, it lacks semantic awareness. It cannot distinguish between a function definition and a comment containing the function name. To bridge this gap, modern AI coding agent tools are adopting hybrid retrieval strategies.

Instead of relying on a full LSP server, these systems use lightweight, tree-sitter-based parsers to build local, partial ASTs on demand. Tree-sitter is an incremental parsing library that can build a concrete syntax tree for a source file and efficiently update it as the file is edited. Crucially, tree-sitter is designed to be highly error-tolerant. It can parse files with syntax errors by inserting error nodes and continuing to parse the rest of the file.

The system can use a fast text search to locate candidate files and lines, then apply a local tree-sitter parser to extract the surrounding class or function block, even if the rest of the file or project contains syntax errors. This limits the failure domain to a single file rather than the entire compilation unit.

Conclusion

The choice between LSPs and text-search utilities highlights a core principle of system design: robustness under failure is often more valuable than precision under ideal conditions. For autonomous agents operating in dynamic, intermediate states, the fault tolerance and speed of line-oriented search make it the superior foundation for context retrieval.

To read more about our engineering decisions and system design patterns, read the full article on bridgedev.io.

Building our context-aware parsing engine for Mobile

HyunKi Lee — Mon, 28 Sep 2026 18:31:34 +0000

Building a Context-Aware Parsing Engine for Mobile Architectures

Dumping an entire multi-module mobile repository into a large context window does not work. While modern models advertise context windows of one million tokens or more, retrieval accuracy degrades rapidly when the input is unstructured raw text. In mobile development, where architectures rely heavily on implicit dependency injection, protocol-oriented programming, and multi-module separation, raw text search fails to capture the execution path.

To solve this, we built a context-aware parsing engine. Instead of treating a codebase as a flat sequence of characters, the engine maps the repository into a deterministic directed graph. This graph represents the structural, logical, and architectural relationships of the codebase. When the planner needs to reason about a specific component, the engine queries this graph to extract a highly relevant, pruned subgraph. This approach ensures that the context window contains only the precise code paths and interfaces necessary for the task, eliminating noise and preserving model attention.

The Structural Complexity of Mobile Codebases

Mobile applications present unique challenges for static analysis. Unlike monolithic backend systems that often follow linear execution paths, modern iOS and Android applications are highly decoupled. They rely on:

Protocol-oriented programming or interface-driven development.
Dependency injection frameworks that resolve implementations at runtime.
Multi-module architectures where code is split across dozens of independent targets.

If a developer asks the system to modify a payment flow, a naive search might locate the view controller. However, the actual business logic resides in a presenter or view model located in a separate module, which communicates via a protocol defined in a third API module. The concrete implementation of that protocol is injected at runtime by a dependency injection container.

Without a deterministic map of these relationships, the system cannot locate the code that actually needs to change. It is forced to guess, leading to incomplete context and broken implementations.

Designing the Context-Aware Parsing Engine

The engine operates in three distinct phases: extraction, resolution, and pruning.

Phase 1: Extraction

We use tree-sitter parsers to generate concrete syntax trees for every source file in the repository. From these trees, we extract key architectural entities:

Classes, structs, and actors
Protocols and interfaces
Method signatures and properties
Import statements and module declarations
Dependency injection registrations

Phase 2: Resolution

Once the entities are extracted, the engine resolves the relationships between them. This is where we build the directed graph. Nodes represent entities, and edges represent relationships such as inheritance, conformance, imports, or calls.

Resolving implicit dependencies requires custom heuristics. For example, if class A's initializer accepts an argument of protocol type P, the engine searches the graph for classes that conform to P. If a dependency injection module binds P to concrete class B, the engine creates a directed edge from A to B labeled as a dependency.

Phase 3: Pruning

When a task is initiated, the engine does not send the entire graph. Instead, it identifies the target file and performs a depth-limited traversal of the graph. It selects the target file, its immediate dependencies, the protocols it conforms to, and the concrete implementations of those protocols. This pruned subgraph is then serialized into a structured format for the planner.

Implementation Sketch

Below is a pseudo-code implementation demonstrating how the parsing engine processes a file, extracts entities, and registers them into a dependency graph.

# Pseudo-code: Context-Aware Graph Construction Engine

class Entity:
    def __init__(self, name: str, entity_type: str, file_path: str):
        self.name = name
        self.entity_type = entity_type  # e.g., "class", "protocol", "struct"
        self.file_path = file_path
        self.dependencies = []
        self.conformances = []

class CodebaseGraph:
    def __init__(self):
        self.nodes = {}  # Map of entity name to Entity object
        self.edges = []  # List of tuples (source, target, relation_type)

    def add_entity(self, entity: Entity):
        self.nodes[entity.name] = entity

    def add_relation(self, source: str, target: str, relation_type: str):
        self.edges.append((source, target, relation_type))

    def resolve_protocols(self):
        # Resolve which concrete classes implement which protocols
        for node_name, entity in self.nodes.items():
            for conformance in entity.conformances:
                if conformance in self.nodes:
                    self.add_relation(node_name, conformance, "conforms_to")

class ParsingEngine:
    def __init__(self, graph: CodebaseGraph):
        self.graph = graph

    def parse_file(self, file_path: str, file_content: str):
        # In practice, this uses tree-sitter to walk the AST
        # Here we simulate the extraction of a class and its dependencies
        lines = file_content.split("\n")
        current_entity = None

        for line in lines:
            line = line.strip()
            if line.startswith("class ") or line.startswith("struct "):
                parts = line.split()
                name = parts[1].split(":")[0].strip()
                current_entity = Entity(name, "class", file_path)

                # Check for inheritance or protocol conformance
                if ":" in line:
                    conformance_part = line.split(":")[1]
                    conformances = [c.strip() for c in conformance_part.split(",")]
                    current_entity.conformances.extend(conformances)

                self.graph.add_entity(current_entity)

            elif "init(" in line or "constructor(" in line:
                # Extract injected dependencies from initializer signature
                if current_entity:
                    # Simple heuristic to find typed parameters
                    # e.g., init(service: PaymentService)
                    if ":" in line:
                        param_part = line.split("(")[1].split(")")[0]
                        for param in param_part.split(","):
                            if ":" in param:
                                dep_type = param.split(":")[1].strip()
                                current_entity.dependencies.append(dep_type)

    def finalize_graph(self):
        # Connect dependencies to their resolved entities
        for node_name, entity in self.graph.nodes.items():
            for dep in entity.dependencies:
                if dep in self.graph.nodes:
                    self.graph.add_relation(node_name, dep, "depends_on")
        self.graph.resolve_protocols()

Managing Multi-Module Boundaries

In large mobile applications, code is frequently split across dozens of local modules or packages to improve build times and enforce separation of concerns. A change in a core module can have cascading effects on multiple feature modules.

Our parsing engine handles this by parsing package manifests, such as Swift Package Manager Package.swift files or Gradle build files. By mapping module-level dependencies first, the engine establishes a high-level topology of the repository. When a class in a feature module is modified, the engine uses this topology to identify which upstream modules must be analyzed for potential breaking changes, and which downstream modules must be updated to accommodate the new interface.

Evaluating the Trade-offs

Building a custom parsing engine involves significant trade-offs compared to using off-the-shelf vector databases or simple keyword search.

1. Maintenance Overhead vs. Precision

Vector databases are language-agnostic and require zero configuration. However, they lack semantic understanding of code relationships. A vector search for a specific service might return the UI layout file, the network client, and the local database schema, but it cannot tell the planner how these files interact. The parsing engine requires custom AST queries for each language, but it provides absolute precision.

2. Static vs. Dynamic Analysis

Our engine relies entirely on static analysis. While dynamic analysis, such as tracing execution paths at runtime, can capture highly dynamic behaviors, it requires compiling and running the application. In mobile development, compilation is slow and environment-dependent. Static analysis allows the engine to map the codebase instantly without requiring a successful build environment.

3. Graph Density vs. Context Window Limits

If the graph is too dense, traversing it can pull in too many files, defeating the purpose of pruning. We address this by categorizing relationships. Imports are treated as weak edges, while inheritance and dependency injection bindings are treated as strong edges. The pruning algorithm prioritizes strong edges, ensuring that only the critical execution path is loaded into the context window.

The Fallacy of the Infinite Context Window

There is a common belief that as context windows expand, the need for sophisticated retrieval systems diminishes. This is a misunderstanding of how transformer models process information. Attention mechanisms scale quadratically with sequence length. More importantly, irrelevant code acts as distractor material, increasing the likelihood of hallucinations or missed details.

By front-loading the structural analysis into a deterministic parsing engine, we narrow the decision space before the planner ever receives the prompt. The planner does not need to figure out how the modules are connected; the engine has already solved that. This separation of concerns, deterministic mapping for structure, probabilistic reasoning for implementation, is the only reliable way to handle large-scale mobile architectures.

Conclusion

Mapping complex mobile codebases into deterministic graphs is essential for accurate code generation and analysis. By combining AST parsing with dependency resolution, a context-aware parsing engine ensures that the planner operates with the exact structural context it needs.

To learn more about how we design deterministic systems for mobile development, read the full article on bridgedev.io: https://bridgedev.io/blog/building-our-context-aware-parsing-engine-for-mobile?utm_source=devto&utm_medium=social&utm_campaign=blog

Preventing AI Coding Mistakes: Proofs vs Planning

HyunKi Lee — Tue, 22 Sep 2026 14:47:20 +0000

Blocking AI Mistakes: Proofs vs Planning

When a code generation system outputs a 500-line React component with a subtle state-synchronization bug, the standard developer response is to feed the error log back into the model. This feedback loop is an expensive, non-deterministic way to write software. It treats code generation as an optimization problem to be solved after the fact, rather than a system design problem to be constrained before execution.

The Core Problem of Post-Hoc Debugging

The core issue in preventing AI coding mistakes is the phase at which constraints are applied. In traditional software engineering, we have two primary paradigms for ensuring correctness: formal verification (proofs) and structured planning (specifications). When using generative models to write code, developers often skip both. They rely on the model to infer the specification from a loose prompt, leading to hallucinated APIs, broken state transitions, and architectural drift.

To build reliable software with generative systems, we must shift our focus from post-hoc debugging to pre-generation constraint definition. This article compares the utility of mathematical proofs with structured planning, demonstrating why front-loading the planning phase is the most viable path to preventing AI coding mistakes.

The Limits of Formal Proofs in Generative Workflows

Formal verification, using tools like TLA+, allows developers to mathematically prove that a system design meets specific correctness properties. In theory, one could generate code and then run it through a formal proof solver to guarantee its correctness.

In practice, this approach fails for generative workflows due to three primary bottlenecks:

Specification Complexity: Writing a formal specification that is complete enough to prove a program correct is often more difficult than writing the program itself.
State Space Explosion: For typical business applications with database interactions, network calls, and user interfaces, the state space is too large for practical proof solvers to evaluate in real time.
Lack of Flexibility: Business requirements change rapidly. A formal proof must be rewritten with every minor change to the user flow, creating a massive maintenance bottleneck.

Relying solely on post-generation verification, such as running unit tests or static analysis, only catches syntax errors or basic type mismatches. It does not catch logical drift or architectural misalignment. If the system generates a function that perfectly passes its unit tests but implements the wrong business logic, the test suite is green, but the application is broken.

Structured Planning as a Constraint Engine

Instead of verifying code after it is written, we must constrain the decision space before the system generates a single line of code. This is the core of the planning as execution methodology. By narrowing the decision space early, we eliminate the vast majority of potential generation errors.

A structured plan for a generative system consists of three core pillars:

Clear User Stories: These define the state transitions and business rules.
Strict Data Schemas: These define the boundaries of data flow and database interactions.
Explicit UX Flows: These define the interaction model and user interface states.

When these three pillars are defined as structured data, they act as a constraint engine. The planner no longer has to guess the database schema or the state management library; those decisions are locked down. The generation task is reduced from writing a checkout feature to implementing a function that maps state A to state B using schema C.

A Concrete Workflow Sketch

To illustrate this approach, let us look at a methodology sketch. We will define a structured plan in JSON format and show a simple Python runner that validates this plan before code generation.

Here is a pseudo-code representation of a planning manifest for a checkout feature:

{
  "feature": "Discount Code Application",
  "state_transitions": [
    {
      "from": "CartEmpty",
      "to": "CartWithItems",
      "trigger": "ADD_ITEM"
    },
    {
      "from": "CartWithItems",
      "to": "DiscountApplied",
      "trigger": "APPLY_DISCOUNT",
      "constraints": [
        "discount_code_must_exist",
        "discount_not_expired"
      ]
    }
  ],
  "schema": {
    "Cart": {
      "items": "array",
      "subtotal": "decimal",
      "discount_total": "decimal",
      "grand_total": "decimal"
    },
    "Discount": {
      "code": "string",
      "percentage": "decimal",
      "is_active": "boolean"
    }
  }
}

Now, let us look at a Python script that acts as the validator. This script ensures that the plan is logically consistent before we pass it to the code generation system.

# validator.py
# A simple runner to validate the planning manifest before code generation

import json

class PlanValidator:
    def __init__(self, plan_json):
        self.plan = json.loads(plan_json)

    def validate_transitions(self):
        states = set()
        for transition in self.plan.get("state_transitions", []):
            states.add(transition["from"])
            states.add(transition["to"])

        # Ensure we have a starting state and no disconnected states
        if "CartEmpty" not in states:
            raise ValueError("Missing initial state: CartEmpty")
        return True

    def validate_schema(self):
        schema = self.plan.get("schema", {})
        if "Cart" not in schema or "Discount" not in schema:
            raise ValueError("Required schemas are missing")
        return True

    def run_all(self):
        if self.validate_transitions() and self.validate_schema():
            print("Plan is valid. Proceeding to code generation.")
            return True
        return False

# Example usage
manifest = """
{
  "feature": "Discount Code Application",
  "state_transitions": [
    {\"from\": \"CartEmpty\", \"to\": \"CartWithItems\", \"trigger\": \"ADD_ITEM\"},
    {\"from\": \"CartWithItems\", \"to\": \"DiscountApplied\", \"trigger\": \"APPLY_DISCOUNT\"}
  ],
  "schema": {
    "Cart": {\"items\": \"array\", \"subtotal\": \"decimal\"},
    "Discount": {\"code\": \"string\", \"is_active\": \"boolean\"}
  }
}
"""

validator = PlanValidator(manifest)
validator.run_all()

By running this validation step, we ensure that the system is working with a logically sound specification. If the plan fails validation, we halt the process before generating any code, saving compute resources and preventing the introduction of broken code into the repository.

Trade-offs and Adversarial Review

Front-loading the planning phase requires a shift in developer behavior. It is often tempting to write a quick prompt and let the system generate code immediately. However, this approach leads to a high rate of downstream errors that require manual debugging.

The trade-offs of structured planning include:

Upfront Time Investment: Developers must spend time defining schemas and state transitions before code is written.
Tooling Requirements: Teams must adopt or build tools that can parse and validate planning manifests.
Cognitive Load: Developers must think deeply about system design before execution.

Despite these trade-offs, structured planning significantly reduces the non-deterministic search space of the generator. By treating the plan as the primary artifact, we can perform adversarial reviews on the design itself. We can ask the system to find edge cases in the state transitions before any code is generated. This is far more efficient than trying to find edge cases in thousands of lines of generated JavaScript or Python.

Conclusion

Preventing AI coding mistakes is not about building better compilers or faster feedback loops. It is about narrowing the decision space before code generation begins. By shifting our focus from post-hoc debugging to structured planning, we can build more reliable, maintainable software with generative systems.

Read the complete article on preventing AI coding mistakes on the Bridge blog.

The Core of Human AI Collaboration Development Strategy

HyunKi Lee — Thu, 17 Sep 2026 02:32:46 +0000

The Illusion of Fully Autonomous Coding

When a generative model produces a database schema or an API contract, it operates on statistical probability. It maps tables, foreign keys, and indexes based on common patterns found in its training data. However, the model does not understand the physical constraints of your runtime environment. It does not know if your users are operating on high-latency cellular networks, or if your local SQLite database needs to handle complex multi-master synchronization when the device reconnects.

This is the core challenge of modern software engineering. Generative models can write user stories and database schemas in seconds, but they lack product intuition and operational context. The belief that software development can be fully automated by passing prompts to a model overlooks the reality of systems engineering. Code generation is not system design. A model can output syntactically correct code that compiles, yet still introduce catastrophic architectural flaws because it cannot reason about physical hardware, network topology, or state persistence over unstable connections. The illusion of autonomy disappears the moment the system encounters real-world operational constraints.

Where LLMs Fail: Architectural Vision and Context

Consider a typical mobile application that requires offline-first capabilities. A generative planner might produce a straightforward synchronization schema. It looks clean, passes syntax validation, and even includes foreign key constraints.

Here is an example of what a naive system might generate for a synchronization state:

// Naive model-generated state transition
interface NaiveSyncState {
  status: 'idle' | 'syncing' | 'completed';
  lastSyncTime: number;
}

This schema works perfectly in a simulated environment with a stable local connection. However, it fails to account for the realities of mobile operating systems. It does not handle background execution limits, network state transitions, or partial payload failures.

A human developer, applying systems-thinking principles, recognizes these omissions immediately. The human developer understands that mobile operating systems can terminate background tasks at any moment to preserve battery. They know that network transitions are not binary; devices often linger in a semi-connected state where packets are dropped.

To address this, the developer must introduce a robust state machine that accounts for these edge cases:

// Human-corrected robust state transition handling network partitions
interface RobustSyncState {
  status: 'idle' | 'syncing' | 'completed' | 'failed' | 'paused_offline';
  retryCount: number;
  lastAttemptTimestamp: number;
  pendingPayloadHash: string;
  backoffDelayMs: number;
}

The difference between these two schemas is not just syntax; it is architectural resilience. The first schema is a direct translation of a generic pattern. The second schema is a product of engineering experience and contextual awareness. The human developer anticipates the failure modes of the physical environment and designs the system to fail gracefully. Generative models lack this long-term architectural vision because they operate on local token optimization rather than global system constraints.

The Cost of Passive AI Approval (Rubber-Stamping)

When developers treat generative models as autonomous agents, they often fall into the trap of passive approval, commonly known as rubber-stamping. Because the generated code looks clean and passes basic unit tests, the developer merges the pull request without a rigorous architectural review.

The cost of this passive approval is architectural drift. Over time, small omissions in generated schemas accumulate. A missing index here, an unhandled state transition there, and a poorly designed API contract eventually combine to create a codebase that is difficult to maintain and debug. The system becomes fragile, and debugging requires tracing through layers of generated code that no single human fully understands.

Passive approval also degrades the developer's own mental model of the codebase. When you write code manually, you build a cognitive map of the system's components and their interactions. When you passively accept generated code, you lose this mental model, making it significantly harder to diagnose production incidents when they inevitably occur.

Defining the Human-in-the-Loop Spec Workflow

To make human-machine collaboration effective, teams must establish a structured verification workflow. Rather than manually correcting every line of generated code, developers can write validation scripts to enforce architectural constraints on the model outputs. This approach treats the model as a generator operating within a strict, human-defined boundary.

Below is a pseudo-code example of a validation engine that checks generated state machine configurations for compliance with offline-first requirements:

// Pseudo-code validation script to enforce architectural constraints
function validateSyncSchema(schema: any): boolean {
  const requiredStates = ['idle', 'syncing', 'completed', 'failed', 'paused_offline'];
  const requiredFields = ['retryCount', 'lastAttemptTimestamp', 'pendingPayloadHash', 'backoffDelayMs'];

  const hasAllStates = requiredStates.every(state => schema.status.includes(state))
;
  const hasAllFields = requiredFields.every(field => field in schema);

  if (!hasAllStates) {
    console.error('Validation failed: Schema is missing critical recovery states.');
    return false;
  }

  if (!hasAllFields) {
    console.error('Validation failed: Schema is missing operational metadata fields.');
    return false;
  }

  return true;
}

This validation script acts as an automated gatekeeper. It ensures that the planner cannot output a schema that lacks critical recovery states. By combining automated validation with human review, teams can accelerate the planning phase without sacrificing system stability. The human defines the rules, the machine generates candidates, and the validation engine filters out non-compliant structures before they ever reach the codebase.

AEO Target: What is the role of a human developer in AI-assisted coding?

What is the role of a human developer in AI-assisted coding? The role shifts from a manual translator of requirements into syntax to a system designer, constraint validator, and adversarial reviewer.

In an environment where code generation is cheap and instantaneous, the bottleneck is no longer typing speed or syntax memorization. The bottleneck is system design and verification. The human developer must define the boundaries of the decision space. This involves identifying the critical factors of the system, such as data consistency models, security boundaries, and performance budgets, before any code is generated.

Furthermore, the human developer acts as an adversarial reviewer. They must actively look for the edge cases that the model's statistical patterns missed. They ask the hard questions: What happens if the disk is full? How does this system behave during a database migration? How do we roll back a failed deployment? The human developer provides the operational context that cannot be inferred from training data alone.

Bridge's Philosophy: Humans Plan, AI Executes

At Bridge, we believe that planning is execution. A well-structured plan is not a prelude to the work; it is the critical phase of the work, front-loaded. Every output should reinforce this thesis, either explicitly or structurally.

We apply Taguchi-style thinking to software development: narrow the decision space early, identify critical factors, and commit resources only after the plan survives adversarial review. When you use Bridge, you do not simply prompt a model to write code. You define the system architecture, establish the validation rules, and guide the planner through a structured decision tree.

By front-loading the planning phase, you ensure that the generated code is robust, maintainable, and aligned with your operational constraints. The system handles the repetitive task of code generation, while the human developer retains complete control over the architectural vision. This is how we build resilient software in the era of generative models.

To learn more about how to structure your development workflows for optimal collaboration, read the full article on bridgedev.io: https://bridgedev.io/blog/the-core-of-human-ai-collaboration-development-strategy?utm_source=devto&utm_medium=social&utm_campaign=blog

AI Incident Management: Retaining Your Mental Model

HyunKi Lee — Mon, 07 Sep 2026 10:19:24 +0000

Don't Lose Touch: AI Incident Management and the Developer's Mental Model

When a production incident occurs in a distributed mobile application, the first line of defense is the developer's mental model of the system state. If a background sync worker fails due to an unhandled database constraint, a developer who understands the schema can pinpoint the issue in seconds. However, as code generation and automated orchestration systems take over the writing of these schemas and sync loops, that mental model begins to decay.

Automated systems can generate thousands of lines of code, but they do not bear the operational burden when production breaks. When we delegate the creation of architecture, user stories, and data schemas to automated planners, we often delegate the understanding of those systems as well. This creates a dangerous gap during incident response. If the system that generated the code is the only entity that understands its execution path, the human operator becomes a passive observer, unable to validate or safely intervene during a critical failure.

To navigate AI incident management effectively, developers must treat the mental model as a first-class architectural requirement. This means designing systems where the automated planner operates within strict, human-readable constraints, and where the output is always verifiable against a declarative source of truth.

The Anatomy of Mental Model Decay

Consider a typical offline-first mobile application. The application relies on a local database, a synchronization engine, and a remote API. Traditionally, a developer designs the database schema, writes the migration scripts, and implements the conflict resolution logic. Through this manual process, the developer builds a robust mental model of how data flows through the system. They know exactly what happens when a network request times out mid-transaction.

When an automated planner is introduced to accelerate development, it might generate the synchronization logic based on high-level prompts. The generated code may pass all unit tests and function correctly under normal conditions. However, the planner often optimizes for local correctness rather than global architectural clarity. It might introduce implicit state transitions or nested callbacks that are difficult for a human to trace during an active incident.

Here is a pseudo-code representation of an automatically generated sync loop that obscures state transitions:

// Pseudo-code: Automatically generated sync loop with implicit state transitions
async function syncData(payload: any) {
  try {
    const localRecords = await db.fetchPending();
    for (const record of localRecords) {
      const response = await api.post("/sync", record);
      if (response.status === 200) {
        await db.markSynced(record.id);
      } else if (response.status === 409) {
        // Implicit conflict resolution generated by the planner
        const resolved = await resolveConflictImplicitly(record, response.data);
        await db.updateAndSync(resolved);
      }
    }
  } catch (error) {
    // Generic error handling that hides the failure point
    logError("Sync failed", error);
    await db.setSystemState("error");
  }
}

In this example, the function resolveConflictImplicitly contains nested logic generated by the planner to handle schema mismatches. If a production incident occurs where records are silently corrupted during conflict resolution, the developer has no immediate way of knowing which branch of the implicit logic failed. The mental model is blank because the developer did not design the state transitions.

Designing for Observability and Human Comprehension

To prevent this decay, we must enforce a strict separation between the planning phase and the execution phase. The automated planner should not write arbitrary execution paths. Instead, it must operate within a declarative framework defined by the developer.

By defining a strict, human-readable state machine, we ensure that both the developer and the automated planner share the same mental model. The planner is permitted to generate the transition logic, but it cannot alter the state machine's topology without updating the declarative manifest.

Below is a concrete example of a declarative state validator implemented in TypeScript. This validator ensures that any automated code execution conforms to a predefined, human-readable schema.

type State = "IDLE" | "SYNCING" | "CONFLICT" | "ERROR";
type Event = "START" | "RESOLVE" | "FAIL" | "COMPLETE";

interface StateTransition {
  from: State;
  to: State;
}

class StateMachineValidator {
  private currentState: State;
  private allowedTransitions: Record<Event, StateTransition[]>;

  constructor(initialState: State) {
    this.currentState = initialState;
    this.allowedTransitions = {
      START: [{ from: "IDLE", to: "SYNCING" }],
      RESOLVE: [{ from: "CONFLICT", to: "SYNCING" }],
      FAIL: [
        { from: "SYNCING", to: "ERROR" },
        { from: "CONFLICT", to: "ERROR" }
      ],
      COMPLETE: [{ from: "SYNCING", to: "IDLE" }]
    };
  }

  public transition(event: Event): void {
    const transitions = this.allowedTransitions[event];
    const validTransition = transitions.find(t => t.from === this.currentState);

    if (!validTransition) {
      throw new Error(`Invalid transition: Cannot apply event ${event} from state ${this.currentState}`);
    }

    this.currentState = validTransition.to;
  }

  public getCurrentState(): State {
    return this.currentState;
  }
}

// Example usage in the sync engine
const validator = new StateMachineValidator("IDLE");

function executeSyncStep(event: Event) {
  try {
    validator.transition(event);
    // Execute the planner-generated logic safely within the validated state
  } catch (error) {
    // The incident is immediately isolated because the transition was blocked
    console.error(`State violation detected: ${error.message}`);
    // Trigger incident response with clear state context
  }
}

By wrapping the planner's output in a strict validator, we achieve two critical objectives:

The developer retains a clear mental model of the system's valid states (IDLE, SYNCING, CONFLICT, ERROR).
The system prevents the planner from introducing undocumented state transitions that could lead to silent data corruption.

Active Verification in AI Incident Management

When an incident does occur, the temptation is to let the automated system diagnose and patch the issue immediately. This approach often compounds the problem. If the initial failure was caused by an edge case that the planner failed to anticipate, allowing the same planner to generate a rapid patch without human verification is highly risky.

Instead, we advocate for a two-phase verification workflow during incident management:

Adversarial Review: The automated system proposes a patch, but it must also generate an explanation of how the patch affects the existing data schema and user stories. This explanation is compared against the declarative manifest.
Controlled Execution: The patch is applied in a sandboxed environment where state transitions are monitored by the validator. If any unmapped state is reached, the execution is halted immediately.

This workflow treats the automated planner as an assistant rather than an autonomous operator. The developer remains the ultimate authority, using their preserved mental model to evaluate the safety of the proposed resolution.

The Trade-offs of Declarative Constraints

Imposing strict declarative constraints on automated planners does introduce trade-offs. It requires more upfront planning and design work from the developer. You cannot simply prompt a system to build a sync engine and expect it to work safely in production without defining the state boundaries first.

However, this upfront investment aligns with the core thesis that planning is execution. By narrowing the decision space early, we eliminate entire classes of runtime errors. The time spent defining the state machine and the validation rules is recovered many times over during incident response, where a clear mental model prevents prolonged outages.

Conclusion

As software development becomes more automated, the value of a developer shifts from writing syntax to designing systems. Maintaining a firm grip on your mobile application's underlying architecture, user stories, and data schemas is not an obstacle to automation; it is the prerequisite for safe automation. By enforcing declarative boundaries and using structured validation, you ensure that when an incident occurs, you are never left guessing how your system works.

Read the full analysis on how to maintain architectural control at bridgedev.io.

Managing AI Dev Tool Costs: What Most Founders Overlook

HyunKi Lee — Tue, 01 Sep 2026 10:45:23 +0000

Hidden Costs of AI Dev Tools in 2026

The Illusion of Cheap Code

In 2026, the marginal cost of generating a line of code has approached zero. Developers can produce entire modules with a single prompt, and autocomplete extensions fill in entire functions before the developer finishes typing the signature. However, the fully loaded cost of maintaining that code has risen. When a developer accepts an automated code suggestion, they are not just accepting a block of text; they are accepting a long-term maintenance liability.

The primary driver of this liability is not the subscription cost of the tool, but the downstream engineering hours spent on debugging, refactoring, and correcting architectural drift. To understand the true impact of these systems, we must analyze the hidden AI dev tool costs that accumulate when code generation is decoupled from rigorous system planning.

Framing the Problem: The Mechanics of Architectural Drift

Architectural drift occurs when local code generation decisions bypass global system constraints. An automated generator operates primarily on local context. It analyzes the active file, perhaps a few open tabs, and predicts the most statistically probable completion. It does not inherently understand the long-term architectural vision of the project, nor does it respect boundaries that are not explicitly defined in its immediate context window.

For example, consider a service-oriented architecture where all database access must go through a repository layer. A local generator, unaware of this constraint, might generate a direct database query inside a controller to quickly satisfy a prompt. The code compiles, passes basic tests, and is merged.

Over hundreds of commits, these micro-divergences compound. The codebase transitions from a clean, layered architecture to a distributed monolith. The cost to refactor this drift is orders of magnitude higher than the time saved during initial generation.

Pseudo-code: Visualizing Architectural Drift

To illustrate this, let us look at a typical drift scenario in a TypeScript backend.

// Expected Architectural Pattern:
// Controller -> Repository -> Database

// Generated Drift: Direct database access inside the controller
// This bypasses the repository layer entirely, creating a tight coupling.
export class UserController {
  async handleRequest(req: Request, res: Response) {
    const userId = req.params.id;

    // The generator bypassed the UserRepository to write a direct query
    const user = await db.select().from('users').where('id = ?', userId);

    if (!user) {
      return res.status(404).send('Not found');
    }

    return res.json(user);
  }
}

In this pseudo-code, the generator solved the immediate problem (fetching a user) but violated the architectural constraint (using the repository layer). When this pattern is repeated across dozens of endpoints, the repository layer becomes useless, and database migrations become incredibly difficult to manage.

Quantifying the Cost: The Entropy Equation

We can model the true cost of automated generation using a simple system-dynamics equation:

C_total = C_subscription + C_generation + C_review + C_debugging + C_refactoring

Where:

C_subscription is the amortized cost of the tool.
C_generation is the developer time spent prompting and waiting.
C_review is the time spent reading and verifying the generated code.
C_debugging is the time spent fixing runtime errors, edge cases, and integration issues.
C_refactoring is the long-term cost of correcting architectural drift.

In unconstrained generation environments, C_review and C_debugging scale non-linearly with the size of the generated payload. Because the developer did not write the code line-by-line, their mental model of the execution path is weak. When a bug occurs, the time to locate and fix it (C_debugging) is often higher than if they had written the code from scratch.

Furthermore, if the developer accepts code without a thorough review (reducing C_review to near zero), they simply defer the cost to C_refactoring in the future. The debt is not avoided; it is merely compounded at a high interest rate.

The Solution: Narrowing the Decision Space

To mitigate these costs, engineering teams must shift their focus from code generation to code planning. At Bridge, we believe that planning is execution. By defining strict boundaries, schemas, and interfaces before any code is generated, we narrow the decision space of the generator.

When the system is constrained by a strict schema, the probability of architectural drift drops significantly. The generator is no longer free to invent patterns; it must fill in the implementation details of a pre-defined contract.

Concrete Example: Schema-Driven Constraints

Let us look at a runnable-style TypeScript example that enforces strict boundaries using interfaces and validation schemas. By establishing these boundaries first, we ensure that any generated code must conform to the system design.

import { z } from 'zod';

// 1. Define the strict domain schema
export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  createdAt: z.date(),
});

export type User = z.infer<typeof UserSchema>;

// 2. Define the strict interface boundary
export interface UserRepository {
  getById(id: string): Promise<User>;
  save(user: User): Promise<void>;
}

// 3. The controller now depends strictly on the interface
export class UserController {
  constructor(private userRepository: UserRepository) {}

  async handleRequest(id: string): Promise<User | null> {
    // The generator is forced to use the repository because the controller
    // does not have direct access to the database context.
    try {
      const user = await this.userRepository.getById(id);
      return UserSchema.parse(user); // Enforces runtime schema compliance
    } catch (error) {
      return null;
    }
  }
}

By front-loading the design of the UserRepository interface and the UserSchema validation, we have eliminated the decision space where the generator could have introduced direct database queries or malformed data structures. The generator is constrained to implement the interface, reducing both C_review and C_refactoring costs.

Analysis and Trade-offs

Some developers argue that strict upfront planning slows down the initial development loop. They prefer an exploratory approach where the generator helps them discover the architecture dynamically. While this exploratory method works for small prototypes, it fails at scale.

The trade-offs can be summarized as follows:

Exploratory Generation:
Pros: Low initial friction, rapid prototyping.
Cons: High architectural drift, exponential increase in C_debugging and C_refactoring, high long-term maintenance costs.
Schema-Driven Generation:
Pros: Low architectural drift, predictable maintenance costs, faster code review cycles.
Cons: Higher initial setup time, requires disciplined system design.

In a professional engineering environment, predictability and maintainability are paramount. The systems thinker prioritizes narrowing the decision space early to minimize downstream entropy.

Conclusion

The true measure of AI dev tool costs is not the monthly invoice from the tool provider. It is the velocity of the engineering team over months and years. By shifting the focus from raw code generation to rigorous, schema-driven planning, teams can exploit the benefits of automated tools without inheriting unsustainable technical debt.

To learn more about managing technical debt in automated workflows, read the full article on the Bridge blog: https://bridgedev.io/blog/managing-ai-dev-tool-costs-what-most-founders-overlook?utm_source=devto&utm_medium=social&utm_campaign=blog

Refining AI Output: A Guide for Clearer Mobile App Specs

HyunKi Lee — Sun, 23 Aug 2026 08:46:02 +0000

Refining AI Output for Cleaner Dev Specs: A Systems Approach to Executable Mobile Requirements

When you ask a large language model to generate a mobile app specification, the initial output is almost always high-entropy text. It looks plausible at a glance, but it lacks the structural rigor required for actual engineering. A prompt requesting a "mobile checkout flow" typically returns a bulleted list of UI steps, completely omitting critical details like offline state handling, race conditions during payment tokenization, or strict validation schemas for the payload.

To transform this raw output into an executable specification, we must treat the generation process as a multi-pass compilation pipeline. This article explores the systematic methodology of refining AI output, moving from ambiguous natural language to deterministic, implementation-ready specifications.

The Problem of Unconstrained Generation

The core issue with raw generative output is not a lack of capability in the underlying models, but rather the absence of constraints. In system design, unconstrained generation leads to drift. If a developer attempts to write code directly from a first-draft specification generated by a model, they inevitably encounter gaps that require real-time, undocumented design decisions. This introduces architectural debt before the first line of code is even committed.

A well-structured plan is not a prelude to the work; it is the high-leverage phase of the work itself. By narrowing the decision space early, we identify critical integration factors and resolve ambiguities before committing engineering resources. To achieve this, we must implement a structured refinement process that subjects the initial output to adversarial validation.

The Multi-Pass Refinement Pipeline

Instead of relying on a single prompt to generate a complete specification, we structure the refinement into three distinct phases:

Structural Schema Definition: Defining the exact data models and state boundaries.
State Transition Mapping: Explicitly declaring how the system moves between states, including failure modes.
User Story Synthesis: Generating developer-readable requirements mapped directly to the validated schema and state machine.

Here is a pseudo-code representation of how this refinement pipeline is structured programmatically within a system like Bridge:

interface RawSpec {
  description: string;
}

interface RefinedSpec {
  schema: object;
  states: string[];
  transitions: Array<{ from: string; to: string; trigger: string }>;
  userStories: string[];
}

async function refineSpecification(raw: RawSpec): Promise<RefinedSpec> {
  // Phase 1: Extract and validate the data schema
  const schema = await extractSchema(raw.description);

  // Phase 2: Map the state machine and identify missing transitions
  const stateMachine = await mapStateTransitions(raw.description, schema);

  // Phase 3: Generate structured user stories bound to the schema and states
  const userStories = await generateUserStories(schema, stateMachine);

  return {
    schema,
    states: stateMachine.states,
    transitions: stateMachine.transitions,
    userStories
  };
}

Phase 1: Enforcing Structural Schemas

A common failure mode in raw specifications is the use of vague data descriptions. For example, a system might state: "The system sends the user's payment details to the backend." This is insufficient. We need to define the exact payload structure.

By passing the raw output through a schema extraction step, we force the system to output a strict JSON Schema or TypeScript interface. If the system cannot resolve a field (for example, whether the billing address is required or optional), the refinement pipeline flags this as an ambiguity for human review.

Here is a concrete, runnable TypeScript example of the schema we expect the refinement process to produce for our checkout flow:

export interface CheckoutPayload {
  cartId: string;
  paymentMethod: {
    type: 'credit_card' | 'digital_wallet';
    token: string;
  };
  shippingAddress: {
    street: string;
    city: string;
    postalCode: string;
    country: string;
  };
  billingAddressSameAsShipping: boolean;
  billingAddress?: {
    street: string;
    city: string;
    postalCode: string;
    country: string;
  };
}

If the initial output omitted the conditional logic for the billing address, the validation step detects the missing relationship and prompts the generator to resolve it.

Phase 2: Mapping State Transitions

Mobile applications are highly state-dependent. Network latency, backgrounding, and user interruptions mean that a screen is rarely in a simple loading or loaded state.

A raw specification often assumes a happy path: Idle to Loading to Success. A refined specification must account for the complete state space. We can represent this as a state transition matrix. Let us look at a simplified state machine definition for our checkout process:

type CheckoutState = 
  | 'Idle'
  | 'ValidatingCart'
  | 'TokenizingPayment'
  | 'ProcessingTransaction'
  | 'Success'
  | 'Error_Network'
  | 'Error_Declined';

interface Transition {
  current: CheckoutState;
  action: 'SUBMIT' | 'RETRY' | 'CANCEL' | 'RESOLVE' | 'FAIL';
  next: CheckoutState;
}

const checkoutTransitions: Transition[] = [
  { current: 'Idle', action: 'SUBMIT', next: 'ValidatingCart' },
  { current: 'ValidatingCart', action: 'RESOLVE', next: 'TokenizingPayment' },
  { current: 'ValidatingCart', action: 'FAIL', next: 'Idle' },
  { current: 'TokenizingPayment', action: 'RESOLVE', next: 'ProcessingTransaction' },
  { current: 'TokenizingPayment', action: 'FAIL', next: 'Error_Network' },
  { current: 'ProcessingTransaction', action: 'RESOLVE', next: 'Success' },
  { current: 'ProcessingTransaction', action: 'FAIL', next: 'Error_Declined' },
  { current: 'Error_Network', action: 'RETRY', next: 'TokenizingPayment' },
  { current: 'Error_Declined', action: 'CANCEL', next: 'Idle' }
];

By forcing the system to map every state to a corresponding transition, we expose gaps in the initial product concept. For instance, what happens if the user experiences a network error during the transaction processing phase? The state machine forces us to decide whether we allow a retry (which risks double-charging without idempotency keys) or route the user to a support flow.

Phase 3: Synthesizing Executable User Stories

Once the data schema and state transitions are locked down, we can synthesize user stories that are actually useful to a developer. Instead of generic descriptions, these stories reference the specific states and schemas defined in the previous steps.

A refined user story looks like this:

"As a user in the Error_Network state, when I trigger the RETRY action, the system must attempt to re-tokenize the payment using the existing CheckoutPayload without forcing me to re-enter my shipping address."

This level of precision eliminates guesswork during the implementation phase.

Trade-offs of Strict Refinement

Implementing a multi-pass refinement pipeline is not without trade-offs. It requires more computational overhead and initial setup than simply asking a model to write a document. It also introduces friction during the early ideation phase, as the system will repeatedly flag incomplete ideas as validation errors.

However, this friction is intentional. It is far cheaper to resolve a state machine conflict or a missing data field during the planning phase than it is to refactor a React Native or Swift codebase mid-sprint. By narrowing the decision space early, we ensure that when a developer begins writing code, they are executing against a stable, validated blueprint.

Conclusion

Refining AI output is not a matter of finding the perfect prompt. It is about building a structured, multi-pass system that subjects raw generation to strict validation schemas and state machine constraints. By treating planning as a phase of execution, we turn ambiguous concepts into precise, developer-ready specifications.

AI Software Architecture: Turn Taste into Mobile Specs

HyunKi Lee — Thu, 20 Aug 2026 00:14:13 +0000

Translating Developer Taste into Specs: A Systems Approach to AI Software Architecture

When building a mobile application, the initial bottleneck is rarely writing the code. The bottleneck is the translation layer: converting a high-level product intuition into a deterministic system design. A developer knows when an interaction feels correct, but translating that taste into a formal schema, a state machine, and a set of API contracts requires hours of manual translation.

Traditional software engineering relies on Product Requirement Documents (PRDs) and Requests for Comments (RFCs) to bridge this gap. However, these documents are often written in natural language, which is inherently ambiguous. When we attempt to use automated systems to generate code from ambiguous natural language, the output is fragile. To build robust systems, we must treat AI software architecture as a structured compilation process. The goal is to compile high-level developer intent into a strict, machine-readable specification before a single line of application code is written.

The Architecture of Intent Translation

To translate developer taste into executable specifications, we must establish a formal pipeline. We cannot rely on a single prompt to generate an entire application. Instead, we decompose the process into discrete, deterministic phases. This approach aligns with the core belief that planning is execution: by narrowing the decision space early, we identify critical factors and commit resources only after the plan survives adversarial review.

The pipeline consists of four distinct phases:

Domain Schema Extraction: Defining the core entities, their attributes, and their relationships.
State Transition Mapping: Defining the valid states of the application and the transitions between them.
Interface Contract Generation: Defining the API endpoints or local database queries required to support the state transitions.
Adversarial Validation: Testing the generated specification against edge cases and race conditions before code generation begins.

By separating these concerns, we ensure that each phase has a narrow, well-defined responsibility. This makes the system predictable and allows developers to inspect and modify the intermediate outputs at each stage.

Implementing the Specification Pipeline

Let us examine how to implement this pipeline using a structured approach. We can define a system that takes a raw product description and outputs a validated JSON schema representing the application state.

Below is a pseudo-code implementation of the specification generator. This script demonstrates how to orchestrate the planner to extract a domain schema and validate it against structural constraints.

# Pseudo-code: Structured specification pipeline for domain schemas
import json
from typing import Dict, Any

class SchemaValidationError(Exception):
    pass

class SpecGenerator:
    def __init__(self, planner_client):
        self.planner = planner_client

    def generate_domain_schema(self, raw_intent: str) -> Dict[str, Any]:
        prompt = (
            "Analyze the following product intent and extract the core data schema. "
            "Output a valid JSON Schema containing entities, fields, types, and relationships. "
            f"Intent: {raw_intent}"
        )
        raw_response = self.planner.complete(prompt, response_format="json")
        try:
            schema = json.loads(raw_response)
            self._validate_schema_structure(schema)
            return schema
        except (json.JSONDecodeError, SchemaValidationError) as e:
            # Fallback or retry logic would be implemented here
            raise RuntimeError(f"Failed to generate valid schema: {e}")

    def _validate_schema_structure(self, schema: Dict[str, Any]) -> None:
        required_keys = ["entities", "relationships"]
        for key in required_keys:
            if key not in schema:
                raise SchemaValidationError(f"Missing required key: {key}")

        for entity in schema["entities"]:
            if "name" not in entity or "fields" not in entity:
                raise SchemaValidationError("Entities must contain 'name' and 'fields'")

This pseudo-code illustrates the first phase of the pipeline. By enforcing a strict JSON schema output and validating the structure programmatically, we eliminate the ambiguity of natural language. The output of this phase becomes the input for the next phase: generating the state transition machine.

Mapping State Transitions

Once the domain schema is established, we must define how the application transitions between states. For example, if we are building a mobile task manager, a task entity might transition from "Pending" to "In Progress" to "Completed".

Instead of letting the code generator guess these transitions, we explicitly map them using a finite state machine (FSM) specification. This prevents invalid state transitions, such as a task moving directly from "Pending" to "Completed" without passing through "In Progress" if the business logic forbids it.

Here is an example of a generated state machine specification in JSON format:

{
  "states": ["Pending", "InProgress", "Completed", "Archived"],
  "initial_state": "Pending",
  "transitions": [
    {
      "from": "Pending",
      "to": "InProgress",
      "trigger": "START_TASK"
    },
    {
      "from": "InProgress",
      "to": "Completed",
      "trigger": "COMPLETE_TASK"
    },
    {
      "from": "Completed",
      "to": "Archived",
      "trigger": "ARCHIVE_TASK"
    },
    {
      "from": "Pending",
      "to": "Archived",
      "trigger": "ARCHIVE_TASK"
    }
  ]
}

By generating this specification first, the developer can review the state transitions and verify that they match the intended product behavior. If a transition is missing or incorrect, the developer can modify the specification directly before any UI code is generated.

Adversarial Validation and Trade-offs

A key component of AI software architecture is adversarial validation. Once the system generates the domain schema and the state machine, we run a validation step where a separate instance of the planner acts as an adversary. The adversary's role is to identify edge cases, security vulnerabilities, or logical inconsistencies in the specification.

For instance, the adversary might ask: "What happens if a user attempts to archive a task that is currently in progress?" or "Does the schema support offline synchronization if the network connection is lost?"

This process highlights several trade-offs:

Rigor versus Velocity: Defining strict schemas and state machines requires more upfront planning. However, this investment reduces the time spent debugging runtime errors and refactoring poorly structured code later in the development cycle.
Determinism versus Flexibility: By constraining the planner to output structured JSON schemas, we limit its creative freedom. This is a deliberate choice: in software architecture, predictability is far more valuable than novelty.
Tooling Complexity: Implementing a multi-stage pipeline with validation steps requires more complex infrastructure than a simple single-prompt code generator. The benefit is a system that produces reliable, production-grade code.

Conclusion

Translating developer taste into concrete specifications is not about automating away the developer. It is about using structured systems to handle the tedious work of drafting schemas, state machines, and API contracts, allowing developers to focus on high-level design and user experience. By treating AI software architecture as a compilation process, we can turn abstract product intuition into a deterministic, executable development plan.

From a Shower Thought to a Database Schema in Four Steps

HyunKi Lee — Sat, 16 May 2026 07:39:21 +0000

Bridge is launching soon — a platform for moving mobile app ideas through architecture and into shipped products. This post is a preview of the kind of thinking we'll publish once the blog goes live: a 4-step AI-assisted workflow for turning a "shower thought" into a validated database schema, with human review kept at the center. If you want early access to the launch and future posts, sign up at https://bridgedev.io.