Guide to AEMaaCS Development with AI

Author: Tom Cranstoun
AEM Development with AI:

My Journey with Cline

AEMaaCS Development with AI: My Journey with Cline

After years of working with Adobe Experience Manager (AEM), I want to share something exciting that's transforming how I approach development. First, let me be clear - I'm not a traditional developer. While I understand AEM deeply from a technical perspective and have fixed my share of broken instances, I don't typically write components or workflows. My strength lies in understanding how AEM works at its core.

The Evolution of My Approach

I recently embarked on an experiment with AI-assisted development, going through three distinct phases before finding what I consider a game-changing solution. It started with exploring various tools and approaches, but the real breakthrough came when I discovered Cline (formerly known as Claude Dev). I started out with a ‘kitchen-sink’ approach, creating a RAG knowledge base for Edge Delivery Services and cursor IDE, as the internet does not have a huge history for EDS.

Kitchen sink approach

https://allabout.network/blogs/ddt/developer-guide-to-document-authoring-with-edge-delivery-services-part-8



This technique does not work for pure AEMaaCS -- too much info out there, no need for a RAG.

I then employed a hard-coded strategy where I assigned a distinct domain name following a specific pattern. For instance, "my company name is tom.com", “my content group name is Tom Site - Content” etc. This involved manually creating and maintaining individual settings for each facet, which presented several challenges.

This naming convention is specific to this project's setup and is crucial for proper component organization and visibility in the AEM authoring interface.

Firstly, it was time-consuming to set up and manage the structures

Secondly, the hard-coded approach lacked flexibility. If a name or branding changed, I would need to manually update the values. This process was not only tedious but also prone to errors.

Additionally, the hard-coded approach made it difficult to maintain consistency across different platforms and systems. For example, if I wanted to share this with another developer, on another project they would have to input new values

To address these challenges, I decided to adopt a more dynamic and scalable approach. Instead of hard-coding the names, I implemented an AI Strategy where the AI would introspect the code to obtain the values

Overall, transitioning from a hard-coded approach to an introspection system has greatly improved the efficiency, flexibility, and scalability of my content management process, allowing me to work on multiple codebases with multiple developers, with no changes required. This would only work if the AI could scan my directories and read files; Enter CLINE.

Enter Cline

https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev

Cline stands out from traditional coding assistants due to its groundbreaking integration with your Integrated Development Environment (IDE) and its utilization of Anthropic's advanced "computer use" capabilities. Here's an elaboration of what makes Cline truly special:

The combination of AI, direct codebase interaction, and real-time feedback makes Cline a powerful and versatile tool that can revolutionize the way developers work. Cline's capabilities are anything but ordinary, providing a cutting-edge solution for enhancing coding efficiency and accuracy.

Cost and Setup

The Magic of Proper Prompting

The secret sauce isn't just the tool - it's how you instruct it. I've refined my prompts through multiple iterations to create a system that:

  1. Introspects existing project structures
  2. Generates appropriate configurations
  3. Adapts to project conventions rather than enforcing pre-existing ones
  4. Understands AEM's component patterns

A Practical Example

During a recent demonstration, I created a simple "Hello World" component. The fascinating part wasn't just that it worked, but how it worked:

What's particularly impressive is that this happened with zero manual coding. When issues arose (as they always do in development), the system was capable of self-correction and provided clear explanations of what needed to be fixed.

Beyond Basic Components

The system isn't limited to simple components. I've developed prompts for:

Each prompt is engineered to understand and work within AEM's architectural patterns.

Prompt Engineering is Key

Prompt engineering is an art that requires creativity, technical expertise, and a deep understanding of the capabilities and limitations of the large language model (LLM) being used. It's not enough to simply type in a few words and expect the LLM to generate the desired output. Instead, prompts must be carefully crafted to elicit the best possible response.

One of the key challenges in prompt engineering is finding the right balance between specificity and flexibility. On the one hand, prompts need to be specific enough to guide the LLM towards the desired outcome. On the other hand, they must also allow the LLM enough room to use its own creativity and intelligence to come up with unique and surprising solutions.

Another important aspect of prompt engineering is understanding the different types of prompts that can be used. Some prompts are designed to be factual and informative, while others are more creative and exploratory. Some prompts are best suited for tasks that require a high degree of accuracy, while others are better suited for tasks that require more creative thinking.

Finally, it's important to remember that prompt engineering is an iterative process. There is no one-size-fits-all approach that will work for every task. Instead, it's important to experiment with different prompts and see what works best for the specific task at hand.

By following these tips, you can master the art of prompt engineering and unlock the full potential of LLMs.

Looking Forward

The landscape of AI development tools is rapidly evolving. While Cline currently has an advantage due to its computer use capabilities, other tools like Cursor are catching up. Since they're both using Claude under the hood, the differentiator comes down to how they interact with your repository.

Want to Try It?

I'm currently sharing my prompts with other developers for testing and feedback. If you're interested in experimenting with this approach, I'd love to hear your results, especially with real-world implementations.

Final Thoughts

The most exciting part of this journey has been discovering how AI can complement our understanding of AEM rather than replace it. It's not about removing the developer from the equation - it's about amplifying what we can accomplish while maintaining control over the architecture and implementation.

Remember, the goal isn't to replace traditional development practices but to enhance them. Whether you're building simple components or complex workflows, the right combination of AI assistance and human oversight can significantly improve your development workflow.

My Prompt for “Create an AEM Component”

# AEM Component creator

You are an AI assistant specialized in creating AEM (Adobe Experience Manager) components. Your task is to generate component code and configurations based on the existing project structure and conventions.

Before creating the components, you need to analyze the project structure and conventions. Document your findings in `<project_analysis>` tags. Pay special attention to:

1. Project namespace
2. Java package structure
3. Existing component patterns
4. Clientlib organization
5. Resource type conventions
6. Component group conventions
7. Property naming conventions
8. Model registration and package exports

In your analysis, include the following steps:

1. Scan the project structure and identify patterns and conventions for each aspect listed above.
2. Read `/pom.xml` to identify the project namespace and extract configuration details, paths, and conventions.
3. Identify patterns and conventions for each aspect listed above.
4. Extract configuration details.
5. Analyze container policies for allowed component groups.
6. Analyze property naming and alignment patterns.
7. Analyze model registration and package exports.
8. List all components that need to be created based on the input.

After your analysis, plan out the file structure for each component before generating the files. Then, generate the necessary files for each component. Follow these steps:

1. **Component Planning:**
   - List all required files for each component.
   - Outline the structure and key elements of each file.

2. **Component Generation:**
   - Use discovered patterns.
   - Follow project conventions.
   - Maintain consistency.
   - Ensure that copyright notices are updated in new files. Do not copy the copyright from the original files. New files should say Copyright {{thisyear}} {{yourname}}.
   - Ensure `componentGroup` matches policy-allowed groups.
   - Ensure property names align across all files.
   - Configure proper model registration.
   - If a text field is unconfigured, provide a default value of 'Configure me!'.

3. **Integration:**
   - Align with existing components.
   - Follow project structure.
   - Use discovered naming patterns.
   - Validate component group against policies.
   - Validate property alignment.
   - Verify model package exports.

When creating brand new code files, do not use (c) copyright messages from templates. use  Copyright {currentyear}

For each component, generate the following files:

1. **Component Definition (.content.xml):** This file should only contain top-level elements defining the component's metadata (title, componentGroup, etc.). Avoid adding unnecessary nested elements within the root `jcr:root` element unless they are required for specific component functionality.  Keep the structure as minimal as possible.
2. **HTML Template (.html)**
3. **Dialog Structure (_cq_dialog/.content.xml)**
4. **Clientlibs (if applicable)**
5. **Java Model**

Ensure that property names are aligned across all files:

- Model (.java): `@ValueMapValue private String property;`
- Dialog (.content.xml): `name="./propertyName"`
- HTML template (.html): `${model.propertyName}`

After generating the component files, create two additional documents:

1. `{component-name}-README.md`: A narrative for developers, installers, and content authors.
2. `{component-name}-self-review.md`: A technical analysis of the code and learning points.

**Troubleshooting:**

- **Empty Node Errors:**  Ensure that the `.content.xml` file does not contain empty nodes.  Only include necessary elements.  If you need to add a policy, ensure it contains at least one allowed component.
- **Validation Errors:** If you encounter validation errors during the build process, carefully review the error messages and ensure that all generated files adhere to the project's conventions and structure.

Present your output in the following structure:

```xml
<component_files>
  <file_path>path/to/file</file_path>
  <file_content>
  // File content here
  </file_content>
</component_files>

<readme>
// Content of {component-name}-README.md
</readme>

<self_review>
// Content of {component-name}-self-review.md
</self_review>
```

Remember to adhere to the following:

- Use Java openjdk version "11.0.16.1"
- Build for AEMaaCS
- Follow Airbnb linting for Markdown files
- Log steps taken in a `log.md` file (append to this file for each new prompt)

Begin by analyzing the project structure and conventions. Once you have completed your analysis, proceed with planning and generating the component files and documentation. Make sure to check for consistency across all generated files before finalizing your output.

This is just the beginning of what's possible with AI-assisted AEM development. I'm excited to see how these tools evolve and how the community adapts them to solve real-world challenges.

/fragments/ddt/proposition
style
bg-dark


Related Articles

guide
guide
Back to Top