This is an expanded version of an internal note I wrote last week, on how we get super powers through prototypes, and what we must give in return.

Sometimes we want to break the rules. Maybe we want to try something quickly, or explore an idea without being constrained by existing systems. Whether we build something by hand, or vibe code it, we give ourselves permission by labelling it a prototype.

By giving it the prototype label, it gives us super powers where we can:

Get customer feedback, and iterate rapidly.

Experiment freely, without fear of failure.

Challenge existing assumptions and norms.

Share ideas with colleagues, and understand implementation approaches.

In return, we must accept some trade-offs:

Prototypes are not production-ready, and won't meet our usual standards for quality, security, or reliability.

Prototypes are temporary, and are designed to be discarded.

Prototypes are rarely documented or maintained.

Before a line of code is vibed or a package installed, we know the outcome: our prototype will be thrown in the bin. The point is to learn fast, move quickly, not to build for real customers.

Be explicit about its purpose, scope, and limitations.

After throwing them away, we'll still scavenge useful parts from them. We can salvage snippets of code that helps us with the next prototype, functions or classes that – with a few tests – are good to ship to production, or a design pattern that saves us hours in our next feature.

Now anyone can build prototypes with AI tools like Claude Code, replit, and Cursor, don't mistake prototype for production, and enjoy the super powers.

Prototypes vs. products – "build to learn" vs. "build to earn"

Quick thoughts: How prototypes give us super powers and the trade-offs we must accept

This is an expanded version of an internal note I wrote last week, on how we get super powers through...

Photo log #001 – bcn

Over the past year I built a generative AI tool that hooked me on high-convenience, ultra-processed article summaries. It made it easier to consume ideas, but didn't help me think more intentionally or more critically. Now, I'm rebuilding it as a high-friction tool to counter AI-induced cognitive atrophy. Only when I built a connector giving Claude Desktop access to my tool did I discover I'd been approaching it all wrong.

18 months ago I was interested in using AI as a second brain. I tried early versions of mem and Reflect, but found they didn't really work for me. So, I built a simple, AI-supported reading app to help me capture and cross-reference content from across the web.

For 12 months, the app served me well, generating condensed overviews, extracting highlights and themes, and connecting disparate content, as well as capturing my own thoughts.

After a while, I struggled to get value from my captured content. I was using the app as a crutch rather than a growth tool. I was relying on the automated summaries more than I had intended, and having to hunt down content to read again in order to recall insights. Text and conversational search didn't really deliver the depth of understanding I had hoped for. I wanted to internalise the content I saved so I could build the knowledge myself. Instead, the AI was reading it for me and spitting out a middle-of-the-road overview, and I wasn't getting much out of it. Since launch I've written notes against fewer than 3% of captures. I knew I hadn't hit the mark, yet.

Building an MCP server for the app led me to the realisation that I was misusing AI. Giving Claude access to what I'd saved meant the content was able to break free from the bounds of my app. When working on a write up of a new product feature, Claude connected it back to the MAYA principle, from an article I had captured many months prior. I hadn't thought about it myself, but Claude, using my app's MCP server, drew the connection I'd missed, contextualising the content, not just summarising it.

A growing body of research shows that heavy use of LLMs can dull reasoning and memory through "cognitive offloading", the outsourcing of thinking to digital tools. Experts fare better than novices, but the evidence shows that less cognitive struggle leads to diminished opportunity for mental engagement and critical analysis.

In my own experience I've felt the dopamine hit of getting an instant article summary, and a quick answer to make me sound smart. My app today feels like ultra-processed food, it can be satisfying in the moment, but hollow over time. The research made me consider what a tool that actively demanded cognitive attention might look like.

So I'm pivoting: from a capture-and-summarise reader tool, to one designed to make me smarter. I want an app that acts as an antidote to cognitive atrophy, one that is actively supporting me, not subtly undermining me.

What might that look like in a product? My top priority is to avoid over-reliance by limiting access to AI-generated insights until I can demonstrate understanding and critical thought around a piece of content.

To achieve this, I'm starting with an experiment that prioritises high-friction "productive struggle" over instant gratification, requiring me to write a short reflection of the content before it gets stored in my app's long-term memory (only long-term memory content can be surfaced in the future). Writing is a powerful tool to help us think, and there is evidence that intentionally adding latency may "scaffold deeper cognitive processing". Using writing as a gate means if I want to find and use this content later, I need to engage with it now, experimenting with how AI agents can assess that writing using a panel of tailored experts.

There's an inherent tension here in using AI to reduce my reliance on AI. The writing requirement forces cognitive engagement. I'd rather an AI push me to think deeper than do the thinking for me.

How will I know it works? In the experiment I will be monitoring:

Capture rate – does friction discourage me from capturing content?

Recall – do I retain and apply more of what I read?

If you have thoughts or ideas for me, or on the wider domain I'd love to hear them. If you enjoyed this post, please consider sharing it on Hacker News.

P.S. I am not making my app generally available right now, it is designed for me (Selfish Software as Edmar Ferreira calls it), but if it's something you do think you'd use, please let me know!

Designing with friction: A cure for AI-induced cognitive atrophy

Over the past year I built a generative AI tool that hooked me on high-convenience, ultra-processed article summaries. It made...

APIs are (sort of) over; and the new era of work

I’ve been using Slack for a long time. A really long time – seven years in fact. Since then Slack has evolved into the super-powered chat app we all know today.

In that time I've run a handful of teams and have helped each of them to make the most of Slack, turning those “I don’t have time to check Slack”-ers into “I don’t know how I could work without Slack”-ers. In each case it came down to being clearer and more transparent about where messages should go, and where you can find them later.

Here are my tips to help you do the same for your team or organisation.

There’s an phrase I often think about that embodies how I think about Slack channels:

A place for everything and everything in its place.

In essence, in the context of Slack, meaning there should be an obvious home for each message, file or document you share, and it should be easy to find them later. Both creation and discovery should be simple for everyone in your organisation.

In order for this to work, it’s fundamental that the right channels exist, their purposes are clear, they are renamed when their working context changes, archived when no longer needed, and unarchived (not recreated!) if you ever need them again.

Avoid mysterious channel names like #project-gravy-train or #new-experience-swt. Think about someone new joining your organisation. Channel names should be self explanatory, and avoid acronyms unless absolutely necessary. Better examples would be #iphone-app-rebuild or #smart-water-technology-user-testing. This makes it easier for your colleagues to discover channels (through the channel list, or using the cmd/ctrl + K shortcut) and more obvious from the name what each channel's purpose is. Note: Slack increased the channel name character limit in 2019, so don’t be afraid of longer channel names!

Naming related channels with a consistent prefix can help discovery too. For example, your finance team might have:

#finance-support: for colleagues who need support on finance issues

#finance-operations: for the finance team to use internally for their own day-to-day operations

#finance-workshop-july-21: a temporary channel for the finance and people teams to organise their upcoming three day workshop

When a project or team’s remit changes, consider renaming your channels to accommodate. For example, if you previously had a team responsible for the customer subscription journey (#subscriptions-team), and now they also look after profile management, you might rename that channel to #subscriptions-and-profiles-team. Something to consider: If you have a full team reorganisation, decide if you want to rename old channels (in order to keep the channel history in place) or archive them and start fresh. Remember, you can always get back to archived channels and their content using search, the channel list, or the cmd/ctrl + K shortcut.

Note: by default, not all Slack workspaces allow channel renaming without admin permissions. Ask your Slack owners about enabling this if it isn't already.

With all these channels, I wouldn’t blame you for thinking “how are me and my team keep on top of all this?!”. Below the user groups and welcome messages sections have some extra suggestions for helping with this.

In most teams it’s natural to have leavers and joiners over the course of their life. Slack can help making that process as smooth as possible for new and existing members of the team, as well as for your stakeholders, through user groups.

You might have found yourself in this situation, stakeholders and senior members of staff know one or two of the highest profile members of a given team. When there’s an issue or the stakeholder has a question or feature request, they send a direct message to those people, entirely skipping the team channel, or they do use the channel but they just tag a single person. This can be frustrating for visibility or alleviating the pressures created by single points of communication. 

This is where user groups come in. You can create teams of Slack users with their very own @ handle. For example, the team that work on your payroll might be the @payroll-team. This means you can easily reach the Payroll team, without having to know who is in the team, or who is on holiday.

But user groups have another powerful feature, default channels. With these, you can set a user group to have a set of channels which every member of the group is automatically added to. Using the finance example from earlier, having a @finance-team user group with a default channel of #finance-operations makes onboarding new team members to Slack a breeze. If anyone wants to see who makes up the current Finance team, they can check the team membership and their profiles too – easy!

If you want to give it a go, you can follow this Slack guide for setting up a user group.

Note: the creation and management of user groups may be disabled in your Slack workspace. Speak to your Slack admins to get this enabled.

The final piece of the channel discovery puzzle is welcome messages. These are done with a straightforward implementation of Slack’s Workflow feature, that allows you to trigger behaviours from events in your workspace. Here we are looking at sending a message to new members of a given channel, helping to point them in the right direction and discover any additional channels they might be interested in. When paired with user groups and default channels, this can create a powerful workflow:

Invite your colleague to Slack ➡️ Add them to the right user groups ➡️ The user will automatically join the relevant channels through default channels ➡️ By joining certain channels, the user is sent a relevant welcome message 👋

With a custom welcome message you can introduce:

Active projects and other channels they might want to join (you might have a #all-pets channel, for example 🐱)

Any relevant sub-teams or user groups and their @ handles

Regular or recurring events and calendar invite links (e.g. daily stand up or monthly team huddles)

Links to useful documents like onboarding or the company strategy video

You can set up the workflow by yourself using the ⚡️icon next to the message box in the channel you want to welcome people to and searching "open workflow builder". From there, create a new workflow, giving it a name and using a "New channel member" trigger. From there, select the channel, click "Next", then select "Add Step" and "Send a message". Use the "Person who joined the channel" magic variable, and write your message.

I have also created a template workflow you can download here (call the file welcome_message.slackworkflow) and import directly into Workflow Builder using the "Import" button. For more on Workflow Builder, check out this guide from Slack.

A bonus feature worthy of a mention is email-to-channel integrations. Even the most well-intentioned teams may still find they have regular company updates or integrations with third party services that only work through email. While you could set up a shared inbox, or auto forwarder to each of your team members, it might be easier for you to get those emails sent directly into a Slack channel.

To set up an email address for your channel take a look at this guide from Slack.

Note: to keep alerts and automated messages to a minimum and out of the critical path of your colleague’s discussions, you might want to set up an alerts channel, for example: #finance-alerts.

So there you have it, how to make Slack work harder for you and your team through clearer channel naming, user groups, and Slack Workflows to create automated welcome messages.

Do you have tips for helping empower your teams to work more openly and collaboratively in Slack? Tweet me your suggestions on @chrishutchinson, I’d love to hear them!

Chris is a Lead Engineer at Made Tech, improving digital services for UK citizens through better technology delivery. He also co-built and maintains The Operator, a Slack app for unleashing the knowledge in your private channels, improving discovery through knock-to-join private channels. He also maintains Slack Testing Library, an open source library for quickly writing powerful integration tests for your custom Slack apps.

How to make Slack work harder for you and your team

Channels, user groups and welcome messages

A couple of weeks ago I moved into a new role at Made Tech, looking across a wider range of products and projects at Hackney Council. This has inevitably come with an influx of new people to meet and new things to get my head around. I picked up a Remarkable 2, on the advice of my predecessor (really I've wanted one for months, they just helped tip me over the edge 😅), to help me structure my notes, maintain a better record of the discussions I'm having, and to keep myself honest about completing the things I've promised to do. So far I'm firmly in the position of taking lots of notes but I'm still not at a place where I'm able to digest them and act on them. Improving this is a goal of mine for the next few weeks.

I got a direct message on Twitter last week about my Train Departure Screen Raspberry Pi project; the message was asking for help in understanding the code I'd written to power the screen. I had intended to reply with a brief overview of how the code works, the main entry points and primary processes / methods, but I felt it might be more useful if I pulled that out of a direct message and instead published a full write up for others to enjoy and learn from too.

I have started doing this and hope to publish something soon, although I was stopped in my tracks by a totally coincidental discussion that happened at work about explaining the behaviour of a system or application. The discussion largely centred around the difference between explaining the codebase (aka. the codebase is the application) versus explaining the abstract capabilities of the application (of which the codebase is just one representation of those capabilities).

The discussion highlighted a few interesting concepts and tools, notably the concept of 'Moldable Development' via Glamorous Toolkit and Projectional Editing, a way of understanding and editing a system through more contextually-relevant projections. While I suspect I will finish writing up the application in a more traditional way (focussing on the codebase itself), given the fairly simple nature of the system it has presented a good opportunity to think about alternative ways of explaining it and whether these concepts could help me publish something that would be useful for different audiences. I hope to dive into in this further the coming weeks.

Weeknotes for week beginning 12th July 2021

We've been preparing for a big piece of new work this week, which will entail building new capabilities and integrating with existing ones, in some cases rethinking how they work today. In order to encourage the discussion, I put together a document reviewing the requirements and proposing one way we could approach our data model ("data model" here being the objects and entities that we will have to flow through the system). 

I knew the document had flaws and there were areas I had intentionally left light on details. Thankfully, the straw man did exactly what I wanted, it gave us something to critique, poke holes in and we have ended the week with both a much better (shared!) understanding of the problem space, but also a robust list of next steps for us to tackle in the next couple of weeks!

I spent some time this week (and a little last week too!) mobbing on a lightweight implementation of feature flags for our application. Three of us spent a couple of days using VSCode Live Share to collaborate on the design and implementation. This was great fun, and not only did it give the whole group a great understanding of what we'd built (and kept us honest around following proper test driven development), it also gave each individual something new. For me, I spent a lot less time writing code, instead describing my thought process and helping guide the rest of the team through the exercise. This gave me an opportunity to explore the way I talk about engineering concepts, and find some new methods to help land complex ideas.

On the surface, mobbing often feels like it will be time consuming and that it'd be easier to just stick on your headphones and build it yourself, but every time I try it I come away impressed at how much we build, often how few lines of code it is compared to my expectations and how much more rounded and complete the implementation is. Having multiple people on the team involved in the design and initial implementation also makes ongoing maintenance and enhancements easier.

I've been working on an iPhone and iPad app over the past few months (built entirely in SwiftUI) that displays the latest UK newspaper front pages as soon as they're published, usually from around 10pm the night before. I'm finally ready to show it to a few more people and have launched a wait list for anyone to join the first beta! If you'd like to get involved and help me shape the app ahead of the first public release, head over to the Tomorrows Papers Today app website and register your details – https://www.tomorrowspapers.app. You can also follow the account on Twitter if you want more regular updates. Thanks!

Weeknotes for week beginning 21st June 2021

Over the past couple of weeks my team and I have been getting our heads into the nuts and bolts of what we need to do to improve our process around continuously delivering code to our users. We’ve been looking at our contribution process, how we pair when making changes to our codebase, how we might use preview environments for quicker user testing, where feature toggles allow us to ship incomplete code to production in a safe way, and how we have confidence in how our application performs once it’s in the real world.

All of this is typically excites us as engineers, but the value isn’t always clear to our stakeholders. Beyond the practicalities of how we might evolve our process, we’ve spent a good amount of time discussing what will actually add real value, and whether it’s possible to incrementally practice continuous delivery and start having an impact sooner.

There is a lot more to think about here, but a comment from one of my colleagues stuck with me this week, as they reminded me of the value of decoupling deployment and releasing as a way to reduce risk. 

I had a few days off last week (hence the short break in my weeknotes!). It was lovely to disconnect and head to the Welsh coast.

Weeknotes for week beginning 31st May 2021

Seeing small improvements starting to pay dividends at work is incredibly satisfying, and even though they’re small, the positive shift in the team’s attitude increases the likelihood of further improvement, and future success. I’m currently thinking on how to get teams to open up more in group sessions, how get everyone to present and challenge ideas, and what I can do, as a member on the team, to encourage that more.

I took my first trip into the Made Tech offices this week, my first central London visit since March. It was great to see the working space and to meet a few new colleagues in person. I’m looking forward to a few more opportunities to visit in the near future, especially with the vaccine coming soon(ish)!

For the past few weeks I’ve been toying with one of my side projects, a service that offers a way for users to connect all (read: some, for now!) their workplace tools in one place, and push it all into a private view in Slack — think of it as your own personal work dashboard, right inside Slack. It runs on a mix of Vercel, Next.js, Supabase and NextAuth, and I’m hoping to be able to launch an early beta version in the next couple of weeks. I’m sure I’ll post on Twitter if I make it that far!

I’m taking some time off for most of next week so, depending on a few things, my weeknotes may take a short hiatus too.

Weeknotes for week beginning 17th May 2021

This is something that seems to come up time and time again in software engineering, and something I’ve been thinking about a lot this week. When a system is struggling, slowing down, or otherwise giving you and your team headaches, all too often the solution teams reach for is to tear it down and start again from the beginning. In almost every scenario I’ve seen this, hindsight has shown it to be a big mistake.

I totally understand the desire to build again, the sales pitch is easy: “we can do everything we can do now and more, that we can release faster and that uses all the latest and greatest technologies – our customers will love it”. I’ve even fallen into this trap more times than once. Inevitably though, it takes longer than you expect, you end up with a small percentage of your original product feature capabilities, and many of your processes haven’t gotten any faster. Often the existing system keeps causing you so many problems you never truly get to focus on the new one, leaving you with two services that aren’t fit for purpose.

There are, of course, cases where building again can be the right choice, but so often my experience shows that critically reviewing what you currently have, looking not at the code and the pipelines, but internally at you and your team, reveals more about the headaches you’re experiencing.

Perhaps you aren’t refactoring as you go. Perhaps tech debt (I prefer the term product debt) is getting out of hand. Perhaps you haven’t been keeping your dependencies up to date and they’re introducing critical security issues. In these scenarios replacing the code and technologies rarely helps in the long run. It’s a bit like buying a brand new car, treating it badly for a couple of years and having constant issues with it, and thinking that just buying a new car is going to solve all your problems. It will for a short while, but if you don’t change your approach, you’ll be back at square one in another couple of years.

Instead, taking time to plot a course to get yourself out of that hole, to develop that maintenance and stewardship mindset in yourself and your team, and to bring the best of your existing system along with you, will likely get you to a much better position, and in a way that you can practically support into the future.

I have lots more (currently unstructured) thoughts on this, likely worth a full blog post at some point, but for now – tell me your stories (good and bad!) of rebuilding software from the ground up, I’d love to hear them @chrishutchinson.

This past couple of weeks I’ve been playing Civilization V with a couple of friends. I stumbled over this podcast – Civ Stories – in which the hosts tell stories of games that have gone on late into the evening, and all too often have had absurd or ridiculous outcomes. Playing Civ again has been fun, although I am fairly awful at it for the time being. Practice makes perfect they say!

chrishutchinson.me

Quick thoughts: How prototypes give us super powers and the trade-offs we must accept

Photo log #001 – bcn

Designing with friction: A cure for AI-induced cognitive atrophy

APIs are (sort of) over; and the new era of work

How to make Slack work harder for you and your team

Note taking and explaining systems

A straw man, the benefits of mobbing and a new app beta

Continuous delivery and the Welsh coast

Small improvements, new offices and side projects

Making the most of what you’ve got