That's Not What I Meant by 'Using AI'

Mudlej · Mudlej ·

11 min read Original article ↗

Article

A classification of the different approaches to using AI in software development

by Mudlej 11 min read

Listen to two developers debate the use of AI in software development and you will often hear something strange: both are making reasonable claims, both have evidence, and neither can understand how the other believes what they believe.

One says AI-generated code is unreviewable slop that will rot your codebase. The other says he shipped a working product in a week. Both are telling the truth. They are just not describing the same activity.

Developers can have vastly different experiences using AI to develop software, depending on the approach they use. This article is my attempt to map1 these different approaches, explain each one, and give each a distinct name.

Whether you like AI or dislike it, we first need to know what we are talking about. A shared vocabulary comes before any meaningful discussion.

I’ve put most of my personal opinions in callouts like this one, collapsed by default, so you can mostly read the classification if you prefer.

Architecture, Detailed Design, and Implementation

To avoid relying on terms that may mean different things to different readers, I want to use a simple example to show what I mean by them.

  1. Architecture
    • What programming language to choose and why?
    • What framework or library to use, and why?
    • What are the system’s components? How will they communicate?
    • How is the data modeled? Where is it stored?
  2. Detailed Design:
    • How does the component do the computation / business logic?
    • What are the public functions for each component?
    • How are we going to pass data around?
    • How are errors handled?
  3. Implementation:
    • The actual code that implements the detailed design.

0. Traditional Development#

The developer owns architecture, detailed design, and implementation, working mostly as developers have for decades: writing code in the IDE, using compilers, static analysis, documentation, and conventional tooling. AI is not a meaningful part of the process.

Trade-offs

  • Pros: The developer has deep understanding and maximum control over the codebase.
  • Cons: Bottlenecked by the developer’s speed, especially for exploration, debugging, and boilerplate.

1. Organic Development (OD)#

The developer is still inside the code editor doing nearly everything manually, including coding. But he might occasionally use AI to research the domain or tools, refine a design, debug an issue, explain unfamiliar code, or review a change.

The developer might even use AI to draft small code snippets, such as asking an AI chatbot or using AI inline autocomplete to help with a code snippet, then manually integrating it into the codebase, usually after some tweaks and edits. This is close to how the developer would have used Stack Overflow in the past.

AI here acts like an on-demand teammate, but the human remains at the center of all development tasks.

Trade-offs

  • Pros: Improves traditional development with better speed, feedback, and accuracy while preserving full human ownership.
  • Cons: Productivity gains might be limited compared to other approaches because the developer is still doing most of the work directly.

Critical systems should probably keep using this approach, at least for the time being.

Example

This article was written organically. I spent a few days writing it fully by hand. After I felt I had said everything I wanted to say, I reached out to AI as a researcher to see what other people had said about the topic, and as a reviewer to challenge what I wrote. That said, the feedback I got from my fellow engineers was much more insightful than any AI feedback I got.

Agentic Development (AD)#

There are at least three approaches to agentic development, and they can be quite different. What they have in common is that the code is generated by AI, not written directly by the developer.

AD is usually done from the terminal using CLI tools such as Claude Code, Codex, OpenCode, and similar agents. Developers doing AD spend a lot of time inside these tools.

When it started

Agentic development started to become a serious option after the November Inflection in late 2025, around the release of Opus 4.5 and GPT-5.2.

Learning Cost

All types of agentic development have a learning curve. AD introduces many concepts that developers were not taught in school or bootcamps: context windows, agents, subagents, teams, agent SDKs, skills, commands, memory, harness engineering, and more.

2. Reviewed Agentic Development#

In Reviewed AD, the developer:

  • Defines the architecture.
  • Defines the detailed design.
  • Prompts an AI agent to generate the code.
  • Reviews the generated code line by line.

The human still owns the architecture and detailed design, but delegates implementation to AI while still reviewing the generated code meticulously, often pushing it back toward his preferred shape. This is usually done through a terminal or an IDE chat.

AI here acts like a tireless junior developer whose output needs careful review.

In approaches where AI generates the code, this approach is the opposite of Vibe Coding.

Trade-offs

  • Pros:
    • High confidence and understanding of the codebase.
    • Enables the developer to participate in adjacent languages, frameworks, or codebases.2
  • Cons:
    • Slow and tedious3.
    • The human’s review speed becomes the bottleneck.

Reviewed AD VS. Organic Development

Some readers might feel that the line between Reviewed AD and Organic Development is fuzzy: in OD, the developer can use AI autocomplete and then review the suggestion, just as he does in Reviewed AD. But the difference is bigger than this.

In OD, the developer lives in the IDE: navigating the codebase, designing the interface, and coding the implementation. The developer earns deep understanding and the ‘Aha moment’ as a byproduct of the labor. He knows the codebase from the inside and understands the decisions embodied in the code he wrote. When AI helps with implementation here, it feels closer to looking for help in online forums, than to offloading the task to AI.

In Reviewed AD, the developer is mostly talking to AI and writing specs. He is not the one directly editing the codebase, so he learns about the implementation after the fact. Consequently, he is not the one making the small implementation decisions. AI makes those decisions, and the developer tries to understand them.4

3. Guided Agentic Development#

In Guided AD, the developer:

  • Defines the architecture.
  • Defines the detailed design.
  • Prompts an AI agent to generate the code.
  • Skips reviewing the code line by line.

The developer owns architecture and detailed design, but trusts the agent to implement that design correctly. The human may skim the code, inspect important parts, run tests, and review behavior, but does not read every line or understand every small implementation choice.

The focus shifts from code authorship to design, constraints, validation, and outcome checking.

AI here acts like a mid-senior developer. You think with it on design, then trust its implementation, and verify by other means.

Trade-offs

  • Pros:
    • Much faster than previous approaches.5
    • The human spends more time on decisions that are harder for agents to get right.
  • Cons:
    • The developer doesn’t fully understand the implementation.
    • The small implementation decisions AI make can accumulate and affect non-functional requirements such as maintainability, performance, security, or observability.

Harness Engineering

Starting from this point, Harness Engineering becomes a crucial part of the system.

4. Fully Agentic Development#

In Fully AD, the developer:

  • Defines the architecture.
  • Delegates the detailed design and implementation to AI.

The developer owns the high-level architecture: the major components, their responsibilities, how they communicate, where data lives, and the broad technical direction.

AI here acts like a senior developer. You think with it on architecture, then trust its design and implementation skills.

That is still different from the next approach, because in Fully AD the developer cares about the technical side: system shape and codebase direction.

Trade-offs

  • Pros: Potentially the fastest way to develop non-trivial software.
  • Cons:
    • Risky without very strong safeguards.
    • Agents can erode boundaries, introduce inconsistent designs, violate architectural constraints, and produce code that becomes difficult to maintain even for AI.

5. Vibe Coding / Synthetic Development#

This is where the prompter stops thinking about the technical side entirely and shifts their attention entirely to the product’s UI/UX.

The term was coined by Andrej Karpathy in February 2025 in a post on X:

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

The architecture, detailed design, and code implementation in this approach are completely synthetically developed by the AI.

The person using the AI here may not be a programmer, and may not care how the system is designed internally as long as it appears to work.

AI here is your entire technical team and you are the product manager.

Trade-offs

  • Pros: Very useful and extremely fast for developing
    • scripts
    • prototypes
    • experiments
    • personal tools
    • demos
    • exploring product ideas.
  • Cons:
    • Too risky for serious systems.
    • Quality attributes such as scalability, security, privacy, reliability, compliance, and maintainability are challenging to add later if they were ignored in the architecture.
    • Usually ignores code quality entirely.
    • It struggles with novel ideas.6

Summary#

ApproachArchitectureDesignImplementerCode ReviewerHuman Owns
TraditionalHumanHumanHumanHumanEverything
OrganicHumanHumanHumanHuman & AIEverything
Reviewed ADHumanHumanAIHuman, line-by-lineImplementation choices+
Guided ADHumanHumanAIAIDetailed design+
Fully ADHumanAIAIAIArchitecture
Vibe CodingAIAIAIAI or noneProduct

They are not mutually exclusive#

A team may move between these different approaches depending on the task, codebase, risk level, and available harness and safeguards.

For example, a project might begin with Organic Development while the architecture is being shaped. Once the design is clearer, the team may use Reviewed AD for early implementation. As confidence grows, they may shift into Guided AD.

For well-bounded tasks in a codebase with a strong harness, Fully AD might be safe.

Vibe coding also remains useful for developing dev tools and quickly trying an idea in the project before committing to a proper design.

Conclusion#

Now let’s go back to the two developers from the start.

The one who called AI code unreviewable slop was probably picturing something like:

  • Vibe Coding in production for a serious system
  • Fully AD in a system with no harness
  • Guided AD in a sensitive / fragile codebase

In such cases, he is probably right: most current AI models will rot the code and harm the product here.

The one who shipped in a week was probably talking about:

  • Reviewed AD for a small ticket.
  • Guided AD in a mature codebase with well-defined patterns.
  • Fully AD in a mature codebase with a harness that checks everything, including code quality.
  • Vibe coding a personal project or a production prototype.

In such cases, he is probably right: most decent models can navigate these cases fine.

They were each pointing at a different way of using AI. Hand them the names:

  • Organic Development,
  • Reviewed AD,
  • Guided AD,
  • Fully AD,
  • Vibe Coding,

and now we can have a far more useful question: does this approach work for this task, this codebase, this level of risk?

It doesn’t necessarily settle who is right. It tells you what you actually disagreed about, and that is where any real conversation about AI and software engineering has to begin.7

  1. This classification is based on how control, decision ownership, and code-review depth are divided between the human and the AI. ↩

  2. Reviewed AD lets a developer work effectively in adjacent languages, frameworks, or codebases they do not know deeply. Since the AI handles the first pass at implementation, the developer only needs enough fluency to understand, review, and steer the generated code after defining the architecture and design. ↩

  3. Reviewed AD can be hard and frustrating for a few reasons:

    • Many coding agents are optimized for autonomous work, so using them in a tightly controlled, step-by-step workflow can feel like fighting the tool.
    • Many models are slow to iterate, which means any change the developer requests can take several minutes of waiting.
    • AI models tend to forget the implementation rules in long conversations or fail to grasp the nuances in them, which leads developers to keep repeating themselves.

    This raises the question of whether Reviewed AD is truly more productive than organic development or not. ↩

  4. Deep understanding in Agentic Development in general has to be actively pursued through meticulous reviewing. AI hands you working code and nothing compels you to deeply understand it. ↩

  5. Some developers remain skeptical, arguing that AI can introduce enough bugs and regressions to offset the claimed productivity gains. ↩

  6. Out of curiosity, after I finished writing the article, I tried to see whether I could vibecode this article. Check out the result here Can I Vibe Code the article? ↩

  7. I still have a feeling that there is something else possible. Another approach where you retain the deep understanding of Organic Development while having the speed of Guided AD without the slowness and frustrating aspects of Reviewed AD. Whether such an approach is possible remains to be seen. ↩

End