DEV Community: Surfing Devs

Introducing ivy: Bring the Legendary Ivy Lee Method to Your Slack Workspace

Surfing Devs — Wed, 16 Apr 2025 17:35:03 +0000

Hey Dev.to community! Today I'm excited to announce the launch of ivy – a free Slack app that brings the power of the Ivy Lee productivity method directly to your team's workspace.

Add it to slack in: https://tryivy.app

What is the Ivy Lee Method?

For those unfamiliar, the Ivy Lee method is a century-old productivity technique that's brilliantly simple yet remarkably effective. In 1918, productivity consultant Ivy Lee suggested this approach to Charles M. Schwab, then president of Bethlehem Steel Corporation:

At the end of each workday, write down the six most important tasks to accomplish tomorrow
Prioritize those six items in order of importance
When you arrive tomorrow, concentrate only on the first task until it's finished
Then move to the second task, and so on
At the end of the day, move any unfinished items to a new list for tomorrow
Repeat this process every working day

This method has stood the test of time because it works—it reduces decision fatigue, encourages focus, and provides a clear structure for daily work.

Why We Built Ivy

Many of us have tried using the Ivy Lee method with paper notebooks, to-do apps, or even just text files. But these approaches have limitations:

Task lists aren't visible to your team
There's no accountability or reminders
Your priorities don't live where your work happens (in Slack!)

Ivy solves these problems by bringing this legendary productivity method directly into your team's Slack workspace, making it simple to stay focused while keeping your colleagues in the loop.

Key Features

🚀 Simple Task Definition
⏰ Daily Check-ins
✅ End-of-Day Reminders
👥 Team Visibility

Getting Started with Ivy

Getting started with Ivy is simple and free:

Visit tryivy.app to add Ivy to your Slack workspace
Follow the onboarding in the app home in Slack.
Experience the power of focused, intentional work

Free to Use

Ivy is completely free to use. We believe in the power of this simple productivity method and want to make it accessible to as many teams as possible.

Join Us on This Journey

We've built Ivy because we believe that in today's distraction-filled work environment, techniques like the Ivy Lee method are more valuable than ever. By bringing this proven approach directly into Slack, we hope to help teams everywhere work with more focus, intention, and clarity.

Visit tryivy.app today to bring the power of the Ivy Lee method to your team. We'd love to hear your feedback and experiences as you use Ivy to transform your productivity!

Have you tried the Ivy Lee method before? How has it worked for you? Share your experiences in the comments below!

Vibe Tech #1: Welcome and initial thoughts

Surfing Devs — Sun, 06 Apr 2025 22:44:12 +0000

Motivation

Each day the AI tech space changes. Each day you wake up with news of a new model breaking benchmarks, a new game changing protocol or a dozen new tools that will make devs perform 10x faster. Do the test yourself, just follow a couple tech users on X or join some dev related subreddits.

However it is yet not clear where we are heading and what the final picture will be in 1/1.5 years.

This series is about filtering the noise, sharing some thoughts and experiences, and trying to predict the impact of this transition.

Disclaimers

The idea is not to use AI to do any of the writing.
The end goal is try generate an audience that could lead to building a community and doing meetups.

Thoughts #1: Vibe Coding

Assistant's code artifacts are low quality. These LLMs were trained on existing open source code. Open source code is in general terms low quality. If most repos follow bad practices, they will outweigh best practices posts in the training data.
Assistant's code artifacts are great for scripting, not for foundational code. Code runs most of the time, which is great for one-off things. But most of the times dependency injection is wrong, parametrization is not optimal, and data classes are not well designed. You still need the senior dev to review the artifacts if you are building the foundation of your system.
For me the big leap was Copilot. The original one, the autocomplete tool. Huge time saver for snippets. If you know what you want, writing a signature and see the function appear was great. Assistants are not a big leap from Copilot imho.
Fine tuning on private codebase >> cursorrules. Prompting rules is not a super power in my experience. LLMs are not sensitive to them. Instead, training on private codebases will allow predictions to follow your practices.
Big codebases are a problem. Although context windows are increasing length, assistants are not able to properly add new code to existing codebases. A lot of duplicated code appears. Its funny that you can immediately tell in a codebase which snippets were written by cursor.
A coding assistant is a junior dev sitting right next to you. The experience with assistant coders (I use Claude Cursor) is similar to reviewing a PR from a junior dev. The type of comments you leave in that PR ("expose this as a constant", "use the function from this module instead", "remove this parameter and inject it to the constructor", etc) is the type of back and forth you have with the assistant to achieve the optimal implementation.

Thoughts #2: Debugging vibe code

Debugging is a pain with vibe code. Debugging is at same level of importance as coding in dev's work. Assistants cannot debug. Copying an error trace to the LLM starts an endless loop of "Oh yes, let me fix that" that almost never works. I believe than trusting your codebase is a must for debugging. If you cannot debug you have a real problem.

Thoughts #3: Future dev pods

Teams will need less people. Tools that save time make teams require less hours to achieve things. Less hours means less people. Seniority is still valuable. Seniority avoid all my concerns from vibe code I expose above. But every senior was once junior. If there is no more space for junior devs, how do we get seniors?

Thoughts #4: Startup world

More solo founders and small teams. I believe this tech will encourage smaller teams to tackle bigger projects.
Bootstrap >> VC back. All AI tools are cheap IMHO. If cursor was 200 USD/month, most users would pay it. You won't need a lot of money because you will need less people (not just devs, but designers, marketers, sales, etc).
Exponential amount of new startups. Time to build will be crazy low. A lot of people will start to create new projects as it is short term and cheap.
Full time devs vs fractional devs. I can envision a future in which a full time dev is not very required anymore as teams get lower and less human dependent. Maybe there is a world in which fractional devs is the standard, similar to fractional CTOs today. Working in multiple spaces and teams at the same time will be exciting. Context switching will be a challenge.

Final words

Would love to hear feedback, questions and new thoughts. What this blogpost ends up being is uncertain to me, but will keep you posted.

AI locators for Playwright 🚀

Surfing Devs — Wed, 05 Mar 2025 13:15:17 +0000

Today I'm excited to present ai-locators for Playwright! 🚀

// 👎 Say goodbye to this complexity
page.locator("//div[contains(@class, 'header')]//button[contains(@class, 'login') and not(@disabled) and contains(text(), 'Sign In')]");

// 🌟 And hello to this simplicity!
page.locator("ai=the login button in the header that says Sign In");

🔗 Check it out: https://github.com/lila-team/ai-locators

😫 The Problem

Let's face it - maintaining locators in Playwright tests can be a real headache! 🤕 They depend on how elements are positioned and declared in the frontend, which changes constantly and breaks your tests.

Sure, you could follow best practices like maintaining test-ids or being consistent with roles and labels (check out these best practices). But let's be real - developers want to move fast, and tests that are hard to maintain often get left behind! 🏃‍♂️💨

🤖 LLMs to the Rescue!

Here's where the magic happens! ✨ This project uses LLMs to generate selectors based on the HTML content and your natural description of the elements you want to find.
It's implemented as a custom selector engine so it fits perfectly into your existing Playwright codebase! 🧩

// 🔍 Search the entire page
const element = page.locator("ai=the login button");
await element.click();

// 🎯 Search inside a container
const container = page.locators('.main-div');
const element = container.locator("ai=search input");
await element.fill("foobar");

🎨 Choose Your LLM!

When registering the custom selector (check out our README for the how-to), you can pick your favorite LLM to power the magic - as long as it follows the OpenAI API! 🪄

🎉 Great news! ai-locators is available in both python and node! Give it a try and let us know what you think! 💭

🔗 Link to project: https://github.com/lila-team/ai-locators

ai-locators is available for Python and for Node.

E2E testing challenges using Playwright

Surfing Devs — Fri, 28 Feb 2025 13:54:54 +0000

So you finally decided to implement e2e tests 🚀. You have a webapp with production traffic and you want to deploy safely knowing your high level features work. Unit test is not a good plan time-wise ⏱️ while e2e tests will give you that coverage you want to continue moving fast 🏃.

You choose Playwright. Playwright is currently the default e2e testing framework out there.

Initial implementation goes well 👍. Playwright is simple and straightforward. Locators are easy to declare and you add a couple tests to your CI/CD pipeline. You feel safer now and continue with fast speed 🧘‍♀️.

One month later 📅

You realize you are spending too much time fixing your e2e tests . Locators need to be updated all the time. Navigation changed. Interaction with DOM elements changed. Fixing tests start to slow you down. 😩

Next steps? Hire QA? Remove tests and pray? Go low level unit testing instead? Standardize FE elements? 🤨

Low level implementation for high level features: the GAP

The problem with Playwright or similar frameworks (Cypress, Selenium, etc) is that they work with implementation details. Locators are literal the implementation of the objects you want to interact with.

You might encounter these:

// Deeply nested CSS selector that depends on exact DOM structure
await page.click('.main-container > div.row > div.col-md-8 > form > div:nth-child(3) > button');

// Selecting elements based on their exact position in a list
await page.click('ul.dropdown-menu > li:nth-child(2)');

// Relying on internal implementation IDs from a component library
await page.click('[id="select2-dropdown-results-9-4"]');

// Using XPath that depends on exact HTML structure
await page.click('xpath=//div[contains(@class, "sidebar")]/ul/li[3]/div/button');

Devs will change these aspects of the components daily. Your tests won't be robust to those changes.

This is the result of testing high level features with low level frameworks 😳. Ideally your test shouldn't break if functionality is still there, regardless if the button was changed to a different <div>. You don't want to test how it was implemented, you want to test what your users will be doing.

Introducing Lila

If you got this far and agree with this, let me introduce Lila, a new testing framework for fast moving teams I'm developing.

Lila remains high level for doing proper high level testing. Your tests declare what your users will do, without using how it was implemented 😎. Lila has AI Agents 🤖 that will try complete the instructions with the available implementation, making it robust to your everyday dev changes.

Without more spam, you can find more information in its repo: https://github.com/lila-team/lila

Final thoughts

Would love to hear in the comments if this problem resonates with you, or if you found good engineering practices to keep Playwright stable over time or if you think a tool like Lila would work.

Thanks for reading!