Software development with AI: what I establish before the first line of code

I design the development process before the product

My civil-engineering background influences how I approach software. Before building, I want to know the loads, constraints and likely failure points. A convincing screen is insufficient if its records, dependencies and recovery behaviour are unclear.

I separate two layers. Reusable standards describe coding conventions, documentation, UI and UX, tests, infrastructure stability, Git, research and AI authority. Project-specific decisions describe the business problem, users, data models, acceptance criteria and architecture.

Reusable procedures stop us reinventing the process. Project-specific decisions stop us imposing the same solution on every problem. My background is explained further on Sina Esfahani's founder page.

“Write good code” is not a usable standard

Instructions such as clean code, best practice and scalability are too vague to review consistently. I need rules about responsibility, dependencies, failure handling, complexity, module boundaries, compatibility and when refactoring is justified.

Code that works today but requires half the application to change for a small addition is not a good result for me. Documentation should preserve reasoning, assumptions, alternatives and uncertainty rather than merely repeat the implementation.

AI generates code faster than a person can always develop a mental model of it. That makes durable explanations and clear boundaries more useful, not less.

Infrastructure stability needs its own constraints

An AI model can respond to a small feature request by replacing a dependency, reorganising files or modernising an unrelated component. A possible improvement is not automatically justified by the task.

Deployment, core dependencies, API and data contracts, authentication and structure need an explicit reason for change. I ask whether the benefit justifies the risk and additional complexity. “It is newer” does not settle that question.

Interface and test standards concern behaviour

An interface includes loading, empty states, success, failure and the full mobile workflow alongside colour and typography. Those states are part of completion rather than late polish.

I define expected behaviour before implementation: what succeeds, what should fail safely, what duplicate requests mean and which edge cases matter. Writing a test is not running it. Passing cases prove the tested scenarios, not scenarios we forgot.

When a test fails, I want to understand why. Removing or weakening its assertion merely to obtain a green result does not answer that question.

Reusable skills should be procedures

A skill in my workflow is more specific than “be an SEO expert”. It identifies its trigger, required information, permitted tools, checks, output and prohibited assumptions. Important decisions belong in persistent project sources rather than relying on a remark earlier in a conversation.

SEO illustrates the approach. Before proposing a content structure, I want evidence for the relevant audience, market, language and task. Missing metrics must remain missing rather than be invented. Useful research becomes a reusable reference, while each page still needs its own reader purpose. Keyword research should not become a count of phrases to repeat.

A written standard is useful only when it changes decisions and the result is assessed against it.

Research needs a decision and a stopping point

Large projects can justify extensive preparation, but exhaustive knowledge is not achievable. Once we sufficiently understand users, scope, architecture, risks and remaining assumptions, implementation should begin.

Scope also records what we will not build yet. A possible feature is not automatically a current requirement. Define acceptance for missing fields, network failures, duplicate submissions and failed authority before generated code silently chooses a behaviour.

Technology and data follow the business reality

I start with what the system must do, how it changes and who will maintain it. Sometimes the justified answer is sophisticated; often it is simple. Complexity needs a reason.

AI can propose database structures and identify relationships or edge cases. A human still supplies business decisions: should a historical order retain its address, what happens after account deletion and which changes must remain auditable?

A destructive data migration is fundamentally different from reverting application code. Schema changes therefore deserve their own review and recovery planning.

After tests, I read the code myself

Once implementation and automated testing are complete, I read generated code line by line. Why is this condition here? Where does the value come from? What happens if the call fails? Can I explain and maintain it in six months?

I may ask AI to criticise the implementation or find edge cases. AI reviewing AI does not remove human judgement. A confident explanation is not evidence that code matches the requirement.

The value of AI is that I can research more quickly, compare approaches, challenge assumptions and explore large codebases. Without a disciplined process it can generate complexity and technical debt just as efficiently as working features.

For me, completion means the requirement is met, important assumptions have been checked and I can take responsibility for the result. It does not guarantee error-free software or eliminate changing requirements.

That is the standard behind custom software at OmniTechs and my approach to building an AI agent. The earlier experiments that shaped it are described in building systems around AI.