Having a son has made me much more conscious of how I spend my time. Not just because there's less of it that's entirely mine, but because there's now someone watching what I do with it.
Nowhere has that been more obvious than with my phone.
I love technology, I love the iPhone, and I enjoy social media. But I find social media becomes too consuming really quickly, and with those apps readily available it is all too easy to pick up your phone to reply to a friend, and then find yourself spending half an hour scrolling.
I already notice just how much he takes in of his surroundings, and I don't want him to look up from whatever he's doing and see me absent-mindedly polishing a piece of glass with my thumb.
My love of technology means I also love the re-emergence of dumb phones (and intentional technology in general - bring back the iPod!). The Minimal Phone 2 looks incredible and I almost joined their Kickstarter campaign. I nearly bought an old Nokia until I learned that WhatsApp was no longer supported. I love e-ink, and think it does a brilliant job at reducing so many of the distracting UI elements that are so common today.
But all of these solutions require you to give up more than I felt I needed to, and I started to appreciate that the device isn't the problem. An iPhone out of the box has no social media on it. I created those accounts and installed those apps myself. The device for me wasn't the issue.
The iPhone is great. Maps, an incredible camera, Apple Pay, messaging and FaceTime, music. These are all powerful features that we're incredibly lucky to be able to carry around with us in one device, and they're all things that I didn't particularly want to compromise on. An old phone would remove the distractions, but leave me without Apple Pay. An e-ink device would make Instagram look less appealing, but it would have the same effect on photos I'd taken or received. And here's the thing. I didn't necessarily want to use social media less. I just wanted to stop using it unintentionally.
The solution I'm therefore trialling now is a twist on the work phone. I have a play phone.
A couple of weeks ago I bought a second-hand iPhone SE for £50 (essentially the cost of one of those physical brick devices to try and reduce screen time). It's tiny, the battery life isn't great, and the lower pixel density display makes it feel like I can see the individual pixels. I've installed all the fun apps onto it; X, Instagram, Reddit, Facebook. All the things that occasionally surface something interesting or genuine from a friend, but all too often lead to endless lost hours. I've also now removed all of these from my main phone.
The beauty of this approach is that I'm still in complete control. I could carry this second device around with me and scroll as much as I'd like. But the older device (combined with it being another thing altogether) introduces a little bit of friction that more often than not stops me. Leaving the house, it stays here. Going to bed, it remains in my office. Occasionally if we're relaxing in an evening and just watching some mindless TV, it comes out and lets me catch up.
That small physical boundary has, so far, been enough. My screen time is down considerably, but I don't feel like I've given anything up. I'm still on Instagram. I can still see what my friends are doing, waste some time on Reddit, or catch up on X. I just now feel like I'm in better control of when I choose to do it.
We've used work phones for years to create a boundary between work and the rest of our lives. The play phone is the same idea in reverse.
The internet is still there. It's just not always in my pocket. And it leaves more time for playing with toy cars and lego. Which I think is how it should be.
]]>We shouldn't treat all AI-generated code equally. Some changes must have close human review (financial transactions, high-volume order routing); others should eventually become safe enough to fully automate because we've built the right guardrails around them. Guardrails such as robust tests, automated checks, clear standards, good observability, controlled permissions and appropriate rollback mechanisms.
If we can build those guardrails, it should allow us to worry less about specific lines of code and focus more on the problem, the behaviour of the system and whether the engineered solution is the right one. Trust then comes from the evidence surrounding the change: tests, checks, observability and appropriate controls, rather than somebody having to manually understand every line.
There’s a huge focus right now on personal AI agents. They’re incredible and certainly have their place, but I think today we’re making things harder for ourselves by all having our own preferred way of working, our own preferred models, tools and markdown files.
A primary engineer on a system can build a lovely environment which makes them really efficient. But as soon as someone else has to pick it up, they’re not only having to learn the system context, but also a completely different way of working with AI.
Our engineering principles, coding standards, repository knowledge and structure, system architecture, testing expectations, release processes and product goals should increasingly become shared infrastructure. Improvements made by one person should improve the system for everyone, and every development environment should feel familiar.
If we can capture our principles and ways of working and automatically share them through every repository, the actual tool or model a developer uses becomes less important, because they’re all then working from a shared context.
We’ve spent the last year or so playing and experimenting with AI, and we’ve integrated it into our daily work with varying levels of success. This has been really useful and has shown that there is genuine value here. I think now the next conversation shouldn’t be about which tools we should use. It needs to be about what a more efficient engineering model looks like. Not a faster one, or an automated one, but a more efficient one.
As a starting point, I think the following questions hopefully prompt some useful discussion:
What engineering work should humans stop doing?
What work remains (or becomes more) important for humans to stay in control of?
What needs to be true before we can trust AI with more autonomy?
The goal here isn't more code or tickets. It's less work in progress, less cognitive load and context switching, more reliable systems and more engineering capacity that can be applied to the problems that actually need us.
I personally think the role of engineering is changing as a direct result of AI, and that over time we'll spend much less of our time manually writing code. But I also don’t think that writing code was ever intended to be the primary task (even though it often took the most time). That has always been solving problems. Engineers are great at developing solutions to problems, a job which involves understanding the company and product context, knowing what’s technically possible, asking questions to get to the best solution, and caring about the quality of your work.
All of that is more important now than ever.
]]>I came across this lovely concept today (in the always excellent Dense Discovery newsletter), the idea being that we can give ourselves a version number.
Today I'm 3.4.95. Tomorrow, the patch number increases by one. Hopefully each day there's a little improvement, something I didn't previously know that I now do. A mistake that I've since learned from. An idea that I can now pursue.
It's a gentle reminder of continuous improvement, that we're always still growing and learning. The day-to-day change is likely small, but imagine what will have changed between today and version 5.7.13, to pick an example.
]]>Engineering teams have been investing heavily in AI and there are clear benefits emerging. Engineers move faster. Boilerplate takes less time. Tests are easier to write. Documentation is less painful to maintain.
But if the headline impact is that the same team gets through the same backlog a little faster, that isn't the transformation we were promised, and it's a pretty poor return on the investment.
Software companies are built around a familiar constraint: engineering capacity. Developers can only do so much, so everything queues behind them.
A designer wants to test a new dashboard component? Add a ticket.
A support lead wants to improve an internal workflow? Ticket.
Someone in operations wants to automate a repetitive task? Ticket.
The bottleneck has rarely been coming up with ideas. It's that every change must flow through a small number of people. But if agents can understand a system, generate code, wire up an interface and explain the errors, hasn't that bottleneck gone away?
The lazy version of this argument is: "AI makes everyone a developer now." It doesn't, and it shouldn't. Letting anyone vibe-code straight into production isn't empowerment. It's arson.
Engineers are right to worry about low-quality code, missing tests, accessibility problems and security holes. Those concerns separate "works on my machine" from "safe to run our business on."
But the answer can't be that only engineers are allowed to change software. The more interesting question is: what would need to be true for more people to change it safely?
None of this is new thinking. Platform engineering has been preaching golden paths for years: clear service boundaries, automated tests, feature flags, approval workflows, observability, automatic rollbacks. The idea was never the problem. The cost was. Those foundations take months of work that rarely reaches the top of the backlog, because guardrails don't ship features.
That's what I believe AI actually changes here. The same capability that makes engineers faster at writing features also collapses the cost of the boring foundational work — drafting tests, configuring integrations, extending delivery pipelines, fitting existing tools together. Guardrails that were unaffordable become affordable. And affordable guardrails expand who can contribute.
The best place to start with this is somewhere low-risk and high-friction: internal tools, dashboard components, onboarding flows and admin interfaces. Let someone propose a change. Let AI refine the idea and draft code, run the checks and then create a preview. Require approval where needed, and roll back if it misbehaves.
A product manager shouldn't be able to edit authentication because they had an idea on a Tuesday afternoon. But should a designer be able to create a button text A/B test, run visual and accessibility checks, launch it to 20% of users and measure the outcome? Why on earth not?
And honestly, the primary beneficiaries of this will be developers. A front-end engineer who can confidently make a change deep in an unfamiliar backend, because the tests, boundaries and rollbacks catch mistakes before they matter, owns a complete problem instead of half of one. The guardrails that make it safe for a designer make it safe for everyone.
Now it’s worth being honest about the catch here: if every AI-drafted change still needs an engineer to approve it, you haven't removed the queue. You've just turned engineers into full-time reviewers, and review is its own bottleneck.
But review scales differently to authorship. A well-guarded change — tests passed, checks green, blast radius contained, rollback ready — takes minutes to review, not hours. And the checks compound: every failure mode you automate is one a human never has to catch again. The goal isn't zero engineering involvement. It's engineering judgement applied where it matters: what should change, where the risk sits, and what standard a contribution must meet.
That doesn't make engineers less important. It makes their judgement incredibly valuable. This is the new leverage of AI software engineering, I believe. Not clearing the queue faster, but building a system in which fewer changes need to join it at all.
For most of my career, the advice has been to specialise.
Choose a discipline. Become excellent at it. Build a career around the depth of expertise that other people do not have.
That advice made sense. Most organisations were built around specialists because most worthwhile work required specialist tools and knowledge. A software developer wrote the code. A designer designed the interface. A researcher spoke to users. A product manager decided what should be built and tried to keep the whole thing moving in roughly the same direction.
One person could have a view across all of it, sure, but they could not do all of it well enough to produce a serious result.
Now though, I think it’s different.
We are back in an era in which someone with a broad set of skills, good judgement and an ability to learn can have an extraordinary ability to just get shit done.
Not because expertise no longer matters. Not because one person should replace an entire team. But because AI has dramatically increased how far one capable person can follow a problem before they need to hand it to someone else.
The most useful generalists are not simply people who can do a bit of everything. They are people who can stay with a problem.
They can work out what is actually happening, rather than accepting the first description they are given. They can speak to the people affected, examine the evidence, understand the constraints and explore more than one possible answer. They can make something, put it in front of people, learn where they are wrong and improve it.
Until recently, that journey usually crossed too many professional boundaries for one person.
Understanding a problem might require user research and data analysis. Exploring it might require service design or technical investigation. Testing an answer might require interface design, software development, copywriting and some kind of operational process. Even a relatively simple prototype could involve a small team, a collection of handovers and several different queues of work.
Now, someone who is strong in one of those areas can become capable enough in the others to carry an idea much further.
A product manager can interrogate a dataset, build a working prototype and put it in front of customers. A designer can connect an interface to real data and test the interaction rather than presenting a static mock-up. An engineer can analyse customer conversations, explore the wider service and test whether the thing they can build is the thing anyone needs.
The output will not always be production-ready, and I’m not sure that it should be expected to be. The important change is that one person can now get far enough to at least learn something real.
I studied software engineering and started my career as a software developer. Over time I moved towards product management.
That move was treated as a change of discipline. I stopped being a developer and became a product manager. The skills I had learned as an engineer were useful, but the organisational model encouraged me to work through an engineering team rather than continue building things myself.
There were good reasons for that. The software became more complex. The consequences of getting it wrong became greater. Doing both jobs properly was difficult, and half-doing either one was not useful.
But I can now do enough of both again.
I can explore a problem, research unfamiliar areas, work with data, design a service, build a prototype and test it with real people. I can use specialist tools without spending years becoming a specialist in each of them. Where I lack knowledge, I can get much further before needing help—and ask much better questions when I do.
That does not make me the best designer, engineer, researcher or analyst in the room. It makes me capable of getting to the point where we know which room we need, who should be in it and what they should work on.
That is a different kind of leverage.
The shallow version of this argument is that AI makes everyone an expert. It does not.
Generating some code does not make someone a software engineer. Producing a plausible interface does not make them a designer. Summarising a set of interviews does not mean they understand the people they are trying to serve.
AI makes it easier to produce convincing rubbish as well as good work. Without judgement, a generalist can move very quickly in the wrong direction.
The useful skill is not knowing a little about lots of things. It is knowing how the different parts of a problem fit together, where your own understanding is weak and when the work requires genuine depth. It is being able to distinguish a shortcut that helps you learn from one that quietly creates risk for somebody else.
The best generalists will still depend heavily on specialists. They will bring in an experienced engineer before a prototype becomes critical infrastructure. They will involve a researcher when the people affected are difficult to reach or the conclusions carry real consequences. They will know that legal, clinical, security and policy expertise cannot be approximated by a confident conversation with a language model.
AI does not remove the need for expertise. It changes when it is needed and makes it easier to use precisely.
Instead of assembling a full team around an untested assumption, a generalist can do enough work to expose the parts that are genuinely difficult. Specialist time can then be spent on the questions that deserve it.
This should change how teams are formed.
The default response to a new idea has often been to identify all the disciplines it might require, estimate the capacity needed from each and put the work into their respective queues. That is expensive, so organisations understandably reserve it for ideas that already appear fairly certain.
The result is a familiar trap: an idea needs evidence before it can earn a team, but it needs a team before anyone can produce the evidence.
A capable generalist can break that loop.
Give one person a meaningful problem, access to the people who understand it and the tools to investigate it. Let them produce the first useful account of what is happening. Let them test the cheapest version of an intervention. Then form the team around what the work reveals, rather than around the assumptions made at the beginning.
This is not a case for running organisations as collections of heroic individuals. Important work still needs teams, institutions and durable expertise. It is a case for recognising that the smallest useful unit of progress has changed.
One person can now create enough momentum to make a problem legible, testable and worth organising around.
There is nothing particularly new about the generalist. Anyone building something from nothing have always had to move between disciplines. Early-stage founders do not get to declare that customer research, finance or operations sit outside their role. People doing difficult work in small organisations have always learned whatever the problem demanded.
What is new is the quality and range of work that one person can now produce, and how much more accessible this ability is.
The generalist is no longer limited to coordinating specialists or producing a rough approximation while waiting for the real team to arrive. With good tools, good judgement and selective specialist help, they can investigate, build and test to a standard that creates genuine evidence.
We were told to specialise because specialisation was how ambitious work got done. That will remain true for many parts of the work.
But the ability to cross boundaries, learn quickly and hold the whole problem in view is becoming valuable again. As execution gets cheaper, the scarce capability is increasingly knowing what deserves to be done, seeing how its parts connect and staying with it long enough to make progress.
The age of the specialist is not over.
But we are definitely back in the era of the generalist.
]]>More and more I'm appreciating just how important communication is in all aspects of life, and how incredibly difficult it is to be genuinely good at it. Professionally speaking, I now see my ability to communicate as the most important aspect holding back career growth. The ability to execute, have good ideas and deliver improvement are all worth so much less if they're not effectively and intelligently communicated to the right people.
I know I need to write more. To think more deeply. But it feels like everything around me works to break my focus, and recovering that is something I struggle with.
When reading Bill Gates' autobiography I learned about his think weeks. A week alone, offline, with little more than a stack of books, paper and a pen. At the time I felt that was unnecessary. Now I think that would be the ultimate luxury.
]]>I was tempted when it was first announced, but the first version seemed to miss the mark and was widely considered almost useless. But the team behind it kept going. They’ve refined it, improved it, and the new version of the OS looks much more capable.
I’ve also had a craving to play with hardware for a while now. The Playdate is on the wish list, as is basically everything designed by Teenage Engineering.
The R1 still has a compelling promise: a simple, dedicated device for asking questions, checking a status, capturing a thought or task. Maybe having a specific device for that means I pick up my phone less often, and avoid getting dragged into the usual time-draining habits.
Maybe it still isn’t quite there and ends up unused in a drawer within a couple of weeks.
Only one way to find out.
]]>After twelve months away from it I'm returned to Whoop. I got a lot of value out of it when I first used it, but when my son was born I knew training would have to take a back seat for a little while. We're now in more of a position where regular training is happening, goals are being reset and my craving for more data is increasing.
Of course 24 hours after re-subscribing, Google announced the Fitbit Air. It looks great but perhaps a little basic in terms of sensors and datapoints. I'm looking forward to seeing what the early reviews make of it because the price point is otherwise excellent. A screen-free, cheap, data capture device that I can then apply my own analysis to is exactly what I'd opt for.
]]>I've used Google Workspace for about 15 years now, and it's been great. The Google ecosystem is comfortable and works well. But more recently — and AI may well be the trigger here — I've wanted to have more ownership of my own data. To know where it is and what it is being used for.
To this end, I've started to build a personal database. I'll share more on that another time, but I'm opting to capture books, films, wines and coffee beans in there rather than use and maintain four different social services that are all essentially just advertising platforms. AI can now provide answers to the "based on my profile, what would I next enjoy" question, so I can trim away the rest.
It's a common saying that if you're not paying for the service, then you and your data are the service. So much of the Google ecosystem is shared, analysed, surfaced and optimised around keeping you inside it, rather than simply providing a requested service.
Email felt like the obvious place to start. Not because I think it's the most at risk, but because it sits underneath so much else. It’s a 15-year archive of messages, receipts, logins, family admin, travel plans, account recovery. A boring utility, until you stop and realise how much of your life passes through it.
I’ve had my own domain for years, so my email address itself isn’t changing. That makes this a much lower-risk move than it would otherwise be. I don't need to ask anyone to update contact details (my parents still try and email my university address!) and I’m not breaking old accounts. I’m just moving the plumbing from Google Workspace to Fastmail.
In theory, this is exactly the kind of internet I prefer. Open standards. A paid service with a clear business model. IMAP, SMTP, custom domains, boring reliability. Less “ecosystem”, more utility.
There’s something quite appealing about that. So let’s see how long this phase lasts.
]]>And while having kids may be warping my present judgement, it hasn't overwritten my memory. I remember perfectly well what life was like before. Well enough to miss some things a lot, like the ability to take off for some other country at a moment's notice. That was so great. Why did I never do that?
See what I did there? The fact is, most of the freedom I had before kids, I never used. I paid for it in loneliness, but I never used it.
With my son now approaching his first birthday I can relate a lot to this piece from Paul Graham. Raising a child has been considerably harder than I anticipated. Don't get me wrong, it's equally the most incredible and fulfilling experience too, but it is relentless, and in the tougher moments it's easy to look back and think about the freedom you've since lost.
Except I never used it.
It's just easier to essentially blame that fact on another part of your life than own up to it. There's also no reason why that freedom has to be lost, and this is something my wife and I are trying to fight. Sure, it's harder to travel with a one year old. Even more so with a dog. But it's far from impossible if that's what you really value.
I agree with a lot of this. The iPad has for too long occupied this strange middle ground. The hardware has been extremely capable for years whilst the software has inexplicably lagged behind. This is now more noticeable with AI.
I've been tempted through the years to consider the iPad Pro as my primary machine. After all, a vast majority of my work only requires a browser; everything of note is a web app or would have an iOS app available. But now, a main device that cannot run Claude Code or Codex wouldn't really be an option. It would feel like having my hands tied behind my back.
The Neo looks to be a great machine. A desire for that kind of device is why I picked up a second-hand 12-inch MacBook last year. Small and capable, though without an M-series chip it was never going to be a long-term main machine.
I still wonder where the iPad fits into my routine. Not as capable for work as a MacBook. Not as good to read on as my Kindle. Not as immediately available as my iPhone.
As Craig finishes by saying, it'll be very interesting to see how John Ternus approaches this when he begins as Apple CEO in September. The iPad is clearly very successful and a popular device, but is an ever closer convergence between iOS and macOS the right approach?
It'll also be fascinating to see how rumoured devices like the OpenAI hardware Jony Ive is working on may disrupt this space. Does the future of computing look completely different in ten years' time?
]]>I recently read an essay by Alan Kay from 1989 that originally featured in The Art of Human-Computer Interface Design, edited by Brenda Laurel. This was essentially before the internet, before smartphones, and long before any of the AI assistants we now use daily. And yet it describes the exact problem we’re still trying to solve.
Kay makes a distinction I haven’t seen articulated as clearly anywhere else. Humans have extended themselves in two ways throughout history.
First, through tools. Physical things we manipulate directly. A hammer, a keyboard. The feedback is immediate. You hit a nail and it moves.
The second way is through management. Convincing other entities to work toward our goals. Other people, historically. But increasingly, software that acts on our behalf. What Kay calls agents.
The interface challenge for these two categories is completely different. With tools, the question is how efficiently can I manipulate this? With agents, the question is how do I know if I can trust this to complete the task I set?
This has been something that I’ve been thinking about this as I’ve played with various AI products. The onboarding for poke.com felt immediately familiar. Within minutes it felt like it “knew” me. But after a week the novelty wore off. Sure, it drafted emails, but I always felt the need to adjust before sending.
This is essentially the gap Kay identified. We’re trying to apply tool-based expectations to something that requires a completely different interaction pattern.
Kay wrote that the thing we most want to know about an agent is not how powerful it is, but how trustable it is. The agent must explain itself well enough so that we have confidence it’s working for us rather than as what he calls an escaped genie.
He predicted agent development would move in two directions. First, expanding into domains where mistakes don’t matter much. Where undo is easy. These would move fast. The second direction would move slowly. Domains where undo is hard or impossible. Where mistakes affect real relationships or irreversible decisions.
Looking at where AI has actually expanded, this prediction holds remarkably well. Code completion moved fast. Autonomous decisions in healthcare or finance remain constrained. The pattern isn’t about technical capability. It’s about reversibility, confidence and trust. Not in the technical abilities, but in the agent itself.
What strikes me most is his claim about explanation. Kay argued that well-done explanation will be needed regardless of how the agent is instructed. The interface challenge isn’t about making AI more conversational. It’s about making the reasoning legible enough to calibrate trust. When I ask an AI to draft something and then need to adjust it before sending, that gap represents a trust calibration failure. The AI was confident. I wasn’t. And I couldn’t easily understand why our judgments differed.
The hardest part to accept is that this might not be primarily a technical problem. Tool-based interfaces can be evaluated through direct feedback. Agent-based interfaces require something closer to the trust calibration we use with human colleagues. But with humans, we have shared context. We have social structures that create accountability. We build trust through repeated interactions where we observe judgment against outcomes.
None of these mechanisms exist for AI agents. The conversational interface creates an illusion of familiarity, but the underlying trust architecture is still largely missing.
Kay saw this clearly in 1989. We’re still figuring it out. But we’ll get there.
Wales stands at a critical moment as our economy continues to degrade the natural resources that underpin our health, security, and prosperity. Wales is one of the most nature depleted countries in the world, with almost 1 out of 5 species at risk of extinction.
Wales’ consumption levels far exceed sustainable limits. If replicated globally, our resource use would require more than two Earths, demonstrating the amount of natural resources we import, all accompanied by impacts on other countries
— State of Natural Resources Report 2025
The State of Natural Resource Report 2025 paints a very bleak picture. All too often we look elsewhere, at what other countries are doing or the United Kingdom as a whole. But here in Wales we’re at a critical point. Our history, particularly agriculture which accounts for 90% of Welsh land, isn’t easily compatible with achieving climate goals. Recent changes to legislation, including the Sustainable Farming Scheme has real potential, though it’s still not perfect and is still struggling to balance the agricultural industry and people with the broader needs of our country.
Reading this report is making me really think about my own impact. We’ve all got to do more to protect nature. I need to find out what that is, though. There’s a lot to think about here.
]]>I haven’t read as many books as I was hoping to this year, but thanks to Matter I’ve read a lot more from across the web. Their support for sending articles to the Kindle makes for an excellent experience for long-form articles.
I’ll try to write about my favourite articles in the next few days, but here are my top three books I read this year.
An incredible storyteller with an incredible story to tell. This was very much un-putdownable and I really enjoyed it. The reader was invited into every conversation and passing thought that really built up the narrative throughout, and how Suleika tackled some incredibly tough topics was truly inspiring.
I first spotted this from The Bear and thought it looked interesting. It was a fantastic read, with so many brilliant stories and anecdotes to really drive home the points that Will was making. The power of incredible levels of service and attention to detail cannot be understated, and thinking about how the lessons here can be applied across other industries occupied my mind for a long time after finishing it.
Jacinda Ardern becoming PM of New Zealand felt like a turning point in global politics. Sadly that influence has perhaps not had the full effect just yet, but her style of leadership is infectious and has certainly show that there is another way. She had to deal with some huge events during her time, and she took on each one with great humility.
The overwhelmingly cheap cost of storage has meant that we rarely delete things any more.
At work we come up with an idea, research it and present our findings as something that we could do. A few months pass, an evolution on that original idea comes along. We refresh our memory from the original idea, research what’s changed and then present it as a new idea, leaving the old one as it was.
Storage is cheap. The old idea is doing no harm. It’s just a harmless old document that no one would go and read.
Until we come to train LLMs on our company documents. All of a sudden, there’s important context missing. All those old (and good bad!) ideas and out of date reports all of a sudden are presented equally for an LLM to train against.
When we then come to interrogate this knowledge, how will we know what’s useful? How will we be able to trust it?
Today shows that you can still play this as a team sport, with honesty, fairness and transparency at the centre of every race and still come out on top as champions.
Papaya rules.
I realise I’m a couple of weeks late to the party with this, but the onboarding user experience with poke.com is brilliant.
It immediately feels familiar, being positioned as a contact through an existing chat interface, and it feels as though it “knows” you within a few minutes. Negotiating a monthly price is also novel, though I expect the vast majority of users end up paying the same amount.
However, I’ve played and enjoyed it for about a week and the novelty is starting to wear off. Sure, it’s immediately accessible and has helped draft a few emails, but in each case I’ve felt the need to adjust the draft before sending. Scheduled reminders and daily briefings are nice, but I’ve struggled to fit them into any sort of routine.
This is very much the state of AI more broadly today. Novel, intriguing, powerful. But we’re still figuring out how to integrate it properly. The real power is still to come. We’re still in the dial-up era.