I've been having issues lately with my machine running out of RAM because of too many agents doing too many things at once. I know I know I need to get on the cloud-agent bandwagon, I'm working on it, but in the meantime I have become very productive with a dozen or so claude sessions running locally all the time. Anyway all that to say, I have started to pay a lot more attention to what is using up all my RAM because I ran out for the first time the other day. The desktop slack app is a pretty bad offender, regularly consuming 1-2GB of RAM, so I went looking for lighter-weight alternatives (since I need to have it running for work, and hate the experience of using it in a browser) and found this awesome slack TUI.

It's really amazing and was immediately more ergonomic to my sensibilities, but there were many rough edges. I don't believe in putting up with paper cuts any more. In this day and age coding agents can fix all of this stuff more or less autonomously, so yesterday I decided to just do it. Slack is the software I use second-most at work, after Claude Code, so running into minor friction with it a hundred times a day was getting pretty frustrating, but I really like the lighter-weight experience of using slack from a terminal.

This raises a lot of meta questions for me about being a good open source citizen, but in this case I actually just needed to get some work done and the bugs in the app were getting in the way of that, so I decided to fork the repo and just fix them all. Over the course of the day I thought I was done three times (see the other two releases, v0.27.0 and v0.28.0), but every time I thought I had fixed the bugs, I realized I was running into more.

For better but mostly for worse, I do not suffer from bug blindness, so it took a few rounds until I stopped running into paper cuts in the course of my normal slack usage. Anyway.. I think there's another post worth writing about the kinds of things I wanted to fix that made this worth forking rather than collaborating (there were some pretty fundamental things around the modelling of time and event architecture, among other things), but I guess that is the point of open source, after all, right? I tried opening an issue for the first bug I ran into last week and haven't heard back, and now after just a few hours of vibing, I have a really awesome app that works really well. So anyway, it's open source and available to everyone. If you find issues of your own feel free to contribute, or fork it and run with it on your own! Here are some details about what's in each released version:

v0.27.0

The first release mostly includes some minor fixes and changes the infrastructure to release the fork independently. Releases, the Homebrew cask, and the update check all point at kirahowe/slk now, so it's installable with

brew install --cask kirahowe/tap/slk

The app now shows an upgrade hint in the status bar when a newer version is available. I also added a slk open <permalink> helper that gives a slack message link to the slk that's already running, so scripts or other programs can try opening slack links in slk before falling back to the browser. The rest of the changes are mostly a pile of small usability fixes that remove some of the friction I was experiencing:

• Line breaks and repeated spaces are preserved in sent message
• :q on the last window quits, like in vim
• Ctrl+X opens the draft in $EDITOR instead of Ctrl+E, which now moves the cursor to the end of the line. Ctrl+A moves to the start of the line
• Sidebar auto-collapses on narrow terminals
• Threads open beside the channel at 120 columns instead of 162

v0.28.0

The main change in this version is highlighting mentions. Messages that contain your handle get a yellow bar in the gutter, a faint tint on the row, and a pill behind your handle. @here and @channel only get the bar. There are tons of small fixes in this release as well, mostly caught by property tests I added, mostly around fixing markdown rendering and obscure timezone edge cases. The changelog has the full list, but these are exactly the kinds of things that fuzzing and property testing are great at catching.

v0.29.0

This included a substantial refactor of the event handling and time modelling in the app, basically implementing optimistic updates. There were lots of bugs caused by mutable state getting mangled as it always does:

• For a few seconds after every send, slk hid every message of yours arriving in the channel
• A request to Slack could hang forever and would keep your new messages in that conversation from ever appearing
• Pressing e or D right after Enter could act on the message before the one you just sent
• Edited messages didn't refresh until a reload
• A late message could move Slack's read position backward and mark newer messages unread again
• A failed send, reply, or edit could lose your text
• If a message came in when you scrolled up to read something you'd get yanked down to it, now "-- more below --" appears and the view stays where you were.

All of these are fixed. I also removed every test that waited on a wall clock -- sleeps, timeouts, polling never belong in tests, in my opinion, and make test suites unnecessarily slow. Timers now run on fake clocks or fire at once, and tests wait on real signals instead. I fixed the flaky tests by making them structurally impossible. This cut the test time by more than half and reduced flakiness to zero including on a heavily constrained machine.

I’m looking forward to reading this series by Tim Pratley. He’s an author and engineer I have a lot of respect for and I’ve grappled with a lot of similar thoughts he raises here. I always appreciate data-driven arguments and an approach to topics like this based on convincing your audience with evidence.

When everyone has a chance to participate in the economy we get more ideas, more productivity, and more opportunity. Extreme wealth concentration blocks innovation and limits broad prosperity.

This only makes sense to me. I think disagreement arises around what we mean by “participate in the economy”. I’d argue that working for wages to survive is not meaningful participation. When people aren’t free to pursue their ambitions or desired careers for whatever reason (sometimes education is too expensive, or maybe they’re stuck at a current employer because they need to retain certain benefits, maybe they can’t afford to move to where the opportunities are, maybe the job market isn’t recognizing their skills, whatever), that limits their potential contributions to society in ways that only limit innovation and degrade overall prosperity.

My nephews and nieces have entered a workforce that offers none of the opportunities I had. Humanity is on a long-term positive trajectory, driven by knowledge creation and sharing, yet we are clearly self-inflicting unnecessary pain in the short term.

This has been on my mind a lot more since a had a kid earlier this year. The world is already unrecognizable to me relative to when I entered the workforce. The way I got into tech and built my career would never work for someone starting out today. I wonder what the world will be like by the time my child reaches working age. I really hope we’ve figured out some of these problems by then and want to be part of the solution.

This is a cool example of the kind of problem that Clojure makes so much simpler to solve. Having a coherent model of time and not sharing mutable state makes parallel computing so much easier, because you’re not trying to coordinate multiple mutators contending for a shared resource. If you just don’t share the resource and let the language level primitives handle serializing operations for you, you can stop worrying about entire classes of bugs and just focus on your problems.

The ideas parallel servers reinvent by hand - immutable snapshot, pure read phase, changes as data - are the language's defaults. If writing from many threads is difficult, then don't write: all game logic is pure functions (fn [world events]) that read the snapshot in parallel and return changes as deltas, merged in one place. The merge preserves order, so the parallel run is bit identical to the sequential one, and no mechanic cares how many cores it runs on.

I think it’s so cool when people experience the benefits of Clojure’s paradigm in real projects. It’s often a tough sell at first but it really is amazing how far you can get with pure functions operating on immutable data. My favourite way to fix bugs is to just make them impossible by default, which often means rethinking the way your program models the world and time. It can be a bit trippy at first but it pays off.

AI is everywhere now and most people hate that, at least in the West. I can understand why. I have to use AI daily now for my work as a software engineer, and increasingly many things I build are effectively some version of “use an LLM to make this feel like magic”. I can appreciate the sentiment behind this in the sense that LLMs appear remarkably capable when asked simple questions about a number of topics, but it is also way too easy to just throw an LLM into the mix and actually end up making everything worse. The industry has vastly underestimated the amount of engineering discipline it takes to make LLMs actually complete tasks reliably or do anything useful from a normal person’s perspective. Which IMO is a big part of what is behind the general disapproval of AI outside the tech industry (among many other reasons).

The overarching principle I wish all product engineers would adopt in their approach to integrating “AI” is that it should always remove friction, not create it. If your “agent” is effectively just throwing up walls of text for me to review, that is not helpful. Other things that are not helpful:

• making decisions that I have to figure out how to go double check or undo
• doing things on my behalf that I have to correct
• impersonating me

Hopefully you get the idea. If you are embedding AI into a product that people use, please ask yourself before you ship “does this make my user’s life better or worse?” If it adds friction to their experience in any way, do not ship it. Fix it first so that your users genuinely benefit from this new integrated “intelligence”, such as it is, and make sure it’s not just another thing they have to work around or figure out how to disable to use your product.

One of my summer jobs in university was working in an analytical chemistry lab. I spent countless hours pipetting liquids from tube to tube, scanning labels, manually entering data into spreadsheets, and operating fancy machines. Even way back then (please don’t ask exactly how long ago 🙈) I couldn’t help but think “we must be close to automating most of this work”. Turns out we were not, but with this announcement I think its closer than ever.

MHS enables AI agents to operate multiple lab and manufacturing instruments, such as microscopes, liquid handlers, and robotic arms, in parallel, and perform intricate tasks ranging from routine drug discovery experiments to laser calibration on a quantum computer.

This is a really cool development and one way I could imagine AI having some genuinely beneficial impact on society. I think we’re arguably living in the bad timeline right now and unless public opinion shifts pretty dramatically somehow it will be difficult to get to a place where AI does more good than harm. Part of getting there is delivering some credible public benefit for all the cost and risk the public is expected to bear as a result of its development and deployment. I think meaningful progress in drug discovery is a potential area where that could happen.

I think a lot about what the future will look like. I always did but even more so since I had a baby. To me it feels like we’re not in a steady state right now. Things are volatile and changing fast. It feels like this pace of change can’t possibly last forever. But it also seems obvious that LLMs are going to dramatically change the nature of my work, and many types of work, permanently.

I am effectively required to use AI at work now, so for now I’ve decided to accept that reality, remain employed as a software engineer, and learn how to use these new tools well. At this point I can’t see software engineering ever going back to the way it was before coding agents. But finding these tools useful doesn’t resolve any of my reservations about AI adoption more broadly, especially with how the main companies selling it act in society.

If anything, using AI every day has made the tension more obvious to me. I think it's possible for a technology to be genuinely useful when applied well, use it regularly, and still insist its makers be accountable for its externalities. AI may be unusually capable and unpredictable, but unpredictability does not erase the responsibility of the people who build, deploy, profit from, and use it to act with care in society.

Upon closer inspection, they are all calling for the same thing: a view of AI systems as being so advanced and capable that no entity, human or corporate, could possibly be responsible for their actions. … This narrative is gaining traction as AI models become more complex and frontier labs reveal their incapability of containing the agents they’ve built. But we need to be careful not to buy into a carefully crafted fiction at the expense of real human lives.

I agree. I think this notion that increasing the sophistication or unpredictability of a tool somehow absolves its makers of any responsibility for its use is absurd. This is the perpetual fight the tech industry keeps having with governments and communities. Regulation has never been able to keep up with technology, and every time companies release a new capability they deploy it at enormous scale and then argue that because this technology is bigger or more sophisticated or whatever the existing expectations around liability and responsibility no longer apply. But scale and complexity don't erase accountability.

If you build a system, decide how it operates, where it deploys, profit from its operation, and have the ability to reduce the harms it causes but simply refuse to do so, you do bear some responsibility for those harms.

The fundamental flaw of framing AI as “conscious” by borrowing the language of neuroscience or animal rights is that it conveniently clouds the issue of what AI is: corporate-built software, with countless billions of dollars in investment behind it and an expectation that countless trillions of dollars in revenue will be generated from it for a few builders and investors.

I think this really gets at one of the core ethical issues with AI and how the companies developing it operate. There are some benefits to AI, but they almost exclusively accrue to a small and elite group of tech industry leaders. The costs and harms, meanwhile, are externalized -- onto creators whose work becomes training material, people subjected to synthetic abuse, workers whose jobs are disrupted, communities absorbing infrastructure and environmental costs, and ordinary people who become unwilling participants in experiments conducted at enormous scale. The asymmetry matters.

If society and average people are expected to tolerate substantial risk and disruption for the sake of pursuing the frontier, there needs to be some commensurate, convincing public benefit. Making a small number of already unimaginably wealthy individuals vastly wealthier is not a good enough reason for the rest of us to take on these risks.

There are currently dozens of cases around the world in which AI companies have been sued for a wide range of abuses. Grieving loved ones, aggrieved creators, and violated individuals have accused companies of willfully enabling self-harm or harm to others, generating child sexual-abuse material and nonconsensual nudes, reproducing copyrighted materials, and provoking psychosis.

Like any problematic technology, it’s really easy to overlook the harms it causes when we are benefiting from it. This isn't unique to AI, but it raises important questions around accountability. When a technology has both beneficial and harmful uses, the question becomes how to develop and deploy it responsibly. We should not just accept "we have no such obligation" as an answer.

Systems do not “attack” because they went “rogue” or are “manipulative” or “malicious.” Harms occur because companies were negligent in their rush to sell their products to as many people as possible to meet revenue targets.

I think this is very important distinction. When an AI system causes harm, describing the model itself as "malicious", "deceptive", "rogue", or "out of control" obfuscates the chain of human decisions that put it in a position to cause that harm in the first place. People built the model, trained it, set up the safeguards, and chose the conditions under which it got released. A small group of humans made deliberate decisions on behalf of everyone else about what level of risk was acceptable.

Responsibility can be distributed but it cannot be abdicated. Otherwise we end up with an untenable accountability vacuum where the more powerful and autonomous a technology becomes, the less responsibility its creators bear for deploying it. That is obviously backwards.

Discussing AI in anthropomorphic terms is a trap, distorting a legal system intended to protect us into one that protects corporate interests at the cost of countless human lives.

I think this is at least one small thing we can do to steer the conversation in the right direction. Language matters. It's easy to slide into describing agentic systems in anthropomorphic terms, but we have to draw a line where that metaphor starts implying legal and moral consequences. AI is a technology, a tool. Not a person, not an independent actor with agency or an entity separate from the person using it. It is built, owned, operated, and deployed by people.

We have to hold those wielding this tool accountable for the harm they cause or we will be living in a world where those with access to it are free to act with impunity destroying the lives of those who don’t.

I can now hand much of the mechanical work to an AI coding tool, then spend my time fixing the interesting parts.

This has been my experience with vibe coding too. On the surface, my coding agents can produce incredible apps very quickly. Once I start actually trying to use them, there are endless paper cuts to fix.

Programming becomes part of using a computer, whether the user calls it programming or not.

This does seem true. Not everyone will become a "programmer" in this sense, but many many more people will, the same way many people use spreadsheets or other similar tools to get their work done.

Traditionally, the software industry has optimized for products that can support large audiences: companies, engineering teams, sales organizations, and lots of customers who, in aggregate, will pay enough to justify building the product. That makes sense when software is expensive to build.

This is a really interesting way of putting it. Finding people to pay for your software is always the challenge.

Finding someone to write and maintain a narrow program used to be the primary bottleneck. Now, the challenge is recognizing when a “throwaway” tool has stopped being throwaway.

This is a great way to frame all of the ad-hoc development happening now. LLMs writing code is cool and fast for sure, but it can be very very annoying when you need the software produced this way to actually work.

Before building your next program, I recommend you ask three questions:

1. Does anyone else depend on it?

2. Can it change or expose important data?

3. Would work stop if it disappeared tomorrow?

If the answer to all three is no, treat it like an experiment, not a product. Build it quickly, skip the formal engineering process, and expect to delete it.

If the answer is yes, add only the structure you really need. Give it an owner, list its connections, limit its credentials, and make failures visible. Then, have a plan for how it gets repaired, replaced, or retired.

The amount of engineering process should follow the consequences. A disposable tool can stay disposable. A tool people depend on needs an owner, tighter access, and a plan for keeping it working.

I really love this framework, I think more people should adopt it. These are very sensible guidelines for vibe coding.