Since we are talking about political leadership at the highest levels (not pastoral local municipalities), a good comparison with priesthood would be the Vatican. Even in priesthood, when there is concentrated power over vulnerable populations, we can find: wealth hoarding, money laundering, collaboration with organized crime, and protection of rampant sexual abuse. For hundreds of years. This suggests to me that the issue is hierarchy more than it is quality of those who reign over us.
People think that quality governance is all about the intelligence to know the best rules to decide for the greater benefit of society. Politicians behave badly because of incentive. Good rules would require correct incentive, not merely higher quality individuals. Intelligence doesn't dissuade corruption of power, if anything it accelerates it.
Well you can’t edit files while Xcode is building or the compiler will throw up, so I‘m wondering what you mean here. You can’t even run swift test in 2 agents at the same time, because swift serializes access for some reason.
Whenever I have more than 1 agent run Swift tests in a loop to fix things, and another one to build something, the latter will disturb the former and I need to cancel.
And then there’s a lot of work that can’t be parallelized, like complex git rebases - well you can do other things in a worktree, but good luck merging that after you‘ve changed everything in the repo. Codex is really really bad at git.
Yes these are horrible pain points. I can only hope Apple improves this stuff if it's true that they're adding MCP support throughout the OS which should require better multi-agent handling
You can use worktrees to have multiple copies building or testing at once
I'm a solo dev so I rarely use some git features like rebase. I work out of trunk only without branches (if I need a branch, I use a feature flag). So I can't help with that
What I did is build an Xcode MCP server that controls Xcode via AppleScript and the simulator via accessibility & idb. For running, it gives locks to the agent that the agent releases once it's done via another command (or by pattern matching on logs output or scripting via JS criteria for ending the lock "atomically" without requiring a follow-up command, for more typical use). For testing, it serializes the requests into a queue and blocks the MCP response.
This works well for me because I care more about autonomous parallelization than I do eliminating waiting states, as long as I myself am not ever waiting. (This is all very interesting to me as a former DevOps/Continuous Deployment specialist - dramatically different practices around optimizing delivery these days...)
Once I get this tool working better I will productize it. It runs fully inside the macOS sandbox so I will deploy it to the Mac App Store and have an iOS companion for monitoring & managing it that syncs via iCloud and TailScale (no server on my end, more privacy friendly). If this sounds useful to you please let me know!
In addition to this, I also just work on ~3 projects at the same time and rotate through them by having about 20 iTerm2 tabs open where I use the titles of each tab (cmd-i to update) as the task title for my sake.
I've also started building more with SwiftWASM (with SQLite WASM, and I am working on porting SQLiteData to WASM too so I can have a unified data layer that has iCloud sync on Apple platforms) and web deployment for some of my apps features so that I can iterate more quickly and reuse the work in the apps.
Yes, that makes sense to me. I cannot really put builds in a queue because I have very fine-grained updates that I tell my agents so they do need the direct feedback to check what they have just done actually works, or they will interfere with each other’s work.
I do strive to use Mac OS targets because those are easier to deal with than a simulator, especially when you use Bluetooth stuff and you get direct access to log files and SQLite files.
Solo devs have it way easier in this new world because there’s no strict rules to follow. Whatever goes, goes, I guess.
I found Codex got much better (and with some AGENTS.md context about it) at ignoring unrelated changes from other agents in the same repo. But making worktrees easier to spin up and integrate back in might be a better approach for you.
When the build fails (rather than functional failure), most of the time I like to give the failure to a brand new agent to fix rather than waste context on the original agent resolving it, now that they're good at picking up on those changes. Wastes less precious context on the main task, and makes it easier to not worry about which agent addresses which build failures.
And then for individual agents checking their own work, I rely on them inspecting test or simulator/app results. This works best if agents don't break tests outside the area they're working in. I try to avoid having parallel agents working on similar things in the same tree.
I agree on the Mac target ease. Especially also if you have web views.
Orgs need to adapt to this new world too. The old way of forcing devs generally to work on only one task at a time to completion doesn't make as much sense anymore even from the perspective of the strictest of lean principles. That'll be my challenge to figure out and help educate that transformation if I want to productize this.
If you cut text in a "separate window" note, it will delete the text, but it won't actually copy it unless you issued the command for a note in the main window. So when you go to paste it elsewhere, you find it's gone, and then you often find Notes has lost the undo history too.
I’m adding a one-act Tanizaki play to Standard Ebooks’ Tanizaki collection[1] on the 1st January. Some Akutagawa shorts go into US public domain next year too. (Note: copyright is based on the translation date, not the original language.)
> Note: copyright is based on the translation date, not the original language.
It’s based on both. For example, a translation or other derivative work whose copyright expired “early” in the US due to non‐renewal would still be encumbered by the copyright of the original. That’s basically what happened to It’s a Wonderful Life—the film is technically in the public domain, but is still held in Paramount’s iron grip by way of the renewed copyright of the original short story.
The "TPP11," which includes a provision to extend the term of protection to 70 years, will enter into force on December 30, 2018.
In Japan, the term of copyright protection will, in principle, be 70 years after the death of the author (or 70 years after publication for works published anonymously, under a pseudonym, or in the name of a corporate body).
Copyrights that have already expired at the time of enforcement will not be revived (principle of non-retroactivity of protection).
Consequently, no works will newly enter the public domain for the next 20 years.
Worth noting that Canada is in the same boat since 2022. Australia has only recently seen authors enter the public domain again, since the change there was made in 2004.
Note that the copyright is not about the source country of the work, but where do make/distribute the copy. Do you live in Japan, or are you interested in Japanese works? (Or both, possibly.)
That's NEAT! I live in Japan myself, and I am a passionate Japanese learner (and used to be a teacher too) of multiple decades. Besides, I'm interested in natural language processing and language related technology, and used to study second language acquisition research back in the university. If you ever take part into any tech / language events or meetups, it would be nice to hang out and hear about the development of that app.
reply