Johnny Krogsgaard

So this is where I landed after spending far too much time on it today: Maybe we shouldn’t be trying to build the perfect AGENTS.md. Maybe we should be building repositories that need as little agent instruction as possible. And continuously deleting instructions as the agents get better.

I actually got to test that today too. I made v6 based on what the first tests taught me. Then pointed the agents at the repo again. One mature project’s entire v5 → v6 upgrade was: 2 files changed. +8 / −1 lines. That made me happier than a 2,000-line “upgrade” would have.

One other thing I wanted to solve was updates. These setups tend to grow forever. So the methodology itself is versioned. Projects record which version + exact commit they were reviewed against. Then a future version is an audit of what changed, not “copy the new template”.

Same thing with instructions. If I can turn an important paragraph in AGENTS.md into a test, type, schema, permission or CI check, I’d rather do that. Code can ignore prose. It can’t negotiate with a failing CI check.

My boring default is becoming: one good agent → make a small change → test it → inspect the evidence → repeat Then bring in specialists / parallel work / independent reviewers when there’s an actual reason. Not because the diagram looks cooler.

I’ve started thinking the same way about multi-agent setups. I like agents. I like sub-agents. I like the graph idea. But there’s a cost every time you split work: context gets lost coordination appears parallel writes collide someone has to integrate it all So “more agents” isn’t automatically more engineering.

So I changed it. The current version now asks the agent to do this BEFORE creating persistent AI stuff: “If this didn’t exist, would a capable agent materially perform worse in this repository?” If the answer is no, don’t create it. Pretty obvious in hindsight.

It deleted its own playbook. And the AI context doc. Its reasoning was basically: A capable coding agent wouldn’t actually perform worse without them. That was probably my favorite result today. And also meant my own bootstrap needed changing.

Another project had almost no proper AI setup. The agent added: AGENTS.md CLAUDE.md a playbook an “AI context” doc some provenance Looked sensible. But it felt like exactly the kind of AI-infrastructure-creep I was trying to avoid. So I asked it to review everything it had just created and justify each file.

One project already had a pretty elaborate AI setup. The agent basically said: “This is mostly good already.” It made a tiny set of changes and kept an existing adversarial review process that, in a previous run, had actually found 10 real billing bugs. Good. I don’t want a framework deleting something that has evidence behind it.

I tried it on three real projects today. They’re quite different, and I deliberately used different agents. The funny thing is that the best signal wasn’t what they created. It was that they DIDN’T end up creating the same stuff.

The repo isn’t a template. That was important to me. I don’t want every project to suddenly have 12 markdown files, 7 specialist agents and an “AI_CONTEXT.md”. The agent should first look at the actual project and figure out what would genuinely make it better. And leave the rest alone.

I (+ai ofc) made a repo with my current thinking on how I want coding agents to work: github.com/jkrogsgaard/AI-En… And then tested something slightly stupid: I gave different coding agents the repo and basically just said: “Use this to upgrade this project.” Nothing else.

Jeg har arbejdet med tillid mellem boligejere og håndværkere i lidt over tyve år hos 3byggetilbud.dk. Og jo længere tid der går, jo mindre tror jeg på “anmeldelser”. Det er lidt bøvlet at indrømme, når man har brugt en stor del af sit arbejdsliv på en markedsplads, hvor stjerner fylder meget. Men sådan er det. Da vi startede, tænkte jeg som de fleste: Flere stjerner giver mere tryghed. Mere tryghed giver flere ordrer. Så regulerer markedet sig selv. Det viste sig at være for enkelt. Vi har efterhånden sendt mere end 800.000 opgaver ud, hver til 3 håndværkere. Det er over to millioner møder mellem et løfte og en kunde. Når man spørger folk på forhånd, hvad der bliver afgørende, svarer mange prisen. Men når boligejerne bagefter fortæller os, hvad der faktisk gjorde udslaget, er historien ofte en anden. Det handler om ting som: Stillede de skoene pænt udenfor? Svarede de ordentligt, når man skrev til dem? Havde de lavet en opgave som min før? Ryddede de op efter sig hver dag, ikke kun den sidste? Og var den nyeste lærling lige så ordentlig som mester? Pris betyder selvfølgelig noget. Det gør anmeldelser også. Men ingen af delene kan stå alene. En anmeldelse fortæller, hvad der skete sidste gang. En pris fortæller, hvad opgaven forventes at koste. Adfærd giver ofte et bedre billede af, hvad der kommer til at ske næste gang. Vores data peger samme vej. Vi kan blandt andet se, at håndværkere, der svarer inden for 4 timer efter at have modtaget en opgave, har markant større sandsynlighed for at vinde den. Ikke nødvendigvis fordi de er billigere eller bedre på papiret, men fordi et hurtigt svar i sig selv skaber tillid. Man mærker, at der sidder et menneske i den anden ende, som har set opgaven og tager den alvorligt. En håndværker, der siger: “Det kan jeg først nå om cirka en måned, når vi er færdige hos familien Hansen” har vist mig mere end ti femstjernede anmeldelser kan. Han lover ikke noget urealistisk. Han har styr på sin kalender. Og han respekterer den kunde, han allerede arbejder for. Det er dér, tilliden begynder. Og det er egentlig også det, vi hele tiden forsøger at putte på dåse hos 3byggetilbud.dk: At finde de håndværkere, man kan regne med, som har den rigtige erfaring og faktisk har plads i kalenderen til en god opgave. Ikke bare dem med flest stjerner eller den laveste pris, men dem, hvor adfærd, erfaring og timing peger i samme retning. Derfor er anmeldelser i dag kun ét af mere end 40 målepunkter i vores matching, når vi finder de 3 håndværkere, der passer bedst til en opgave. Ikke fordi stjernerne er ligegyldige, men fordi tillid ikke kun er noget, man kan læse sig til på en profil. Det er noget, man oplever i den måde, mennesker opfører sig på. Vi har som branche, mig selv inklusiv, i mange år solgt tillid som noget, man kan vise frem. Men tillid er i sidste ende noget, andre skal kunne regne med. Hvis jeg skulle koge 20+ år ned til én sætning, ville det være: Byg systemer, der belønner mennesker for at være til at stole på, ikke for at se ud, som om de er..

This is in my opinion a peek 👀 into the future..