Clojurians Log v2

bare vanlig jobb herfra, dessverre!

Samme her, skulle gjerne ha vært der!

Beklageligvis, virker som det er mye spennende der.

Dessverre ingen Bergenstur denne gangen. Booster er en veldig fin konferanse.

Vi bruker

Funksjonsområde/navnerom: hva commit'en gjør (imperativt)

Hvorfor gjorde vi endringen

Metadata (jira-nummer, co-author, etc)

Jeg bruker subjekt først og verb i passiv form, og med saksnummer først:

#883 Deleted fields and options are shown in red rather than bold

Interessant!

Jeg har lite til overs for issue-nummere, men tror jeg liker "subjekt først" 😄

også veldig kul vinkel med "les denne commit-loggen og se om du skjønner hva som skjer". Eksempelet fra artikkelen var veldig godt.

Enig, dette er kult!

Saksnummeret fortjener plassen hos meg av to grunner: 1. Visuell gruppering 2. Github viser commits for en sak i historien Men ikke så viktig egentlig. Artig at dere tar denne brannfakkelen (subjekt først) på strak arm! 😅 Selv hadde jeg en nesten fysisk (negativ) reaksjon da jeg først så det. Men argumenter veier tyngre enn følelser.

> Artig at dere tar denne brannfakkelen (subjekt først) på strak arm! Du snakker om hvordan man fremmer intensjon i teamet gjennom kommunikasjon! Det er det mest spennende, underdiskuterte temaet jeg kjenner til om koding.

Og med ekte eksempler (saknumrene dine og subjekt-først-meldingene) blir poenget belyst svært tydelig.

> Github viser commits for en sak i historien Det gjør den kanskje også hvis saksnummeret kommer nede i beskrivelsen til commit-meldingen?

Ja, det har du rett i. Så det er vel egentlig bare den visuelle grupperingen som er argument for å starte med saksnummeret.

Det jeg synes er vanskeligst med commit-meldingene er å gi kontekst. Det jeg kaller "Funksjonsområde" / "Navnerom". Vi har såpass mye funksjonalitet at hvis man bare skriver hva commit'en gjør, så blir det lett tvetydig.

Men så er det også vanskelig å lage og bli enig om gode og korte nok navn på funksjonsområdene

(jeg gjør mitt ytterste for å holder subject-line innenfor 72-characters-grensen for å forhindre trunkering i ymse utlistinger)

Det har jeg helt sluttet å forholde meg til med subjekt-først (men ofte er meldingene ganske korte). Nettopp fordi det viktigste står først i meldingen, og innen tegn 72 har jeg forstått hva dette handler om.

Det er en kjempefin egenskap ved subjekt-først ja!

Artikkelen som ble lenket til, https://github.com/aaronjensen/software-development/blob/master/continuity.md var også veldig fin! > If you've ever experienced the greenfield scenario I've described, you've likely also experienced a transition towards (but perhaps not all the way to, depending on how long you worked on the project) the second scenario I've described. You've seen tests take longer and longer until you've needed to parallelize your build across multiple CI agents. You've seen the impact of adding more developers to the team decrease over time. You may have even seen your team's ability to add new functionality, especially complex functionality, decrease precipitously. > > If only the description of greenfield projects resonates with you, then I would posit that one of two things is true: 1) You've never been on a project for more than a year or two, or, 2) You're on a very special project that has managed to stem the tide of what most think is inevitable in software projects.

I mina egna projekt (inklusive Calva) bara skriver jag nåt, vad som helst. Jag gör oftast väldigt många commits och orkar inte hålla på att författa. Jag författar i PR:n, och inte speciellt mycket där heller. Jag läser typ aldrig commits, så mitt incitament att lägga tid på den texten är mycket lågt.

Jeg gjør noe sånt 👆 jeg også når jeg jobber med PR-er.

Ja, det spelar roll vad det är för sorts projekt. Mina egna projekt är typ alltid open source så PR. I andras projekt försöker jag göra som de gör.

Jeg drømmer om en verden hvor alle skriver gode og gjennomtenkte commit-meldinger 😄 jeg hater commits som åpenbart er skutt fra hofta med like dårlig melding som innhold (som gjerne ikke engang kompilerer - bruk rebase for pokker!). Anyways, den største verdien med en god commit-melding hvor det også står noe om intensjonen bak endringen, er i feilsøkingsscenarier.

Jag felsöker helt sjukt mycket och ofta. Har aldrig haft nytta av commit-meddelanden då. Fast mina meddelanden är ju slarv så kanske därför.

På egne prosjekter er jeg også ganske løssluppen på meldingene:

@pez det er nok derfor ja 😅

När jag committat i Replicant så har jag gått in i OCD-mode. 😃

Her er noen eksempler på commits produsert av AI agenter med https://github.com/leifericf/agentic-software-delivery-toolkit

Hver commit har en liten paragraph som utfyller litt mer info

Det som er ganske kult er at AI agenten kan bruke commit historikken aktivt også

Dette er mitt testprosjekt for 100% AI-drevet koding hvor alt er automatisert 😅

Så jeg har masse regler og Git hooks for å "tvinge" AI-en til å gjøre ting på en viss måte

Den commit-lista illustrerer poenget med subjekt-først godt: veldig vanskelig å rask finne noe der for det menneskelige øye. Men en KI klarer seg fint, helt sikkert.

Jepp! Den ser ganske shit ut for mennesker, men LLMs liker den 😅

Det er en fyr over i #ai-assisted-coding som holder på med noe symbolske greier for KI, nesten mystiske greier:

λ engage(nucleus).
[phi fractal euler tao pi mu ∃ ∀] | [Δ λ Ω ∞/0 | ε/φ Σ/μ c/h] | OODA
Human ⊗ AI ⊗ REPL

jeg ser på dette litt som binærenkoding. Tekst er lett å lese for mennesker, men unødvendig indireksjon når en CPU bare har lyst til å allokere 2 gig med flyttall.

Ja, mye rart som skjer for tiden

Jeg er på stadiet hvor jeg fortsatt er svært skeptisk men gjør masse eksperimenter og undersøker mulighetsrommet, hva som funker og hva som ikke funker

I den takt AI utvecklas kommer de förstå mina commit-meddelanden om ca 5 år. Då kan ni sitta där med era putsade loggar.

Haha! 😀 Jeg har laget en /commit-msg skill for Claude Code:

---
name: commit-msg
description: Generates a Git commit message for code that has changed. Use when asked to commit or write a commit message.
---

**Core principle:** Write commit messages in **indicative mood, passive voice**,
placing the *subject* (what changed) first — not the action or the author.

### Format

- ✅ `Widget reconciliation is corrected`
- ✅ `Default batch size is sourced from reader class`
- ❌ `Fix widget reconciliation`
- ❌ `Added default batch size from reader class`

This style optimizes for **scannability**. When humans read a list of commits,
they scan — not read. Putting the subject first means the most meaningful word
appears where the eye lands first. Imperative-style messages ("Fix", "Add", "
Update") frontload a generic verb, forcing the reader to parse further to
understand what actually changed.

### Specific conventions

- **New additions:** Omit the verb entirely. Prefer `Widget tests` over
  `Widget tests are added`.
- **Bug fixes:** Use `is corrected`, not `is fixed`. E.g.,
  `Unbalanced parenthesis in log output is corrected`.
- **Refactors/improvements:** Use `is clarified`. E.g.,
  `Store's project method is clarified`.
- **Renames:** Use `rather than`. E.g., `Widget, rather than Sprocket`.
- **Version bumps:** State both old and new versions explicitly. E.g.,
  `Package version is increased from 1.1.1 to 1.2.0`.
- **Formatting:**
    - Don't artificially constrain subject to 50 characters — be as descriptive
      as needed for clarity, but stay concise.
    - Add an extra newline before the body.
    - Keep lines in the body shorter than 80 characters.
    - Use bullet points in the body when there are multiple changes.

Den kan muligens gjøres mer konsis, men jeg får gode resultater med dette.

https://github.com/leifericf/agentic-software-delivery-toolkit/blob/main/.agentic/shared/skills/git/git_commit.md i mitt «toolkit» som AI agentene bruker.

Men det der «toolkit» var å gå litt alt for langt med generalisering og sånt. Jeg har tenkt å lage en dramatisk simplifisert versjon spesifikt for OpenCode, som er min prefererte editor/plattform for øyeblikket.

kombinér det med deploy-flyt uten PR-er, så har du oppskriften for å putte skrivefeiler i commit-meldinger 😭

"Referer"-headeren er et godt eksempel på dette 😊

I tillegg til å overvurdere hvor mye LLM-ene er bra til tror jeg folk grovt undervurderer hvor mye av en distraksjon det er. AI er i ferd med å gjøre med fokus på arbeidsplassen det smarttelefonen og sosiale medier gjorde med fokus og konsentrasjonsevne på fritida.

Og for å ha det på det rene: ja, jeg undervurderer helt sikkert hva det er bra til, ved å basically ignorere hele greia. Jeg tror allikevel jeg kommer greit ut av det ved å ikke spora av på all den utforskningen og konstante "hva om"-jaget. Vi får se hva ettertiden har å si. Her blir jeg dinosaur 😊

Haha! Ja, jeg har valgt å følge med for å holde meg orientert, og har de siste ukene eksperimentert med agenter for å se hva greia er. Har i hovedsak testet med konkrete og godt definerte ting. Og det funker helt fint. Men jeg fikk en stor overraskelse i en feilsøkingssituasjon da jeg brukte git blame for å finne ut hvorfor en av kollegaene mine hadde skrevet et stykke kode, bare for å finne ut at det var meg selv to uker tidlere! (altså, koden agenten hadde skrevet). Jeg tror dette berører noe viktig: at vi tilbringer mindre tid sammen med informasjonen når vi ikke skriver den, og da vil den i mindre grad feste seg i hodet. Litt det samme som håndskrift vs ipad i skolen.

Og dette er til og med før en snakker om det etiske rundt hvordan teknologien er skapt, hvem som tjener på den, hvor store ressurser den legger beslag på, og hva den brukes til ellers.

@teodorlu: man burde også spørre seg om problemene man bidrar til: økt energiforbruk, avhengighet til et lite sett med aktører, og konsentrering av makt hos disse aktørene.

Tror det er lett å bli blendet av hva LLMene får til, slik at man glemmer litt av hva du sier her. Også er det vel en stor grad av FOMO over hele fjøla 😄