The next meaningful breakthrough that has emerged in AI‑assisted software development is orchestrating fleets of coding bots that can build entire features or apps from a plain‑English strategic plan, not line‑by‑line prompts. This isn’t “AI helps me code”; it’s “AI builds the code while I direct the strategy.” Anil Dash calls this “codeless,” and I think that’s a great name for it.
-
Raphael Amorim on Monozukuri and Software Development
[AI prioritizes] time over quality. To achieve quality, a programmer needs to have experienced what is being built. Software development follows the path of craftsmanship, where an artisan—through years of experience, repeated attempts, occasional luck, or natural talent—can produce remarkable results. This idea aligns closely with a Japanese concept known as monozukuri.
-
Details Make the Design
I was poking around on Detail, getting some inspiration when it occurred to me that the small details really do make a big difference. I know that’s not a huge revelation, but CSS makes it incredibly easy these days.
Chris Coyier has a post about modern CSS two-liners that have a big impact on the design of a website. Here are two more, not as fresh,
n <= 2liners.Page transitions
You can put a nice fade in/out effect on the entire site in one line. Now when you navigate to any other page on the site, it will look nice and polished.
@view-transition { navigation: auto; }Selection color
Let’s not forget selection color. Of course, you can make the selection color as wild as you want, but a simple inversion of the main site colors is usually enough to make it look intentional.
::selection { color: white; background-color: black; } -
Signs of AI Writing Checklist
Wikipedia has a good page about the Signs of AI Writing. When I mentioned that we should try to educate others about writing (rather than slamming them as AI slop), this is the kind of thing I meant. On the other hand, for someone who isn’t great at writing to begin with, this list represents another list of stuff I need to consider when writing.
Here’s a checklist I created to help identify AI wording in your own text. First read through the Signs of AI Writing page and then use these as quick reminders of things to look for.
Content
- Exaggerated significance claims
- Overstated notability/coverage
- Shallow, generic analysis
- Promotional or ad‑like tone
- Vague attributions/weasel words
- Formulaic “challenges/future” endings
- List titles treated as proper nouns
- Overly broad “see also” sections
Language and grammar
- Repeated AI buzzwords
- Avoidance of simple “is/are”
- “Not only…but also” overuse
- Rule‑of‑three phrasing
- Unnecessary synonym swapping
- “From X to Y” ranges without a scale
Style
- Title‑case usage in headings
- Excessive bolding of keywords
- Inline‑header list formatting
- Emoji usage in headers and lists
- Heavy em‑dash reliance
- Unnecessary or short tables
- Inconsistent curly quotes
- Email‑style subject lines, “subject:”
Communication intended for the user
- Conversational helper language
- Knowledge-cutoff disclaimers and speculation
- Phrasal templates and [placeholder text]
Markup
- Leftover Markdown markup
- Broken or missing inline citations
- JSON code at the end of sentences
Citations
- Broken external links
- Invalid DOI and ISBNs
- Stale access-dates
- DOIs that lead to unrelated articles
- Book citations without pages or URLs
- Incorrect or unconventional use of references
- utm_source= parameters in URLs
Miscellaneous
- Sudden shift in writing style
-
Why I Chose Tauri for My Text Adventure Game
When I started designing Head in the Cloud, a horror text-adventure game, I figured C would be the natural language of choice. There is a romanticism to writing a text-based game in C. But I wanted to ship the game, and I knew that C wasn’t the best choice for that (for me).
I ultimately chose Tauri, a framework that allows you to build desktop applications using web technologies, over a traditional systems language. Here’s why.
1. Avoiding the Language Learning Curve
My biggest constraint was time. As a Lead Software Engineer with two decades of experience in web development, I’m most familiar with HTML, CSS, and JavaScript. Conversely, I don’t know C and my knowledge of Rust (another systems language) is novice at best.
Choosing C would have turned this into a language learning exercise rather than a game development journey. By choosing Tauri, I eliminated the “language tax.” I can think in game logic—inventory arrays, state management, narrative branching—rather than syntax. The goal is to ship a game, not to learn a language.
2. CSS is Great for Text, Layouts, and Graphics
The web browser is the most sophisticated text rendering engine in existence. If I were to build in C, I would be giving that up. I also wanted keep the option to modernize the game with graphics. A text-based game benefits a lot from illustrations.
Using Tauri allows me to use CSS. I can utilize Flexbox and Grid for responsive layouts that look good on any screen size. I can load custom web fonts to set the retro atmosphere instantly. I can use CSS animations for subtle text fades or “glitch” effects that would be nightmarish to code from scratch in C. Tauri gives me a AAA-level UI layer for free.
3. Smaller Build Sizes than Electron
The immediate counter-argument to using web tech for desktop apps is usually “Electron bloat.” Electron bundles a version of the Chromium browser and Node.js into every single application installer. This leads to simple chat apps weighing in at 100MB+.
Tauri solves this by relying on the Operating System’s native webview (WKWebView on macOS, WebView2 on Windows, WebKitGTK on Linux). It does not bundle a browser.
The result is massive binary reduction. A basic Tauri app can be less than 5MB. For a text adventure game, keeping the footprint small is essential. I get the development experience of Electron without forcing the user to download an entire web browser just to play a text game.
4. Simpler Architecture than Electron
While I wanted the web environment, I did not want the Electron ecosystem. Electron is powerful, but it requires you to manage the complexity of the Main vs. Renderer processes, context bridges, and inter-process communication (IPC).
Tauri simplifies this architecture. It is built on Rust, providing a secure, lightweight backend that communicates with the frontend. I don’t have to worry about spinning up worker threads manually or managing complex menu configurations just to get a window on the screen. It provides sensible defaults that let me focus on the JavaScript layer where my game logic lives.
5. Iteration Velocity
Game development requires constant tweaking. You change a line of dialogue, you tweak a color, you adjust a timing delay.
In a C environment, this is a compile-run loop. In the Tauri environment, I have access to Hot Module Replacement (HMR). I can change the CSS of the game interface or the JavaScript logic of a puzzle, and the game window updates instantly without a restart. Over the course of a 6-month development cycle, those saved seconds compound into days of saved time.
6. Safety by Default
Writing a game in C opens the door to memory leaks and segfaults. One bad pointer arithmetic error can crash the user’s desktop.
Tauri relies on Rust for its backend bindings. Even though I am a Rust novice, I benefit from Rust’s memory safety guarantees. I am writing high-level JavaScript, which is sandboxed, and the heavy lifting is done by a backend that is proven to be memory-safe. It is a safety net that C simply does not offer.
7. Cross-Platform without the Pain
Finally, compiling C for Windows, macOS, and Linux requires managing makefiles, compiler flags, and distinct build environments. Tauri abstracts this complexity. With a few commands, I can cross-compile binaries for the major operating systems. Since the UI is just a webview, I don’t have to rewrite the rendering logic for different OS window managers. It ensures Head in the Cloud is accessible to everyone, regardless of their machine.
Conclusion
There is no “best” language, only the best tool for the job at hand. For a high-fidelity 3D shooter, C++ or Rust is the answer. But for a narrative-driven text adventure built by a veteran web developer? Tauri offers the perfect intersection of performance, file size, and developer velocity. It lets me respect the user’s hardware while respecting my own time.
-
Conviviality as the Antidote to Enshittification
A website to destroy all websites argues that friendliness is the cure for enshittification (the process where online platforms degrade in quality over time as they shift focus from serving users to extracting maximum profit for shareholders) of the internet.
The article outlines three things that convey friendliness on the web:
- Authoring and sharing content for free
- Creating your own social networks
- Learning how to write code
And personal websites are the embodiment of conviviality on the web. It ends with an encouragement to make your own site and share it on PersonalSit.es.
-
Don’t Forget About JavaScript Iterators
In Stop turning everything into arrays (and do less work instead) Matt Smith argues that modern JavaScript developers often default to converting data into arrays so they can chain familiar methods like
.map(),.filter(), and.slice(). That habit, he says, leads to unnecessary work—extra memory usage, wasted computation, and slower apps.Instead, he encourages leaning on iterators and generator functions, which let you process data lazily and sequentially. With iterators:
- Work happens only when consumed, not upfront.
- You avoid building full arrays when you only need a slice of the results.
- You can stream data from APIs or large collections without blowing up memory.
- You can compose transformations without paying the cost until the final
.toArray().
His rule of thumb: If you don’t need the whole array, don’t create one. Iterators represent “work that hasn’t happened yet,” making them ideal for efficient pipelines, async data fetching, and scenarios where you only need a subset of results.
-
Code Review at AI-Scale
Traditional Code Review Is Dead. What Comes Next? makes the case that humans won’t be able to keep up with code reviews when AI is at scale. It concludes that humans should move to testing behaviors in a preview environment (i.e. manual testing) instead of line-by-line reviews. Personally, I don’t see how you can ship AI-generated code without a traditional code review. However, I do agree that humans will be the bottleneck when AI is operating on code at scale. Is there a better solution?
-
AI-Ready Frontend Architecture
To get the most out of AI it makes sense to architect your frontend in a well-known and predictable way. I’ve been thinking about what an AI-ready frontend architecture might look like but have yet to test and recommend a specific solution. However, Nelson Michael has an interesting take on the problem in the article A Developer’s Guide to Designing AI-Ready Frontend Architecture.
Here are some key points:
- AI amplifies weak architecture
- Teach AI your architecture explicitly file
- Directory conventions matter more than ever
- Use design systems as constraints
- The use-case pattern is the backbone
- Use middleware for cross-cutting concerns
- Pay special attention to auth, testing, and observability