How AI taught me to work with juniors

Like many others, I've been experimenting with LLMs for coding quite a bit recently. One thing that astonished me is what vibe-coding taught me about how I should work with junior engineers.

I started teaching developers very early in my career as a software engineer. But I also fast-forwarded to teaching advanced engineers instead of juniors, early. I now realize that when I was in touch with junior engineers, they must have been happy to have additional mentors besides me, because my management style with them was not very suitable.

Here is what I learned:

1. Be absolutely explicit about what is to be done. ¶

As a senior engineer (or a product manager), you might think that "adding that new button to the card destroyed the layout, the text is now wrapped - fix this" is a pretty clear instruction. That is, unless you have seen an LLM restyle the whole card and introduce new style concepts. But a junior could have done pretty much the same. You can help both the junior and the LLM with clarity about your expectations: "adding the new button destroyed the layout of the card, the text is now wrapped - fix it by adjusting the width of the text box to a fixed size and let the buttons be wrapped" is much clearer.

2. Organize frequent check-ins. ¶

Letting an LLM run wild on a non-trivial task is not a good idea. Too frequently I have seen LLMs get stuck in endless loops of "changing more code" and "desperately trying to make the test green." This is not only environmentally and token count-wise costly, but can also occur with any junior. In the latter case, it causes frustration (on the junior's side) and only a few learning effects.

Therefore I recommend the organization of frequent check-ins. For the junior you can easily do that with time boxes (try for an hour and then let's discuss the state and steps). For the LLM it's a little trickier, because those tend to not come back after a given time box. So, for more complex tasks I tend to go in smaller steps:

Make a plan first, no code changes yet. Organize your plan in smaller steps to be executed in sequence. Present your plan and let me give you feedback before starting the execution.

This lets the LLM carry the load of creating the plan. You can then adjust the plan first and ask for step-by-step execution with a checkpoint after each step. And by the way: This works with juniors too, and teaches them to work in a structured way at the same time.

3. Clarify guidelines and boundaries. ¶

When working among more senior engineers I accepted good engineering habits as a given. One example is to not adjust a test case to make it green again when you made it red by some production code change. But LLMs "fixed tests" that way frequently until I explicitly told them not to do it. And, of course, how could someone not familiar with automated testing know about this? It's the same with junior engineers: Clear rules and boundaries, for individual tasks and the overall project, help them to explore the right solutions. There are many more such things, like "do not introduce another framework for a single component" or "check how the rest of the code does something before introducing a totally new way."

Writing down these guidelines and boundaries is actually a good idea, so everyone has them present. We call this documentation.

4. Ask to use and produce documentation. ¶

And documentation should not only be used and created by senior staff. Instead, it makes a lot of sense to let juniors create the documentation. That overcomes the biases that seniors have in mind: information that we consider "for granted" might be new and important for juniors.

This is the same with LLMs. While those basically ate the whole internet, they also ate the bad-code parts and cannot distinguish which of the many notions of coding you want to apply. Therefore you will need to explain to them how you expect code to be written. If you are lucky, they also discover some parts in the course of analyzing your code. But all of that knowledge will vanish as soon as you start the next chat.

All of these explanations that occur along the way are lost with the next chat. But how can you remember what to add as documentation to conserve it for the next chat? What is important enough and will help future sessions to work smoother and produce better results from the start? Ask the LLM! At the end of a session I got used to asking something like this:

What did you learn about the project, its code base, the guidelines to follow, and the style of coding that can be useful for future sessions? Do not make anything up that sounds nice and shiny, but extract the discovered knowledge from the current chat and its context. Propose suggestions for incorporating this knowledge into as a unified diff.

A similar task should be part of your definition of done and should explicitly be adhered to by junior engineers.

5. Provide pointers where to look. ¶

As soon as my project grew larger than 5-10 files, the LLM could not keep it in its context. Therefore, it will always need to glance through the code base to find the right places to look into. Many models already act kind of smart there, using find, grep, and friends. Still, this is unnecessary overhead.

As a human senior, you a) know how code bases (especially your own) are structured. In addition, humans are very good at optimizing pattern recognition mechanisms and so you easily remember the important pieces of code and where to find them. So, providing this knowledge advantage is a great way to reduce friction during your vibe-coding session.

Juniors still need practice in finding the right patterns in a code base and often have little experience analyzing code bases at all. That can be the cause of much unnecessary frustration. So be kind to your junior and give them some hints on where to look - unless you want to explicitly make them hone their code analysis skills during a task.

What's the roundup? ¶

Reading through this you can easily feel reminded of "micro management", which is considered a bad management style by many. And I agree with this for senior staff - those require autonomy and leeway in decision making, so micro management is probably not a great fit. But it's different for juniors. Micro management is actually a very good style to teach a junior something new. And working with your code is something new for an LLM in every new chat.