ajrouvoet

Indeed. I’m personally doubling down on model-centric programming and keep tight control of the models, while being more permissive with the transformations between models.

It is nice that models remain stable, explains points of the architecture and an llm is good at following instructions that model changes needs a human in the loop. Languages with good static type systems cause friction in a transformation to show up in the types, which act as (weak) specifications.

It works to some extent

When the loop speeds up you need good judgement more often. It explains the divergence and it explains why I feel so tired at the end of a workday.

I’m increasingly curious if revisiting Brooks’ surgical team makes sense in this age. Knowledge transfer has always been a bottleneck, but in this time it is often just no longer worth it (compared to the old world where the costs were justified by increased manpower for execution of an idea).

I’ve recently given a talk on R&D in the time of AI and based it on Naur’s essay for exactly that reason.

While it is in some sense harder, there are also opportunities, because the reach of a person is bigger and one can refactor more frequently to align with the theory being developed without the cost that used to be associated with this. AI is also effective for producing materials to teach the theory, increasing the chance that others can contribute coherently to a product.

Right, I think Brooks means “the act of creation” here, rather than “the product of their creation”.

While that is a challenge, I think the author does a good job explaining that intuition is more than “good vibe”. It is a coherent understanding. And luckily, coherent understanding is by its nature also easier to transfer. For example, because someone with coherent understanding will teach the same ideas over and over. That is not to say that it will necessarily win over incoherent ideas, but it is recognisable.

I enjoyed the introduction. I just picked up “The mind of the Maker” by Sayers, which Fred Brooks cites in The Mythical Man Month: “ Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author.” He goes on to say how the user meets the mind of the maker in the interaction: “The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.”

For my work in innovation/R&D the leaps are relevant but more or less orthogonal to what I’m talking about above. I think there is a limit to the consistency and quality that one can expect of software whose surface area scales linearly with the feature set, if that makes sense.

It is tempting to extrapolate the fast progress and conclude that everything will be automated soon, but it still appears to me that LLMs have a “spikey profile”: while very good in some areas, they fail completely in many others, with no evidence that this is only a matter of time.

“I almost get physically ill when there is more code than I can keep in my head” resonates with me, but it is the exact reason that I enjoy working on better abstractions. Not in the “Javaesque” sense, as you call it, but in the mathematical sense.

I’m working intensively with LLMs to find out what they can and cannot do and for all the capabilities in there they remain terrible at compressing functionality into few concepts and as a result they produce incoherent (read Fred Brooks on coherent design!), failure-prone products. In other words: I expect that there will be good demand for people who refuse to let code grow beyond something they can keep in their head, even though the means by which one accomplishes this might be different than what you do now.

Hope that there is some solace in this.

Inexplicable has a range from “I can’t explain that” to “that is not in the realm of possibility”. Windows failures especially have been steadily moving from A (already pretty sad) to B in the past years and I’ve been thinking about how utterly unempowering that is. Tools stop being tools if they have a secret life of their own.

Excellent post!

It is baffling to me that Python seems to insist on reinventing language features and coming up with the most incomprehensible of designs. The whole dataclass and serialisation ecosystem comes to mind, as well as the evolution of typing.

The language exposes so much of its internals that even if the design were consistent, the ecosystem of (buggy) libs and tools makes it inconsistent.

Excellent and (it goes without saying) important work. My only suggestion is to edit a file by… playing Minecraft. Extra points if you make a meaningful edit in survival mode.

Yes: the human provides the qualitative judgement and the agent provides the executive function.

Do you mean that specifically those models perform badly without guidance or do all models need specific instructions for technical writing?

We have observed that it is a loss for teamwork that the sparring with AI is entirely lost when only the technical conclusion is recorded. I write to recover that for my team and an AI can use it to its advantage as a side effect.

It would be cool to have good tool support for this process, but I’d bet on support, not delegation in that case.

Although I’d like this to work, I have not seen evidence that AIs extract good reusable knowledge from sessions without strong guidance.

I do R&D work in comp sci and usually write software and reports or papers in parallel. I have been using Opus in a controlled human-in-the-loop fashion to (significantly) speed up the work. While I’m at times surprised how high-level input steers output the right way, no high level ideas emerge from the AIs output. Many attempts to abstract from the concrete are wrong.

As a consequence, most writing is poor on content and form. It writes about the wrong things and crosses abstraction levels all the time. It cannot keep implementation details and conceptual leaps apart.

I don’t know what this means for the aim of this project to maintain important info for agents. Perhaps there are enough low-hanging fruits. That said, I’m skeptical that the resulting wiki is good documentation for human contributors.