I used this in earnest yesterday on my Zillow saved listings. I prompted it to analyze the listings (I've got about 70 or so saved) and summarize the most recent price drops for each one and it mostly failed at the task. It gave the impression that it paginated through all the listings, but I don't think it actually did. I think the mechanism by which it works, which is to click links and take screenshots and analyze them must be some kind of token efficiency trade-off (as opposed to consuming the DOM) and it seems not great at the task.
As a reformed AI skeptic I see the promise in a tool like this, but this is light years behind other Anthropic products in terms of efficacy. Will be interesting to see how it plays out though.
I've had extensive luck doing just that. Spend some time doing the initial work to see how the page works and then give the llm examples of the HTML that should be clicked for next page or the css classes that indicate the details you're after and then ask for a playwright to yaml tool.
Been doing this for a few months now to keep an eye on the prices for local grocery stores. I had to introduce random jitter so Ali Express wouldn't block me from trying to dump my decade+ of order history.
LLMs struggle with time (or don't really have a concept with time). So unless that is addressed, they'll always suck in these tasks as you need synchronization. This is why text/cli was a much better UX to work with. std in/out is the best way to go but someone has to release something to keep pumping numbers.
Agree. I'd add that a aha moment to skills is AI agents are pretty good at writing skills. Let's say you have developed an involved prompt that explains how to hit an API (possibly with the complexity of reading credentials from an env var or config file) or run a tool locally to get some output you want the agent to analyze (example, downloading two versions of python packages and diffing them to analyze changes). Usually the agent reading the prompt it's going to leverage local tools to do it (curl, shell + stdout, git, whatever) every single time. Every time you execute that prompt there is a lot thinking spent on deciding to run these commands and you are burning tokens (and time!). As an eng you know that this is a relatively consistent and deterministic process to fetch the data. And if you were consuming it yourself, you'd write a script to automate it.
So you read about skills (prompt + scripts) to make this more repeatable and reduce time spent thinking. At that point there are two paths you can go down -- write the skill and prompt yourself for the agent to execute -- or better -- just tell the agent to write the skill and prompt and then you lightly edit it and commit it.
This may seem obvious to some, but I've seen engineers create skills from scratch because they have a mental model around skills being something that people must build for the agent, whereas IMO skills are you just bridging a productivity gap that the agent can't figure out itself (for now), which is instructing it to write tools to automate its own day to day tedium.
The example Datasette plugin authoring skill I used in my article was entirely written by Claude Opus 4.5 - I uploaded a zip file to its the Datasette repo in it (after it failed to clone that itself for some weird environment reason) and had it use its skill-writing skill to create the rest: https://claude.ai/share/0a9b369b-f868-4065-91d1-fd646c5db3f4
That's awesome and I have a few similar conversations with Claude. I wasn't quite an AI luddite a couple months ago, but close. I joined a new company recently that is all in on AI and I have a comically huge token budget so I jumped all the way in myself. I have my choice of tools I can use and once I tried Claude Code it all clicked. The topology they are creating for AI tooling and concepts is the best of all the big LLMs, by far. If they can figure out the remote/cloud agent piece with the level of thoughtfulness they have given to Code, it'd be amazing. Cursor Cloud has that area locked down right now, but I'm looking forward to how Anthropic approaches it.
Completely agree with both points. Skills replacing one-off microservices and agents writing their own skills feel like two sides of the same coin to me.
I’m a solo developer building a markdown-first slide editing app. The core format is just Markdown with --- slide separators, but it has custom HTML comment directives for layouts (<!-- layout: title -->, <!-- layout: split -->, etc.) and content-type detection for tables, code blocks, and Mermaid diagrams. It’s a small DSL, but enough that an LLM without context will generate slides that don’t render optimally.
Right now my app is designed for copy-paste from external LLMs, which means users have to manually include the format spec in their prompts every time. But your comment about agents writing skills made me realize the better path: I could just ask Claude Code to read my parser and layout components, then generate a Slide_Syntax_Guide skill for me. The agent already understands the codebase—it can write the definitive spec better than I could document it manually.
Skills have a lot of uses, but one in particular I like is replacing one off MCP server usage. You can use (or write) an MCP server for you CI system and then add the instructions to your AGENTS.md to query the CI MCP for build results for the current branch. Then you need to find a way to distribute the MCP server so the rest of the team can use it or cook it into your dev environment setup. But all you really care about is one tool in the MCP server, the build result. Or...
You can hack together a shell, python, whatever script that fetches build results from your CI server, dumps them to stdout in a semi structured format like markdown, then add a 10-15 line SKILL.md and you have the same functionality -- the skill just executes the one-off script and reads the output. You package the skill with the script, usually in a directory in the project you are working on, but you can also distribute them as plugins (bundles) that claud code can install from a "repository", which can just be a private git repo.
It's a little UNIX-y in a way, little tools that pipe output to another tool and they are useful in a standalone context or in a chain of tools. Whereas MCP is a full blown RPC environment (that has it's uses, where appropriate).
Another thing I'd suggest: look into and use non-coding AI tools that improve productivity. For example:
Zoom meeting transcriptions and summaries or Granola. A lot of context is lost when you take manual notes in meetings. If you use a tool that turns a meeting into notes automatically, you can use those notes to bootstrap a prompt/plan for agents.
We use "Notion AI" to transcribe meetings and it's actually pretty good, we just had a team meeting where we talked shit about stuff going on in the company along with actual tasks.
It picked just the tasks and actual points from the transcript and skipped all of the jokes and us bitching about processes =)
There's something fundamentally strange about how prices have spiked and inventory has tightened since Covid. Where I live in rural New England, prices are up 50–100% in five years. And this is on pretty poor quality homes. Yes, low interest rates led to a surge in buying and bidding wars that spiked the baseline, but when people say "the real problem is there isn't enough housing" that feels incomplete to me. Of course supply has been an issue for a while, but home prices nearly doubling in five years doesn't look like a normal supply story -- it's not as if we suddenly created 20-50% more qualified buyers in that time. I guess the lack of churn, with people hanging onto those sweet 3% mortgages much longer than usual, is probably part of it. But I really don't have an answer for the current state of home buying. I make great money but if I was to buy a house the quality of the house I got in 2018 with the same % down payment I would be looking at over 40% of my take home going to a mortgage, PMI and taxes.
> it's not as if we suddenly created 20-50% more qualified buyers in that time.
We don't create buyers quickly, but mobility means that a large number of buyers can show up in one concentrated area much more quickly than housing can adapt.
One piece of the US real estate puzzle is that automation and outsourced killed agriculture and manufacturing jobs. Those are the kinds of jobs that have some natural incentive to be spread across the US. Ag, because farms literally take up a lot of space and are spread out, and manufacturing because factories tend to be close to raw materials, ports, or other local resources.
When you get rid of those jobs and replace them with information work, you create a feedback loop with no dampening in it. People want to go where the most jobs are, so they move to the cities. Businesses want to open where the most workers are, so they start companies in cities.
The next thing you know, all the small towns are filled with dirt cheap empty houses because there are no jobs. Meanwhile, every metro area is bursting at the seams.
This makes some sense to me. The solution to housing often put forth is to build more affordable housing. In the context of people wanting to move toward cities where jobs are this makes sense.
But it seems like there is a larger problem of just having tons of housing inventory that is out of reach or untenable to most people. What are the more basic numbers of how many units exist in the country vs. how many people there are? How many second, third, investment, vacation units are there, how many sit empty most of the time? (I'm mostly not talking about true "country"/vanity houses far away from economic centers that will always only be accessible to the rich)
It seems to me that rather than just "build build build" we could do a lot to reconfigure the existing supply to make it fit the people better? Why is there so much "unaffordable" stock out there and continuing to be built? It kinda feels like the affordable housing issue is just a red herring for the larger wealth inequality issue.
> we could do a lot to reconfigure the existing supply to make it fit the people better?
The problem is that housing and infrastructure is, you know, actual giant physical objects. It takes a year of planning and millions of dollars to move a road. You can't tear down a block of single family homes and put a denser apartment building in there until everyone living in them sells. You need to run sewer, power, and roads to make a new neighborhood, and even then you will still have to deal with the impact to nearby schools, traffic, hospitals, etc.
Making places for people to live is, like, many orders of magnitude more effortful than anything we do in the software world.
> It kinda feels like the affordable housing issue is just a red herring for the larger wealth inequality issue.
Yes, this is certainly another piece of the puzzle. For every 100 people who can't afford a thing, there's still 1 rich person who can, and increasingly, rich people are the primary source of profit for businesses. So businesses target them more and more and we end up in today's world where it seems like "no one can afford what's being sold".
It's because unless you're one of the wealthy minority, you're simply not a market participant at all.
Sorry, by reconfigure I meant something akin to artificially lowering prices, legislation to push more homes to be filled by people that need them, allowing remote work, anything leveraging existing infra as much as possible.
My point is that we have the physical problem of housing units per capita beyond solved already, it's just socially/economically out of whack.
Unless there is not something I am seeing, people aren't racing to move to rural New England. Maybe it's retirees, red to blue state migrations, or remote workers. But I haven't seen a ton of evidence of that. People didn't really migrate out here before covid and I don't think enough people have to justify the rise in prices.
Personally I think people that otherwise would be selling are sitting on their homes because of the interest rates and this is causing a strange feedback loop of low turnover causing low supply which in turn causes new buyers to accept the prices (probably with a hope that interest rates will come down and they can re-fi in the years to come). I also think a non-trivial number of houses that on the market due to the owners passing or going into retirement homes are sitting there on the market because prices are so high but the only money the family is out is taxes. Or they are being turned into rental units, since rental prices are out of whack in these areas too.
My point I guess is where I live we haven't seen a big influx of population (probably the opposite) or significant job or wage growth to make sense of the increase in housing prices. I guess at the end of the day people are just stretching themselves further and sending more money to the banks in the form of interest to get into homes that were literally half the price in 2019. Strange times.
I agree that people sitting on their mortgages is part of the story.
I do also think there's a thing where home prices have risen so steeply in metro areas that even rural areas with fewer jobs are seeing prices go up because the market will allow it. Because the cities are so expensive, a house in a rural area can still be a relative good deal even if it's more expensive than it used to be.
City planning certainly isn't my area of expertise. I think it's a fiendishly hard problem. For a small town to draw people in and thrive, it needs:
1. Jobs.
2. Good K-12 schools.
3. Some amount of things to do and cultural amenities.
Remote work can help a lot with #1. I think people are fairly tolerant of a lack of #3 and it's a thing that can grow organically over time. People will also accept fewer things to do if the area is quieter, they can afford bigger homes, and there's more outdoorsy stuff nearby.
But #2 is really hard. You need a strong tax base to fund it, which small towns don't have. They are sort of trapped in a death spiral where if they had more people coming in, they could have better schools with the increased tax base, but they don't, so they can't, so no one moves there.
House value has gone up along with other assets since Covid because a lot of money have been printed. A trillion here and a trillion there, pretty soon we're talking real inflation. Real estate is the real inflation hedge.
What boundaries does this 8GB etcd limit cut across? We've been using Tekton for years now but each pipeline exists in its own namespace and that namespace is deleted after each build. Presumably that kind of wholesale cleanup process keeps the DB size in check, because we've never had a problem with Etcd size...
We have multiple hundreds of resources allocated for each build and do hundreds of builds a day. The current cluster has been doing this for a couple of years now.
Yeah I mean if you’re deleting namespaces after each run then sure, that may solve it. They have a pruner now that you can enable too to set up retention periods for pipeline runs.
There’s also some issues with large Results, though I think you have to manually enable that. From their site
> CAUTION: the larger you make the size, more likely will the CRD reach its max limit enforced by the etcd server leading to bad user experience.
And then if you use Chains you’re opening up a whole other can of worms.
I contracted with a large institution that was moving all of their cicd to Tekton and they hit scaling issues with etcd pretty early in the process and had to get Red Hat to address some of them. If they couldn’t get them addressed by RH they were going to scrap the whole project.
Most guides to wringing productivity out of these higher level Claude code abstractions suffer from conceptual and wall-of-text overload. Maybe it's unavoidable but it's tough to really dig into these things.
One of the things that bugs me about AI-first software development is it seems to have swung the pendulum of "software engineering is riddled with terrible documentation" to "software engineering is riddled with overly verbose, borderline prolix, documentation" and I've found that to be true of blog and reddit posts about using claude code. Examples:
These are thoughtful posts, they just are too damn long and I suspect that's _because_ of AI. And I say this as someone who is hungry to learn as much as I can about these Claude code patterns. There is something weirdly inhumane about the way these walls of text posts or READMEs just pummel you with documentation.
Thanks for the new word re: prolix! Couldn't quite pin down why heavily AI generated posts/documentation felt off — aside from an amorphous _feeling_ — until today.
MCPs as a thin layer over existing APIs has lost utility. Custom MCPs for teams that reduces redundant thinking/token consumption and provides more useful context for the agent and decreases mean time to decision making is where MCPs shine.
Something as simple as correlating a git SHA to a CI build takes 10s of seconds and some number of tokens if Claude is utilizing skills (making API calls to the CI server and GitHub itself). If you have an MCP server that Claude feeds a SHA into and gets back a bespoke, organized payload that adds relevant context to its decision making process (such as a unified view of CI, diffs, et. al), then MCP is a win.
MCP shines as a bespoke context engine and fails as a thin API translation layer, basically. And the beauty/elegance is you can use AI to build these context engines.
In your example, you could achieve a similar outcome with a skill that included a custom command-line tool and a brief description of how to use
it.
MCPs are specially well suited for cases that need a permanent instance running alongside the coding agent, for example to handle authentication or some long-lived service that is too cumbersome to launch every time the tool is called.
I mention mean-time to decision making and that's one of the rationales for the mcp. A skill could call a script that does the same thing -- but at that point aren't we just splitting hairs? We are both talking about automated repetitive thinking + actions that the agent takes? And if the skill requires authentication, you have to encode passing that auth into the prompt. MCP servers can just read tokens from the filesystem at call time and don't require thinking at all.
Exactly. The way it’s mostly been used so far is a poor abstraction over stuff you can just put in the context and have the agent run commands.
It really shines in custom implementations coupled to projects. I’ve got a QT desktop app and my mcp server allows the agents to run the app in headless mode, take screenshots, execute code like in Playwright, inspect widget trees, send clicks/text/etc with only six tools and a thousand tokens or so of instructions. Took an hour to build with Claude Code and now it can run acceptance tests before committing them to code end to end tests.
It's fairly straightforward to build resilient, affordable and scalable pipelines with DAG orchestrators like tekton running in kubernetes. Tekton in particular has the benefit of being low level enough that it can just be plugged into the CI tool above it (jenkins, argo, github actions, whatever) and is relatively portable.
I get the feeling that most people commenting here have only surface level experience with deploying k8s applications. I don't care for helm myself but it's less bad than a lot of other approaches like hand rolling manifests with tools like envsubst and sed.
Kustomize also seems like hell when a deployment reaches a certain level of complexity.
As a reformed AI skeptic I see the promise in a tool like this, but this is light years behind other Anthropic products in terms of efficacy. Will be interesting to see how it plays out though.
reply