In scope of the discussion about mastery, I thought about advice I would give beginners and skeptics how to start with agentic engineering and agentic workflows.

1. Start small

Forget all the fancy tools and frameworks out there and start with the basics. You’ve probably used AI for some better auto-completion, as it is a built-in feature in IDEs, such as IntelliJ IDEA.

Next step is to use a coding agent for a small and well-defined task. You should use it for a simple problem, you already know the solution. I think this is crucial, because you can compare the results from the agent with your desired solution. I think good examples are new REST controller or minor domain adaptions.

The initial goal is not productivity. It is to become familiar with the workflow and develop realistic expectations of what agents can and cannot do. Iterate and continue with more complex tasks.

In this phase, your prompts will look like this:

• “Implement field name as non-nullable string in controller UserController”
• “Create tests for method changeUserName in UserControllerTest”

2. Use different agents modes

Make yourself familiar with planning and implementation modes of coding agents, as they will use different set of tools and permissions. In planning mode, agents only have read-only access, and they will guide you through a planning process which is quite good, depending on the complexity of the task.

Typical prompts at this stage might look like:

• “Create a plan to implement field name as non-nullable string in controller UserController. Also include unit tests in your plan. I want to have a test for changing the username.”
• “Implement now the plan”

3. Improve Context

When you start with more complex tasks, they also need more context. You will experience over time, that vague and ambiguous prompts lead to worse results. In general, the more context you provide, the more accurate and repeatable your results will be. Context can be anything. It can be user story descriptions, API documentation, screenshots of mockups, example code, references to commits, etc.

In the examples above, updating the controller was just one part of your user story. The whole story was about enabling users to change their name via REST API.

At this point, you’ll write prompts such as:

Look at the user story description in `user-story.md`. I want to provide a feature for users to change the name, via a
REST API. The acceptance criteria are specified in the story.

Technical notes:

- You need to implement the controller, the service layer and the persistence layer.
- For changes in the REST controller, you also need to update the API specification `openapi.yaml`.
- For changes in the entity layer, you also need to document new fields in `gdpr.md`, with PII classification and
  deletion retention.
- You need to create flyway migration script as well.

Deployment notes:

- Design it in a way that I can roll out this change without downtime.

Examples:

- As a reference, look at the commit with the hash starting with `4ad69327d6ca631aa5929`. In this commit, a `title`
  field was added for `books`.

Make a plan. 

4. Identify repeating usage patterns and encapsulate in Skills

When you do the steps above, you’ll reach a point where you repeat yourself many times. For example, you don’t want to specify over and over again how rest controllers or entities should be implemented your way.

For that, you can encapsulate the logic and constraints in skills. With skills, you can even create custom tools and make them accessible to the agent.

In our example above, you would probably create a db-implementation-skill, that contains information that db changes should be implemented in a non-breaking way, db fields should be documented in the gdpr.md file. Or you could also have an api-implementation-skill that describes that API changes also need to be reflected in the openapi.yaml file.

A realistic prompt could be:

Look at the user story description in `user-story.md`. I want to provide a feature for users to change the name, via a
rest API. The acceptance criteria are specified in the story.

Use the `api-implementation-skill` and the `db-implementation-skill` for designing this change.

Examples:

- As a reference, look at the commit with the hash starting with `4ad69327d6ca631aa5929`. In this commit, a `title`
  field was added for `books`.

Make a plan. 

Note: You don’t have to specify the skills exactly by name. The agent will detect and pick them up automatically. I typically prefer to explicitly name them.

5. Build collaboration processes on top

Since you work in a team with other engineers, prompting the whole day alone with the agent is boring. If you foster pair programming as in my company, you would design a collaboration process around steering the agent.

I believe in this phase, you really need to find what works best for your team. I made some observations in my team where I believe they are also true for other teams.

1. Make the collaboration interactive for all engineers

When you work in pairs, you typically switch the roles between driver and co-driver. This also needs to be done, when working as humans in pairs with the agent. I made good experiences by dumping an agents implementation plan into a Markdown file. This file is shared with a collaborative editor, so that all participants can read it on their own screen, in their own pace and everybody can annotate the plan.

After a review cycle, somebody asks the agent to incorporate the user feedback into the plan and create a new version. This can be done multiple times, until the plan is good. The execution of the plan again is done by one engineer.

2. Work in small(er) groups

In the beginning, our whole team was present in an agentic engineering session, because we were excited and everybody wanted to learn. It was boring for most the engineers, because we haven’t had established a collaboration process yet. Over time, we realized, that the whole team doesn’t need to be present in such sessions. Now, depending on the scope and the impact of a user story, our groups consist of 1 to 3 persons.

Conclusion

A solid agentic engineering approach is no myth. It already exists and can be learned by any engineer who is interested and willing to learn and think differently.

---