Claude works fast.
Make it work well.
Claude token usage is up.
Output seems up.
Is productivity?
Is quality?
Our solution
Your process, your tools, augmented with AI.
- Familiar, but revolutionary
- Streamline everything
- More quality, more output
See it in action
Imagine you have an app that lets people create gift lists, for birthdays, holidays, weddings and more.
Your users want to rate how much they want each gift.
The following interactions are highlights from a series of real session logs. They have been compressed but capture how an example lifecycle could be semi-automated.
Product development & planning
Objective
Not all gifts are created equally! To allow their loved ones to pick wisely, allow a user to “rate” how much they want a gift compared to the others. In many ways, think of this as a “priority”.
They should be able to add this rating/priority when adding the item.
They should be able to change this rating later.
The rating/priority should appear in the shared list.
Plan
- Introduce the concept of a “priority” (ranking from 1 to 5, 5 being high priority).
- Update gateway and giftlists microservice to support this
- Expose this in the UI when adding, editing, and viewing a shared list
That’s the whole brief, written by you. Now it goes to engineering.
Engineering
/design-epic GL-145
Before I design this, five decisions would change the result. My suggestion is after each one.
- Must every gift have a rating? No: default to 3.
- What about gifts that already exist? Show them as 3.
- Should the shared list sort by rating? Not yet: keep today’s order.
- Should owners see ratings on their own list? Yes.
- How is a rating changed? As its own action, like editing a description.
All five as you suggest.
The design is ready: four pieces of work and 78 tests. Three questions are still open.
- Should a guest’s open page update live when a rating changes? I suggest yes, for ratings only.
- What happens to a rating outside 1 to 5? I suggest the server quietly rejects it.
- How should the rating look: five stars, a number, or named levels like “Nice to have”? I suggest stars.
1 and 2 as you suggest. For 3, named levels.
Five levels
| Rating | Shown as |
|---|---|
| 1 | Nice to have |
| 2 | Would like |
| 3 | Want |
| 4 | Really want |
| 5 | Want most |
Rename “Want most” to “Would love”. Otherwise, approved.
Four tickets, 79 tests, all checked
| Ticket | Piece of work |
|---|---|
| GL-146 | Store the rating |
| GL-147 | Show the rating |
| GL-148 | Set it when adding a gift |
| GL-149 | Change it later |
/implement-ticket GL-147
Two parts: the server first, then the website. Before I start, nine questions, with my suggestion after each.
- Live updates when a rating changes: leave them to the later ticket that adds changing a rating? Yes.
- One planned test can’t pass as written. Reword it.
- One test step can never fail. Drop it.
- One test has nothing to prove it works. Add a check.
- One test looks for text that never existed. Reword it.
- Two tests can’t fail until a later ticket. Keep them for then.
- Nothing catches a rating lost when a gift is edited. Add two tests.
- The tests stub one layer higher than described. That’s fine.
- What should show for a rating outside 1 to 5? “Want”.
Agree with 1 to 8. For 9, normalise out-of-range values when they’re read.
So below 1 shows “Nice to have” and above 5 “Would love”. Where should that happen?
In the website. Plan approved.
Both parts built. Every test passes, and each new test was broken on purpose to prove it can fail.
The review caught a test that never checked what it claimed. Fixed. Both changes are ready.
/test-ticket GL-147
I’ve added two extra tests to this run.
20 of 21 passed
| Test | Result |
|---|---|
| Owners and guests see each gift’s level, in a real browser | PASS |
| Server tests (122) | PASS |
| Website tests (270) | PASS |
| Extra: the dashboard still loads | PASS |
| Extra: a live update reaches a guest’s page | FAIL |
The test is wrong, not the app: in development the page deliberately starts twice. I suggest correcting the test, and tightening two weak ones.
Agreed. Fix all three.
23 of 23 passed
Ready for your review
Review them the way you always do.
| Change | Tests |
|---|---|
| Server: keep each gift’s rating and send it to both pages | PASS |
| Website: show the level name beside every gift | PASS |
Your review found one problem: a rating of 2.5 would crash the page.
/implement-ticket GL-147 review
Fixed and tested, and every comment has a reply. One question: update the documentation now, or once the whole feature is finished?
Once it’s finished. Re-test before we merge.
23 of 23 passed
Ready to merge: the server change first, then the website. I don’t merge. That’s yours.
Merged, server first.
Done. On to the next piece of work.
Release
Follow your normal release process.
Nothing about how you ship has to change.
Our process
Collect
We spend the time understanding your current code base and processes: reading documentation, sampling code, and interviewing key team members.
Build the tools
A bespoke Claude plugin of skills, agents, workflows and scripts, built around how you already work.
Test and train
We’ll sit with each member of your teams to train them and polish the final set of tools.
Hand over
Documentation and training, so that you can maintain and evolve the tooling yourselves.