AI workflows

What I want from an AI development partner

A pull request full of code gives me little basis for judging software. I'm not a developer. A working example, supported by a clear explanation of what it does and what still needs attention, gives me something useful to respond to.

That experience has helped clarify the partnership I want with AI. My role is closer to a client bringing an idea to someone with the expertise to help develop it.

I can explain what I'm trying to accomplish, but I don't always know what's technically possible. That's where I want some expertise and creativity brought into the conversation. If there's a better way to do it, help me see it.

Understand the purpose before assigning the work

A request for a screen or feature can sound specific while leaving the purpose unexplained. It may describe the only solution the person asking can picture.

Before turning that request into coding tasks, the agent should ask questions. What am I trying to make easier? What would a useful result let me do? Could another approach serve that purpose better?

The answers give us something to judge the work against. They also give the agent room to challenge an assumption or suggest a possibility beyond my technical knowledge. That contribution is part of the expertise I'm looking for.

Use working examples to develop the idea

Sometimes the missing piece only becomes clear in a working version. An example might reveal that the agent understood the idea differently, that the implementation needs work, or that the idea itself is less useful than expected.

Those are different problems. A misunderstanding calls for another conversation about the purpose. Weak implementation needs technical attention. An idea that doesn't hold up may need rethinking before more coding.

I'm comfortable with that kind of iteration. Clear, concise explanations and something visible make it possible to discuss what needs to change. I can judge how a tool behaves and whether it helps with the task. The technical partner needs to take responsibility for evaluating the code behind it.

Keep reviews connected to the original idea

The same partner should act as a technical lead, coordinating the coding and review work.

Repeated review comments and fixes can gradually carry a project away from its original purpose. A reviewer asks for a change, a coder makes it, and the next review starts another round. Someone needs to decide whether those changes fix a real problem or alter what we set out to build.

Within the agreed work, the lead should resolve defects, settle conflicting feedback and explain important trade-offs in plain language. Changes to scope or design need to come back to me for a decision.

This is a working relationship I'm still trying to develop. I don't yet have a finished system doing all of it reliably. What interests me is access to expertise that can expand an idea while keeping its purpose intact, with a capable partner managing the technical work and helping me judge whether the result is useful.