Kira Howe

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. link / reddit.com (via) / #clojure #concurrency #functional-programming #immutability #software-development

> 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. link / fastcompany.com (via) / #ai #ai-agents #coding-agents #software-development

This is the best “AI usage” policy I’ve seen yet. I would love it if projects I worked on would adopt similar conventions and standards. > you as an author need to take the time to make sure that all of the ideas in the writing are the ideas that you personally intend to convey (including the structure and wording that determines which ideas are emphasized) and that the documents are a good use of your readers’ time. The thing that frustrates me the most about how AI is used in the contexts where I’m exposed to it is when people try to pass off what is clearly unedited slop as their own work. Rather than seeing AI as a tool to assist with human productivity, too many people are trying to make it replace human productivity, but all they’re really doing is unloading their work on some other human. I feel pretty strongly that asking someone to read AI generated output is rude and inconsiderate. You are effectively asking them to fact-check, edit, summarize, and distill a jumbled bag of claims that may or may not be true for you. To the author, if feel like they saved a ton of time producing the document or message or whatever they needed to write. To the person on the receiving it’s another chore. To be fair I have mostly stopped tolerating this behaviour. > You will confuse your readers (and waste their time) if you present them things that are not genuinely representative of your thoughts. In some cases, readers will recognize and call out the incongruous parts; in others, they will be misled as to what your actual thoughts are. This cuts to the core of the issue, I think. I'd strongly argue that we shouldn't be outsourcing our actual thinking to AI. It's so tempting to just post whatever it generates because it creates the illusion of productivity which is highly rewarded in many white collar jobs. Most managers reward velocity and not quality. The problem is certainly that the incentives are wrong in the first place, but until those are corrected we have to rely on our own self-discipline to resist the urge to just ship more slop for the sake of seeming more productive. > Pascal once wrote, “I have made this [letter] longer than usual because I have not had time to make it shorter.” I love this quote, but I always thought it was Mark Twain's. I guess a lot of quotes are misattributed to him. > If you are producing a longer piece of writing from a shorter prompt, consider instead just sharing the prompt itself. I like this suggestion. link / sophiebits.com (via) / #ai-ethics #communication #documentation #human-computer-interaction #productivity #quality #writing

> I apparently can’t hold a conversation with a friend, post on social media, or even daydream idly without the topic eventually turning to bloody A.I. > > It’s not always me who brings it up, but it often is; I’ve rarely known such a “sticky” subject. This resonates. Unlike Oliver Burkeman I do use AI more or less all day every day at work. But I also find myself talking about it so much more than I need to. > One answer is that the general topic is an unusually powerful trigger for a major disease of our times: overthinking. This is an insightful take. Whatever you think of AI, it is upending many industries very quickly and has implications one way or another for the future of society. Whether you’re for or against, whether you use it or not, it’s become very difficult to ignore its pervasiveness in day to day discourse anymore. This diagnosis of the reason being that it naturally triggers all kinds of pre-existing neuroses about our place in the economy, the nature of our relationships, even what it means to be human in the first place, seems apt. These are all heavy, anxiety-inducing topics for many people and the way AI is often discussed very nonchalantly by those creating it as though it might ruin all of our lives is a bit hard to ignore. > Whatever the details, this is where overthinking kicks in, because it feels like the solution to the anxious feelings in your body is to scurry off into your head and think some more, read some more, argue some more, maybe use A.I. some more… But scurrying off to your head doesn’t work… I think this is one of the key things software people get wrong about the world, and the source of a lot of the friction the tech industry is running into with regards to AI adoption. There’s a pervasive tendency among us to really highly overvalue intelligence, but not every problem can be resolved by just thinking harder. > Lives immeasurably fuller and more interesting than can be dreamt of in Silicon Valley’s ideology. Lives that encompass vastly more than what software can do. I find this vision of what a good life can be so much richer and more appealing than what’s on offer in my tech bubble. It’s important to remember this. At the end of the day computers are just tools we can use to facilitate some of the things we want to work on, but have very little to do with what it means to live a full and interesting life. link / ckarchive.com (via) / #ai #anxiety #ethics #human-computer-interaction #overthinking #reflections #society #tech-industry

It feels like the big LLMs have come full circle. At first they were too naive to implement meaningful features autonomously and took so much handholding to get anything done it was quite a pain babysitting them. Then they got good enough to do meaningful software engineering work and there was (I now recognize in hindsight) a sweet spot at some point early this year where they got meaningfully better and good enough to take non-trivial work off my hands without causing dramatically more work. But now they're far too eager and require constant babysitting again. Opus 5 and Fable are so relentless about completing a task at any cost that it creates a lot of work reining them in. If left unattended they will make crazy decisions without consulting me on architecture, project setup, dependency management, or all kinds of other areas that are far above their pay grade. I'm finding they also tend to massively over-engineer simple tasks compared to Opus 4.8/GPT 5.5 and require a lot of cleaning up after if left unattended to just finish something. Their weights are so much more powerful than any markdown instructions you can give them and they pattern-match so aggressively on existing code it's very difficult to steer them in the right direction. No matter how desperately you plead in markdown, they will inevitably still infer conclusions from your existing shitty legacy code and happily ignore your instructions to not emulate it. In a way I guess this is not such a bad thing, because it means I can probably start using Opus 4.8 and similar-level models for meaningful day-to-day work and maybe finally stop chasing the frontier, wasting days fighting my tooling every time a new model comes out. Also convenient at a time when the frontier is increasingly closing for lack of interpersonal skills in Silicon Valley. Now that I've written this down I realize what I really need is an eval suite for my dev environment, some way to assess each new model against my actual workload before deciding whether it's worth adopting or not. Now that would be an interesting project! post / #agent-driven-development #ai-agents #ai-hype #ai-safety #coding-agents #developer-workflow #llms #software-engineering