So I vibe coded an app to fix it.

Khi is a macOS application that connects to a Kobo e-reader, extracts your highlights and exports them as Markdown files. It’s local-only, free, and does exactly one thing well. I built it over several days using AI as my co-developer: Claude Code for most of the implementation (including an initial interview that produced a detailed SPEC.md), with Kimi 2.5 during some early sprints (since it was free over Opencode for a week!) and Gemini for stretches where API constraints on Opencode were not playing along.

I’m not a programmer. I understand HTML and CSS reasonably well, have some familiarity with Svelte, but I’d never written a line of Rust in my life and had no experience with Tauri, a framework for building lightweight native apps that I chose specifically because it’s less resource-intensive than Electron. The architecture (a Rust backend parsing Kobo’s SQLite database, a Svelte frontend, communication through Tauri’s IPC bridge) wasn’t something I designed. I described the problem and the stack I wanted; the AI proposed the architecture and implemented it.

The code side

The technical side delivered. The Rust code that reads the Kobo database, queries the SQLite tables, extracts highlights with their chapter metadata — none of this was something I could have written or even reviewed at a detailed level. It worked. There were refactors, moments where early architectural decisions needed revisiting. But that’s true of any project, with or without AI. As someone who couldn’t have written a line of this code alone, the moment that landed was simple: the first time I saw my own highlights appear in the interface, pulled from the database, chapter names intact. I hadn’t expected to feel much. I did.

That fluency has a clear explanation. Code has clear evaluation criteria. A function either produces the correct output or it doesn’t. Unit tests pass or fail. Error messages point to line numbers. The model has been trained on enormous amounts of annotated code: billions of files across dozens of languages, bug fixes, code reviews, explanatory pairs. When it writes Rust to parse SQLite, it’s operating in a domain where correctness is verifiable and the feedback loops that shaped its training were precise.

Sometimes, when working on more difficult bugs, I had to remember that fluency and accuracy are different things and that nothing in the model’s training gave it a reliable way to tell them apart. It would loop through approaches, each slightly reframed, each delivered in the same assured tone, apparently unable to flag that it had reached a limit. That recognition was mine to supply, suggesting it look at the official documentation or pointing it toward how a similar project had solved the same problem.

The design wall

The visual implementation was a different story.

I had no experience with AI-assisted UI design, so I decided to try it out: I used Figma Make to produce a simple but effective visual design, then exported everything into a specification document: design tokens, CSS variables, color palettes, typography scales, etc. Component specifications down to padding values, with React reference files showing exactly how each element should look. The spec was precise.

Generating a “good enough” design was rather trivial. Getting the AI to implement it was slower, more iterative, and more frustrating than I’d expected.

The core problem is the translation layer. When you describe a visual error in text, the model has to guess which element, which property, which value.

Tools like Agentation address this differently. Rather than approximating the problem in language, they extract precise CSS selectors and computed styles directly from the interface — exact coordinates instead of a verbal description. The model still can’t see the layout, but it doesn’t need to: “this selector, this computed value” is a different kind of input than “the button looks slightly off.” A more precise dialect.

Unfortunately, Agentation only works with React projects. For a Svelte app, that bridge didn’t exist. Screenshots and approximations were what remained.

Give the model a screenshot and you gain something, but less than you’d expect. The image becomes a set of numerical embeddings carrying a rough sense of composition: light areas, dark areas, blocks, text zones. Not “this button is misaligned by 8 pixels from the grid.”

This asymmetry is structural. For code, the training data contains annotated files, code reviews, bug fix commits, test suites: a rich record of correct and incorrect states with rationale. For visual design, what exists is mostly static HTML and screenshots, with almost no “this layout was broken, here’s how it was improved” pairs.

The context problem

On smaller tasks, context window limitations stay in the background. At the scale this project required, they didn’t.

Context is what the model can “see” at once: the active conversation, the files in scope, the spec you’ve shared. Modern models have large windows, but large isn’t the same as reliable. Researchers have a name for it: context rot. The longer the session runs, the less reliable the model — not in any obvious or traceable way. Some models start making things up with increasing confidence, others stop committing to answers. It just begins to forget, quietly and unevenly.

The developer needs, if there’s no better word, to act as a kind of “RAM manager” for the model. Deciding what stays in context, what needs to be restated, when to start a fresh session. The effective window — the range where performance stays consistent — is typically less than half the declared maximum. The rest is territory where the model still responds, but less reliably than advertised.

This is where context rot becomes most costly: any task that requires holding many constraints simultaneously. Design implementation is the clearest example in this project, but complex debugging sessions told the same story. The difference is feedback. Code tells you when something is wrong — an error, a failing test. Design just drifts.

Looking forward

The constraints I’ve run into here are, I suspect, temporary ones.

I expect most of what I’ve described here to be solved, progressively, by the companies building these models. Context rot, miscalibrated confidence, the failure to step back rather than just iterate — these are documented limitations, not mysteries. I think the design gap will close too, as multimodal training improves and more tools appear to address exactly this problem. None of this is guaranteed to go fast. But the direction is clear, and so is what’s already possible.

For most of recorded history, tools were built by specialists for general audiences. You got the features the developer thought you needed, the workflow that fit most users rather than you. That’s changing. It’s now possible to build the exact tool you need — with only the features that serve your specific use case, at a cost that makes the experiment worth running even if the result is imperfect. Khi is a modest example of that. The principle scales.

Anton Sten frames the deeper point better than I can:

“Building something silly is how you practice that. Not because the tool matters, but because the act of building rewires how you think. You stop being a passive consumer of software and start being someone who shapes their own tools. That’s adaptability in action.”

Khi wasn’t silly, but the logic holds. The real output of a project like this isn’t the app. It’s the rewiring.

This is a note published on workingbruno.com

His conclusion is what sticks with me most: LLMs are simultaneously much smarter and much dumber than he expected - and the industry hasn’t yet realized even 10% of their current potential.

This is a link published on workingbruno.com

Update: Since this article was published, Claude Code version 2.0.70 introduced native auto-update functionality for plugin marketplaces. You can now enable per-marketplace automatic updates directly in Claude Code. This script remains useful for on-demand checks without consuming tokens or for users who prefer manual control over updates.

If you use Claude Code, you know the drill: run claude update, get the latest version and carry on to your sessions. Anthropic has solved the update problem for the CLI itself in a way that is clean and simple.

But here’s the thing, a significant part of Claude Code’s value is in the ecosystem: plugins, skills, MCP servers and custom agents.

The marketplace model has exploded with really useful repositories for all sorts of work (programming, scientific work, etc.) and dozens of community-maintained collections adding capabilities daily.

Yet, there’s no way to easily know when any of those plugins need updating. There’s not a notification or a dashboard showing “3 updates available.” You install plugins, they work, and you forget about them, never knowing that there’s a bug fix sitting in the repository, or a new feature you’re not using.

This isn’t a criticism of Anthropic. They’re building at speed, and the plugin system is still maturing. They’ll almost certainly add this functionality at some point, as others have requested it, but until then, the current path requires you to “proactively navigate through the Claude Code menu to trigger an update,” assuming you remember which plugins you have and which marketplaces they came from.

The script

As you know, Claude Code plugins live in a distributed world. Each marketplace is a Git repository, and each plugin you install is pinned to a specific commit SHA. Some plugins follow semantic versioning, others just track commits without version tags. When you install a plugin, Claude Code records the commit hash at that moment and never checks again.

You might be thinking about /plugin marketplace update. That command exists, but it only refreshes the marketplace catalogue (what’s available to install), not your installed plugins. Your plugins stay pinned to whatever commit they had when you installed them.

A slash command could work for checking updates, but it consumes tokens every time you run it. A hook that runs every session would add some latency to startup. I wanted something simple I could run on demand, outside of Claude Code entirely.

The script does what Claude Code doesn’t:

1. Fetch all marketplaces: Loop through ~/.claude/plugins/marketplaces/ and run git fetch on each
2. Read installed plugins: Parse ~/.claude/plugins/installed_plugins_v2.json to get plugin names, marketplaces, and installed commit SHAs
3. Compare commits: For each plugin, check if commits exist between your installed SHA and the marketplace’s current HEAD
4. Extract versions: Parse commit messages to find version numbers where available
5. Report: Show which plugins have updates, how many commits behind, and what version is available

The script handles edge cases: plugins without version tags show “X commits behind” instead of version numbers; it accommodates marketplaces using main vs master branches; and it flags plugins whose installed SHA no longer exists in the remote history (installed from a fork or rebased branch) instead of failing silently.

Here’s what the output looks like:

Checking Claude Code plugin updates...

Fetching latest from marketplaces...

⬆  superpowers@superpowers-marketplace
   3.5.1 → 3.6.2 (12 commits)
⬆  episodic-memory@superpowers-marketplace
   1.0.11 → 1.0.13 (4 commits)
⬆  mgrep@Mixedbread-Grep
   31 commits behind (local plugin, no version tracking)
?  some-plugin@some-marketplace
   Cannot compare (installed SHA not found in remote history)

Summary:
  2 plugin(s) with updates available
  1 local plugin(s) with possible updates
  7 plugin(s) up to date
  1 plugin(s) could not be compared

To update a plugin:
  claude plugin update <plugin-name>@<marketplace>

Runs in about one second. No Claude Code session needed. No tokens consumed.

Installation

The script requires jq for JSON parsing. If you don’t have it, it easy to install using one of your operating system’s popular package manager:

# macOS
brew install jq

# Ubuntu/Debian
sudo apt-get install jq

# Fedora
sudo dnf install jq

# Windows (via Chocolatey)
choco install jq

And here’s how to install the script itself:

# Create the scripts directory
mkdir -p ~/.claude/scripts

# Download the script
curl -o ~/.claude/scripts/check-plugin-updates.sh \
  https://gist.githubusercontent.com/BrunoMiguelMonteiro/9a60d4c792fb5b0c3f79c2e4fcb2c5e0/raw/check-plugin-updates.sh

# Make it executable
chmod +x ~/.claude/scripts/check-plugin-updates.sh

# Add an alias (zsh)
echo "alias claude-plugin-updates='~/.claude/scripts/check-plugin-updates.sh'" >> ~/.zshrc
source ~/.zshrc

# Or for bash
echo "alias claude-plugin-updates='~/.claude/scripts/check-plugin-updates.sh'" >> ~/.bashrc
source ~/.bashrc

Then just run claude-plugin-updates whenever you want to check. To update a plugin, use the command Claude Code already provides:

claude plugin update <plugin-name>@<marketplace>

Restart Claude Code after updating for changes to take effect.

Building it

There’s something funny about using Claude Code to build a simple tool that solves a Claude Code problem, but that’s exactly what happened. The script itself was developed iteratively in a Claude Code session — exploring the plugin file structure, testing git commands, refining the output format.

It’s a small example of what makes Claude Code useful: not just writing code, but understanding the environment it’s running in and solving real friction points in my workflow.

Get the script

The full script is available as a GitHub Gist:

Download check-plugin-updates.sh

If you improve it, by adding auto-update functionality, notifications or better version parsing, I’d love to see what you build. Fork the Gist or drop a comment.

This is a note published on workingbruno.com

This is a link published on workingbruno.com

It’s a strong, almost dystopian claim, but Kelly argues we’re already on that path. He uses his own experience as evidence: he stopped questioning calculators long ago, then stopped questioning Google, and now finds that most answers from current AIs are pretty reliable. His observation about younger people is even more revealing—they use AI in always-on mode, and more and more of their intangible life goes through the AI and no further. “The AIs are becoming the arbiters of truth,” he concludes.

This is one of those plausible scenarios worth keeping on your radar. Scary? Yes. Impossible? Unfortunately, no.

This is a link published on workingbruno.com

Here’s the thing: I’m not a programmer. I’m a UX designer who’s comfortable enough with code to be dangerous, but diving into Astro’s rendering pipeline and TypeScript configurations? That’s not my daily work. But RSS feeds are having a moment again, and I wanted my site’s feed to respect that. Full content. Proper formatting. Working images.

So I did what made sense: I turned to Claude Code as my co-pilot. If AI is genuinely good at anything, it’s navigating code that would otherwise intimidate someone like me. This isn’t a story about me heroically solving a complex technical problem alone—it’s about using the right tools to bridge the gap between what I understand (UX, content structure, web design) and what I needed to figure out (Astro’s Container API, TypeScript configurations, regex patterns for image paths).

Turns out that even with AI assistance, that last part is harder than it should be.

The disconnect

Astro’s official RSS integration handles basic markdown beautifully. You point it at your content collections, and it generates a perfectly functional feed. But here’s the thing: sometimes I write in MDX. Not because I enjoy complexity, but because I import images, use custom components, and occasionally need JSX when plain markdown won’t cut it.

Standard markdown parsers look at MDX and see nonsense. When they encounter something like <img src={bookCover.src} alt="Book cover" />, they either render it as literal text or strip it entirely. The imported image? Gone. The carefully optimized asset that Astro processed during build? Nowhere to be found.

I tried the obvious fixes first. Strip the imports, hope the references resolve somehow. Parse it as HTML. Use a different markdown library. Nothing worked quite right. The images either broke in development, failed in production, or simply never appeared.

What I actually needed

The problem runs deeper than just rendering. MDX files aren’t just markdown with imports — they’re JavaScript modules that need proper compilation. When you write import bookCover from '../../assets/image.webp', Astro transforms that into an optimized asset with a hashed filename. That transformation happens during build, which means any RSS generation that happens outside that pipeline sees unresolved references.

I needed something that could:

• Actually render MDX, not just parse markdown
• Handle imports properly
• Resolve image paths correctly in both development and production
• Maintain Astro’s image optimization

The official documentation wasn’t much help and most RSS tutorials assume markdown. The few that mention MDX either skip images entirely or suggest workarounds that feel fragile.

The Container API

Astro v4.9 introduced something called the Container API. It’s marked as experimental, which initially made me hesitate — I’ve been burned by experimental features before. But the core idea made sense: it allows rendering Astro components outside of .astro files.

That’s exactly what RSS generation is: rendering content outside the normal page context.

This is where having Claude Code as a thinking partner became invaluable. I could explain what I was trying to accomplish—“I need my MDX files to render properly in RSS feeds with all the images working”—and it could navigate the Astro documentation, suggest implementation approaches, and help me understand what each piece of code was actually doing. Not just “copy this code,” but “here’s why this approach works and here are the trade-offs.”

The key insight (which took some back-and-forth to understand) is that MDX files in Astro are essentially components. When you render them through the Container API, they go through the same processing pipeline as they would in a regular page. Imports get resolved. Images get optimized. JSX gets compiled.

The TypeScript hurdle

First obstacle: the Container API needs moduleResolution: "bundler" in your tsconfig.json. I had mine set to "node" like most tutorials recommend. One line change:

{
  "compilerOptions": {
    "moduleResolution": "bundler"
  }
}

Setting up the container

The expensive part of using the Container API is creating the container itself. You don’t want to do this for every single post. Create it once, reuse it everywhere:

import { experimental_AstroContainer as AstroContainer } from 'astro/container';
import { getContainerRenderer as getMDXRenderer } from '@astrojs/mdx';
import { loadRenderers } from 'astro:container';

let mdxContainer = null;

async function getMdxContainer() {
  if (!mdxContainer) {
    const renderers = await loadRenderers([getMDXRenderer()]);
    mdxContainer = await AstroContainer.create({ renderers });
  }
  return mdxContainer;
}

Smart content processing

The actual rendering logic needs to distinguish between regular markdown (which can use a fast parser) and MDX (which needs the Container API):

async function processContent(entry, siteUrl) {
  const isMdxFile = entry.filePath?.endsWith('.mdx') ?? false;

  if (isMdxFile) {
    const { Content } = await render(entry);
    const container = await getMdxContainer();
    let htmlContent = await container.renderToString(Content);

    // Handle development image paths
    if (htmlContent.includes('/@fs/')) {
      htmlContent = htmlContent.replace(
        /\/@fs\/[^"'\s]+/g,
        (match) => {
          const urlMatch = match.match(/\/([^/?]+\.(webp|jpg|jpeg|png|gif))(\?[^"'\s]*)?/);
          if (urlMatch) {
            const params = urlMatch[3] || '';
            return `${siteUrl.origin}/_image?href=${encodeURIComponent(match)}${params ? '&' + params.slice(1) : ''}`;
          }
          return match;
        }
      );
    }

    return htmlContent;
  }
  
  // Regular markdown - use the fast path
  let content = entry.body?.replace(/^import.*$/gm, '') || '';
  return parser.render(content);
}

That regex for image paths? That’s handling the difference between development (where Astro serves images through /@fs/) and production (where everything gets hashed into /_astro/). In development, we convert those virtual filesystem paths to proper image endpoints. In production, Astro’s build process handles it automatically.

This was one of those moments where Claude Code really proved its worth. I understood the concept — paths need to work differently in dev vs production — but writing a regex pattern that correctly matches and transforms those paths? Not something I do regularly. Having an AI that could generate the pattern, explain what each part does, and then help me test it with different edge cases made this tractable instead of frustrating.

The parts that still feel rough

The Container API works, but it’s not perfect. Adding it to my build increased generation time by maybe 8-10 seconds for about 50 posts. Not terrible, but noticeable. And because the API is experimental, there’s always that nagging concern about future breaking changes.

I also had to be more careful about error handling. If MDX rendering fails for any reason — a bad import, a syntax error — the entire RSS generation could break. My solution was to catch errors and fall back to basic markdown parsing:

try {
  // Try MDX rendering
  const { Content } = await render(entry);
  const container = await getMdxContainer();
  htmlContent = await container.renderToString(Content);
} catch (mdxError) {
  console.warn('MDX rendering failed for', entry.id);
  // Fall back to markdown parser
  let content = entry.body?.replace(/^import.*$/gm, '') || '';
  htmlContent = parser.render(content);
}

Not elegant, but pragmatic. Better to have a feed with basic markdown than no feed at all.

What actually changed

My RSS feed now includes the full content of every post, images and all. Readers using apps like NetNewsWire or Reeder see the complete article without needing to click through to the website. The images aren’t broken references—they’re actual, optimized images that load properly.

More importantly, I’m not fighting the tool anymore. The solution fits within Astro’s architecture instead of working around it. Regular markdown posts still use the fast parser. MDX posts get the full rendering pipeline. The system detects the file type and handles it appropriately.

If you’re dealing with this

The complete code is longer than I want to paste here, but the pieces I’ve shown are the essential parts. The rest is mostly constructing XML, handling dates, that sort of thing.

A few things I learned:

• The Container API is stable enough for production despite the “experimental” label. It’s been working reliably since I got it running.
• Build time impact is real but manageable. Consider caching the RSS feed at the CDN level if you’re worried about performance.
• Test your feed in actual RSS readers, not just by looking at the XML. Some readers handle images differently.
• Keep your MDX simple in content files. The more complex your components, the more likely you are to hit edge cases.
• If you’re not a programmer, don’t let that stop you. Tools like Claude Code can bridge that gap, helping you understand the code you’re implementing rather than just blindly copying it.

The Astro docs have more details on the Container API if you want to dig deeper. The implementation isn’t as complicated as it first appears, but it does require understanding how Astro processes MDX files.

I’m curious if anyone else has tackled this problem differently. RSS seems like it should be straightforward, but the reality is messier when you start combining modern tooling with a format designed decades ago. That tension between old standards and new workflows creates these odd gaps where the obvious solution doesn’t quite exist yet.

What’s interesting to me, as someone who isn’t a programmer by trade, is how AI tools like Claude Code are changing what’s possible for designers and other non-developers to accomplish. Five years ago, I would have lost an absurd number of hours trying to figure this out or simply given up. Today, I could work through it with an AI assistant that understood both my goal and the technical implementation needed to get there. That feels like a meaningful shift in what’s achievable when you’re willing to learn but don’t have a CS degree.

For now, though, my feeds work. Images show up. MDX renders properly. That’s good enough.

This is a note published on workingbruno.com

“We are growing extremely powerful systems that we do not fully understand.”⁠

Jack Clark argues for a blend of technological optimism and appropriate fear: scaling keeps unlocking unexpected capabilities (including signs of situational awareness), yet alignment remains hard and success is not guaranteed. He calls for a transparency regime built before the inevitable crisis, grounded in listening to public anxieties (jobs, mental health, misalignment) and publishing real data. The post threads concrete risks—from model sycophancy to AI‑enabled biosecurity bypasses—while insisting that acknowledging the “creature” we’ve built is the only way to tame it.

This is a link published on workingbruno.com

This is a link published on workingbruno.com

Over a 12-month period, while delivering higher-quality responses, the median energy consumption and carbon footprint per Gemini Apps text prompt decreased by factors of 33x and 44x, respectively. Based on our recent analysis, we found that our work on efficiency is proving effective and the energy consumed per median prompt is equivalent to watching television for less than nine seconds.

Google seems to be taking a transparent approach to measuring and improving the environmental footprint of its AI models, sharing detailed methodology and impressive efficiency gains. Their commitment to data center optimization and clean energy scaling is a strong signal for the future of sustainable tech. It’s encouraging to see major players publish real numbers and push for accountability as AI adoption accelerates.

This is a link published on workingbruno.com

This is a link published on workingbruno.com

This is a link published on workingbruno.com

Anticipatory obedience is a political tragedy. Perhaps rulers did not initially know that citizens were willing to compromise this value or that principle. Perhaps a new regime did not at first have the direct means of influencing citizens one way or another.

This is a very important message on which we should reflect deeply.

This is a link published on workingbruno.com

We’re all familiar with the pattern: discover a new tool, get excited about its possibilities, integrate it into our workflow, and then… start looking for something better. Just when you think you’ve found the perfect note-taking app or task manager, someone shares their setup with a compelling alternative.

What drives this perpetual search? Perhaps it’s not just about the tools themselves, but our secret hope that the right combination of software will unlock unprecedented productivity. We’ve all been there – watching those “My Productivity Setup” videos, convinced that this new system will finally be the one.

It’s fascinating how certain tools become almost viral in professional circles. Notion, Figma, VS Code – these aren’t just tools anymore; they’re expected competencies which is seems to me plain wrong. Being proficient in Figma, or Sketch for that matter, doesn’t make you a better designer.

Here’s my current toolkit, though I’m sure it will look different in a few months:

AI tools

• Claude: Desktop client for Anthropic’s LLM. While capable, it currently lacks feature parity with ChatGPT’s interface.
• Goose: Promising on-machine AI agent in early development. Shows significant potential despite its nascent state.
• Sanctum: Privacy-focused, open-source LLM interface. Enables local model running with complete data control.
• Windsurf AI: Collaborative coding environment with integrated AI capabilities. Truly impressive.

Browsers and web tools

• Arc: Innovative browser with a minimalist approach. Development has paused as The Browser Company shifts focus.
• Firefox: Reliable development browser featuring industry-leading inspection tools.
• Raindrop.io: Comprehensive bookmarks manager with solid cross-platform support and browser integration.
• Netnewswire: Time-tested, open-source RSS reader. Offers robust functionality without unnecessary complexity. Thank you, Brent Simmons.

Design

• Adobe Creative Suite: Adobe suite of tools needs no introduction. I use it less and less these days.
• Color Slurp: Straightforward color picker that delivers exactly what it promises.
• Eagle: Efficient asset management system. I use it mainly for design inspiration collections.
• Figma: One of the tools — besides the browser, Obsidian and mail — where I spent most of my working hours.

Development

• OutSystems Service Studio: Low-code development environment used at FCT for rapid application deployment.
• Tower: Definitive Git client for macOS. Sets the standard for version control interfaces.
• VS Code: Versatile code editor with built-in Copilot integration. Maintains the perfect balance between features and performance.
• Warp: Modern terminal built in Rust. Enhances command-line productivity with AI-assisted features. Replaced the trusty iTerm in my toolkit.

Communication, media and entertainment

• Calibre: The most comprehensive eBook management tool for organizing digital books that I know. Indispensable companion to my Kobo Libra 2.
• Ivory: Refined Mastodon client with Tapbots’ signature polish.
• Microsoft Teams: Corporate collaboration platform used within FCT.
• Spotify: You know Spotify, right? No, seriously. More than once, I’ve tried to change but I have a family plan and… you know.
• WhatsApp: Because everybody uses it and I’m still quicker on a physical keyboard.
• Zoom: Standard video conferencing solution.

Productivity

• Apple Notes: Simple yet powerful note-taking app for capturing ideas across Apple devices.
• Tick Tick: Current task management choice after evaluating various alternatives including Omnifocus and Things.
• Obsidian: Markdown-based knowledge management system built on local plain text files.
• Notion: All-in-one productivity tool that combines note-taking, task management, and database organization in a highly customizable workspace. I use it mainly for small databases.
• Office Suite: Still use Word and Excel at my work.

Utilities

• Raycast: Powerful launcher and utility suite. Handles everything from quick calculations to snippet management.
• Moutain Duck: Efficient cloud storage mounter for macOS Finder. Simple yet effective Google Drive integration.
• Transmit: Still my favorite sFTP visual client for mac.
• Hazel: Automated file organization and management for macOS. It keeps my mac tidy!
• Dropbox: Legacy cloud storage choice. Continued use driven by deep system integration and inertia.
• Klokki: Lightweight time-tracking solution. Particularly valuable for freelance work management.

We’re at a unique moment in software history. AI isn’t just another feature – it’s fundamentally changing how we interact with our tools. Applications like Windsurf AI and Goose aren’t just doing tasks for us; they’re working alongside us, learning our preferences, and adapting to our needs. This shift raises interesting questions. When your IDE can generate code or your writing assistant can draft entire documents, what does that mean for traditional productivity metrics? Are we moving from tools as implements to tools as collaborators?

This is a note published on workingbruno.com

Embracing automation for tactical efforts while intentionally cultivating strategic thinking ensures that designers maintain their thought-leader and decision-maker roles, while no longer acting as mere executors of predefined processes.

Great article from Pablo Fernandéz Vallejo from Nielsen Norman Group on how to prepare for AI in design. It speaks on task automation and augmentation, organizational change, the importance of strategic thinking and more. It’s a great read for anyone looking to stay ahead in the design industry.

This is a link published on workingbruno.com

Writing can save you time. Publishing ideas on paper is how you create intellectual capital because writing is how you make your ideas permanent. Words on paper are the closest thing we have to time travel. Once you write something down, you can remix and reuse the ideas for the rest of your life.

Writing is research and development for your brain. The words you publish now are the seeds of your future projects. Every time you write down an idea, you add a Lego block to your intellectual arsenal. The more Legos you have, the more things you can build. Writing is the same. The more you write now, the more you can create in the future. As the number of artifacts you create increase linearly, the number of connections you make between them increase exponentially.

I was poking around Paul de Raaij’s digital garden when I came across the phrase “Writing things down helps build intellectual capital”, and luckily Paul linked to this wonderful article by David Perell. It such a strong and truthful idea.

This is a link published on workingbruno.com

Understanding the AI transformation

You’ve probably heard that AI is different from previous waves of automation. And it really is - research from MIT and Boston University shows it’s primarily impacting highly educated, well-paid professionals in urban industries like medicine, finance, and tech (Acemoglu & Restrepo, 2019). But here’s the thing - it’s not just about replacing tasks. It’s about augmenting what we can do.

The power of personal examples

Let me share how this plays out in my daily work. As a content creator and designer, I’ve recently found myself relying more and more on AI tools. They’ve become like quiet but incredibly capable assistants, handling tasks that used to eat up hours of my time. Here are a couple of examples that really show this evolution in action.

When AI becomes your coding buddy

While working on this website, I faced a common challenge for non-developers: getting stuck on technical implementation details. Though familiar with frontend technologies like HTML, CSS, and JavaScript, I’m not a full-time developer. AstroJS, a modern web framework that optimizes content-focused websites, presented a learning curve that could have been daunting.

That’s when I discovered that Claude and specially Windsurf could be my AI coding companions. Researchers call this kind of help “cognitive process automation” (CPA) – using AI to handle tasks that require judgment and decision-making (Richardson, 2020) — but I just call it a game-changer. Here’s how these AI assistants enhanced my workflow:

• Code scaffolding and boilerplate generation
• Real-time debugging suggestions and error analysis
• Documentation queries and synthesis
• Component optimization and performance recommendations
• Quick prototyping of new features

The impact was immediate: tasks that previously took hours now take minutes, and the quality of output has improved consistently while it helps me to learn how AstroJS works.

From problem to solution: AI-powered tool creation

The true power of AI assistance became even more apparent when facing a common content management challenge. Like many content creators, I was constantly fighting with Word documents and WordPress - you know that frustrating process of copying content only to find it loaded with unwanted styling markup? Yeah, that used to drive me crazy.

Instead of accepting this as a necessary evil, I took a different approach which wasn’t possible about a year ago:

• Collaborated with AI to design a custom React utility app
• Developed the solution in about 5 minutes
• Created a reusable tool that benefits both me and my team

It might sound simple, but that’s exactly the point. Similar examples are popping up everywhere - check out Simon Willison’s explorations with Claude artifacts if if you want to see more creative uses of AI tools.

The in-between era

We’re living in a fascinating moment of technological transition. While AI tools have become powerful enough to transform how we work, we’re still learning to dance with these new partners. It’s like learning a new instrument – we know it can make beautiful music, but we’re still mastering how to play it effectively.

The integration of AI tools into knowledge work isn’t following a clear, predefined path. Unlike traditional software where features and use cases are well-defined, AI tools reveal their potential through experimentation and creative application. What begins as a simple code completion tool might evolve into a sophisticated programming partner that helps architect solutions and identify potential issues before they arise.

The learning curve presents another interesting dimension. It’s not just about learning to use the tools – it’s about learning to think alongside them. Effective prompting, for example, is more art than science. It requires understanding both the capabilities and limitations of AI systems, while maintaining a clear vision of the desired outcome. This skill, which Sharon Richardson on her paper “Cognitive automation: A new era of knowledge work?” came to call “AI-augmented problem solving” takes time to develop but proves invaluable once mastered.

Integration into daily work brings its own challenges and surprises. Remember that content cleaning tool I mentioned? That wasn’t just about solving a problem - it changed how I think about solving problems entirely. Instead of looking for ready-made solutions, I’m now thinking about how to create tools that make tedious tasks disappear.

The benefits are real - we’re seeing better output, more consistency, and tackling projects that would have seemed impractical before. But let’s be honest: these tools aren’t magic. They can be unpredictable when pushed too far, and there’s definitely no autopilot mode. You need to stay engaged, guiding and supervising the AI’s work.

What really excites me is how this is changing our understanding of productivity. We’re moving beyond simple metrics like tasks completed or lines of code written. Instead, we’re thinking about problem-solving effectiveness and creative output. It’s a whole new way of measuring what matters in knowledge work.

Looking forward

So where does all this leave us? If you’re thinking about incorporating AI tools into your work, here’s what I’ve learned:

• Start small - find those annoying repetitive tasks that eat up your time
• Experiment with different tools to see what fits your workflow
• Look for opportunities to create lasting solutions, not just quick fixess
• Keep notes on what works and what doesn't
• Gradually expand as you and your team get comfortable

The tools are evolving rapidly - getting better at understanding code, processing language, and working within our context. But more importantly, we’re getting better at working with them.

The biggest challenge isn’t technical - it’s rather conceptual, it’s about changing how we think about these tools. They’re not just fancy automation; they’re collaborative partners in the creative process. This means developing new skills: learning to direct AI effectively, validate its output, and integrate it into our broader problem-solving approach.

The end of intellectual Fordism doesn’t obviously mean the end of knowledge work, but rather reflects my wish to eliminate the tedious tasks inherent in intellectual work. It marks the beginning of what researchers call a “new era of knowledge work” where AI cognitive process automation enhances rather than replaces human capabilities. The challenge now is learning to dance with these new AI partners effectively - and I, for one, am excited to keep learning new steps.

This is a note published on workingbruno.com

OpenAI’s new model, called GPT-4b micro, was trained to suggest ways to re-engineer the protein factors to increase their function. According to OpenAI, researchers used the model’s suggestions to change two of the Yamanaka factors to be more than 50 times as effective—at least according to some preliminary measures.

Seems that OpenAI is diversofying its AI models to cover more fields of science… and business. They’re doing this research by investing in Retro Bioscience, a company that focuses on longevity science. The shaddy part is that Sam Altman, CEO of OpenAI, is also a co-founder of Retro Bioscience. Nevertheless, it’s a great example of how AI can be used to solve real-world problems.

This is a link published on workingbruno.com

Archaeologists have discovered a sumptuous private bathhouse - potentially the largest ever found there - complete with hot, warm and cold rooms, exquisite artwork, and a huge plunge pool.

I’ve been to Pompeii twice and I’ve always been amazed and surprised. In some areas of the city, it’s as if you’ve traveled back in time to 79AD, a few days before the eruption of Mount Vesuvius. It’s a unique, dramatic and breathtaking place where discoveries are made every day.

This is a link published on workingbruno.com

This is a link published on workingbruno.com

“This in my opinion is what any product company should strive for. Make useful things for people. Make them high-quality and durable. Make them so that if and when a thing wear down, people will want to replace it with the exact same thing. Repeat the cycle.” — Brad Frost

Producing durable products is a necessity. I think it’s unrealistic to think that we can solve the climate change crisis without changing the paradigm of industrial production.

This is a link published on workingbruno.com

Lynch then embarked on another noirish project, the opaque and surreal murder-mystery Twin Peaks that – unusually for notable film directors of the period – was envisioned as a TV series;Lynch developed it with former Hill Street Blues writer Mark Frost. A mix of small town comedy, police procedural and surreal dreamworld, and described as “the most hauntingly original work ever done for American TV” — Andrew Pulver

I still believe that the Twin Peaks series was something unique in the history of television. In another article in The Guardian, journalist Peter Bradshaw called Lynch “the great American surrealist who made experimentalism mainstream”. I couldn’t have said it better myself.

This is a link published on workingbruno.com

But what did my radar pick up last week?

• Steph Ango published an improved version of his Flexoki colour scheme. In his words, this colour scheme is: ‘designed for reading and writing on digital screens. It is inspired by analog inks and warm shades of paper.’
• Polymath Heydon Pickering has written a text on web accessibility principles that everyone who produces web content and cares about accessibility should read.
• Colossal is one of the best little boxes of surprises. ‘The World in an Acorn’ is perhaps one of the most beautiful and original constructions I’ve ever seen, and I was keen to visit. It was designed by Linfeng Zhou and ‘lives’ in a forest in Rouen, France.
• My mind works better with some structure and organisation. So does my work as a designer. Sometimes it takes time to arrive at an organisational structure that is really flexible and appropriate. Dan Mall wrote a nice article entitled ‘The File Folder Structure Every Designer Needs’. I don’t agree with all the options, but it’s an excellent basis for work.

This is a note published on workingbruno.com

minha avó dizia
quando matava
uma pulga
já ganhei o dia
eu quando escrevo
um poema bom
digo como a minha avó
já ganhei o dia

Não gosto de matar

This is a note published on workingbruno.com

I didn’t stop working, but I avoided being around computers whenever possible. I’ve tried to focus a bit more on family life and doing some things I’ve been meaning to do for a while, like getting my motorcycle licence.

I’ve also taken a break from reading, which means my books and my Kobo have been gathering dust on the shelf. I have to say that, contrary to what you might expect, it wasn’t complicated - I think I really needed this break. There’s a certain empowerment in freeing yourself from the idea that all your time has to be productive. It’s not. I was happy to be able to do it and not feel embarrassed about it.

I’ve slowly started to consume some digital content again, but I want to use the summer to spend more time outdoors, walking with the family. So I’ll be dropping in sporadically. I wish you all a wonderful summer. Enjoy it!

This is a note published on workingbruno.com

Here’s some of the content I’ve found interesting over the past two weeks:

• Anne-Laure Le Cunff has a very interesting video on the differences between note taking and note making;
• Do you want to run an LLM on your computer? There’s an app for that, it’s called LM Studio and it’s available for Linux, Windows and Mac OS;
• Stephen Wolfram has written a very interesting long (technical) article on how ChatGPT works for those who like to get to the bottom of things;
• The use of LIDAR technology by archaeologists has made it possible to discover in the Amazon rainforest a gigantic complex of cities that existed 2000 years ago. A kind of South American Rome where a highly stratified and specialzed society lived. Fascinating!

This is a note published on workingbruno.com

• Ben Thompson analysis on OpenAI latest events in the article “OpenAI’s Misalignment and Microsoft’s Gain”
• If you want to understand why all the buzz around OpenAI, read"AI is about to completely change how you use computers" by Bill Gates
• Snugug’s excellent “Strategy, Team Culture and Organisational Change” is a must read this week
• Use cases are an important part of UX design. Mads Soegaard wrote a long yet very complete guide about this topic.
• Rasmus Anderson released a new major version (4.0) of Inter typeface after two years of work. The result is awesome.

See you next week, hopefully. 😅

This is a note published on workingbruno.com

• Veritasium’s latest video:How One Line in the Oldest Math Text Hinted at Hidden Universes
• Untools is a “collection of thinking tools and frameworks to help you solve problems, make decisions and understand systems”
• Started a test-drive to Warp, a rust-based terminal that’s very fast and has a really nice feature set
• Color palette tools are never too much! This one is rather peculiar and it’s called Poline and described by it’s creator as “an enigmatic color palette generator, that harnesses the mystical witchcraft of polar coordinates”

This is a note published on workingbruno.com

Such is the case with James Payne’s recently launched YouTube channel, titled “Great Books Explained”. This channel follows in the footsteps of the notorious “Great Art Explained” known for its approachable presentations of notable paintings and sculptures, delivered in a language free from the jargon of the art world.

“Great Books Explained” shares a common objective with its artistic counterpart, as James Payne articulates: “Fifteen minutes, clear and concise language, devoid of outlandish theories—just a genuine passion for books and the joy of reading.”

The inaugural video, delving into James Joyce’s literary masterpiece, “Ulysses,” has recently been released, promising a thoughtful exploration of this iconic work.

This is a note published on workingbruno.com

The concept draws inspiration from the idea of a garden, where ideas can be planted, nurtured, and allowed to grow in a more natural and interconnected way.

It’s also somewhat related to the idea of personal knowledge manager and second brain where digital tools are used to capture, organize and make sense of information in a way that makes more sense to a person’s mental processes. In practice, individuals often integrate these concepts, using a digital garden as a way to share and explore ideas with a broader audience, while their second brain serves as a private repository for personal knowledge and information management. Both concepts share the common goal of leveraging digital tools to enhance cognitive abilities, creativity, and knowledge retention.

Some of the best-known examples of “digital gardens” that I find interesting:

• Andy Matuschak
• Chris Biscarddi
• Maggie Appleton
• Matthem Strom
• Joel Hooks

This is a concept that I’m interested in exploring and which greatly enhances the scope of a personal website.

This is a note published on workingbruno.com

So here it goes:

• Casey Netwon’s article on Why note-taking apps don’t make us smarter
• Is always a pleasure to read Mandy Brown’s articles. This one is called “Late Pandemic”.
• HBO is debuting a documentary about the peculiar Michael Chow — it’s called “aka Mr.Chow”. Watch the trailer and I’m sure you’ll want to see it when it debuts.
• Why Israel was Attacked is the latest CapianReport’s video on the most recent and deadly Hamas strike in Israel
• Hocus:Focus is a funny accessibility horror game

This is a note published on workingbruno.com