My thinking about AI-assisted software development has changed several times. I adopted coding tools early, became sceptical as their weaknesses became more apparent, and have now settled into a more selective way of using them. Coding agents can generate implementation quickly when they understand the pattern they need to follow. The more useful question is where that speed gives an engineer room to solve a harder problem.
I now spend more time away from the editor, often writing and drawing on paper or using Excalidraw. For around nine out of ten pieces of work I give an agent, I also ask for an HTML artifact: a standalone visual I can open in a browser and inspect. It gives the proposed solution enough shape for me to verify the direction before a large amount of code exists. I remain involved throughout the process, even when the agent handles most of the implementation.
Software does not demand equal engineering attention
A piece of software contains work with very different levels of uncertainty. Some tasks follow conventions already established in the codebase, have an obvious result, and are easy to inspect when finished. Other tasks require somebody to understand an unclear product need, choose between competing tradeoffs, or make a decision that will shape the system for years. Treating those tasks as equivalent wastes senior engineering attention.
I use predictable to describe work where the intended behaviour and implementation pattern are already understood. The work may still be necessary and technically involved. Its defining characteristic is that an engineer can describe the result clearly enough to recognise whether the agent produced the right thing.
This distinction can appear in any part of the stack. Interface components often follow visible patterns, while backend services can also contain routine integrations, transformations, and repetitive implementation. I have written previously about keeping engineering ownership close while using coding agents, and task predictability is the practical boundary I now use to apply that position.
What makes software work predictable enough to delegate
Task labels provide a weak delegation rule because two apparently similar features can contain very different risks. A small settings screen might expose a difficult permissions problem, while a substantial integration might follow an existing adapter almost exactly. I find it more useful to examine the shape of the work.
| Question | Good candidate for delegation | Keep closer when |
|---|---|---|
| Is the desired behaviour clear? | The expected result can be described precisely | Important product questions remain unresolved |
| Does a pattern already exist? | The codebase contains a convention or similar implementation | The task will establish a new architectural direction |
| Can the result be verified? | Tests, types, HTML artifacts, or visible behaviour expose mistakes | Correctness depends on hidden assumptions or specialist knowledge |
| Is correction inexpensive? | A mistake is local and easy to reverse | A mistake could damage data, security, or reliability |
| Does the team understand the surrounding system? | The agent is extending something the team already owns | The generated work would become the team’s only source of understanding |
None of these questions depends on a specific model, editor, or framework. They describe the conditions that make delegation safe enough to be useful. When several answers fall into the right-hand column, the engineer still has discovery work to do before asking for implementation.
Verification is especially important because agents can move from a vague request to a substantial amount of code very quickly. An HTML artifact gives me an intermediate result that is cheaper to inspect and change. I can verify the flow, structure, and intended behaviour while the work remains easy to redirect.
The difficult work begins before implementation
I increasingly start with paper because an empty editor encourages me to think in code too early. Writing and drawing make it easier to move between the product problem, user flow, system boundaries, and unresolved questions. Excalidraw serves the same purpose when the drawing needs to be shared or changed without covering my desk in increasingly mysterious pieces of paper.
Once the rough thinking is clear, an HTML artifact often becomes the next step. It translates part of the plan into something concrete enough to inspect without committing to the final implementation. Missing states, unclear relationships, and incorrect assumptions become easier to notice when I can see the proposed result instead of reviewing a description alone.
The goal is to remove enough ambiguity that the work separates into meaningful decisions and predictable implementation. I want to know which behaviour is essential, which constraints are real, and where a wrong choice will spread through the rest of the system. This produces a better plan for me and better instructions for an agent.
Planning also reveals when a task only looked predictable from a distance. A request for a simple feature can hide questions about permissions, data ownership, failure handling, or an unclear product rule. Discovering those questions before generation saves me from reviewing a large implementation built on an assumption I never intended to make.
What should remain under direct engineering ownership
Some areas deserve direct attention because they define what the product means or how the system behaves under pressure. An agent can contribute options and prototypes in these areas, although the team still needs enough understanding to choose responsibly. I keep the following work close:
- unresolved product and domain behaviour
- the data model, meaning the structure and relationships governing stored information
- architecture and boundaries between important parts of the system
- security, permissions, and handling of sensitive data
- reliability and recovery when something fails
- decisions that will be expensive to reverse
Generated suggestions can help compare approaches and expose questions I have missed. They can also produce visual artifacts or small experiments that make an abstract tradeoff easier to evaluate. The final decision remains mine because I will need to explain it, operate it, and change it when the assumptions eventually move.
This ownership is especially important around security and data. Plausible output provides no assurance that the model understood every trust boundary or failure case. These parts require explicit review, testing, and a person who accepts responsibility for the result.
Delegation should buy attention rather than code volume
People often describe AI coding progress through the percentage of code generated or the number of tasks completed without manual typing. Those measurements are easy to produce and difficult to connect to a useful product outcome. A larger implementation can create extra review, rework, and maintenance while still looking productive on a dashboard. I care more about what the recovered engineering time made possible.
The practical test is whether delegation created room for the project’s real bottleneck. That bottleneck might be an unclear workflow, an architecture decision, a difficult migration, or a reliability problem. AI has created leverage when the engineer can spend more time resolving that uncertainty without allowing the predictable work to stall delivery.
For founders and engineering leaders, I would evaluate AI-assisted work through questions such as:
- Did the team reach a sound decision sooner?
- Could the engineer verify the direction before full implementation?
- Can the engineers explain and change what was generated?
- Did delegation reduce delivery time without creating avoidable rework?
- Is the critical path easier to operate and maintain?
- Did senior attention move towards the most consequential problem?
These questions are less convenient than counting generated lines. They are closer to the reasons a company pays for engineering in the first place. Software creates value through the problems it solves and the risks it removes, while code remains one of the materials used to get there.
The boundary will keep moving
A reasonable counterargument is that this division reflects the limitations of current tools. Models will improve, automated verification will become more capable, and tasks that require close supervision today may become predictable tomorrow. I expect the delegation boundary to move as those changes arrive.
I still see two risks in following that boundary too aggressively. Engineers need enough regular contact with code to recognise poor generated work and diagnose a system when the agent cannot help. Teams also depend on external subscriptions whose prices, limits, and capabilities can change, which makes rented implementation capacity a real operational consideration.
Visual verification reduces some of the distance between me and the generated work. It does not prove that the implementation is secure, reliable, or correct beneath the surface. I still need tests, code review, and enough understanding of the system to recognise when the artifact presents a convincing version of the wrong solution.
The framework remains useful because it evaluates the work in front of us instead of preserving a fixed list of tasks for humans. Better tools can move more work into the predictable category. The team should still understand the critical system and retain the ability to operate it.
What founders and engineering leaders should expect
AI-assisted software development should change expectations without reducing engineering to agent supervision. A capable engineer should identify where judgment matters, make proposed solutions visible, create clear boundaries for delegated work, and verify that the result belongs in the wider system. They should also leave the team with enough understanding to maintain the software after the initial delivery.
In practice, I would expect an AI-assisted engineer to:
- clarify the product problem before generating implementation
- identify decisions that are expensive to reverse
- make plans and proposed behaviour easy to inspect
- delegate work with explicit constraints and a verifiable result
- review generated code according to its actual risk
- explain the architecture and important tradeoffs
- keep ownership of the system inside the team
This is where senior engineering becomes more valuable. Faster implementation increases the number of possible directions, and somebody still needs to choose a direction that fits the product, team, and operating reality. Good judgment keeps that speed attached to a useful outcome.
The workflow I use now
My current workflow is deliberately simple. It gives the agent enough structure to move quickly and gives me clear points where I remain responsible. The exact tools can change without changing the process:
- Understand and draw the problem using paper or Excalidraw.
- Identify the essential and difficult-to-change decisions.
- Separate predictable implementation from unresolved engineering work.
- Generate an HTML artifact for most tasks so I can inspect the proposed direction.
- Correct the flow, structure, or assumptions while changes remain inexpensive.
- Give the predictable implementation to an agent with clear boundaries.
- Review the result according to its risk.
- Stay active in the code carrying long-term ownership.
- Spend the recovered time on the harder parts of the product.
I am still keeping my hands in the code. I am becoming much more selective about which code deserves direct attention and which implementation can follow a recipe I already understand. The artifacts ensure that delegation does not remove me from the process, because I am verifying the shape of the work before and during implementation.
This is also how I approach technical leadership and AI-assisted engineering through MBV Labs. I help founders identify the important decisions, make the proposed direction inspectable, and stay close enough to the implementation to own what ships. If your project has more technical ambition than available senior attention, you can share the problem with MBV Labs.