I'm not the expert, and that's the point

In the last months some people asked me for advice regarding AI and agentic coding. They wanted to know things like: how to use these agents, my experiences, best practices, which model to use etc.

That actually increased in the last weeks, so I asked them if it would be helpful to have a summary of things going on in that field on a regular basis. They agreed. This blog is the public part of that.

So before anything else, let me say what you are actually getting here… because I think the framing matters more than the content that follows it.

TL;DR

• I am not the expert on this, and I don’t think anybody is yet
• “Then just write it by hand” is fair today and still misses where this goes → if the results are bad it’s most likely misusage
• What I’m really bad at: slowing down, recapping, evaluating
• Not every generated line needs to be a pull request
• Expect field reports with a date on them, not tutorials

Far away from being the expert

Let me get that out of the way first.

I am far away from being the expert on agentic coding, or having a perfect workflow, or getting mergeable code one-shotted. Or maybe even reaching the point where I get code out of the models which is on the same quality as I would get if I did it by hand all the time.

That’s not me being humble as a rhetoric move. This whole thing is maybe two years old in the current form and it changes monthly. Everybody presenting a finished methodology is really just presenting a snapshot.

“Then just write it by hand”

Maybe you think exactly that… and yes, maybe it would actually be faster and maybe the results would be even better. I really get that and see the point at the current state today.

But I think we need to get over it: these frontier models can write fully functional code on nearly the same level most of us can deliver. If the results are bad, it’s most likely a misusage, wrong/missing/polluted context or anything else.

That’s basically the reason I write any of this down. It moves the question from “can it do this?” to “what did I actually give it?” → and the second one you can do something about. When a model produces garbage out of a codebase where the truth is not findable, or out of a session that already rotted, that’s not the limit of the model, that’s what you gave it.

And that’s also happening to me… regularly. The reframe doesn’t make me better at this, it just points me at the part I can fix.

What I’m really bad at

I want to see what’s working, what’s not working, which model is good at which things or not… and to be honest… I am not good at evaluation at the moment. I am bad at slowing down, recapping and adapting, maybe because of my ADHD, but that is something I need to get better at.

I think this is the underrated skill in the whole field. Not prompting, not picking tools. Evaluation. Actually noticing which of the twelve things you changed last week made anything better, instead of collecting habits that felt good in the moment. Most of us (definitely me) are running on vibes and call it experience.

Writing this on a schedule is my fix for that. It forces the recap I normally skip, and it puts a date on everything so I can be visibly wrong later. That’s a feature, not a bug. A workflow I described in March that I silently dropped by July is more useful to you than a polished guide pretending it never happened.

Not everything has to be a pull request

To be clear, I don’t say each generated LOC needs to be for a pull request trying to get merged into production. If you don’t feel comfortable using it for production work, use it for prototypes, use it for getting ideas, use it for battle testing your solutions or stuff like that.

And that’s not the consolation prize, that’s how you build the feeling for when it is ready for the production work. You can’t get that from reading about it, only from watching these tools succeed and fail on problems you understand well enough to grade yourself.

We are all over the place

Look around any engineering team right now and the spread is huge. Some of us are creating a hell lot of tokens, some of us nearly nothing. Same tools, same access, completely different usage.

I don’t think that’s a discipline problem, and treating it like one is how you get a mandate nobody follows. It’s an information problem. The people on the low end mostly never saw what the setup looks like when it works, and the people on the high end nearly never write down what they changed.

We can and we should learn from each other here, and also make the environment better for ourselves and also for our agents, because it turns out that’s the same work.

The thing that really pushed me

What really impressed me lately was not an engineering team at all. It was seeing people with no engineering background (marketing people) writing their own skills and plugins, experimenting with it, using MCPs in different tools, automating stuff. It’s really crazy, and it moved faster than most engineering adoption I’ve seen.

Think about that for a second, because I find it the most interesting data point in this whole discussion: the group with the least attachment to writing code by hand moved the fastest. That’s not a coincidence, and it’s uncomfortable if your professional identity sits on the craft → which is a post of its own.

It really inspired me to also go more in that direction, be even more engaged, share more. This is part of that.

What to expect here

Field reports, not tutorials. Things I tried, with a date on them, in the state I really found them, including the parts that didn’t work.

And the obvious one, which I mean seriously: don’t copy any of it blindly. Take the observation, leave the config → there is a whole post about that.

Actually I don’t really know where to start with all of this. I have so much to share but don’t want to overload you, so I just start where we are now and go one topic at a time :D