How architects and technical leads define data, access, workflows and failure behaviour before AI builds code.
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
AI can now produce a working application interface, database query, API endpoint, integration, or infrastructure configuration in minutes. This changes the economics of custom software delivery.
The main constraint is moving away from the mechanical production of code. Companies still need someone to define the data, access rules, workflows, failure behaviour, infrastructure boundaries, and acceptance criteria behind that code.
AI-assisted development creates the greatest advantage when an experienced technical lead controls those decisions. The same tools can implement a strong system quickly or turn a weak assumption into a production application before anyone has examined the consequences.
The value increasingly sits in deciding what should be built, directing the implementation, and verifying that the complete system behaves correctly.
I learned full-stack development before AI coding tools could reliably implement complete application features.
Building a production application required manually working through frontend components, API routes, database queries, authentication, hosting, caching, queues, migrations, and deployment. A missing piece could consume several days of documentation, experimentation, and debugging.
That slow process built a detailed understanding of how the parts of an application interact.
I now use AI throughout development. I spend more time defining the system, reviewing decisions, testing behaviour, and controlling the direction. The implementation itself moves far more quickly.
During a recent marketplace prototype, AI helped accelerate the delivery of vehicle listings, financing calculations, partner access, lead capture, structured operational screens, and the supporting data model. The speed came from combining capable tools with clear business rules and an existing understanding of marketplaces, multitenancy, permissions, and production infrastructure.
AI did not decide how financing should behave, which data needed to be preserved with each lead, how partner access should be isolated, or which actions belonged in the customer journey. Those decisions had to exist before the code became useful.
A custom application begins as a set of business statements.
A company may need multiple brands, editorial approvals, customer accounts, partner access, document processing, financing calculations, internal search, or an AI assistant.
Each statement contains several technical decisions.
“Multiple brands” can involve shared content, tenant-specific content, user permissions, media separation, localization, reporting, and deployment boundaries.
“Editorial approvals” can involve roles, versions, workflow states, publishing authority, audit history, notifications, and rollback behaviour.
“An AI assistant” can involve document ownership, access-aware retrieval, source attribution, ingestion, model selection, data retention, and escalation to a human.
AI can implement whatever structure it's given, and choosing that structure remains a decision only a person can make.
A vague prompt can produce a plausible demonstration, though production software still requires explicit decisions about ownership, security, failure handling, and long-term operation.
Traditional development created natural friction. A complicated feature took time to implement, which sometimes forced a team to examine the requirement before investing heavily in it.
AI reduces that friction. A poorly considered feature can now reach a convincing state very quickly.
This affects several common areas:
| Area | Fast implementation can produce | Architecture must define |
|---|---|---|
| Data model | Collections, fields, and relationships that appear complete | Source of truth, ownership, lifecycle, duplication rules, and future migration |
| Access control | Login screens and role checks in the interface | Server-enforced permissions for every operation and data boundary |
| Multitenancy | A tenant selector and filtered pages | Isolation across queries, APIs, background jobs, media, and administrator actions |
| AI retrieval | A chatbot connected to documents | Ingestion rules, permissions, citations, freshness, and acceptable failure behaviour |
| Infrastructure | Containers, databases, storage, and deployment files | Recovery requirements, operational ownership, cost boundaries, and scaling assumptions |
| Background processing | Queues and scheduled jobs | Retry logic, duplicate prevention, status tracking, and manual recovery |
| Caching | Faster responses and fewer database requests | Invalidation, privacy boundaries, drafts, localization, and user-specific content |
| Migrations | Automatically generated schema changes | Testing, sequencing, rollback, data transformation, and production safety |
The resulting application can look polished while carrying structural problems that only appear with real data, different user roles, failed integrations, or production traffic.
These problems are difficult for decision-makers to see during a demonstration. They emerge later as rework, operational confusion, data exposure, or an inability to change the system safely.
AI-assisted development works best when architecture provides a control layer between the business requirement and the generated implementation.
That control layer defines four things.
Every important category of information needs a clear owner.
Product data may belong in an inventory system. Marketing content may belong in the CMS. Customer activity may belong in the application database. Private documents may require a separate ingestion and permission model.
AI can connect these systems after their responsibilities are clear. Connecting systems without ownership rules creates duplication and uncertainty.
Permissions need to be defined from the data outward.
Reliable security requires the underlying API and database operation to reject the action, beyond simply hiding a button in the interface.
This becomes especially important in multi-brand, multi-tenant, partner, healthcare, finance, and internal knowledge systems. AI can generate access rules quickly, but those rules still need to reflect the actual organization and be tested against realistic roles.
Business processes contain states, decisions, exceptions, and responsibility.
A lead can be new, reviewed, qualified, assigned, contacted, rejected, or converted. A document can be drafted, translated, approved, scheduled, published, or withdrawn. An AI-generated answer may be accepted, corrected, escalated, or stored.
The implementation needs to preserve these transitions and make them understandable to the people operating the system.
Production systems spend part of their life in imperfect conditions.
An integration becomes unavailable. A queue retries the same task. A deployment introduces an incompatible schema. A document fails to process. A user loses access halfway through a workflow.
Architecture defines what the system should do in those situations. AI can help implement retries, logs, fallbacks, and recovery tools after the expected behaviour has been specified.
The practical role of an experienced developer is changing.
Manual code production remains necessary, but it occupies a smaller share of the delivery process. More time moves toward:
This role combines aspects of software architecture, product thinking, implementation, and technical operations.
It is particularly valuable for companies that need one accountable person to connect the business problem with the delivered platform.
AI gives a small experienced team the ability to deliver more without recreating the structure of a large agency.
A senior technical lead can remain directly involved in discovery, architecture, implementation, and production validation. Design, engineering, infrastructure, and content decisions can be coordinated with fewer handoffs.
This model suits focused platforms where clarity, speed, and direct ownership matter, more than large transformations with many simultaneous workstreams that call for larger specialist teams. Examples include:
The advantage comes from combining senior attention with increased implementation leverage.
A proposal that mentions AI-assisted development should explain how the work will be controlled.
Decision-makers should understand:
A strong answer describes a delivery process, while a weak one focuses only on the tools being used.
The tool generates the code, and the delivery partner remains responsible for the system it becomes part of.
Companies should benefit from faster implementation.
A feature that previously took several days may now take several hours. A small team can test more ideas, build more complete prototypes, and spend more time validating the actual business workflow.
The saved time should go toward better discovery, architecture, testing, documentation, and iteration, expanding the capacity for that work rather than becoming a reason to skip it.
This is the commercial opportunity of AI-assisted development. Companies can receive sophisticated systems faster while retaining senior oversight throughout the engagement.
AI can implement a large portion of a production application, though the system still needs clear requirements, architecture, security rules, infrastructure decisions, testing, and accountable technical ownership.
The quality of the result depends heavily on the direction and review provided by the people using the tools.
It can reduce implementation time and allow a smaller team to deliver more. The final price also depends on complexity, risk, integrations, data migration, design, compliance, and the amount of operational responsibility involved.
The clearest benefit is usually more delivery capacity for the same project team.
The buyer should assess the delivered behaviour and the process used to validate it. This includes permissions, workflows, data integrity, failure handling, migration safety, performance, recovery, and maintainability.
A technical review may also be appropriate for sensitive or business-critical systems.
Yes. Experience with databases, security, infrastructure, application architecture, and production operations helps a developer direct AI effectively and identify unreliable output.
AI provides implementation leverage. Existing knowledge determines how safely and usefully that leverage is applied.
Projects with clear business requirements, accessible systems, and an experienced technical lead can benefit substantially. Internal applications, CMS platforms, marketplaces, workflow systems, integrations, and focused AI tools are strong candidates.
Projects with unclear ownership, unresolved business processes, or highly specialized technical requirements need more discovery before implementation speed becomes useful.
AI has made application development significantly faster, though the business still depends on the quality of the decisions behind the application.
A clear source of truth, reliable permissions, controlled workflows, safe migrations, and defined failure behaviour give AI a structure it can implement effectively.
My work starts by defining that structure. I then use AI-assisted development to move from architecture to a working production system with less implementation overhead and direct senior ownership throughout the process.
If your company is planning a custom application, digital platform, CMS modernization, marketplace, or internal AI workflow, I can help define the system and build the implementation around it.
Thanks, Matija