by A lot has been talked about what the best way is to drive when practicing agentic engineering. Some people still find it frustrating because of their expectations: they want the agent to write the code as close as possible (if not identical) to what they would do.
I recently read the post Taming the Genie: "Like Kent Beck", by Kent Beck himself. In this post, he described an experiment he carried out with the goal of getting an AI coding agent (which he calls "the genie") to code like him based on something he was suggested: adding "like Kent Beck would" to the prompts. Considering that he’s a famous and well-succeeded developer, with books and other sources that show his coding practices and skills, the training set of the model he’s using probably has thousands of examples of how he would code, right? I don’t want to spoil the content of Kent’s post, you should read it yourself as it’s a very interesting read!
What caught my attention in this idea is that it scratches an itch that I’ve been having! Here’s a bit of the story: I’ve been developing the backend of an application, and most of this has been done organically, with little to no usage of a coding agent because I really wanted to feel the impact of my decisions, carefully design the abstractions and their implementations, so on and so forth. As for the frontend of this application, I’ve decided from the beginning that I wanted to use as much of agentic engineering as possible, as long as I enforced two things: 1) the tech stack, and 2) the software architecture practices followed by the agent to be similar to what I would do.
So, even though I’ve been a public speaker since 2015 (with some of the recordings and slides available online), and have been writing blog posts for a while as well, I knew that I wasn’t even close to be as well-known as Kent Beck is to pull it off like him, but I still wanted to teach the agent to code like me.
I wanted to avoid the frustration of having to pinpoint every decision made by the agent and tell "ok, stop, this is how it should be done", especially because I knew some of this information was already publicly available! And that’s when it hit me.
What if I teach the agent from the recordings of the talks where I speak about how I write frontend code?
Take 1 – Can the agent learn from a video?
My first attempt was to get the video of my talk DDD on the frontend at DDD Europe 2024 and ask the agent: ok, can you learn from this video and update architecture.md with what you learned from it?
And this is what I got back:
⏺ I'm not able to watch or access YouTube videos — I can only work with text, code, and files. I don't have the ability to view, listen to, or extract content from video URLs.
If you'd like me to learn from the practices in that video, you could:
1. Share a transcript or summary of the key points
2. Describe the practices you found valuable
3. Paste relevant code examples from the videoWhen I first read that it can work with files, I considered downloading the video and feeding it to the agent, but the options the agent gave me seemed worth trying before that.
Take 2 – What else can I feed the agent with?
I tried to figure out how I could quickly get and provide the agent the information I wanted to be extracted from the video, so I gathered it from 3 sources:
- I asked Gemini to give me the most important takeaways and techniques from the video through the Gemini button
- I grabbed the link for the slides of that talk
- I grabbed the text that I sent during the CFP of DDD Europe 2024 about my talk
It didn’t seem like a lot, but it was quick enough to be worth trying.
To my surprise, it worked even better than I expected! The core parts of the concepts and practices I follow were there, the agent described them, tried (mostly successfully) to infer the reasoning and the implications of the decisions. Looks like it works!
Well… even though the reasoning of my practices was there, when the agent tried to generate code from it, it still used practices that I wouldn’t use, a lot of them even considered anti-patterns by the frontend community. Bummer.
My first thought was: "Well, where did it learn to code like that? Certainly not from me! Wait… NOT FROM ME!", and then it hit me again.
Take 3 – Show me the agent the code!
Conference talks are really good to learn new concepts and practices, but without seeing actual code, it’s hard to know how that really plays out in an actual codebase, and agents work way better when given examples!
Lucky for me, I gave a workshop at Explore DDD 2025 about DDD on the frontend, and a talk at JSConf Chile 2023 about frontend software architecture, and for both of them, I had a small repository of examples. I then promptly (pun not intended) grabbed the links for the code used in the workshop and the example repository for the talk and commanded the agent: mix the knowledge you got previously with the source code of these repositories and update architecture.md.
Ok, NOW it works!
Of course, it didn’t write exactly as I would, but I also wouldn’t expect that from anyone when working on a team, I didn’t want to have a double standard for agentic code. It worked as well as I would expect as the architect of a team.
Take 4 – Can we collaborate?
When it comes to software development, you’re always learning and refining your techniques, changing your opinions and practices as you learn how and where they work. From the time I presented these talks, I changed the way I’d solve some challenges, I learned the limitations of some of my approaches, and so on, but I never got to write that down. Could I discuss that with the agent and collaborate with it to update the practices documentation of the project?
To complete my journey, I told the agent: "ok, I want to mix some concepts of task based interfaces with what you’ve learned. I don’t want you to replace all of it, find the parts where the concepts blend well, and where they conflict, let’s discuss it".
I feel like it’s one of the most missed parts of agentic engineering, people lose the chance of discussing with the agent and take advantage of all the learning process the agent has been put through, get insights, feedback, criticism from a variety of backgrounds mixed together!
By the end of the discussion, I had files documenting the architecture I wanted to enforce in the frontend of my application, with practices I would like to enforce, even the ones that I hadn’t documented before, and now the whole process of agentic engineering became way less frustrating and reliable for me.
You might be asking: "Well, don’t the agent make mistakes once in a while?", and I answer: "Yes, very similarly to how a human would, and I solve both cases the same way: with communication and documentation".
What can we learn from that?
At this point, it’s clear that different people have different workflows when using coding agents. Some prefer to let the agent take more decisions and act more like a product person or architect with a higher level view of the application, others prefer to use it only in specific tasks, others prefer the middle-ground. The conclusion here is that it’s important to find what works for you. If we intend to enforce software design and architecture practices like we would do ourselves, there is a way to do that: use all the information and examples you can for that, instead of feeling frustrated, even if the information is not public, ask the agent to learn from other projects on your machine.
After all, it’s hardly a problem with the agents, but with the way we instruct them, teach them, and expect from them.
We want to work with you. Check out our Services page!
