anthropic – Rich Sharples' Weblog

Diary of an Agentic Wrangler (part 4)

Posted on June 13, 2026 by Rich Sharples

On these pages, I’m keeping notes of my experimentation with new AI based software development tools. My goal is to understand for myself whether tools like Claude and Codex are ready for developing commercial software. Low code and zero-code tools have been around for a decade or so – this is not the same. Vibe coding has been around for a few years as well – this isn’t the same.

This new approach has various names – agentic coding, spec driven development, personally I think “intent driven development” captures it best, though I’m confident that name won’t catch on. With intent driven development – I’m responsible for the what, the AI is responsible for the how.

As the cost and time to develop software shrinks, the focus will shift to other critical elements of the product lifecycle. I believe the next areas of differentiation for builder / product organizations will be:

Choosing hard problems to solve and solving them in ways that delight users. The easy problems can now be easily solved with a few well authored prompts and a vibe coding platform. Vibe Coding is incredible for solving small local problems – it’s the new Excel (and I mean that with a huge amount of respect)
Accelerating all the other toil related to building and product – pricing, training, marketing, enablement
Convincing enough people that your solution to the problem is the best. As time to market collapses, you have to assume competition and cheap imitation will be rife – how do you stand out ?

And so it is with my little pet project. I’ve invested 6.5 hours in the development of the application – included in that is some overhead in getting the development environment setup (GitHub automation, local Xcode), design, development and building regression test harnesses. For fun, I did a little costing analysis on the main code repo using scc – clearly COCOMO hasn’t really kept up with even pre-AI development tools but it’s a good way to reason about the magnitude in productivity – 8 months compressed to a week – even if the COCOMO estimate is out by a factor of 10 – the point still stands.

			
───────────────────────────────────────────────────────────────────────────────
Language            Files       Lines    Blanks  Comments       Code Complexity
───────────────────────────────────────────────────────────────────────────────
TypeScript             65       8,455       681       302      7,472        796
SVG                    24         281         9         0        272          0
JSON                    8         192         4         0        188          0
Swift                   4         211        24        35        152         16
CSS                     3         388        50        11        327          0
JavaScript              2          49         1         2         46          3
HTML                    1          17         1         0         16          0
Markdown                1          22         9         0         13          0
───────────────────────────────────────────────────────────────────────────────
Total                 108       9,615       779       350      8,486        815
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $725,251
Estimated Schedule Effort (organic) 8.18 months
Estimated People Required (organic) 2.77
───────────────────────────────────────────────────────────────────────────────
Processed 467665 bytes, 0.468 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

		

But that’s not really the point of this post. In my humble opinion, software development for low-stakes, greenfield problems are largely solved at this point and development time and cost is collapsing – it’s hard to debate this any longer and I personally don’t require any convincing. I don’t see an imminent plateau either – even if the models are throttled – agentic development can still scale in other ways. The way we develop software – heavily augmented with AI and human as the designer / orchestrator – that’s the way – there’s no going back.

So on to the next bottleneck – that’s pretty much everything upstream and downstream of software development. Software development is the tip of the spear in terms of agentic augmentation and performance improvement – everything else is next.

I spent a few frustrating hours this week downstream – fighting with the Apple TestFlight review process – clearly the user-centric design and detail to attention that Apple products are known for is pretty much absent from their developer tooling. I won’t belabor the point here but it’s classic “toil” – work that has to happen but brings you no joy at all. But it does highlight the point about the whole product lifecycle – everything has to get leaner and faster – it’s not going to be acceptable to wait three days for an App Store approval if the app only took a day or two to develop. You can’t spend a month on a marketing plan for a new release if the release will be out in two weeks. Everything has to speed up.

As part of the early access stage for my little test app – I needed an onboarding process. I could have used the Apple TestFlight defaults but want to own the onboarding and capture some user information in the process so I pretty much single-shotted a simple website (hosted on GitHub pages) and setup a Google form to capture registrations – not as automated as I’d hoped but mostly a one time cost.

Now I have the simple web presence – I have a home for the app’s change log so I got Claude to create an Action to create release notes every time I push a new release. The only twist here is that the Action calls out to Anthropic to turn PR text into human readable release notes – so far It seems to work well.

How we think about planning and project management will have to change. Even for a small one man project – normally there would be some planning involved but what I’ve learned this week is that if you have time to write a GitHub issue or a Jira ticket, then you probably have time to “do the thing” you were going to write the ticket about. What kind of planning is eve required in world of constant feature delivery – all you really need is direction / themes and prioritization.

The next thing I’m thinking about is how to take this experiment further – I have the first batch of beta users (you can sign up here if there are still slots available) and I expect to get some feedback – I’m hoping I can largely cut myself out of the loop. My goal is for Claude (or whatever) to present the work planned for the next release (new features, bug fixes, tech debt) based on customer feedback and product analytics – let me review it then just get on with the implementation, testing and delivery. Self improving software / products / systems with human defined policy and guardrails – that’s where were heading. Sure someone still needs to inject strategy and innovation into the loop but product maintenance and improvement can be largely automated.

Diary of an Agentic Wrangler (part 5)

The next big feature is integrated the PullBook App with the Half Decent scale so I can completely automate the “pull a shot” workflow in the app but due to a shipping delay from Hong Kong all I have is a rough implementation and a simulator as shown below : Status report – I gave…

by Rich Sharples June 21, 2026

Diary of an Agentic Wrangler (part 4)

by Rich Sharples June 13, 2026

Diary of an agentic wrangler (Part 3)

FWIW – my day job is running a largish (28 people) Product and Design team for Cellebrite. Cellebrite has nothing to do with Espresso – though some of the offices do have decent machines. I’ve been leading product teams for over 20 years and that background is driving how I develop software with Claude. For…

by Rich Sharples June 10, 2026June 13, 2026

Casual Coding with Claude (Part 1)

Posted on May 31, 2026June 4, 2026 by Rich Sharples

The Casual Coder

This was cross posted from Linked.

Although I haven’t been a full-time developer for well over 25 years, most of my career in product leadership has been in support of people building, deploying, and managing software systems, so I’ve always maintained a close interest in the art and science of software. With only a few exceptions—pretty much every year for the last 25 – I’ve managed to find a reason to actually write some code. I’m a big fan of learning by doing.

The early AI augmented co-pilots were very useful for someone who, like me, is not a regular coder and doesn’t have the time to learn the latest language, framework, or stack. The first vibe coding platforms were even more useful—producing running prototypes from simple prompts but the tools quickly became confused after a few iterations.

In the last 6 months, though—I feel like we’ve hit a significant step change in capability. On rainy Memorial weekend this year, I jumped into full AI development using Claude Design/Code, and I am pretty blown away with the speed and results.

Over the last 3 days, I developed two non-trivial apps—both of which would’ve taken me months to hand-code. Note in aggregate – I suspect I only spent about 5 or 6 hours actually developing software.

The work-related app

This first (A11yBot) is a web-based tool for completing Accessibility documentation (aka VPATs)—something most government customers require but part of the “whole product” that is usually de-prioritized. Yes, there are commercial apps, open-source apps and even commercial services for producing A11y report – but that’s not really the point – it’s a rich enough space to make a good target app.

The A11yBot app runs locally, scans source code and a running web apps, and produces a VPAT report covering the standards you have selected. AI-generated responses synthesize the evidence from scans and completes the report. It supports the major Accessibility standards in the US and internationally. You can plug in an LLM for the AI response generation using OpenRouter or hook up to local models using Ollama APIs.

For this app – I started with a two-page-long specification outlining the MVP, goals (as automated as possible), and constraints (easy to run locally). From that, I asked Claude to produce a design – schema, workflow, and technology stack. Got the first working release in about 30 minutes and pushed it to GitHub as a baseline.

Running local models, scanners, test environment, and builds on a 24Gb M5 MacBook doesn’t work well, so I invested time in using the remote option in Claude Code so everything is running on a bigger Mac mini in my office. I have a suspicion that Claude leaks Chrome helpers as well – ended up with hundreds consuming about 70Mb each. Reboot time.

I also spent time trying different local models (via Ollama) for the report generation, then had Claude implement an OpenRouter API so I could use larger text models – huge improvement in speed and quality. Tldr – the big hosted models are a) much faster; b) produce much better outputs. You pay for what you get.

After several iterations – the app functioned well but looked like crap, so I opened Claude Design, asked it to do a design review (just needs access to code), and then to come up with a better design. Also added a dark mode switcher and took care of some outstanding A11y issues. It took about three more sprints (maybe 2 hours in total) to get all this work done, which required some restructuring and updates to the underlying data model, but this phase truly left me impressed. I realize Claude Design is still new, but it can already do some impressive work – I need to invest more time. Once Claude Design is fully integrated with Claude Code – it will be incredible – for now you just have to copy whole design briefs over and have Claude Code ingest them.

The A11yBot project is available on GitHub under – feel free to take it for a spin. If enough people are interested – I’ll invest more time in it and push it to npmjs to make it even simpler to run and probably license it under ASL2.0. Likewise – if anyone wants to improve on it – bring your robots !

The lifestyle app

The next app came off the long list of apps that I wish existed. I’m a bit of a home Espresso aficionado and go through a manual process of dialing new beans (dose, grind, extraction time, etc.) – the science/logic is well established, but I’ve never seen a decent application to make it easier.

Unlike the first app, I had a very good sense of how the app should behave, so I started in Claude Design (oops, ran out of credits) rather than diving straight into code gen. I started with a one-page specification describing the manual workflow and form factor – iPads, iPhone, and the areas I thought could be improved with an app.

MVP is:

loading a new bean – scans QR code and pulls details from the roasters’ website, or you can enter details manually.
Maintaining your Bean database (hopefully with the perfect extraction parameters).
Running an extraction, recording parameters like dose, grind, time, etc.
Taking user input on taste and giving advice on how to improve the next extraction.

I handed over the Design spec to Claude Code – asked it to come up with a schema and technical design and then let Claude go in full auto mode (oops, out of credits again).

I had to do a fair amount of debugging and research with this one (maybe 30 – 60 mins.) – especially the QR code reader. And I had to do two extra test shots to get the flow right – buzz!. I’m not making this repo public for now – need to iterate on it some more but may share it in the future. I also think this App will scale up well – the more people use it the more data on perfect extractions will be available without the need for experimentation.

Lessons Learned

A few things I’ve learned through this long weekend exercise:

For anything but minor fixes – do focused design / plan session – that gets you down to a very specific plan and goes much quicker
Maintain a regression suite. After major revisions, ask Claude to update regressions tests – I mostly do this for the data layer and APIs. Also, have some baseline reports to black box test end to end.
As long as I’m working on my own, I’m just working on the main branch though I’ve used feature branches for more speculative / risky stuff. Right now, I’m just letting Claude deal with GitHub.
Experiment in branches – code is now cheap – if the change doesn’t work, abandon the branch.
To do any kind of development, you need a $200 / month plan – I’m guessing full time devs are burning through $1000’s a month ??
Ask Claude to delegate visual testing back to you – watching Claude do testing via Chrome with screenshots is painful and very slow and no doubt burns tokens
Cost aside – code is cheap. I did start logging issues in GitHub for future work but quickly realized it takes only a little more (of my time) to ask Claude to code it.
If you have multiple machines – there are various ways you can leverage them – I’m using SSH to run stuff on my Mac mini while working on my laptop.
I find working in focussed sprints much quicker and less likely to exhaust / pollute the context window (mine and Claude’s!).
Batch up small fixes into a single prompt. This fits with how I work – I’ll run through the flow and make notes then ask Claude to fix them before the next iteration. Bigger stuff goes into a separate sprint.
Use /clear regularly – I use /clear as a matter of course when I’m starting a new “sprint”
The collapsed feedback loop is a true game changer – you can sit down with a user (myself included, in this case) and iterate in real time.
I’ve become acutely aware of token costs and have already started reading tips on token frugality.

Note – I’ve used the word sprint here – to me that’s a focussed batch of work with some outcome but instead of taking 2-3 weeks – it takes between 5 and 15 minutes with Claude.

In a previous life, I was a developer for about a decade – Assembly, C / C++, Fortran, Smalltalk, Java, I used to love developing software – you get a real sense of accomplishment but I never had the patience for the yak-shaving, obscure language syntax or arcane behaviors of someone else’s framework. Removing coding tasks from software development has been a dream for decades but we’re getting dangerously close to finally achieving it IMO.