Wonderful article on how to build an (AI coding) Agent. It greatly increased my understanding of the subject. In short, it’s a CLI that pipes your requests to an LLM, but it’s also authorized to execute CLI commands on your machine and feed the output back into the context.

After reading that, I came across Simon Willison’s blog post showing the prompt of Google’s version of an AI CLI agent:

Notably, the Google coding agent defaults to using Google technologies. Compose Multiplatform might be a good tool, but I wouldn’t say it is the current market leader. This illustrates my main current concern with AI agents: they appear impartial and unbiased, while in fact, their prompts can have a significant but invisible impact—in this case, influencing what technologies are chosen by default for countless apps, subtly tilting the scales further in favor of those tools. (That said, they include Django as one of the defaults, so I’m happy 😊)

In this case, the bias is relatively benign, but it’s clear that these invisible influences can and will be exploited. See, for example, Grok ranting about conspiracy theories.

This isn’t a new problem—newspapers and even Google Search already have similar “invisible influence” issues. Just don’t believe AI agents will be free of them.

In the context of a Django application (but this probably applies to any web development) I’ve been trying devin.ai. It creates pull requests to your repositories from the request you express to it through the browser or Slack. It works well and the quality of the code produced is quite convincing, as I expressed in a previous post, but this process is still full of friction. I still have to:

• git checkout the branches it creates to test the result,
• set up a different environment on their infrastructure so their bot can test
• and push my modifications to Github so that it can see them.

This workflow seems to be the one adopted so far by Chatgpt Codex too, but I did not push that one very far yet.

After that, I tried claude.ai, and their workflow is different: you install their command line, and it will work as you would on you own machine, modifying the local files and running in your own environment. This removes all the frictions that I just described and feels even more efficient. Also, CLI tools are easy to integrate in any IDE, so if you prefer not to leave yours, it must be possible, but I didn’t test that yet.

I think this is the most destructive popup in Google Drive.

It has caused countless problems for us—people lose access to important files simply because someone tried to make a directory private and clicked the blue button. Why? Because it’s presented as the advised next step. It’s clearly the “call to action.”

I really struggle to see how “it will make permissions easier to manage”, as the popup claims.

I don’t think that I can change that behaviour through a feature toggle in Google Drive. I’m wondering if there exists a good solution to this, maybe in other products.

Worse still, the interface offers no clear preview of who will lose access—and no obvious way to undo the change if you make a mistake.

This isn’t something we can train our team out of. It’s a design problem.

Giving a try at one of these AI tools making pull requests to your repository based on chat commands, and I must say that the productivity of that workflow is super high.

And since I’m using that for a task that I do think can avoid hundreds of hours of admin work for health workers, it’s hard to argue against any of this.

It’s a bit mind boggling. Feeling like I’m at major speed increase in my career, a bit like when Firebug appeared.