Pip: Welcome to another lap around Claudio Lassala’s blog, where the recurring thesis is: stop letting your tools drive the car.
Mara: This episode covers a lot of ground — how to choose AI tools with actual purpose, what testing philosophy looks like when you stop calling them tests, how to write Cypress specs that read like plain English, and why the stories you tell about your users matter more than the requirements you write.
Pip: Let’s start with the AI tools question — and what it actually means to pick one on purpose.
Choosing AI Tools That Serve the Work
Mara: The tension here is between chasing novelty and chasing outcomes — which tools belong in your workflow, and how do you decide?
Pip: The post opens with a clear position: “I don’t chase tools. I chase outcomes.”
Mara: That framing drives every tool decision described — from cycling through Cursor, Windsurf, and Claude Code, to eventually settling on Windsurf with Devin CLI handling sub-agent orchestration. The point isn’t which tool wins; it’s whether a tool earns its place by enabling something genuinely new or meaningfully faster.
Pip: The real prize turned out to be the orchestration layer — parallel sub-agents handing work off to each other — not any single environment. Which is a useful thing to know before you spend eight months switching editors.
Mara: And the patterns for how tools hand off to each other are what carry forward, even as the tools themselves keep changing.
Pip: On to testing — where the argument starts with what we’re even calling these things.
Specs Over Tests: A Framing That Changes Everything
Mara: The question this segment addresses is whether the word “test” is quietly shaping how teams write, maintain, and trust their automated verification — and whether a different word would change the work.
Pip: The post on specs versus tests puts it directly: “A spec describes what should be true, independently of how it’s implemented. It’s a specification of behavior. The fact that running it also verifies the implementation is a byproduct.”
Mara: So the upshot is that a failing spec tells you a behavior is no longer happening as intended — which points your attention at the user experience, not the code structure. That’s a more useful signal than “something broke.”
Pip: And the fragility problem that framing solves is real. Tests coupled to CSS selectors and button labels break every time the UI shifts, even when the behavior hasn’t changed at all. That trains teams to dread refactoring — which is a slow way to make a codebase worse.
Mara: The post on E2E test strategy makes the complementary argument: end-to-end tests are necessary, but using them as your only layer is, as the post puts it, “like doing a crash test every time you want to check if the stereo works.” Every feature gets at least one Cypress spec — but E2E has held steady at around five percent of the total test count deliberately.
Pip: Five percent is a constraint, not an accident. The discipline is being tested now that AI tools make E2E tests faster to write — but the runtime cost of browser automation hasn’t changed.
Mara: The third post in this theme, on user stories, anchors the whole testing conversation in something upstream: “Nobody says, ‘Let me tell you a requirement.’” Stories give you a person, a context, and a goal. That shared understanding is what makes specs readable — and what makes AI-assisted test generation accurate when the model knows how your team thinks.
Pip: Requirements skip the conversation. Specs preserve it. That’s the thread connecting all three posts here.
Mara: The readable Cypress work is where that philosophy meets the actual file structure.
Hiding the Plumbing Behind Plain English
Mara: The design question here is how to write Cypress specs that a non-technical reader can follow — and why that abstraction pays off technically, not just aesthetically.
Pip: The post on readable Cypress tests captures the reaction from a developer new to the project: “Wait… where’s the cy.get? Where are the selectors?” That’s the right question, and the answer is that all of it lives inside a context class — one place to update when the UI changes, rather than dozens of scattered selectors.
Mara: The companion post on stakeholder questions shows where the scenario language comes from in the first place — surfacing edge cases through conversation, not requirements documents, so the spec reflects what the user actually does.
Pip: Turns out the abstraction that makes tests readable for humans also makes them easier for AI tools to extend accurately. A clean English-language surface is a good interface for everyone.
Mara: From readable specs to the question of what we actually want to keep doing ourselves.
The Air Drum Moment: Protecting What Brings You Flow
Mara: The post frames a question that often goes unasked alongside “what can AI do for me” — namely, what do you want to keep doing yourself, and why does that matter?
Pip: The answer arrives through Phil Collins: “That moment is theirs.” The drum fill in “In the Air Tonight” that makes people stop mid-conversation — that’s the image for the kind of work you shouldn’t hand off just because a tool could technically do it.
Mara: So the practical stakes are this: if you delegate the parts of the work where you find flow, you don’t become a more efficient orchestrator. You become someone who no longer experiences what they loved about the work.
Pip: The reframe is that AI isn’t most useful as a replacement for what you enjoy — it’s most useful for scaling it, or clearing the runway by handling what you don’t. Automating the right things so the moments that matter still happen.
Mara: The post closes with an Allan Watts line worth sitting with: “Measure productivity not by how much we get done, but by how many moments we spend being present.”
Pip: Which is a better optimization target than automating your whole life, however many content creators are currently pitching that.
Mara: The thread across all of this is intentionality — about tools, about tests, about stories, about what you protect.
Pip: Start from the outcome, write the spec before the code, and keep the air drum moment for yourself. Next time, we’ll see what else is worth holding onto.
Leave a Reply