Filip Hric

Every repo has them now: CLAUDE.md, AGENTS.md, a folder of markdown rule files written to steer the AI. Write the rule once, get the code you want. Except these files are advisory, not enforced, as every major vendor says so in their own docs. The research backs it up. Adding them doesn't always improve results, and it can raise the costs by more than 20%. Adherence fades as files grow and conversations run long.

This talk is about how to minimize and fix this problem. First, how the tools really work: how Cursor, Claude Code, and Codex load and rank rule files, why precedence between them is often undefined, and how to check what actually reached the model on a given run. Then how to govern rules like real code: scope each one so it fires only where it should, put the non-negotiables up top where the model pays attention, and prune the files before they rot or start contradicting each other. And for the rules that truly cannot fail, move them out of prose and into hooks and CI, where the action is guaranteed every time.

Do all that, and each rule earns a second job. Beyond steering the AI, a written-down rule is the standard you measure the finished code against. And that gap, between the app you described and the app you got, is where trust actually lives. You'll leave knowing which of your rules do real work and which just sit there looking like they do, and how to verify that instead of assuming it.

What would you do differently if you could travel back in time? Modern testing frameworks have transformed this whimsical question into a practical one, by creating their own “time machines”.Cypress’ timeline, Playwright’s trace-viewer and Replay.io’s recordings have offered a retrospective look into the life of a test, ensuring that developers and testers are no longer limited to basic error messages on test failures.However, these different time machines will bring different insights. So how do you decide? The decision on which one to use can make a significant difference in time spent on debugging a flaky test.In this presentation I will be focusing on comparing different time machine solutions and showing various flaky test examples to demonstrate how to navigate through debugging process and believe it or not - make it fun.Key Takeaways:- learn about how different time machine solutions work- discover how to effectively use time machines to debug a flaky test- find out about sources of flakiness within the test and within the application under test

Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ