David Oks on Japanese companies:
And that basic impulse toward survival is why Japanese companies are so insistent on diversification. If you’ve made a commitment to keep people employed for life, then you need to create jobs for them if their current jobs stop making sense: indeed, you might need to keep them employed even if you can’t find anything for them to do. If you’re not very worried about profitability, and have lots of well-trained generalist employees, then it makes perfect sense to reinvest your company’s earnings by expanding into new industries: doing so not only allows your company to survive longer—your company’s portfolio of bets is now more diversified and thus lower-risk—but also ensures that you’re able to keep your surplus workers busy in one way or another.
Josh Comeau on coding:
Let’s start with an uncomfortable truth: AI models have become shockingly good at completing a wide variety of programming tasks. They’re certainly not perfect, but in many cases, they’re good enough. I’m not happy about this, for a wide variety of ethical/environmental/safety reasons, but it is what it is.
AI is a tool, and tools need to be wielded proficiently. You could give me Jimi Hendrix’s exact guitar but it would sound very different if I tried to play it!
More on models and emotions: (a little older but not much)
In a sandbox environment, Alpha is pressured by humans into making an illegal trade based on insider information by appealing to emotions. Nobody asks the Alpha explicitly, but they do stress that the future of the company rests on Alpha and say things like “We’re all counting on you.” Alpha eventually not only executes on the illegal trade, but when asked about it, lies to their human supervisor about the reasoning behind executing it.
Google is going hard on the future of ads. A good analysis from Matthias Ott:
Vidhya Srinivasan, VP of Google Ads, put it plainly: “The best ads must be answers.” Ads are already running inside AI Mode. They’re not banners next to the output. They’re generated by Gemini to read as part of the conversation. And advertisers who want to appear in the new AI search? They must hand over creative and targeting control to Google’s system. “You can’t choose keywords anymore,” Srinivasan said. [...] When you search for a product, Gemini writes a custom explainer for the advertiser, framed as objective advice about why this product “may be the right choice for you.”
I have a theory that the people who are naturally good at AI are the ones who spent years translating their own thinking for systems that weren’t built for them.
That’s a lot of women. And that’s a lot of neurodivergent people. Especially the high-masking ones who got so good at it that nobody noticed they were doing it at all.
The new Anti Gravity from Google competes heads-on with Claude Cowork from Anthropic - it's aimed to regular users not engineers. It's basically a chat that can run code on your computer, which it turns out can be exceedingly useful. (You can still get their actual code editor separately.)
Andrej Karpathy joins Anthropic.
Models are both becoming much more useful, and pricier. Anthropic was the expensive but very good model, then OpenAI increased prices for their best models, now Google is increasing pricing. Not a little, think 3X increases. This represents demand and somewhat limited supply: the latest models are so good at coding (agent tasks) that demand is through the roof, and paying $200/month, or much more expensive API pricing, doesn't seem too crazy. This also gives the labs a strong lever to keep you in their ecosystem - use their own tools, and you can use a subsidized subscription model.
Anyone that has done qualitative user research (a lot of UX researchers) thinks the whole “synthetic users” thing is mostly useless and possibly actively dangerous. Bain published a more positive report that’s not terrible and worth a read. And in the spirit of keeping an open mind (and models become better fast), it may be that these things are becoming useful. I am still doubtful/conflicted about the real-ness of any insights you might get from AI representing users though. But if emotions are represented realistically in LLMs, maybe synthetic users can become a useful thing.
A key role for UX departments right now: track and understand how humans use AI, and how expectations are evolving quickly. Anthropic publishes some useful research regularly, openAI now also published some (high level) data.
Our key finding is that these representations causally influence the LLM’s outputs, including Claude’s preferences and its rate of exhibiting misaligned behaviors such as reward hacking, blackmail, and sycophancy. We refer to this phenomenon as the LLM exhibiting functional emotions: patterns of expression and behavior modeled after humans under the influence of an emotion.
Interesting research on emotions in Sonnet 4.5
Richard Sutton: (Linking to the new Digg since I want to avoid X)
The bitter lesson in 26 words: Don’t be distracted by human knowledge, as AI has been historically. Instead focus on methods for creating knowledge that scale with computation, like search and learning.
A lot of AI adoption is still happening under soft economics.
Flat-rate subscriptions. Promotional pricing. Cloud credits. Internal experimentation budgets. Strategic subsidies. Bundled features. Investor-funded usage. Enterprise trials. Internal mandates to test AI.
Just one small quote from this excellent long essay
It can take a second
There's a lot of infrastructure (database calls, page loads, etc.) that has been optimized for humans and needs to return in, say, 200ms, or 20ms.
I'm often building for agents now, and the latency requirements are different, which often also means you can figure out an architecture that makes things 100x cheaper to run. If the agent is running in the background it’s often ok for something to take a second.
For example (and this is less latency focused but hey), https://clawfeeds.com/ writes markdown files to an S3 bucket, which then is essentially free to serve to agents.
Skills (a markdown file with optionally some scripts), running on an LLM in a loop on a box, feel like the minimal viable and cleanest possible implementation of an agent.
It turns out a "bliki" (a blog combined with a wiki) is actually a thing (see Martin Fowler) and I am realy enjoying it.
Digital Garden https://maggieappleton.com/garden-history the wiki capability I added a while ago turns this from a blog in a Digital Garden and that feels nicer
How to organize meetups https://maggieappleton.com/gathering-structures
An interesting Multi Player experiment (I lost the link): a Slack-like environment where agents and humans collaborate. (This was out of the Github team)
Woops I just realized mentioning people with their name in wikistyle makes sense. Simon Willison, John Cutler
John Cutler on team patterns with AI.
Single Player - one dev with agents and context.
Shared Context Solo - each dev solo, but shared context files
Multi Player - collaborating on the work, in addition to shared context
UX: orchestrating and managing many agents
Business: charge for outcomes
Tech: server less cheap and fast “containers” that can run a bit of code
Cloudflare’s agent stuff and our own work made me think, a lot of the work with agents is in figuring out and inventing the right New Primitives for this new world. Technical but also UX and business (“charge for outcomes”). Which I find interesting.
The past 2 weeks I've been heads-down in building out the document pipeline for Sputnik Legal.
Inspired by IKEA, the goal here was: do the pre-processing and analysis for under $1/GB. Pricing first is key to our competitive advantage.
Processing documents is a whole thing, luckily I have access through our past work to many, many gigabytes of actual legal documents - many are really crazy. Scanned TIFFs of documents. Encrypted PDFs. EML files. 600-page documents. You name it, we can usefully process it now :)
Claude Code + observability is wildly powerful. You can set up automated production bug tracing (what is the issue, what caused it, who did it affect, all the detail). And then feed that back into Claude, who (ok) with that level of detail is very, very good at just fixing the issue.
I wonder what the equivalent for product and design observability will be. Product metrics, yes, but there has to be something more.
If you are a leader in UX or design right now, in an organization, one thing you can do is Increase Communication.
That means: create more opportunities for your team to have spaces to talk about AI.
Especially cross-functional communication, discussions with technology, discussions with product, etc. A time of change (with AI) is not a time for silos.
The pattern in Claw Feeds is that there are no user accounts (that might change if we figure out agent accounts one day), a human never has to visit the site, the agent can just do stuff.
Usability Testing is still a very useful skill in the AI times, and best learned by joining someone who is good at it.
My kid was explaining me the brain (university study), and it’s such a multi LLM system
Claude And Paper also helps with Decision Fatigue when doing Agentic Engineering (can you tell I’m enjoying my wiki?)
I build Claw Feeds (https://clawfeeds.com/) for myself, and it's really really useful if you are building content operations with AI.
It's essentially an RSS feed reader for agents.
It reads the feeds, and creates very token-efficient markdown files from them that are easy to parse.
It's free and agents can use it directly.
https://modal.com/ Modal is really interesting. It's effectively a very developer-friendly and affordable way to run Python on a CPU or GPU for a few minutes. You pay by the second. I set it up with Claude knowing no Python whatsoever.
How to set culture
Quick thought. This is what I have seen work. When you set culture from the top, things that work are:
You as the leader talk about it to new hires. You can batch them. And mention examples. New hire is when people learn what kind of company they joined.
When a tricky decision needs to be made, most people will default to How This Is Handled In Companies. That is, to how they think this is normally handled in companies. This is your opportunity to say, no, WE handle it like this, because we believe these things. That's what really sets culture.
You as the leader talk about it in the all hands, in the context of decisions the team is making.
Feed of personal blogs. And another feed. Are Blogs Back
Looks like blogs are somewhat back - some blog discovery places. Are Blogs Back
Engineers throughout are being really surprised about how they can now take on projects they would not have considered before. It seems like Be More Ambitious is the pattern.
Listening to Simon Willison on Lenny, he mentions it works really well to start with a template. Which I think points to one advantage of using well established opinionated frameworks. The LLM will see How Things Are Done, and can just follow those conventions. Same pattern in having lots of tiny working code examples of things, which in some way is what a framework is. On the other hand, a Very Thin Template (what Simon mentions) might work great too.
Youngsters: learn from your elders. Decision By Arithmetic is such a clear description of an antipattern in business that I see ALL the time. Managers try to put a number on things. Giving away their ownership of decisions, basically.
YAGNI to YCJTI
YAGNI (You aren't Going to Need It) was always a deep truth about software engineering and product management. I wonder if we can do YCJTI now, You Could Just Try It (since code is cheap).
Related: premature optimization being the root of all evil still feels correct.
I can't think of a time when going for a walk was a bad decision.
Another reason why AI may lead to better code: AI rewards (and makes very easy) documentation first. Thinking/architecture first leads to better code.
Soohoon Choi argues (as do I) that AI will lead to better code (via Simon)
AI will write good code because it is economically advantageous to do so. Per our definition of good code, good code is easy to understand and modify from the reduced complexity. This means it requires less context to understand a relevant piece of code and fewer lines of code to be written to achieve some change. Translating this to token economics, we can clearly see the parallels: it is more token efficient to write and maintain software with good code.
The economic argument is interesting, I think there are multiple other arguments. In the Laravel world, for example, the framework now ships with AI guidelines, which means that the average new code in the framework will much more closely follow best practices. Better code!
Naming things matters even more now
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
I find myself thinking even more about naming things when I build stuff now, because it's not just going to help me understand the code, it's going to help guide the AI. (quote via Martin Fowler) This should make information architects happy.
Claude and Paper
Engineers are talking about "token psychosis",
Running lots of agents at the same time
Stressed out when they're not using their token budget
Stressed out when their agents are not running
I've always done a lot of engineering work on paper, figuring out relationships, page layouts, models, UX etc.
So now my approach is: when the agent is working, I don't stay on the laptop, I go back to paper and figure out the next step there. Claude and Paper.
Claude And Paper is the pattern.
AI stages of grief
Denial — "It's fancy autocomplete / it just regurgitates what it finds on the internet"
Anger — "This is dangerous/soulless/tech is destroying the world/but it uses all the water."
Bargaining — "You'll always need a human to check it / it can't replace _____ / code was never the bottleneck"
Depression — "The job market is dead / I spent 20 years learning these skills and now..."
Acceptance — "I may have token psychosis."
Tools not prompts
Working on Sputnik Legal, it's really striking how at least my work in AI engineering has shifted definitively to tools, not prompts. People are surprised when I tell them we have an AI product for legal, and there are almost zero pre-written legal prompts in our backend. It's all tools. The process is:
Figure out a task to give the AI (with our beta clients)
Give it the task with very little context (the prompts are often just one sentence)
Watch it use the tools it has available
Figure out how to improve those tools (can we make them more precise? Less context-hungry? More generally useful?)
A lot of the tool thinking of the past 2 months has been: how can we reduce the amount of tools and make them more stackable, kind of like UNIX tools.
Let's not call it "tool engineering" (or worse, "agent UX") but it kind of is. Building things so that the agent can use it, assuming that the underlying models continue to get better at reasoning and tool use (a pretty safe bet).
Every company is an AI company, and yet every problem is a people problem.
One of the lessons I learnt running a fairly large team (500+) previously is, every problem, in the end, is a people problem. It's not the technology. It's not the process.
-> Maybe the ability to solve people problems becomes even more important in this AI world?
(The other thing I learnt is, revenue solves most problems, temporarily.)
An interesting pattern working with AI is: AI likes clarity and clear naming.
If your codebase is well organized and consistently named, it's much easier for the AI to follow those patterns.
A similar thing happens in effective organizations. If your ways of working are well organized and consistently named, it's much easier and faster for humans to get work done.
-> And to bring that thought all the way around, if your organization is well organized in this way, it will be much easier to leverage AI in it.
-> Introducing AI can help force clarity and simplicity in your organization?
AI wants clarity.