Developing for AI: The New Paradigm of Application Architecture with Intelligent Agents

Introduction: An Experiment to Understand the Future of Development

Neutral Starter Py is an experiment conceived to explore how we should design applications in the era of AI agents. Its premise is radical: if we want AI to actively collaborate in software development and maintenance, the architecture must be designed from the ground up to be readable, modifiable, and extensible by language models.

This project, which combines Python (Flask) with the Neutral TS template engine, proposes one path: extreme modularity based on self-contained components. But beyond the technology, what is truly innovative is its stated goal: "to provide developers with AI-powered agentic capabilities." It is, above all, a testing ground for understanding where we are heading.

The Motivation: Adapting to the New Reality

We are living through a paradigm shift. AI models are no longer just tools for consultation or text generation; they are becoming agents capable of executing complex tasks within our development environment. However, most current codebases are optimized for human reading, not for autonomous AI intervention.

How can we, as developers, face this challenge?

The answer may lie in changing our role: from being mere "code scribes" to becoming architects and orchestrators of architectures. Our work will no longer be just implementing functionalities, but creating the blueprints and rules (the "skills") so that AI agents can build and evolve software within safe and coherent boundaries.

The Heart of the System: Components as "Atomic Units" for AI

The strength of this approach lies in a directory like src/component/. Each subfolder with an identifying prefix (for example, cmp_6100_rrss, an RSS reader) is a complete and isolated functionality.

What does this mean for an AI?

• Self-containment: A component includes everything it needs: routes, business logic, templates, static files, configuration, and metadata. An AI can read a single component and fully understand its purpose and operation without examining the rest of the project.
• Isolation: If a model receives the instruction "modify the RSS reader to include images," it can operate within the boundaries of that component with the certainty that it will not affect the login component or the database one. This drastically reduces cascading errors and the need for constant human supervision.
• Replaceability: A component can be removed simply by deleting its folder, without causing application failures. This feature is crucial to allow the AI to experiment, propose alternative versions, and subject them to testing.

Practical Example: A component like cmp_7000_hellocomp serves as a template. It contains its own logic, its specific CSS/JS, and its templates. For an AI, it is a model to follow: "if you want to create a new component, copy the structure of hellocomp and adapt it."

Persistent Memory: The AI's "Skills"

One of the biggest challenges when working with AI on software projects is the loss of context between conversations. Each new interaction starts practically from scratch, leading to inconsistencies and having to repeat instructions.

The solution proposed by this paradigm is the creation of a repository of "skills" accessible to the AI, typically in a folder like .agent/skills. These are definitions of "abilities" that the AI must read to align its behavior with the project's architecture.

How do they work in practice?

1. When starting a new task, the AI consults these files.
2. It finds rules like: "To create a new component, you must:
   • Name it with a prefix and an order number.
   • Include a metadata file.
   • Define its routes following the established pattern."
3. With these "workshop instructions," the AI can generate code that integrates perfectly with the rest of the application, maintaining coherence over time.

The conclusion is key: a large part of the developer's work in this new paradigm will consist of providing the project with sufficient skills. In the same way that we used to document code so that other humans could understand it, we now have to document tasks and processes so that the AI can execute them autonomously and coherently. Every recurring operation (creating a component, adding a route, modifying a template) must have its counterpart documented in the form of a "skill." These skills are the project's long-term memory and the main deliverable of the developer-architect.

Prompt Strategy: The Art of Communicating with AI

If the skills are the "manual," the prompt is the "work order." A good prompt in this context follows a structure we can call Prompt Strategy: the systematic way of asking the AI to generate new functionality.

An effective prompt contains key elements:

"Your task is to create the component [name], which must [functional description]. Use route: /my-route. To complete this task, review: - .agent/skills/manage-component/SKILL.md - .agent/skills/manage-templates/SKILL.md - src/component/[example_component] (as an example). Define routes dynamically if needed, following the pattern used by other components."

This strategy includes:

1. Clear Identity: Component name.
2. Functional Purpose: What it should do.
3. Entry Point: The URL.
4. References to Documentation: The skills the AI must consult.
5. A Concrete Example: A real component from which to extract patterns.
6. Design Principles: Style guidelines.

A good Prompt Strategy recognizes that the AI is a "collaborator" that needs context, examples, and clear rules to operate effectively within our code ecosystem.

A Qualitative Leap: Towards "Darwinian" Component Development

Component-based modularity opens fascinating possibilities. Since each component is an independent unit, nothing prevents the existence of multiple simultaneous versions for the same functionality (e.g., a comment system) generated by different AI models or in different sessions.

A developer (or even an "AI supervisor") could then:

1. Run performance and security tests on each version.
2. Evaluate code quality, readability, or resource consumption.
3. Select the best implementation and promote it to the definitive version.

This turns the development process into a cycle of generation, evaluation, and selection, similar to an evolutionary process. Our role would no longer be to write every line, but to design the experiment, define the selection criteria, and orchestrate the flow.

Conclusion: The New Role of the Developer as Architect-Orchestrator

If AI can write increasingly complex code, our value will no longer reside in the ability to type algorithms, but in:

• Designing architectures that are inherently "AI-friendly," with clear boundaries and explicit rules.
• Defining the "skills" , i.e., documenting the tasks and processes that the AI needs to know to operate coherently. This is, essentially, documenting the "how things are done" in the project.
• Creating effective Prompt Strategies that guide the AI towards optimal solutions.
• Orchestrating and evaluating the generated work, deciding which components deserve integration.

In this new paradigm, code is not only for humans to read, but also for machines to interpret and modify. Documentation is no longer just for other developers: it is the fuel that allows AI to operate autonomously and aligned with our objectives.

The question is no longer "how do I program this?", but "how do I organize the knowledge, architecture, and tasks so that AI can program it with me, coherently and reliably?" Answering this question will likely be the most valuable skill for developers in the coming decade.