Published on 2026-02-20
]]>Published on 2026-02-20
Tags: article, code-review, llm, ocaml, software-eng, software-eng-auto
Today's changes build on the previous commit's unpacking of Todo, making a repository for Todos, and hooking it up to the command line to provide bs add todo ....
The implementation plan forgot to add a task for integration tests, which resulted in a bin principle saying changes to bin, where we're only keeping command-line parsing and top-level orchestration, should always be accompanied by an integration test. I also had the agent put together an architecture document guiding the structure of integration tests and their purpose.
In the hopes of keeping file sizes down, I added a line length principle to bin and lib. I'm not sure about these principles, because I think this can be automated as a lint. I will keep these in mind and improve the linting situation when I get another structural/syntactic principle that can be automated.
Published on 2026-02-19
]]>Published on 2026-02-19
Tags: article, code-review, llm, ocaml, software-eng, software-eng-auto
Today's change to Knowledge Bases is addressing my unhappiness at the beginning of the month: "Data modeling". I've returned to the work of unpacking Note into Todo, to make it easier to control the TypeID prefix, and prepare for making a Todo repository.
A handy thing about coding agents: they can make such a wide-ranging change with minimal effort (see the number of changed files in the commit). Additionally, the coding principles guidance doc paid for itself — agent code review noted the duplicated validation logic for title and content now in both Note and Todo and recommended deduplication. I redirected it to encapsulate the validation into new types, a favorite software engineering technique of mine (see "Aside: Correct Construction"), as well as adjusted the guidance.
Published on 2026-02-15
]]>Published on 2026-02-15
Tags: code-review, commentary, llm, software-eng, software-eng-auto
OpenAI has put out yet another software engineering report on coding agent use, closer to StrongDM's Software Factory than to Gas Town.
Ryan Lopopolo for OpenAI on 2026-02-11:
Over the past five months, our team has been running an experiment: building and shipping an internal beta of a software product with 0 lines of manually-written code.
The product has internal daily users and external alpha testers. It ships, deploys, breaks, and gets fixed. What’s different is that every line of code—application logic, tests, CI configuration, documentation, observability, and internal tooling—has been written by Codex.
Humans steer. Agents execute.
OpenAI provides a number of interesting details here that, I think, complement the practices described by StrongDM. They started by reviewing Codex's commits, and that review load shrank drastically over time as every correction was worked into a set of guiding documents that agents would automatically pick up. It sounds like they did human-to-human reviews of feature and guidance documents. The picture they paint makes a lot of sense — encoding practical software engineering standards into tooling and guidelines documents, and then routinely "garbage collecting" using agents prompted specifically to review and clean up. An interesting thing to me is that they found "rolling forward" via speedy coding agent code generation to be faster and less disruptive to the process than rolling back bugs.
]]>Published on 2026-02-12
]]>Published on 2026-02-12
Tags: code-review, commentary, llm, software-eng, software-eng-auto
Complementing Gas Town, a team of engineers at StrongDM have coined the term "Software Factories" (via) for a different kind of coding agent software engineering methodology. They get straight to the heart of things:
Code must not be written by humans
Code must not be reviewed by humans
Coding agents write code faster than a human can read and understand it. This has the potential to be very valuable — quickly producing working programs on its own, but also the amount of work a single engineer can ship. To sustain that speed, the code cannot be reviewed. I think most people who've worked with coding agents have seen that they can tap into the speed, but then you end up forced to slow down and stretch your code review skills. What would need to change to make full use of the speed?
]]>Published on 2025-11-18
]]>Published on 2025-11-18
Tags: code-review, commentary, llm, software-eng
A “probably not new to me but I’ve been thinking about it” hot take:
AI-first development processes are significantly different than traditional ones in a similar way to how subtractive manufacturing is different than additive manufacturing
Some of what this means is based on what these forms of manufacturing mean to you.
What I mean is something akin to “traditionally you build up what you want from nothing” and with AI is something closer to “throw some clay on a wheel and start shaping”
This resonates. As some folks have discussed, coding agents require that the engineer in charge have stronger code review skills than code authoring skills, as well as mid-level code architecture skill (where should the abstraction boundaries be, where should logic live?). I'm also getting the impression that the software process itself will become part of what is engineered, because coding agents are low-skill and semi-autonomous — how to break work down into reviewable pieces, how to mitigate lack of testing or other code quality issues, how to coordinate work between agents, etc.
]]>Published on 2025-08-20
]]>Published on 2025-08-20
Tags: code-review, commentary, git, software-eng
I saw an interesting concurrence between a couple blog posts that came across my feed:
In both there's a desire to capture the conversations that produced code, alongside the code. For the Tigerbeetle dev, the desire is to reuse git and your usual text editor when doing code reviews, so that the code review comments, answers, and adjustments live in git as part of the history. For the Zed team, they think git is insufficient for capturing the conversations they're having, which I presume would include code review, such that they're going to build a new version control system. I wonder if the Zed team and the Tigerbeetle dev are feeling the same pain around trying to orchestrate communication within git's commit system.
]]>Published on 2025-07-01
]]>Published on 2025-07-01
Tags: article, code-review, communication, software-eng
At my day job I review a lot of other people's work, in the form of code reviews or design (and other) documents. A few years back a coworker whose code I was reviewing requested, rather insistently, that I start using conventional comments when doing code reviews. They also messaged it out to the team, though more as a practice suggestion and not a proposed change to the team's process.
I internally shrugged the request off, as they were a junior engineer still working through their personal relationship to feedback — as we all do. I don't think many people are raised with the education necessary for internally de-personalizing feedback, analyzing your own behavior, synthesizing the given feedback with your own understanding of "the world", and thanking the other person for their gift, regardless of your orientation towards that "gift". It's complicated stuff and most of us, myself included, take years to adjust our reactions accordingly.
]]>