Leading AI-assisted development when you don’t write code

You don’t need to read code to lead your developers well. You need a clear result for the user, an agreed scope, someone responsible for technical quality, and proof that the change works.

AI can help write a brief, suggest steps, and draft code and checks. Your job is to make the business decision clear. Your developer’s job is to decide whether the implementation is sound and safe to run. A convincing AI summary settles neither.

This guide is for founders who already work with a developer or a team. The client portal below is an example, not a client project. Adapt the brief and the review questions with your technical lead.

1. Turn a request into a useful outcome

Consider this request: “We need a client portal.” It sounds like a feature, but leaves the expensive decisions open. Does a client need invoices, messages, approvals, schedules, files, or all of them? What problem is worth solving first?

Start with the most recent real situation. A client emailed the project manager to ask when the next delivery was due and where to find the approved file. The useful outcome is narrower: the client can answer those two questions without waiting for a reply.

Before building, check whether the information already exists, who updates it, and whether clients would use a portal to find it. A new screen cannot make an unmaintained schedule trustworthy. If the problem is that nobody updates the milestone, the first change may be an ownership agreement inside the team.

DORA’s guidance on user-centric focus says AI amplifies whatever organization surrounds it, and warns against shipping features that don’t help users. In practice: agree on the user’s job before you ask an agent to build the screen.

2. Write the smallest useful brief

A brief should settle the questions that are expensive to get wrong. It doesn’t need to dictate how to build it. Here is an example to discuss with your developer:

Then agree on what you will check. Each check describes a situation and the result you expect:

• Given a client assigned to Project A, opening that project shows its next milestone and approved file.
• Given a newer draft file, the client still sees the approved file until the draft is approved.
• Given an unrelated client, both the project view and a direct file request deny access to Project A’s information.
• Given no approved file, the page explains that none is available. It does not select a draft as a substitute.
• Given an unavailable source, the page shows that the information could not be loaded and offers a retry. It does not invent a date or report success.

Your developer will refine these based on how access and errors actually work. You can agree on what must happen without choosing the database or the security setup.

DORA’s small-batch guidance links smaller changes that can be tested on their own with faster feedback. Here, the smallest useful piece is one complete client task. A new page header is small, but it doesn’t answer the client’s question.

3. Agree what AI and people own

Use AI where it’s clear what goes in and who checks what comes out. For this feature, it could turn the agreed brief into task drafts, suggest missing scenarios, prepare a change explanation, or assemble the results of existing checks.

Give it the current codebase conventions, the agreed brief, explicit exclusions, and the checks the developer expects. Ask it to point out missing information before it makes a choice that matters. Keep its access to customer data and live systems within what your team has agreed.

One person can hold several of these roles. What matters is that everyone knows who owns what. If nobody can judge a serious technical risk, bring in someone who can before you release.

4. Ask to see it working before release

Instead of asking “Is it done?”, ask for a short walkthrough of the agreed task. Use test data that includes a draft file and a client who shouldn’t have access.

Keep three questions apart. Did the automated checks pass? Did the walkthrough behave as agreed? Is the result good enough to release? A green build only answers for the checks it ran. A demo with one account doesn’t prove that other accounts are locked out.

Ask for the evidence that matters, not a wall of logs: the reviewed change, the access-check results, notes from the walkthrough, and the release decision, with any gaps stated plainly.

Rolling back code doesn’t always undo database changes. Your developer should pick a way back that fits the change. After release, check the task again on the live site.

5. Check whether things actually improve

Measure what slows you down. If requests keep waiting for answers, track the waiting time. If changes keep coming back, write down why. For the portal, also watch whether clients find what they need and whether related support emails go down.

Before you add automation, look at a few similar changes to get a baseline: the time from an agreed request to a checked result, bugs, failed releases, and user feedback. Note differences in size and staffing. A before-and-after difference alone doesn’t prove that AI caused it.

More code or more closed tickets don’t mean the business is better off. The question is whether a customer’s job got easier, at a cost and reliability you can live with.

A practical first step

Pick one feature your team is about to start. Fill in the brief together, leave the unknowns visible, name who decides what, and agree what you want to see before release. That conversation also shows you which parts of the process are ready for automation.

If that’s where your team gets stuck, tell me about it. We start with one request and the path it takes.