What We Still Do Manually When Building With AI

I use AI to search unfamiliar code, compare approaches, implement changes, write tests, and prepare documentation. It can carry a task across more of the development cycle than the tools I used a year ago.

I still make the decisions that determine whether the work should exist.

“Manual” does not mean typing each line by hand. It means a person understands the situation, accepts the trade-off, and remains accountable for the result.

We Choose the Problem

A backlog gives an agent plenty to do. It cannot tell us which item will help the business learn, remove the most expensive friction, or make the product easier to change.

That choice needs product context. A customer request may point to a missing feature, an unclear workflow, or a sales promise the product should never support. An agent can group the evidence and identify patterns. A person has to decide which interpretation deserves investment.

I want to hand an agent a useful problem, not a pile of tickets.

We Set the Boundary

Software work expands unless someone defines where it stops.

A request to add export functionality can grow into new permissions, background jobs, retention rules, audit records, and several formats. The agent can describe those dependencies. The team decides which slice can deliver value without creating an unsafe shortcut.

The boundary includes what the change must preserve. Existing URLs may need redirects. Stored data may need migration before a field disappears. A visual control may need to remain inside the surface it affects.

These constraints turn a plausible implementation into a product that respects its users.

We Make Architecture Trade-offs

AI can list the advantages of a queue, event stream, scheduled job, or direct request. It can inspect the codebase and show where each option would connect.

The decision depends on facts outside the code. The team may have limited operational capacity. A feature may need an audit trail. A failure may cost money or expose private data. A temporary solution may need to survive longer than anyone wants to admit.

A senior developer reads those conditions and chooses the structure the team can operate. The best technical option on paper can create the wrong system for the people maintaining it.

We Judge the Experience

An agent can reproduce a design and check contrast, labels, focus order, and responsive breakpoints. Product judgment reaches further.

Someone needs to use the interface and notice that the action appears too early, the explanation arrives too late, or the layout encourages the wrong choice. A screenshot can show that every component rendered while the experience still feels uncertain.

I treat visual review as part of implementation. Geometry, hierarchy, and timing affect whether the feature works for the person using it.

We Decide What Evidence Is Enough

Agents can run tests, inspect logs, open pages, and compare screenshots. They can also accept a weak proxy unless the brief names the expected proof.

The person responsible for the change decides whether a mocked test covers enough risk, whether a staging response reflects production, and whether a deployment reached a live state. Security, financial behavior, data migration, and destructive actions need stronger evidence than a local component change.

The distinction matters most when the output looks finished. A polished report can hide an untested assumption.

We Stop the Work

AI tends to continue while it has an instruction and available context. People decide when another improvement no longer earns its cost.

We may stop because the experiment answered the question. We may reject a feature after seeing the prototype. We may leave an awkward implementation in place because changing it would create more risk than value this quarter.

Stopping can produce more value than another round of generation. It protects the budget and keeps the team focused on the next useful thing.

We Explain the Decision

Code records the implementation. It does not explain why the team chose it.

I still write the short note that connects the problem, trade-off, evidence, and next step. That note helps a founder understand what changed and gives the next developer enough context to challenge the decision later.

A useful weekly update can answer three questions: what became real, what did we learn, and what changes next.

The Division of Work

My current boundary looks like this:

The boundary will move as the tools improve. Accountability will stay with the people building and operating the product.

Senior Work Becomes More Visible

AI removes some of the typing that used to occupy a developer’s day. The remaining work exposes the decisions behind the software: which problem to solve, which risk to accept, and which result counts as finished.

That work has always shaped the product. Faster implementation makes it harder to confuse code volume with progress.

At Dakic, we use AI throughout delivery while keeping product judgment, verification, and release decisions in human hands. If your team needs a senior partner for that boundary, start with the problem that needs a useful decision.