The Typist Fallacy: Why AI Doesn't Need to Write All Your Code

When I started learning to program in 2021, I chose to start with Atom.

At the time, VS Code was already the default choice for most developers, with rich autocomplete and helpful developer conveniences. But I chose a different path while learning. I wanted to spend time writing code myself and really understanding what I was doing before relying on editor conveniences. I spent roughly my first year learning the fundamentals that way, writing code by hand, reading the official documentation, and running things directly from the terminal.

I kept syntax highlighting, of course. But working without autocomplete helped me build confidence and understand what was happening under the hood.

After that first year of focusing on the basics, my workflow naturally evolved. Today, I use WebStorm, PhpStorm, or Android Studio almost exclusively to write and review code. If I need to sit down and write a feature by hand in PHP, Laravel, TypeScript, Vue, or Kotlin, I can do it without hesitation. I know the method signatures, I understand the request lifecycle, and I know how the frameworks behave.

At the same time, I also use AI agents heavily to generate code. I use them to do the initial writing for me in seconds, and then I review, update, and approve what they produce. The code remains mine, but the mechanical typing happens in a fraction of the time.

That balance took time to figure out. It required separating two distinct parts of our work: the intellectual effort of software engineering, and the mechanical effort of typing syntax.

Typing is not where the value lies

There can sometimes be an unspoken assumption among developers that manually typing every line of code is where the engineering value lives.

In my experience, typing is simply the mechanism for translating ideas into the computer. The real work of software development happens before and after code is written:

• Clarifying what a feature actually needs to accomplish.
• Designing how data should flow between the frontend, the application layer, and the database.
• Thinking through edge cases and how the system should recover when something fails.
• Structuring code so that teammates can easily read, test, and maintain it later.
• Investigating unexpected behavior and identifying root causes.

When I look at my daily work, a noticeable portion of the physical code is routine and predictable.

It is writing a database migration with standard timestamps and foreign keys. It is scaffolding a controller that validates incoming request data and returns an Inertia response. It is creating mock data for test suites. It is converting an API response into TypeScript interfaces.

Manually typing that kind of code does not make me a better engineer. It just takes time.

Two different perspectives

Discussions about AI in software development often gravitate toward two extremes.

On one side, there is an approach where people try to generate entire features or applications directly from prompts, without spending time reviewing or understanding the underlying code.

On the other side, there is a purist perspective that views any use of AI as a compromise of engineering craft, arguing that developers should type every character themselves.

Personally, I do not find either extreme practical.

Consider a concrete example. Suppose you need to add milestone tracking to tasks in a project management system.

If I ask an AI agent to write the migration, the basic Eloquent relationship, and a form request, it can produce that in seconds. In my experience, that is genuinely helpful. It saves time on boilerplate that I have implemented many times before.

What I do not delegate to AI are the architectural decisions:

• How should related tasks be handled if a milestone is removed? Should the reference be cleared, or should the action be prevented?
• Do we need a composite index on (project_id, milestone_id) to keep team queries fast as the dataset grows?
• Does a milestone belong in its own table, or is it better modeled as a property on an existing entity?
• How does this change affect the mental model of the people using the product?

An AI can generate code quickly, but it does not carry operational responsibility for the application. It will not be in the room when an unindexed query causes performance issues under heavy traffic.

Dividing the work

Here is how I tend to divide the work between myself and AI agents.

Areas where I use AI agents to do the writing

• Routine boilerplate: Standard resource controllers, form requests, and data transfer objects.
• Test scaffolding: Generating repetitive test fixtures, edge-case data sets, and standard assertion matrices.
• Database migrations: Writing out column definitions once I have already planned the schema design.
• Mechanical refactoring: Renaming a method across multiple files or updating components to a newer API convention.
• Type definitions: Taking a JSON payload from an API and generating matching TypeScript interfaces.
• Exploring unfamiliar code: Asking for a quick explanation of a complex regular expression or an unfamiliar configuration file.

Areas I keep firmly in human hands

• System architecture: Defining domain boundaries, choosing design patterns, and structuring module dependencies.
• Database design: Planning schema relationships, constraint strategies, and indexing.
• Security and authorization: Managing permissions, authentication flows, and data isolation between tenants.
• Core business logic: Financial calculations, state machines, and critical operational rules.
• Complex debugging: Diagnosing concurrency issues, race conditions, or intermittent cache behavior.
• Review and approval: Opening the diff in PhpStorm or WebStorm, updating what needs improvement, and approving the final result.

AI is very capable at the mechanical aspects of writing code. It is far less reliable when it comes to context, judgment, and restraint.

Keeping the code yours

The shift from Atom to IDEs like PhpStorm, WebStorm, and Android Studio did not weaken my understanding of programming. It made me more productive, because I already understood what the editor was helping me write.

I treat AI agents the same way.

I let AI agents do the heavy lifting of writing code because they can produce the syntax in seconds. But I review every change in my IDE, make the necessary adjustments myself, and only approve what meets my standards.

The code remains mine because I understand every line, I direct the architecture, and I take responsibility for how it runs. The only difference is that I didn't have to spend thirty minutes typing boilerplate to get there.