Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from A Beautiful Site
As software engineers, we take pride in hand-written code and knowing how everything we build works in detail. While there are many developers out there who build good software, there are many, many more who don’t. Yet we balk at the idea of vibe coding, even when it yields decent results. You don’t need a scientific study to realize the mean quality of human-authored software leaned towards slop even before AI was around. How many times have you been frustrated by an app or website that just didn’t work right? (This is especially true for software produced by big companies.) The quality of software humans can build is absolutely incredible. But the quality of software humans actually do build is usually not. So no, AI can’t build perfect software. Maybe that will improve in the future, or maybe it will remain just as messy as the human-authored code LLMs have been trained on. I don’t think any of that matters, because if AI can build software that’s at least as good as the mediocre code that came before it, that will be acceptable for most industries. Customers don’t care about the craft, they care about the result. And if the result is faster, cheaper, and good enough…well, that’s a better combination than anything they’ve ever had before. Why wouldn't they choose it?
I launched ColorCopy on May 18. It was my second macOS app, but the first one I launched on the Mac App Store. Today, I decided to pull it. The app isn't a new idea, but it bakes four color tools into a single menu bar app: an eyedropper, a color picker, a palette manager, and a contrast checker, each one a hotkey away. I made it available for free, with a one-time in-app purchase to unlock unlimited use. No subscription, no recurring fees. It's simple, stable software with the lowest possible barrier to entry…exactly the kind of utility the App Store seems made for. I wasn't sure what to expect, so I ran an experiment to answer some questions: Is there any real benefit to having your Mac app on the App Store? Is the Apple tax worth it? Will customers just come flooding in? For ColorCopy's release, I did zero marketing. No Product Hunt launch. No Hacker News post. The only things I published were this blog post and a tweet. If the App Store delivers on its promise of discoverability, that should be enough to see some kind of traffic…right? You be the judge. In nearly three months on the App Store, ColorCopy got a little over 1,000 impressions, 149 product page views, 85 first-time downloads, three in-app purchases, and $21 in proceeds. Not per day. In total. Broken down over 81 days, that averages out to: 13 impressions per day 1.8 product page views per day 1 download per day 0.04 in-app purchases per day (about one per month) $0.26 in proceeds per day Extrapolated to 12 months, ColorCopy would have earned about $95…not even enough to cover Apple's $99 annual developer fee. If discoverability isn't a part of the App Store deal, what exactly is the benefit? Why limit your Mac app to the sandbox?* Why spend hours in App Store Connect filling out metadata, screenshots, and localization information? Why wait an arbitrary number of days for someone to review your app with the consistency of a coin flip? It doesn't seem worth it for Mac developers. Adios, App Store 👋 As of today, ColorCopy is self-distributed and sold through Polar (the new Stripe, which I highly recommend). This is the same way I sell TongueType, which makes pretty much everything easier on my end: one dashboard, real customer relationships, no finicky review process, and updates ship the moment they're ready. The move required swapping out in-app purchases from StoreKit to Polar, and updates now ship through Sparkle instead of the App Store's built-in update mechanism. Both are tried and true solutions for self-distributed Mac apps. To be fair, you can't really do this on iOS. Most users aren't jailbroken…walled garden and all. But on Mac, where self-distribution is still a first-class option, there seems to be zero incentive to be in the App Store, especially if you're counting on discoverability. In three months, the App Store sent me barely a trickle of customers. Had I marketed the app myself, the traffic would have flowed the other way. I would've been sending my customers to Apple and paying a tax for the privilege.** Self-distribution gives me the freedom and control over my apps that the App Store's sandbox never will. If it's on me to drum up all of my own traffic, I'm going to send it to my own website. *I originally used a third-party library for the eye dropper because NSColorSampler is meh, but the sandbox forbids it so I was forced to remove it. Yes, I had to make my app shittier in order to put it on the App Store. **I fully acknowledge this may not be the case for every app, but it was my experience and worth sharing. Your mileage may vary. Aside: ColorCopy was available in 10 languages on the App Store. For some reason, the listing always showed FR as its primary language (it wasn't). The app is available in many languages, including English.
I built the dictation app I wanted. It's called TongueType, and my daughter did the voice over for the video. (Family business.) It hasn't gotten much traction yet, and I think I know why: dictation has been bad for so long that most people stopped paying attention. I don't blame them. But I don't think most people realize how good local models have gotten. The thing that was flaky and frustrating five years ago is genuinely good now, and it runs entirely on your Mac. Downloads are low. But the conversion rate is great. The people who actually try it tend to stick around, which tells me the problem isn't the app, it's getting someone to give dictation one more honest chance. The real hurdle is the habit The hard part isn't accuracy. It's that talking instead of typing is a new habit, and new habits are awkward before they're automatic. For the first week it feels strange. You catch yourself reaching for the keyboard out of muscle memory. Then one day it clicks, and you realize how slow typing was making you for certain things. I still write code by hand. That's thinking, not transcribing, and I want my fingers on it (plus saying HTML tags and attributes out loud seems counterintuitive 😂). But for almost everything else, I talk. I prompt LLMs I send emails I reply on Slack I write commit messages I do most other text with my voice The common thread is that the thinking is already done and the only thing left is getting the words out. That turns out to be a surprising amount of my day. My desk setup On the go, the MacBook's built-in mic works just fine. You don't need fancy hardware to get good results. But when I'm at my desk, my laptop is docked, so I pair TongueType with a Tula mic. It's small, portable, sounds great, and looks the part! (Kuru Toga mechanical pencil positioned for size comparison.) One tip: use a wired mic if you can. Bluetooth adds latency, and latency is the enemy of a tool you reach for dozens of times a day. A wired connection makes the whole thing feel instant. Honest caveat: it's probably not a great look in a co-working space. 😂 "Why is this better than macOS dictation?" More accurate. Less flaky. More customizable. More fun. I could list the features, but the honest answer is the same one I'd give for most things: just try it and you'll feel the difference immediately. It's free to start. What's your experience been with dictation? If you wrote it off years ago, I'd genuinely love for you to give TongueType a shot and tell me what you think.
I just launched my first macOS app called TongueType. It's voice dictation that runs entirely on your Mac. Hold a key, speak, release, and your words appear wherever your cursor happens to be. I build small, simple, stable software. TongueType fits that description, and it scratches an itch I've had for a while. Why I made it I type fast, but I often think faster than I type. When an idea is fully formed in my head, the bottleneck is my fingers. macOS has had built-in dictation forever, but I never liked relying on it. Accuracy aside, I didn't love the idea of my voice taking a trip to a server and back just to write a sentence. There are many dictation apps in the wild, but I want one that's privacy focused, doesn't send data to the cloud, doesn't charge a monthly subscription, and gets out of the way. TongueType uses OpenAI's Whisper model running locally on Apple Silicon. Nothing is uploaded. Nothing is logged. There's no account to create. Zero telemetry. Your voice never leaves your Mac. How it works The whole interaction is one key. By default it's the Right Option key, because it's sitting right there and your thumb isn't doing anything important. Hold it, talk, let go. The transcribed text is inserted at your cursor…in your editor, your email, a chat box, a search field, anywhere text goes. You can also drop in an audio or video file — WAV, MP3, MP4, MOV — and get a transcript back. Handy for meeting recordings and voice memos. A few things I sweated the details on: A grace period so a quick accidental tap doesn't start recording. Double-tap to latch for when you want to keep talking without holding the key down. Cancel phrases — say "scratch that" at the end and the whole thing gets discarded. You will use this more than you expect. Spoken symbols — say "new line" or "question mark" and you get the symbol, not the words. Post-processing — for common terms that seldom get dictated properly. TongueType speaks twelve languages and includes automatic detection, so you don't have to tell it which one you're using. How I actually use it Building the app was one thing. Using it every day turned out to be another. A couple months in, it's quietly worked its way into most of what I do at the keyboard: Prompting LLMs. Talking to an AI assistant is conversational by nature, and typing out a long, detailed prompt is tedious. Speaking it isn't. I get more context into a prompt because I'm not rationing my words to save my fingers. Email. Replies that used to sit in my drafts now get spoken out in a single pass. I still read them before sending, but the blank-page friction is gone. Code comments and commit messages. The parts of coding that are just writing. It's faster to explain why a change exists out loud than to stop and type it. Direct messages. Quick replies in chat without breaking flow. Hold the key, say it, done. The common thread: TongueType is best wherever the thinking is already done and the only thing left is getting words out. That's a surprising amount of my work day. A fun personality TongueType is minimal and fun. It lives in the menu bar. The recording overlay is small and out of the way, and you can configure its position on screen. There are twenty accent colors including Rainbow Mode. None of these extras were necessary, but all of it was fun to build. Accessibility I want to call this out specifically. Voice dictation isn't only a convenience. For some people it's the difference between using a computer comfortably or not. If typing is painful or difficult for you, TongueType is built to be a genuine alternate input method, not an afterthought. That mattered to me, and it shaped a lot of the decisions above. Pricing TongueType is free to try, and the free tier includes every feature. You get 30 minutes of live dictation each month and short file transcriptions. If you want unlimited, TongueType Pro is a one-time $19.99 purchase that covers up to five Macs and unlocks unlimited dictation and full-length file transcription. No subscription. Buy it once, keep it forever. Requirements TongueType needs macOS 14 or later on an Apple Silicon Mac (M1 or newer). The local model is the whole point, and that's what makes it run so well. If any of this sounds useful, give it a try at TongueType.app. It's free to start, and I'd genuinely like to hear what you think.
I believe artificial intelligence is a powerful and valuable tool that can significantly improve how we create, solve problems, and bring ideas to life. I didn't always feel this way.. But these days, I use AI regularly in my work and I expect that to continue. We may not have chosen this reality, but it's the reality we're in. The tools and their benefits — costs be damned — can no longer be ignored. That said, when people ask "was this made with AI?" the honest answer is rarely simple. AI can speed up many parts of the process, but it doesn’t replace human judgment, creativity, or responsibility. What appears effortless on the surface rests on deliberate human direction, critical thinking, and careful review. Getting good results from AI requires active guidance and oversight. The nuances of context, ethics, user needs, and real-world application are simply too varied given the current technology. Moreover, AI doesn’t generate meaningful ideas or elegant solutions on its own. Strong human vision, architecture, and decision-making are still essential. There is no prompt, model, or service that can deliver finished, trustworthy work without substantial human input. My commitment to you is this: everything I create will be driven by human ideas, architecture, verification, and final review. I will use AI as an assistant to do what I would have done anyway, but more efficiently. I will not let AI replace my intelligence, but I will use it to turn my intelligence into code faster. — Cory LaViska
More in programming
I listen to a lot of podcasts, and I like how they fit around other tasks. I press play, lock my phone, and put it down. I’m free to wash the dishes, fold the laundry, or shop for groceries. Unfortunately, more and more information is only published as a video. Technical talks, conference sessions, video essays – they don’t work in an audio-only podcast app. I could convert these videos to MP3 files, but that breaks down the moment a video isn’t pure spoken word. If a speaker says, “Look at this slide” or holds up a diagram, an audio-only file leaves me stranded. I don’t want to give up the podcast player I like, nor stare at a screen for an hour – but I do want the information in these videos. To solve this, I’m abusing my podcast player’s chapter support. This gives me the best of both worlds: I can listen to a video as audio-first, and glance at my lock screen if I need a moment of visual context. The idea: Chapters every few seconds MP3 files can have ID3 metadata, and ID3 metadata can include chapters. A chapter covers a particular time range, and it can have an associated title, description, and cover art. My podcast app of choice is Overcast, which can’t play videos, but it does have robust chapter support. I can jump between chapters, navigate a table of contents, and see per-chapter cover art. To get videos into Overcast, I’m creating MP3 files with a new chapter every few seconds, and the per-chapter cover art is a corresponding frame from the video. As I play the file, I get a slow, stop-motion-like rendition of the original video. If my phone is locked, I can glance at my lock screen and see the current frame in the Now Playing screen. Overcast is developed by Marco Arment, and I got this idea from Forecast, his app for adding chapters to podcasts. In particular, I was struck by its ability to create chapters that don’t display in the chapter list – ideal if I don’t want a table of contents with hundreds of entries. As I was developing my script, I compared my output to the output from Forecast to ensure I was creating the chapters correctly. The code: FFmpeg and Mutagen There are three steps in this process: Convert a video file to an MP3 Extract images from the video at a fixed interval Insert the images as hidden chapters in the MP3 file Let’s go through each in turn. 1. Convert a video file to an MP3 Converting a video file to an MP3 is a single FFmpeg command: ffmpeg -i video.mp4 audio.mp3 This is consistently the slowest step of the process, and I do wonder if I could use different settings or an alternative encoder to make it go faster – but it’s not slow enough to be worth further investigation. 2. Extract images from the video at a fixed interval Extracting images from a video needs a more complicated FFmpeg command: ffmpeg -i video.mp4 \ -vf 'fps=1/5,scale=iw*sar:ih,scale=min(iw\,945):min(ih\,945):force_original_aspect_ratio=decrease' \ thumbnail_%04d.jpg This extracts an image every 5 seconds, downscales any image larger than 945 pixels square (while preserving the original aspect ratio), and saves the results as sequentially numbered JPEG images (thumbnail_0001.png, thumbnail_0002.png, and so on). The key is the -vf flag, which defines two FFmpeg filters: The fps filter selects one frame every 5 seconds (fps=1/5). The first scale filter scales the width based on the sample aspect ratio (scale=iw*sar:ih). Without this filter, frames can be stretched and distorted. The second scale filter scales the input video, preserving the original aspect ratio (force_original_aspect_ratio=decrease), and ensuring the output images fit within 945×945px or the size of the input video, whichever is smaller. My limit is 945 pixels because that’s the largest size that cover art is shown on my iPhone. This filter still isn’t completely correct – it sometimes creates images from portrait videos that are smaller than I’m expecting – but it’s good enough. These are only thumbnails for glancing at, and if I want to change it later, I can always do the image resizing outside FFmpeg. 3. Insert the images as hidden chapters in the MP3 file Inserting the chapters into the MP3 file is more complicated. Although FFmpeg has basic support for ID3 metadata, as far as I know, it can’t insert chapters with per-chapter artwork. Instead, I’m going to reach for Python and the Mutagen library. Here’s the code to add a chapter to an MP3 file: from mutagen.id3 import APIC, CHAP, ID3, PictureType audio = ID3("audio.mp3") with open("thumbnail_0001.jpg", "rb") as f: img_data = f.read() image_frame = APIC(mime="image/jpeg", type=PictureType.OTHER, data=img_data) chapter_frame = CHAP( element_id="chp1", start_time=0, end_time=5 * 1000, sub_frames=[image_frame] ) audio.add(chapter_frame) audio.save() This creates a single chapter that lasts the first 5 seconds (0 to 5000 milliseconds), and the per-chapter cover art is thumbnail_0001.jpg. If we ran this in a loop, we could add images for every 5 second slice of the original video. This code is inserting two frames into the ID3 metadata: The CHAP (chapter) frame contains the timing information, and it can have subframes for metadata like title, chapter art, or associated URL. The APIC (attached picture) subframe contains information about a picture, which can either be a blob of image data or a URL to an image on the web. Normally, you’d also insert a CTOC frame which defines a table of contents, but I don’t want a TOC with hundreds of 5-second chapters, so I’m deliberately not doing this here. This is allowed by the ID3 spec – you’re not required to insert a CTOC frame if you’re using chapters, and you can have chapters that aren’t listed in your table of contents. To work out which frames I needed, I used Forecast to create some chapters by hand, and I inspected their frames. In particular, loading an MP3 and calling Mutagen’s pprint() method shows a human-readable list of frames, and then I could drill into the individual fields: from mutagen.id3 import ID3 audio = ID3("audio.mp3") print(audio.pprint()) I wrapped all this code in a project called glancecast, which allows you to convert a video file with a single command, with optional flags to set the frame length and chapter art size: $ python3 glancecast.py interesting_talk.mp4 interesting_talk.mp3 The process takes a minute or so to complete, most of which is spent transcoding the video file to MP3. The resulting MP3s are usually 40 to 50 MB in size, which is very reasonable. The outcome: How it looks in practice Here’s what one of these “glanceable” podcasts looks like in Overcast and on my lock screen: Maggie Appleton presented this talk over two years ago and it’s been on my “talks to watch” list ever since. Once I put it in Overcast? I listened to it in less than a day. It’s not a lot of extra information, but enough that I can quickly glance down and get the gist of what a speaker is saying. Both views update with a new frame every few seconds, or I can put my phone in my pocket and ignore the screen. I’ve used this approach for half a dozen videos so far, and I’m happy with the results. I expect to keep using it, because I have a long queue of videos I’ve been meaning to watch. If you’d like to try this, check out glancecast for the full code and instructions. [If the formatting of this post looks odd in your feed reader, visit the original article]
Andrew Baker, the current Group CIO at Capitec Bank wrote an interesting piece on AI and open source, and how these tools that generate code according to one’s specification may replace the general reliance on open source implementations done by contributors around the world. I’d really recommend reading it. I have great admiration and respectContinue reading "AI Isn’t Replacing Open Source"
A framework for thinking about when AI involvement is additive or a violation
Why we need richer, thicker interfaces and better boundary objects for collaborative planning with agents
A look at 10 foundational pillars that enable agents to operate more competently and more efficiently in any codebase.
