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

> Why I write about agentic coding without claiming to have it figured out: what I'm bad at (slowing down, evaluating, finishing), why I'd rather be wrong in public than fluent in a workflow that's already obsolete, and what you should expect from anything here.

- Author: Jonas Rohde (@edhor)
- Published: 2026-07-25
- Canonical: https://edhor.me/blog/learning-in-public/
- Tags: agentic-coding, learning-in-public, adhd, developer-culture

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](/blog/good-for-new-joiners-good-for-agents/), or out of a session
[that already rotted](/blog/be-aware-of-the-context-window/), 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](/blog/good-for-new-joiners-good-for-agents/).

## 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](/blog/the-adoption-experts-who-wont-adopt/).

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](/blog/steal-the-idea-not-the-config/).

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