What AI Actually Changed in My Engineering Work

Some days I have one agent reading a codebase while I review a diff from another task. Both can produce more work before I have finished deciding whether the first change is safe.

That review queue is where the change became real for me.

My path into engineering was fairly traditional. During internships, I learned by working inside real codebases and shipping internal tools. At Caris, production systems and data pipelines made reliability concrete. At Meta, a large codebase and a rigorous review culture kept raising the cost of changing something without understanding its surroundings.

The loop used to feel linear: read the task, explore the code, implement, debug, review, ship. My speed set the pace.

I still do all of those things. The difference is that an agent can now explore and implement while I am writing acceptance criteria, tracing an edge case, or reviewing a different change. Typing is no longer the only expensive part of the loop. Deciding what should happen, supplying the missing context, and proving that the result is safe now take a larger share of my attention.

The agent can move before I finish thinking

For a bounded task, I might ask an agent to map the relevant files, explain the current behavior, and propose the smallest change. While it reads, I can tighten the requirement or inspect the risky path myself. If the proposal is sound, it can implement and run the focused checks.

That can be much faster than discovering every file by hand. It also creates a new failure mode: the work can look complete before my understanding is complete.

A passing test tells me that a case passed. It does not tell me that the test covers the right boundary, that the implementation fits the rest of the system, or that a confident explanation is true. I still need to read the code, inspect the assumptions, and decide what evidence is strong enough for the change.

Concurrency has a limit too. Five agents can create five review queues, but I do not get five independent streams of judgment. When tasks overlap, parallel work can make context harder to hold rather than easier. I get better results by keeping the tasks bounded and making the verifier clear before asking for implementation.

Writing the context is part of engineering

Working with agents exposed how much specification I used to keep in my head.

When I write code myself, I can begin with an incomplete thought and resolve it while moving through the code. An agent needs the goal, the constraints, the existing seam, and a definition of done early enough to choose a useful path. If I cannot explain those things, the ambiguity does not disappear. It comes back as a plausible implementation that solves the wrong problem.

This is why repository structure, naming, tests, and short decision records matter more in my current workflow. They are not decoration for an AI tool. They make the system legible. The same habits that help a teammate understand why code exists also give an agent a better chance of changing it without guessing.

I do not think of this as prompt engineering. It is closer to making engineering intent inspectable.

Review became the center of the work

Caris taught me to distrust clever changes that ignore production behavior. Meta sharpened the habit through code review: follow the data, look for the hidden dependency, and ask what happens outside the happy path.

Those instincts transfer directly to agent-generated code. The awkward part is that AI mistakes often arrive in clean code with a calm explanation. A missing edge case may sit beside good naming and a green test. Surface quality can make weak assumptions harder to notice.

So I review the contract before the implementation. What is the behavior we are preserving? Which path is allowed to change? What observation would prove the fix? Then I review the diff against that contract. If the evidence cannot distinguish the new behavior from the old one, the task is not done.

Architecture sense, debugging, and taste still matter here. AI did not remove those skills from the job. It made them the part I cannot delegate casually.

My side projects are where I test the workflow

This site has become one of my laboratories. I have used it to test structured data for LLMs, repository instructions for agents, and conversational search. The useful question is rarely whether an agent can produce code. It is whether the repository gives enough context for the agent to make a change I can understand and verify.

Side projects are a safer place to discover where a workflow breaks. I can try a new tool, inspect the failure, and decide whether the extra machinery actually earns its place. Many experiments do not survive that test.

That is intentional. I would rather understand one workflow deeply than collect ten shallow demos.

The cost showed up as attention

The old fatigue often came from getting an implementation through the loop. The newer fatigue comes from supervising several plausible implementations and keeping their assumptions separate.

Agents do not get tired of producing another option. I do get tired of evaluating them.

I now protect uninterrupted time for one decision-heavy task, even when the tools could run more jobs in parallel. I stop an agent when the task is drifting instead of letting it finish an impressive answer to the wrong question. I also leave the screen. Skiing and photography are not productivity tricks for me, but distance often makes a muddy engineering decision easier to see.

This is where essentialism became practical. A new tool has to remove a real bottleneck or improve the evidence I can get. Novelty alone is not enough.

What AI-native means to me now

I use the label "AI-native" to describe a workflow, not a new kind of engineer.

The workflow begins with a clear task and enough context to act. It gives the agent bounded room to explore or implement. It ends with a human reading the result and evidence that can fail for the right reason. When any of those pieces is missing, speed mostly helps me reach uncertainty sooner.

The transition has changed what I practice. I spend more time turning an intuition into a contract, designing checks, and reviewing unfamiliar code. I still write code, especially when direct control is cheaper than explaining the task. The goal is not to hand every keystroke to an agent. It is to use the available leverage without handing away responsibility.

That is the version of AI-assisted engineering I trust: faster where the work is mechanical, slower where the decision deserves care, and explicit about which one I am doing.