Alexandre Gerlic

Everyone can build Everyone can build blog article

We wrote about how we built this momentum, the systems behind it, and what's next: alan.com/en/blog/disc...

Everyone Can Build is now real:
* Faster iteration. Broader ownership.
* Teams unblocked.
* Code became our shared interface.
#everyonecanbuild

We started with foundations:
* Running the product locally
* Standardizing on @cursor.com.web.brid.gy
* Dedicated crew for setup & AI workflows

283 PRs later from designers, PMs, and Ops at Alan.
Small text edits → layout tweaks → full features.
#everyonecanbuild

A button color took weeks to ship. Not because it was hard—but because the designer who spotted it couldn't fix it themselves.
So we asked: what if everyone could build?
#everyonecanbuild

💬 Instead of waiting for “vibe-coding” tools to scale…

What if we made existing engineering tools and workflows more accessible?

So, when should you use it?

✅ Rapid experiments: landing pages, waitlists, MVPs
✅ Small teams: can handle an app with a few engineers
❌ Large teams or large codebases: not ready yet

⚠️ The rough edges
- No branches → every save goes straight to main (no workflow/CI)
- Tests & linters exist, but don’t run on Lovable
- File sprawl: creates new files instead of editing → dead code risk
- Tagger conflicts (e.g. breaks map rendering)

✨ The good

- Instant feedback loop: prompt → preview → revert if needed
- Custom domain deployment, effortless updates
- Supabase integration (auth, edge functions, env vars) worked seamlessly
- Proactive nudges: refactoring + security alerts keep code healthy

In theory, this is exactly where vibe-coding tends to break down.

And yet—Lovable delivered.

Here’s what stood out 👇

💡 Should you use Lovable?

Over the past few months, I’ve had the privilege of watching yamas.tech come to life built with Lovable.

It’s not “just a landing page.”
It’s a full-fledged product: frontend with complex states + AI multi-agent backend.

💡 Overall impression: @kiro.dev is onto something. They’ve rethought the IDE not just as a coding tool, but as a specification and workflow engine. Even if it’s not fully mature yet, the ideas are bold and might influence how other IDEs evolve. Worth exploring!

What can be improved
⚠️ Spec-to-Code maturity: The spec creation feels strong; the code generated still needs refinement.
⚠️ Pricing clarity: splitting “vibes” vs. “specs” requests makes forecasting harder.
⚠️ Settings surprises: autocompletion was disabled by default.

✨Hooks with real ergonomics: event‑based and manual hooks (e.g., when a new React component file is created). A powerful approach to enable scaffolding and best practices.

✨ Spec workflow From a small prompt, Kiro generates:
- requirements.md (like integration tests from user stories)
- design.md (architecture & evolution)
- tasks.md (with refs back to requirements)
Each doc must be reviewed before moving on.

✨ Agent steering done right
Instead of endless rules, Kiro uses 3 lightweight docs:
- product.md
- tech.md
- structure.md
Feels like a cleaner, smarter version of the hacks many of us have been hand-rolling.

Kiro The AI IDE for prototype to production

🚀 Just tested @kiro.dev (kiro.dev), Amazon’s new AI IDE. Not just another “copilot” — it rethinks the IDE as a spec + workflow engine. Here’s what stood out 👇

#alan #healthcare #engineering #hiring | Alexandre G. 🚀 If you had the chance to improve the way millions of people access healthcare, would you take it? 😍 We're expanding our engineering team across France…

🚀 If you had the chance to improve the way millions of people access healthcare, would you take it?

😍 We're expanding our engineering team across France, Spain, Belgium, and Canada for both individual contributors and leadership positions

#hiring #engineering

www.linkedin.com/feed/update/...