DUMB DEV Community

Google Antigravity 1.0 to 2.0/IDE Quick Migration Guide

Regnard Raquedan — Fri, 22 May 2026 18:24:09 +0000

Like many Google Antigravity users, I was very excited about the Antigravity 2.0 announcement at Google I/O 2026.

Who would't be enthusiastic about the new cost efficient Gemini 3.5 Flash? Plus, a standalone desktop app form factor that seems to rival Claude Code and OpenAI Codex at that!

There are a lot of great things to be eager to try it out but I want to provide some pointers in the upgrade and migration to save you some headaches and hassles later.

The upgrade path from Antigravity 1.0 to 2.0 is straightforward:

At the Antigravity 1.0 user interface, there should be a button that asks you to restart the app to update.
Follow the steps to install Antigravity 2.0, including logging into your Google account linked to the app.
There's a call-out to install Antigravity IDE in addition to 2.0.
When you're done with the upgrade, you will be asked about customizations.

Now here's the key point: Antigravity 2.0 is a huge departure from 1.0 in the sense that it is functionally no longer based on Microsoft's VS Code. That means a huge majority of all the personalizations from 1.0 will not carry over to 2.0.

Yes, there was a quick patch that would let you import your customizations, including a migration flow that allows users to import settings, extensions, and keybindings from Antigravity 1.0. (Imagine a very eager person like me making the upgrade before this patch was applied). However any history and past work you've done in extensions like Claude, Cline, and Codex will not be carried over. Even your work history with the Gemini agents in 1.0 will not be ported.

If you want to retain as much information from your 1.0 setup, here's the playbook I wish I'd had on day one.

Back up before you click update. Specifically, copy ~/.gemini/antigravity somewhere safe. The migration has a known quirk where past conversations, scratch space, and agent brain entries get stranded in ~/.gemini/antigravity-backup rather than carried into the new app. If you've already updated and your chat history looks gone, it isn't — that's where it went. You can rsync the backup directory back into ~/.gemini/antigravity (skip mcp_config.json, you want the new one) and restart.

Say yes to installing the Antigravity IDE alongside 2.0. The IDE isn't being sunset — it's positioned as a sibling product, still maintained, still the VS Code fork you remember. That's where your keybindings, extensions, and editor muscle memory live. The cleanest mental model: 2.0 is for agent orchestration, the IDE is for everything VS Code-shaped you already do. Just don't run both against the same working tree simultaneously — you'll fight yourself.

If 2.0 isn't your speed yet, you can stay on the IDE. Uninstall 2.0, install Antigravity IDE 1.23.2 from the releases page, set updates to manual. There's no forced migration deadline on the IDE side — the deprecation pressure is on Gemini CLI users (June 18, 2026), not Antigravity IDE users.

The mental note that helped me most: this isn't a version bump. It's Google shipping a second product that shares a name with the first. Your 1.0 work doesn't need to migrate — it needs to coexist. Once I stopped expecting parity and started treating 2.0 as a new tool in the kit, I felt better about this (but still licking my wounds from the re-work and missing stuff).

Don't Make the Agent Re-Run the Test Suite to Find the Failure

Ian Johnson — Fri, 22 May 2026 18:22:38 +0000

Here is a small failure mode that cost me time for longer than it should have.

The agent would run the test suite. Tests would fail. The agent would announce that tests failed. Then, when it needed to know which tests failed, would either guess, ask, or run the suite a second time to scrape the output. Sometimes it would run it a third time. The failing tests were right there in the output of the first run; the agent didn't read them carefully enough to remember.

This is not the model being lazy. It is the model being honest about its attention. Test output is voluminous, the failure summary is buried at the bottom, and by the time the agent is reasoning about the next step ("which test failed, what assertion, what file"), the relevant lines have scrolled past whatever the agent actually retained. The cheapest way to get the information back is to run the command again.

Running the command again is the wrong answer. A full suite takes minutes. Doing it twice to learn something the first run already told you is a tax on every red-test loop, and the loops compound.

The fix: `tee` everything to a gitignored directory

The rule I added is short:

Every test command pipes through tee into .test-output/<scope>.log. The directory is gitignored. When you need to inspect failures, grep the log; do not re-run the suite.

The agent's commands now look like:

make test 2>&1 | tee .test-output/full.log
make test-parallel 2>&1 | tee .test-output/parallel.log
make vitest 2>&1 | tee .test-output/vitest.log

That is it. The fix is one Unix utility, deployed deliberately.

Why `tee` is the right tool

The trick is that tee does not replace the stream; it forks it. STDOUT still flows to the terminal in real time. The agent still sees the test run as it happens, still gets the streaming feedback that lets it react to a hang or an obvious early failure. Nothing about the foreground experience changes.

What changes is that the run is also persisted. After the command exits, the output exists as a file. The agent can grep -n FAIL .test-output/full.log, jump to the failing test, read three lines of context, and decide what to do without burning another full suite run to recover information.

You could imagine alternatives. Redirect everything to a file and tail it (loses interactive feedback). Tell the agent to "remember the test output" (the failure mode this is supposed to fix). Increase the agent's context window (treats the symptom, not the cause). The tee approach is boring, which is its strength. It uses a tool that has been in every Unix shell since 1973, costs nothing, and survives every framework choice the project might make later.

The gitignored directory matters

.test-output/ is committed nowhere. It is ephemeral: overwritten on every run, never inspected by humans, never reviewed in a PR. Making it a real directory rather than /tmp keeps it scoped to the project, which means a grep from the repo root finds it without thinking.

I also keep the filenames stable. full.log, parallel.log, vitest.log; not timestamped. The agent never has to ask "which file is the latest"? The latest is the only one. If you want history, the agent can copy it before re-running. By default, nobody needs history; they need the most recent failure.

The general lesson

The interesting thing here is not tee. It is the shape of the fix.

An agent reading a 4,000-line test run and an agent grepping a file for FAIL are doing the same work in principle, but the second one is the work the tool is good at. Long, streaming output is something an agent should read past (most of it is success noise) and only return to when a question demands it. Persisting the output to disk turns the question "what failed?" from "scroll back through my context and hope" into "run a deterministic command and read the answer."

Wherever an agent re-runs a command to recover information that was already produced, there is a tee waiting to be added. Build output. Type-check output. Linter output. Long-running scripts that print progress. Any time the command is expensive and the output is the artifact, persist the artifact. The rule shape (fork the stream, persist the artifact, grep the file) generalizes far past test runs.

The agent does not need a better memory. It needs the harness to stop throwing away information that was already on the screen.

Assembly Code to Machine Code (ARM)

Trinity — Fri, 22 May 2026 18:22:17 +0000

Summary of the video https://www.youtube.com/watch?v=ttJZjP0p_uE

I have heard assembly code is the closest of how humans can write in a fashion that machines can understand. I have never understood how. Here's the bit of how the translation occurs from assembly instruction to machine code.

In ARM Assembly, the following is the translation from assembly code to binary. After looking at each section in detail, we will try to translate ARM operations into binary operations that machine (ARM chip in this case) understands.

31:28	27:26	25	24:21	20	19:16	15:12	11:0
cond	op	I	cmd	S	Rn	Rd	Src2

Cond

Opcode [31:28]	Mnemonic extension	Interpretation	Status flag state for execution
0000	EQ	Equal / equals zero	Z set
0001	NE	Not equal	Z clear
0010	CS/HS	Carry set / unsigned higher or same	C set
0011	CC/LO	Carry clear / unsigned lower	C clear
0100	MI	Minus / negative	N set
0101	PL	Plus / positive or zero	N clear
0110	VS	Overflow	V set
0111	VC	No overflow	V clear
1000	HI	Unsigned higher	C set and Z clear
1001	LS	Unsigned lower or same	C clear or Z set
1010	GE	Signed greater than or equal	N equals V
1011	LT	Signed less than	N is not equal to V
1100	GT	Signed greater than or equal	Z clear and N equals V
1101	LE	Signed less than or equal	Z set or N is not equal to V
1110	AL	Always	any
1111	NV	Never (do not use!)	none

SOME NOTES

ADD operation takes Opcode 1110 AL for always.
Flag bit is usually the previous operation that results in some bit set. In ADDEQ it will execute if the previous instruction set Z flag to true (1).

op

I

It stands for immediate
Example, ADD, R1, R2, #0x28
If a constant / label is used, then the I field is set to 1

cmd

This is the operation that we are well aware of
It is ARM data processing instructions

Opcode [24:21]	Mnemonic	Meaning	Effect
0000	AND	Logical bit-wise AND	Rd := Rn AND Op2
0001	EOR	Logical bit-wise exclusive OR	Rd := Rn EOR Op2
0010	SUB	Subtract	Rd := Rn - Op2
0011	RSB	Reverse subtract	Rd := Op2 - Rn
0100	ADD	Add	Rd := Rn + Op2
0101	ADC	Add with carry	Rd := Rn + Op2 + C
0110	SBC	Subtract with carry	Rd := Rn - Op2 + C - 1
0111	RSC	Reverse subtract with carry	Rd := Op2 - Rn + C - 1
1000	TST	Test	Scc on Rn AND Op2
1001	TEQ	Test equivalence	Scc on Rn EOR Op2
1010	CMP	Compare	Scc on Rn - Op2
1011	CMN	Compare negated	Scc on Rn + Op2
1100	ORR	Logical bit-wise OR	Rd := Rn OR Op2
1101	MOV	Move	Rd := Op2
1110	BIC	Bit clear	Rd := Rn AND NOT Op2
1111	MVN	Move negated	Rd := NOT Op2

S

Setting S here means, we want the status of operation
For example, ADDS R1, R2, R3 means, put on the status like whether the operation will be Zero, Negative, Carry (this will be shown in CPSR register - which we will cover but not in this article)
ADDS operation will set S status to 1 and let us start tracking the status.

Rn (19:16)

It is called first source register
In ADD R1, R2, R3 Rn is R2
Hence get's binary value of 0010 in 19:16

Rd (15:12)

It is also called destination register
In ADD R1, R2, R3 Rd is R1
Hence it gets binary value of 0001 in 15:12

Src2 (11:0)

Second Source: Can be a variety of things a) Immediate b) Register c) Register-shifted Register

Immediate

11:8	7:0
rot	imm8

rot is for rotation. Mnemonic for it is ROR for rotate right.
NOTE: It is subject to rotate right by twice the value in the rotate field
11:8 bits represent the amount of rotation to right of their immediate counterpart (7:0)

Register

11:7	6:5	4	3:0
shamt5	sh	0	Rm

shamt5 represents amount of shift whether left or right
sh is the shift operators - ops table at the bottom
Rm is the register of target whose values being shifted

Register-shifted Register

11:8	7	6:5	4	3:0
Rs	0	sh	1	Rm

Rs is the register that holds the amount of shift
Rm is the target register whose value is being shifted

sh table

Instruction	sh	Operation
LSL	00	Logical shift left
LSR	01	Logical shift right
ASR	10	Arithmetic shift right
ROR	11	Rotate right

STARTING WITH THE EASY ONE `ADD R5, R6, R7`

Let's unpack one section at a time

cond is ALWAYS hence 1110, since there's no condition to prevent ADD being done.
op is 00
I is 0 (there's no immediate values here)
cmd is ADD which translates to 0100
No Status indicator ADD(S) S is omitted, hence S is 0
Rn is source, hence R6, 0110
Rd is destination, hence R5, 0101
shamt5 is 00000, since there's no shift
Sh is 00 as there's no shift
Rm is src2 hence, 7. 0111.

Combining them leads to

31:28	27:26	25	24:21	20	19:16	15:12	11:7	6:5	4	3:0
1110	00	0	0100	0	0110	0101	00000	00	0	0111
cond	op	I	cmd	S	Rn	Rd	shamt5	sh	N/A	Rm

Nicely formatted binary here:
1110 0000 1000 0110 0101 0000 0000 0111
Care to convert to hex?
0xE0865007

SLIGHTLY HARDER: `ADD R5, R6, R7, LSR #4`

we pick immediate variety for shift operations since because #4 is a literal value

Most are the same except fields 11:0
LSR has sh code as 01
LSR amount is 4 so shamt5 is 00100
Rm is 7, hence 0111

31:28	27:26	25	24:21	20	19:16	15:12	11:7	6:5	4	3:0
1110	00	0	0100	0	0110	0101	00100	01	0	0111
cond	op	I	cmd	S	Rn	Rd	shamt5	sh	null	Rm

LET'S DO MORE: `ADD R0, R1, #42`

The third one is immediate, hence
I is set to 1
Src2 becomes immediate format (rot for 11:8 and immediate value 7:0)

31:28	27:26	25	24:21	20	19:16	15:12	11:8	7:0
1110	00	1	0100	0	0001	0000	0000	00101010
cond	op	I	cmd	S	Rn	Rd	Rot	imm8

BRING SOME MORE! `SUB R2, R3, #0xFF0`

Rd is 2, Rn is 3, imm - 0xff0
SUB has 0010 code.
OH NO, BUT #0xFF0 does not fit in 8 bit.
That's ok. That's what rot is for.
0xFF0 is 0000 0000 0000 0000 0000 1111 1111 0000
0xFF is 0000 0000 0000 0000 0000 0000 1111 1111
How many shift to right will make 0xFF the 0xFF0?
1 shift right is 1000 0000 0000 0000 0000 0000 0111 1111
Following? Let's shift right a little more.
4 shift right is 1111 0000 0000 0000 0000 0000 0000 1111
8 shift right is 1111 1111 0000 0000 0000 0000 0000 0000
guess what? it takes 24 shift right to get 0xFF0!
So, rot should be 12 since by our rule the actual rotation is twice the value at rot.
Hence, the 11:8 bit values will be 1100 and 7:0 1111 1111
which is just a representation of 0xff0 into 8 bit number combined with rotation.

31:28	27:26	25	24:21	20	19:16	15:12	11:8	7:0
1110	00	1	0010	0	0011	0000	1100	11111111
cond	op	I	cmd	S	Rn	Rd	Rot	imm8

WHAT ABOUT THIS? `LSL R0, R9, #7`

WAIT WAIT... LSL is not in the command table. How am I supposed to put in the bit field 24:21?
Thanks Rakesh, the creator of the video: Basically LSL is equivalent to this: MOV R0, R9, LSL #7
Wait again... Rakesh says R9 is not Rn... Hm.. I thought it would be the same as how SUB was done above.
In the MOV operation, that's not the case, as per user guide armasm user guide page 333 MOV R0, R9, LSL #7 applies to the following syntax: MOV{S}{cond} Rd, Operand2 where operand2 is (according to page 244 the same guide) can be Register with optional shift.. Hence, on page 246 of the guide it says, register with optional shift, is Rm{, shift}.
Still following?
Hence, R9 here is Rm, where Rm is the register holding the data for the second operand.
Hence, Rn here is 0 and Rm is 9
(BY THE WAY THE REFERENCE I'M TALKING ABOUT IS armasm User Guide Version 6.6) - the latest is here

31:28	27:26	25	24:21	20	19:16	15:12	11:7	6:5	4	3:0
1110	00	0	1101	0	0000	0000	00111	00	0	1001
cond	op	I	cmd	S	Rn	Rd	shamt5	sh	null	Rm

OK TAKE A BREAK AND COME BACK! `ROR R3, R5, #21`

GUESS WHAT.. SHIFT AGAIN! Which means Rm is 5
This is equivalent to MOV R3, R5, ROR, #21
Same translation step for LSL above..

31:28	27:26	25	24:21	20	19:16	15:12	11:7	6:5	4	3:0
1110	00	0	1101	0	0000	0011	10101	11	0	0101
cond	op	I	cmd	S	Rn	Rd	shamt5	sh	null	Rm

KEY TAKEAWAY:

There's no one rule for all in the translations. Sometimes, you have to look up command table sometimes you will face operation that are not in one table hence, need to break down the command.
But, all should be translated to binary otherwise, machine won't understand! So, let's stick to the basics and see if we can translate!!!!!
Good news and bad news: You and I have learned how to translate,, not entirely but seen a bit of it... But these translation steps will be also different in A64 architecture but... we learned how to apply our knowledge in some way... Some methods must be similar... must be..

OK AFTER YOUR DINNER... `LSR R4, R8, R6`

This time the shift amount is in R6.
Does that make R8, the source register the Rn?
NOPE!!
This is equivalent to MOV R4, R8, LSR, R6
R6 is Rs haha! Found it!
Rm is 8 hohoho

31:28	27:26	25	24:21	20	19:16	15:12	11:8	7	6:5	4	3:0
1110	00	0	1101	0	0000	0100	0110	0	01	1	1000
cond	op	I	cmd	S	Rn	Rd	Rs	N/A	sh	N/A	Rm

PHEW LET'S SLEEP AFTER THIS... `ASR R5, R1, R12`

What is Rd, Rn, Rm, Rs?? Is some of them 0? Which one?
Answer below:

31:28	27:26	25	24:21	20	19:16	15:12	11:8	7	6:5	4	3:0
1110	00	0	1101	0	0000	0101	1100	0	10	1	0001
cond	op	I	cmd	S	Rn	Rd	Rs	N/A	sh	N/A	Rm

Spring boot Interview Questions

Poojitha — Fri, 22 May 2026 18:18:21 +0000

1. What is CORS and why is it required?
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that allows/restricts APIs from being accessed by another domain.
Example:
Frontend: http://localhost:3000
Backend API: http://localhost:8080
These are different origins because ports are different.
Without CORS configuration, browser blocks the request.
Why required?
To securely allow frontend applications to call backend APIs hosted on different domains/ports.
Interview Answer:
CORS is a browser security feature that controls cross-origin HTTP requests. It is required when frontend and backend run on different domains, ports, or protocols. In Spring Boot, we configure CORS to allow trusted origins to access APIs securely.
2. How do you configure CORS in Spring Boot?
Using @CrossOrigin
Java
@RestController
@CrossOrigin(origins = "http://localhost:3000")
public class UserController {
}
Global Configuration
Java
@Configuration
public class CorsConfig {

@Bean
public WebMvcConfigurer corsConfigurer() {
    return new WebMvcConfigurer() {
        @Override
        public void addCorsMappings(CorsRegistry registry) {
            registry.addMapping("/**")
                    .allowedOrigins("http://localhost:3000")           .allowedMethods("GET", "POST", "PUT", "DELETE");
        }
    };
}

}
Real-time usage:
In production, React/Angular frontend calls Spring Boot APIs from another domain.

3. What is CSRF attack?
CSRF = Cross Site Request Forgery
It tricks a logged-in user into performing unwanted actions.
Example:
User logged into banking site
Malicious website sends transfer request automatically
Browser sends session cookie
Server thinks request is genuine
Interview Answer:
CSRF attack occurs when a malicious site tricks an authenticated user into sending unauthorized requests to another application where the user is already logged in.

LambdaTest vs BrowserStack : Detail Comparison in 2026

Morris — Fri, 22 May 2026 18:18:16 +0000

Choosing between LambdaTest and BrowserStack gets harder once you actually start using both in real testing workflows.

On paper, they look very similar. Both offer cloud-based cross-browser testing, real device testing, automation support, and CI/CD integrations. But after spending time with both platforms, the differences start showing in day-to-day QA work especially around execution speed, debugging experience, pricing, and overall workflow flexibility.

BrowserStack feels more polished from an enterprise reliability perspective. Its real device cloud is mature, stable, and trusted by larger engineering teams running large-scale automation suites.

LambdaTest feels more aggressive around modern testing workflows. The platform focuses heavily on faster execution, affordability, and AI-assisted testing through Kane AI and the broader TestMu AI ecosystem.

Neither platform is objectively better for everyone.

Some teams will care more about enterprise stability and device coverage. Others will prioritize execution speed, lower costs, or AI-native testing capabilities. The right choice usually depends more on your testing workflow, team size, and automation maturity than feature lists alone.

What Is LambdaTest?

LambdaTest is a cloud-based testing platform designed for cross-browser testing, real device testing, and automated test execution.

Instead of maintaining an in-house device lab, teams can run tests across different browsers, operating systems, and real mobile devices directly from the cloud. The platform supports popular automation frameworks like Selenium, Playwright, Cypress, and Appium, which makes it easier for QA teams to integrate existing automation suites without major rewrites.

What makes LambdaTest more interesting recently is its push toward AI-assisted testing workflows. Features like Kane AI and the broader TestMu AI positioning show that the platform is trying to move beyond traditional browser testing and into AI-driven automation, test generation, and autonomous testing workflows.

From my experience, LambdaTest feels heavily optimized for teams that want:

faster parallel execution
broader browser coverage
lower infrastructure costs
easier scaling for automation
modern CI/CD-friendly testing workflows

It’s especially appealing for startups, lean QA teams, and engineering teams trying to scale testing quickly without investing heavily in physical device infrastructure.

What Is BrowserStack?

BrowserStack is one of the most widely used cloud testing platforms for cross-browser testing, mobile app testing, and real device testing.

It allows QA and engineering teams to run manual and automated tests across a large range of browsers, operating systems, and physical mobile devices without maintaining their own device infrastructure. The platform supports major automation frameworks like Selenium, Playwright, Cypress, and Appium, making it easier to scale automation across different environments.

What stood out to me while using BrowserStack was its overall stability and ecosystem maturity. The platform feels built for larger QA operations where reliability, debugging visibility, and device consistency matter more than flashy automation features.

BrowserStack also has strong enterprise adoption because of:

extensive real device coverage
stable automation infrastructure
mature debugging tools
strong security and compliance support
reliable CI/CD integrations

More recently, BrowserStack has also started moving toward AI-assisted testing workflows with features like Percy Visual Review Agent, but compared to LambdaTest, the platform still feels more infrastructure-first than AI-first.

For enterprise QA teams and mobile-heavy testing environments, BrowserStack still feels like one of the safer long-term choices.

LambdaTest vs BrowserStack: Feature Comparison Table

Both LambdaTest and BrowserStack cover the core areas most QA teams need today cross-browser testing, automation support, real device testing, and CI/CD integrations.

The real differences start showing once you compare execution speed, enterprise maturity, AI capabilities, pricing flexibility, and debugging workflows side by side.

From my experience, LambdaTest feels more aggressive around speed, pricing flexibility, and AI-native testing direction. BrowserStack feels more polished when it comes to reliability, device infrastructure, and large-scale enterprise testing operations.

Device and Browser Coverage

This is usually where the biggest differences between LambdaTest and BrowserStack start becoming noticeable in real testing workflows.

On the surface, both platforms support a wide range of browsers, operating systems, and mobile devices. But once you start running larger regression suites or mobile-heavy testing cycles, the overall experience feels different.

BrowserStack Feels Stronger for Real Device Testing

BrowserStack still feels ahead when it comes to real device infrastructure maturity.
The platform offers extensive coverage across:

real iPhones and Android devices
older browser versions
multiple OS combinations
tablet and mobile environments What stood out most during testing was consistency. Device sessions felt stable, browser rendering was reliable, and debugging mobile-specific issues was generally smoother compared to most cloud testing platforms.

For enterprise teams running large mobile test suites, stability matters a lot.

LambdaTest Focuses More on Flexibility and Scale

LambdaTest also offers strong browser and device coverage, especially for cross-browser automation workflows.

The platform performs well for:

browser compatibility testing
parallel browser execution
automation scaling
cloud-based regression testing

It also felt faster in certain parallel execution scenarios, especially during browser-heavy automation runs.

While BrowserStack still feels more mature for deep mobile device testing, LambdaTest feels more optimized for teams trying to scale browser testing efficiently without significantly increasing infrastructure costs.

Which One Is Better?

If your workflow is heavily focused on mobile app testing and real device reliability, BrowserStack still has an advantage in overall maturity and device ecosystem depth.

If your team is more focused on browser automation, faster execution, pricing flexibility, and scaling cloud-based testing quickly, LambdaTest becomes very competitive.

For most teams, the decision comes down to whether mobile device depth or browser automation efficiency matters more in day-to-day QA workflows.

Automation Framework Support

Both LambdaTest and BrowserStack support the major automation frameworks most QA teams already use today. So if your team already has an existing automation setup, migrating to either platform is usually straightforward.

The biggest difference isn’t framework compatibility itself. It’s how smooth the execution, debugging, and scaling experience feels once automation suites become larger.

Support for Modern Automation Frameworks
Both platforms support popular frameworks like:

Selenium
Playwright
Cypress
Appium
Puppeteer

They also support multiple programming languages including Java, Python, JavaScript, C#, and Ruby, which makes them flexible enough for most engineering teams.

LambdaTest Feels More Focused on Fast Automation Scaling

While testing LambdaTest, the platform felt optimized for teams trying to execute large automation suites quickly across multiple browser combinations.

Parallel execution setup was relatively simple, and the platform integrates well into CI/CD pipelines where faster feedback cycles matter heavily.

The newer AI-focused direction through Kane AI and TestMu AI also makes the platform feel more aligned with modern automation workflows rather than purely infrastructure-focused testing.

BrowserStack Feels More Mature for Stable Enterprise Automation

BrowserStack felt stronger from a reliability and debugging perspective.

Automation sessions generally felt stable, logs and recordings were easier to analyze, and mobile automation workflows were especially polished during testing. That becomes important once teams start managing large-scale enterprise regression suites where debugging failed runs consumes significant time.

For enterprise teams prioritizing stability and mature automation infrastructure, BrowserStack still feels slightly ahead overall.

Which One Is Better for Automation?

If your team prioritizes faster execution, flexible scaling, and modern AI-assisted workflows, LambdaTest feels more aggressive and developer-focused.

If stability, mature debugging workflows, and enterprise-grade mobile automation matter more, BrowserStack still has a stronger reputation in those areas.

For most teams already using Selenium, Playwright, or Cypress, both platforms are capable. The better choice usually comes down to workflow preferences rather than framework support itself.

Speed, Parallel Testing, and Test Execution

Execution speed is one of the first things teams notice once automation suites start growing.

A small regression suite might run fine anywhere, but once you begin testing across multiple browsers, devices, and environments simultaneously, platform performance starts affecting release cycles directly.

LambdaTest Focuses Heavily on Faster Parallel Execution

LambdaTest feels aggressively optimized for parallel testing and faster automation scaling.

During browser-heavy automation runs, the platform handled parallel execution smoothly, especially when running large Selenium and Playwright suites across multiple browser combinations. The setup process for scaling parallel sessions also felt relatively simple compared to some enterprise-focused platforms.

For teams running frequent CI/CD pipelines, that faster execution can reduce feedback delays significantly during regression cycles.

This is one of the areas where LambdaTest feels very startup and developer focused.

BrowserStack Prioritizes Stability Over Raw Speed

BrowserStack still performs well in parallel execution scenarios, but the platform feels more focused on reliability and consistency than aggressive execution speed.

Automation sessions generally felt stable during longer runs, especially in mobile and real-device testing workflows where infrastructure consistency matters more than shaving a few minutes off execution time.

That tradeoff makes sense for enterprise teams where failed or inconsistent test runs can create larger operational problems than slightly slower execution.

Real-World Difference Between the Two
In smaller automation suites, the speed difference between the platforms is not huge.

The differences become more noticeable when:

regression suites become larger
parallel sessions increase
multiple browser combinations run simultaneously
CI/CD pipelines require faster feedback loops

LambdaTest tends to feel faster and more execution-focused, while BrowserStack feels more stable and infrastructure-focused.

For fast-moving engineering teams shipping frequently, LambdaTest’s execution speed can become a real advantage. For enterprise environments where reliability matters more than raw execution time, BrowserStack still feels safer overall.

Visual Testing and Debugging

Visual testing and debugging are areas where both LambdaTest and BrowserStack have improved a lot over the last few years.

Once automation suites grow, execution alone is not enough. Teams also need clear debugging workflows to understand why tests failed, what changed visually, and whether failures are actually important or just noisy automation issues.

BrowserStack Feels More Mature for Visual Debugging

BrowserStack felt stronger from a debugging and reporting perspective during testing.

The platform provides:

detailed session logs
video recordings
screenshots
console logs
network logs

What stood out most was how polished the debugging workflow felt during failed automation runs. Analyzing browser behavior, reproducing issues, and tracking visual inconsistencies was generally smooth, especially in mobile testing scenarios.

BrowserStack’s Percy Visual Review Agent also pushes the platform further into AI-assisted visual regression testing, which can help teams catch unexpected UI changes earlier.

LambdaTest Focuses More on Workflow Speed

LambdaTest also offers strong debugging capabilities with logs, recordings, screenshots, and live testing visibility.

The platform feels optimized for faster troubleshooting during browser automation workflows, especially when running large parallel execution suites. Debugging information is easy to access, and session analysis feels fairly developer-friendly.

Where LambdaTest becomes more interesting is its growing AI-testing direction. Kane AI and the broader TestMu AI ecosystem suggest the platform is trying to move toward more intelligent debugging and AI-assisted automation workflows rather than traditional reporting alone.

Which Platform Handles Debugging Better?

For enterprise teams that prioritize mature debugging workflows and polished visual regression tooling, BrowserStack still feels slightly ahead overall.

For teams focused on execution speed, fast automation feedback, and modern AI-assisted workflows, LambdaTest feels more agile and developer-oriented.

Both platforms cover the core debugging features well. The real difference comes down to whether your team values enterprise stability or faster AI-driven testing workflows more.

CI/CD, Local Testing, and Integrations

Modern testing platforms are no longer just about running browser tests. They also need to fit smoothly into existing engineering workflows.

That includes CI/CD pipelines, local environment testing, GitHub-based development workflows, and debugging applications before changes reach production.

LambdaTest Feels More Developer-Focused

LambdaTest integrates well with modern CI/CD workflows and feels heavily optimized for fast automation execution inside deployment pipelines.

The platform supports integrations with:

GitHub Actions
Jenkins
GitLab CI
CircleCI
Azure DevOps

Setting up automated execution across browser combinations felt relatively straightforward, especially for teams already using Selenium or Playwright pipelines.

LambdaTest’s local testing tunnel also worked well during development-stage validation where applications are not publicly accessible yet. That becomes useful when testing staging environments, internal applications, or locally hosted builds before deployment.

BrowserStack Feels More Mature for Enterprise Workflows

BrowserStack supports similar CI/CD integrations and framework
compatibility, but the overall experience feels slightly more enterprise-oriented.

The platform integrates well into larger QA ecosystems where:

automation pipelines are already mature
multiple teams share infrastructure
security and compliance matter heavily
long-running regression suites are common

BrowserStack Local also performs reliably for testing internal environments and locally hosted applications without exposing them publicly.

What stood out most was stability. The integrations felt polished, predictable, and reliable during larger automation workflows.

Which Platform Integrates Better?

Honestly, both platforms handle modern CI/CD workflows well.

If your team prioritizes faster setup, developer-focused workflows, and aggressive automation scaling, LambdaTest feels more flexible and execution-focused.

If your organization already runs large enterprise testing pipelines and values long-term infrastructure stability, BrowserStack still feels more mature overall.

For most engineering teams, integration support probably won’t be the deciding factor because both platforms already cover the major CI/CD and automation ecosystem requirements well.

Security and Enterprise Readiness

Security and enterprise reliability become much more important once testing infrastructure starts scaling across larger engineering teams.

For startups, browser coverage and pricing usually matter most. But enterprise teams care more about things like infrastructure stability, access controls, compliance requirements, audit visibility, and long-term reliability.

This is one area where BrowserStack still feels slightly stronger overall.

BrowserStack Feels More Enterprise-Mature

BrowserStack has been heavily adopted by larger organizations for years, and the platform feels built around enterprise stability.

During testing, the platform consistently felt polished in areas like:

infrastructure reliability
session consistency
user management
debugging visibility
enterprise workflow integrations

BrowserStack also has a stronger reputation around enterprise trust, especially for organizations handling large-scale mobile testing, regulated environments, or distributed QA operations.

For bigger teams, that maturity matters because unstable infrastructure quickly becomes expensive at scale.

LambdaTest Is Catching Up Quickly

LambdaTest has improved significantly in enterprise positioning over the last few years.

The platform now supports many of the enterprise features larger teams expect, including:

secure local testing
role-based access
CI/CD integrations
scalable automation infrastructure
enterprise support workflows

What makes LambdaTest different is that the company feels more aggressive around modern AI-assisted testing workflows. Kane AI and the broader TestMu AI direction make the platform feel more innovation-focused compared to traditional cloud testing providers.

For teams prioritizing faster automation scaling and AI-native testing capabilities, that modern direction may actually matter more than enterprise legacy maturity.

Which Platform Is Better for Enterprises?

For large enterprises prioritizing long-term stability, mature infrastructure, and proven ecosystem trust, BrowserStack still feels like the safer choice overall.

For organizations looking for a more flexible, cost-conscious, and AI-focused testing platform, LambdaTest has become a very serious alternative.

The decision usually comes down to what matters more:

mature enterprise stability
AI-assisted testing innovation
infrastructure reliability
scaling costs
workflow flexibility

Both platforms are enterprise-capable today. The difference is mostly in how they approach modern testing workflows.

Pricing and Total Cost of Ownership

Pricing is one of the biggest reasons teams compare LambdaTest and BrowserStack so closely.

At first glance, both platforms seem similar. But once teams start scaling automation, parallel sessions, real device usage, and CI/CD execution, the total cost can change very quickly.

One important thing to remember is that pricing changes frequently, especially as both companies continue expanding AI testing and enterprise offerings. It’s always worth verifying the latest plans directly before making a final decision.

LambdaTest Is Usually More Affordable

LambdaTest is generally positioned as the more cost-effective option, especially for startups and automation-heavy teams.

Current pricing commonly starts around:

$15/month for live testing plans
~$79/month for automation-focused plans

higher pricing for HyperExecute and enterprise scaling
The platform also offers a free tier with limited testing access, which makes it easier for smaller teams to experiment before committing to larger plans.

What makes LambdaTest attractive financially is that:

parallel execution costs scale more gradually
automation-focused plans are comparatively cheaper
HyperExecute can reduce execution time significantly
teams can scale browser testing without massive upfront infrastructure costs For lean QA teams, the pricing-to-performance ratio feels very competitive.

BrowserStack Has a Higher Enterprise Price Positioning

BrowserStack is usually more expensive, especially once real-device automation and enterprise-scale parallel execution are involved.

Typical pricing often starts around:

$29–$39/month for live testing
$129–$199/month for automation plans

higher enterprise pricing for larger QA teams and advanced device access
The pricing increases faster when teams need:

more parallel sessions
larger real-device access
enterprise support
advanced security and compliance
large-scale automation execution

That said, many enterprises are willing to pay the premium because BrowserStack’s infrastructure maturity and real-device ecosystem are still considered among the strongest in the market.

In practice, LambdaTest usually feels more cost-efficient for fast-growing teams and aggressive automation scaling, while BrowserStack feels more optimized for enterprise reliability and long-term infrastructure stability.

LambdaTest vs BrowserStack: Which One Should You Choose?

After using both platforms in real testing workflows, I don’t think this decision comes down to feature checklists alone. Both tools already cover the basics extremely well. The better choice usually depends on how your team tests software, how fast you scale automation, and what problems you’re trying to solve.

Choose LambdaTest If You Want Faster Scaling and Lower Costs

LambdaTest makes more sense for teams that prioritize:

faster parallel execution
aggressive automation scaling
affordable pricing
browser-heavy testing workflows
AI-assisted testing features

The platform feels more modern and developer-focused overall. Features like Kane AI and the broader TestMu AI direction also make it appealing for teams exploring AI-native testing workflows rather than traditional cloud testing alone.

For startups, lean QA teams, and fast-moving engineering organizations, LambdaTest often feels easier to scale financially without sacrificing too much functionality.

Choose BrowserStack If You Prioritize Enterprise Stability

BrowserStack feels stronger when stability, mature infrastructure, and real-device reliability matter most.

It’s usually a better fit for:

enterprise QA teams
large mobile testing environments
organizations running massive regression suites
teams requiring mature debugging workflows
companies with stricter compliance and infrastructure expectations

The platform feels polished and consistent, especially during large-scale automation and real-device testing workflows. That reliability becomes very valuable once testing operations grow across multiple teams and pipelines.

My Practical Take After Testing Both

If I were building a fast-moving startup QA workflow today, I’d probably lean toward LambdaTest because of the pricing flexibility, execution speed, and AI-focused direction.

If I were managing enterprise-scale automation with heavy mobile testing requirements, I’d still trust BrowserStack slightly more because of its infrastructure maturity and overall ecosystem stability.

The good news is that both platforms are strong enough now that most teams won’t make a “wrong” choice. The better decision usually comes down to:

speed vs stability
affordability vs enterprise maturity AI-native workflows vs traditional infrastructure reliability That matters far more than small feature differences on comparison pages.

Top Test Automation Platforms Replacing BrowserStack & LambdaTest in 2026

For a long time, most teams compared only BrowserStack and LambdaTest when choosing a cloud testing platform.

That’s changing quickly.

In 2026, QA teams are looking beyond traditional browser infrastructure. They want platforms that reduce automation maintenance, support AI-assisted testing, improve debugging, and fit modern CI/CD workflows without slowing releases down.

A few platforms are starting to stand out because they focus on more than just running browser sessions in the cloud.

TestGrid

TestGrid is a strong alternative enterprise-grade testing platform that combines real-device testing, automation, AI-powered workflows, and testing infrastructure into a single platform.

It supports web, mobile, API, performance, and cross-browser testing while integrating with frameworks like Selenium, Appium, and Cypress.

Through CoTester™, TestGrid also adds AI-powered assistance for test generation, execution, and maintenance workflows, helping teams reduce repetitive QA effort and scale testing more efficiently.

Sauce Labs

Sauce Labs still remains one of the strongest enterprise-focused alternatives in the market.The platform is heavily used by larger organizations running large automation suites across Selenium, Playwright, and mobile testing pipelines. Compared to BrowserStack and LambdaTest, Sauce Labs feels very enterprise-oriented and stability-focused.

It’s usually a better fit for organizations that already have mature automation processes in place.

Kobiton

Kobiton stands out mainly for mobile testing.Teams building mobile-first applications often prefer Kobiton because the platform focuses deeply on real-device mobile automation, Appium workflows, and mobile performance validation rather than broad browser testing alone.

Compared to LambdaTest and BrowserStack, it feels much more specialized around mobile QA.

Perfecto

Perfecto continues to position itself strongly in enterprise mobile and web testing.

The platform focuses heavily on reliability, reporting, compliance, and large-scale automation stability. It’s commonly used in organizations where testing infrastructure maturity matters more than aggressive execution speed or low pricing.

For enterprise QA operations, Perfecto still feels like one of the more stable long-term options.

HeadSpin

HeadSpin approaches testing differently compared to traditional cloud testing platforms.Instead of focusing only on automation execution, the platform combines testing with performance monitoring and real-world user experience analysis. That makes it more appealing for teams that care heavily about mobile app performance and production-like testing environments.

Selenium Grid

Some teams are still moving away from cloud platforms entirely and building internal automation infrastructure using Selenium Grid.

It offers full control over browser execution and scaling, but also requires significantly more maintenance and infrastructure management. For organizations with strong DevOps support, that tradeoff can still make sense financially at a very large scale.

Final Verdict

After testing both LambdaTest and BrowserStack, I don’t think there’s a universal winner.

LambdaTest feels more modern and execution-focused. It’s a strong fit for teams that want faster automation scaling, lower costs, and AI-assisted testing workflows.

BrowserStack still feels stronger from an enterprise reliability perspective. Its real-device infrastructure, debugging workflows, and ecosystem maturity make it a safer choice for larger QA operations.

In the end, the better platform depends on your workflow. If your team prioritizes speed, flexibility, and AI-native testing, LambdaTest will probably feel more appealing. If stability, mobile testing maturity, and enterprise reliability matter more, BrowserStack still has the edge.

Frequently Asked Questions

Which is better: LambdaTest or BrowserStack?

LambdaTest usually feels better for teams prioritizing faster execution, lower pricing, and AI-assisted testing workflows. BrowserStack feels stronger for enterprise reliability, real-device coverage, and mature mobile testing infrastructure.

The better choice depends on your testing workflows, automation scale, and infrastructure needs.

Is LambdaTest cheaper than BrowserStack?

In most cases, yes.LambdaTest is generally more affordable for startups and growing QA teams, especially when scaling parallel automation execution. BrowserStack usually has higher pricing because of its mature enterprise infrastructure and larger real-device ecosystem.

However, total cost also depends on parallel sessions, real-device usage, and enterprise support requirements.

Do LambdaTest and BrowserStack support Playwright and Cypress?

Yes. Both platforms support modern automation frameworks including:

Playwright
Cypress
Selenium
Appium

That makes it relatively easy for teams to migrate existing automation suites without major framework changes.

Which platform is better for real device testing?

BrowserStack still feels slightly stronger overall for real-device testing, especially in enterprise mobile testing environments.

Its device ecosystem, session stability, and debugging workflows feel more mature during large-scale mobile testing. LambdaTest also offers strong device coverage, but BrowserStack currently feels more polished for deep mobile QA workflows.

Does AI testing change the LambdaTest vs BrowserStack decision?

It can, especially for teams exploring AI-assisted QA workflows.

LambdaTest is pushing more aggressively into AI-native testing through Kane AI and the broader TestMu AI ecosystem. That makes the platform more appealing for teams interested in AI-generated tests, autonomous workflows, and faster automation scaling.

BrowserStack is also adding AI-assisted features like Percy Visual Review Agent, but the platform still feels more infrastructure-first than AI-first overall.

What is the best alternative to BrowserStack?

The best alternative to BrowserStack is TestGrid, especially for teams that want real device testing, browser automation, mobile app testing, and AI-assisted QA workflows in one platform.

Unlike traditional cloud testing platforms focused mainly on browser infrastructure, TestGrid combines automation, real-device cloud testing, visual testing, performance validation, codeless testing, and AI-powered workflows through CoTester. It also supports frameworks like Selenium, Appium, and Cypress while integrating directly into existing CI/CD and engineering workflows.

For organizations looking for scalable testing across cloud, hybrid, dedicated, or on-premise environments, TestGrid has become a strong BrowserStack alternative for modern enterprise QA teams.

Como eu acelerei o desenvolvimento frontend utilizando ferramentas de IA e o MCP do Figma

Danilo Itagyba — Fri, 22 May 2026 18:17:46 +0000

Ferramentas de IA aceleram muito o desenvolvimento frontend, mas só funcionam bem quando recebem contexto, limites e validação.

O ganho real não veio de pedir “crie uma tela”. Veio de organizar o fluxo:

instruções claras para o agente
integração com design via Figma MCP
mudanças pequenas
revisão humana
testes automatizados
validação visual com Playwright

O problema: IA sem contexto gera ruído

Um prompt assim normalmente gera dívida técnica:

Crie essa tela em React.

O resultado tende a vir com:

componentes grandes
CSS fora do padrão
nomes genéricos
regra de negócio misturada com UI
poucos testes
layout quebrando em estados reais

O que funcionou melhor foi tratar a IA como parte do fluxo de engenharia.

Codex com instruções do projeto

No Codex, usei um AGENTS.md para definir como o agente deve trabalhar no repositório.

Em vez de repetir regras em todo prompt, deixei o projeto explicar:

stack
estrutura de pastas
padrão de testes
comandos principais
regras de TypeScript
cuidados com integração
checklist antes de finalizar

No corpo do artigo, deixo só a ideia. O exemplo completo está no final: AGENTS.md exemplo.

Um prompt melhor para Codex fica assim:

Refatore este componente seguindo o AGENTS.md.
Mantenha o comportamento visual.
Adicione testes relevantes.
Rode lint e testes.

Isso muda bastante o resultado. O agente passa a respeitar o projeto em vez de inventar um padrão novo.

O mesmo conceito pode ser aplicado a outras ferramentas, como Claude, com alguns ajustes no arquivo de instruções. No Claude, por exemplo, eu usaria um CLAUDE.md mais focado em análise, revisão e tomada de decisão, enquanto no Codex o AGENTS.md fica mais direcionado à execução dentro do repositório.

Figma MCP no fluxo frontend

O MCP do Figma aproxima design e implementação.

Ele permite que o agente leia contexto do Figma, como:

estrutura da tela
nomes de layers
textos
medidas
componentes
variáveis
estilos

Isso ajuda muito em tarefas como:

Use o frame selecionado no Figma como referência e implemente a tela usando os componentes existentes do projeto.

O ponto importante: o MCP não substitui engenharia frontend. Ele reduz o atrito entre design e código.

Ainda é necessário:

adaptar ao design system do projeto
reaproveitar componentes existentes
validar responsividade
revisar acessibilidade
testar estados reais

Como configurar o MCP do Figma

A forma exata muda conforme o cliente, mas o fluxo geral é:

Instalar e abrir o Figma Desktop.
Abrir o arquivo de design.
Entrar em Dev Mode.
Ativar o Dev Mode MCP Server.
Configurar o cliente MCP para apontar para o servidor local.

O servidor local oficial do Figma usa HTTP, normalmente em:

http://127.0.0.1:3845/mcp

Exemplo genérico de configuração MCP:

{
  "mcpServers": {
    "figma-desktop": {
      "transport": "http",
      "url": "http://127.0.0.1:3845/mcp"
    }
  }
}

Depois disso, o agente pode receber prompts como:

Leia o frame selecionado no Figma e compare com a implementação atual.

ou:

Use o design selecionado como referência e implemente a tela mantendo os padrões do projeto.

Fluxo prático com Codex

O fluxo que mais funcionou foi:

1. Ler instruções do projeto
2. Inspecionar arquivos relevantes
3. Fazer mudança pequena
4. Adicionar ou ajustar testes
5. Rodar lint, testes e build
6. Revisar diff
7. Só então finalizar

IA acelera, mas testes e revisão seguram a qualidade.

Testes são o contrato

Sem testes, a IA acelera a entrega e também acelera regressões.

Usei diferentes camadas de teste.

Teste unitário

Para função pura:

it('formats currency', () => {
  expect(formatCurrency('10.5')).toBe('R$ 10,50')
})

Teste de componente

Para comportamento visível:

it('increments quantity', async () => {
  render(<QuantityStepper />)
  await user.click(screen.getByRole('button', { name: /aumentar/i }))
  expect(screen.getByRole('textbox')).toHaveValue('2')
})

Teste de hook

Para estado reutilizável:

it('loads data', async () => {
  const { result } = renderHook(() => useItems())
  await waitFor(() => expect(result.current.isLoading).toBe(false))
})

Teste de API

Para contrato com backend:

it('parses response', async () => {
  mockFetch({ success: true, data: { id: '1' } })
  await expect(fetchItem('1')).resolves.toEqual({ id: '1' })
})

E2E com Playwright

Para fluxo real:

test('opens product detail', async ({ page }) => {
  await page.goto('/app')
  await page.getByRole('textbox', { name: /referência/i }).fill('ABC')
  await page.getByRole('button', { name: /realizar leitura/i }).click()
  await expect(page.getByRole('region', { name: /dados/i })).toBeVisible()
})

Teste de layout

Para proteger alinhamento e scroll:

const box = await page.locator('.content').evaluate((el) => ({
  clientHeight: el.clientHeight,
  scrollHeight: el.scrollHeight,
}))

expect(box.scrollHeight).toBeLessThanOrEqual(box.clientHeight + 1)

Teste de screenshot

Para telas visualmente sensíveis:

test('matches open form layout', async ({ page }) => {
  await page.setViewportSize({ width: 1456, height: 793 })
  await page.goto('/app')
  await page.getByRole('button', { name: /verificar/i }).click()
  await expect(page).toHaveScreenshot('form-open.png')
})

Esse teste pega regressões difíceis de cobrir só com assertions:

botão quebrando linha
texto saindo do container
painel desalinhado
scroll inesperado
espaçamento quebrado

O que mudou na prática

Com esse fluxo, o Codex virou uma ferramenta de engenharia, não só geração de código.

Ganhos principais:

menos tempo em boilerplate
refactors mais rápidos
testes criados junto com a alteração
design mais próximo da implementação
regressões visuais detectadas cedo
revisão mais objetiva
padrões documentados no repositório

Conclusão

Codex e MCP do Figma ajudam muito no desenvolvimento frontend.

Mas a aceleração sustentável vem da combinação:

contexto claro
instruções versionadas
mudanças pequenas
testes automatizados
validação visual
revisão humana

IA boa não substitui engenharia. Ela aumenta a velocidade de quem sabe definir limites e validar resultado.

AGENTS.md exemplo

# AGENTS.md

## Purpose

This project uses React, Vite and TypeScript with a focus on predictable, typed, testable and maintainable code.

## Language Rule

- All source code must be written in English.
- Use English for identifiers, file names, comments, constants and test names.
- User-facing UI copy may follow product requirements.

## Stack

- React
- Vite
- TypeScript
- ESLint
- Vitest + Testing Library
- Playwright

## Main Commands

- `npm run dev`
- `npm run build`
- `npm run lint`
- `npm run test`
- `npm run test:e2e`

Before closing a meaningful change, run at least `npm run lint` and the relevant test suite.

## Project Structure

- `src/app`: app composition and providers
- `src/pages`: route-level pages
- `src/features`: domain-specific modules
- `src/shared`: reusable UI, styles, config and utilities
- `src/test`: Vitest setup and helpers
- `e2e`: Playwright specs and page objects

## Core Conventions

- Prefer small, local and predictable changes.
- Prefer composition over premature abstraction.
- Keep business logic out of purely visual components.
- Avoid generic `utils.ts` dumping grounds.
- Use explicit names for files, functions, props and types.
- Do not introduce `any` unless there is a strong reason.

## React and TypeScript

- Use functional components.
- Keep components focused on one responsibility.
- Derive values from props and state instead of duplicating state.
- Use `useEffect` only for real side effects.
- Do not add `useMemo` or `useCallback` by default.

## Testing

- Test user-visible behavior, not implementation details.
- Prefer Testing Library queries by role, text or label.
- Add tests when fixing bugs or introducing meaningful flows.
- Keep unit, integration and E2E scopes separate.

## Checklist

- The change respects project boundaries.
- Types are clear.
- No redundant state was introduced.
- Relevant linting and tests were executed.

Referências

Figma Dev Mode MCP Server: https://developers.figma.com/docs/figma-mcp-server/local-server-installation/
Guia do Figma MCP Server: https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server

Track YC Demo Day Companies in Real Time (with code)

NexGenData — Fri, 22 May 2026 18:15:30 +0000

Track YC Demo Day Companies in Real Time (with code)

Y Combinator Demo Day is the single most concentrated VC sourcing event of the year. Twice annually, ~250 companies present back-to-back over 1-2 days. Within 48 hours, the top 50 have term sheets. Within 7 days, the next 50 have term sheets. By day 14, the remaining 150 are either oversubscribed or starting to struggle.

The associate's job at a multi-stage fund during Demo Day is roughly:

Within 6 hours: scrape every company's details from the YC site
Within 12 hours: triage to the 30-50 worth investigating
Within 24 hours: book first calls with the top 15
Within 48 hours: close on the top 5

The bottleneck is step 1 — and it's an entirely-solvable bottleneck. YC's company directory updates in real time as Demo Day progresses. The Algolia-indexed search behind the YC site is publicly queryable. With 50 lines of Python you can pull the full active-batch roster in under 5 seconds, refresh every 90 seconds, and have a live feed during Demo Day itself.

This post is the working code, the join logic, and the prioritization framework. The NexGenData YC Companies Directory actor wraps this if you want a hosted version.

The YC Algolia Endpoint

YC's company list page (https://www.ycombinator.com/companies) is fully client-rendered. The page bundle includes a hardcoded Algolia application ID and a public read-only API key. Both are visible in the browser dev tools network tab.

import httpx

YC_ALGOLIA_URL = "https://45bwzj1sgc-dsn.algolia.net/1/indexes/YCCompany_production/query"
YC_ALGOLIA_HEADERS = {
    "X-Algolia-Application-Id": "45BWZJ1SGC",
    "X-Algolia-API-Key": "Y2VkOWQyMTJlYjZkZjE3MDRkY2YyNjBmYmIzMjVhMzA1ZmRlYTQ4OTUyZjEyZjRiNzc0OWQ4MjRmMzVlYmUxN3RhZ0ZpbHRlcnM9JTViJTIyJTVEJmZpbHRlcnM9aXNIaXJpbmclM0F0cnVl",
    "Content-Type": "application/json",
}

async def fetch_yc_batch(batch: str = "S26") -> list[dict]:
    """Fetch all companies in a specific YC batch."""
    payload = {
        "query": "",
        "hitsPerPage": 1000,
        "facetFilters": [[f"batch:{batch}"]],
    }
    async with httpx.AsyncClient(headers=YC_ALGOLIA_HEADERS, timeout=20) as client:
        r = await client.post(YC_ALGOLIA_URL, json=payload)
        r.raise_for_status()
        return r.json().get("hits", [])

A response hit looks like:

{
  "name": "ExampleCo",
  "slug": "exampleco",
  "batch": "S26",
  "industry": "B2B",
  "subindustry": "DevTools",
  "team_size": 4,
  "regions": ["United States of America"],
  "isHiring": true,
  "stage": "Active",
  "tags": ["api", "developer-tools"],
  "description": "ExampleCo lets developers...",
  "website": "https://exampleco.com",
  "long_description": "ExampleCo is the missing layer between..."
}

For a full active batch, expect 200-280 hits. Demo Day batches are gradually populated over the 90-day program — by Demo Day itself, all companies are publicly searchable.

Polling for Real-Time Updates

During Demo Day, YC's batch index updates in waves as companies present. To get a live feed:

import asyncio
from datetime import datetime

async def live_demo_day_tracker(batch: str, interval: int = 90):
    seen_slugs = set()
    while True:
        try:
            companies = await fetch_yc_batch(batch)
            new = [c for c in companies if c["slug"] not in seen_slugs]
            for c in new:
                print(f"[{datetime.now().isoformat()}] NEW: {c['name']} - {c['description'][:80]}")
                seen_slugs.add(c["slug"])
        except Exception as e:
            print(f"  poll error: {e}")
        await asyncio.sleep(interval)

Polling every 90 seconds is gentle on YC's Algolia backend and keeps you within ~2 minutes of the actual update. Run it in a tmux session during Demo Day; pipe output to Slack via a webhook for team-wide visibility.

Triage Logic: From 250 Companies to 30 Worth Investigating

The hard part of Demo Day isn't ingest — it's prioritization. The naive approach (read all 250 descriptions) burns 3-4 hours and produces lukewarm shortlists. The better approach: pre-define your fund's thesis filters and score each company automatically.

A simple scoring model:

def score_yc_company(c: dict, thesis: dict) -> int:
    score = 0

    # Industry alignment (0-30 points)
    if c.get("industry") in thesis["target_industries"]:
        score += 30
    elif c.get("industry") in thesis["adjacent_industries"]:
        score += 15

    # Team size sweet spot (0-15 points)
    team = c.get("team_size", 0)
    if thesis["min_team"] <= team <= thesis["max_team"]:
        score += 15
    elif team < thesis["min_team"]:
        score += 5  # too early but not disqualifying

    # Hiring signal (0-10 points)
    if c.get("isHiring"):
        score += 10

    # Geography (0-10 points)
    regions = c.get("regions", [])
    if any(r in thesis["target_regions"] for r in regions):
        score += 10

    # Tag overlap (0-20 points, 5/tag up to 4)
    tag_overlap = set(c.get("tags", [])) & set(thesis["target_tags"])
    score += min(20, len(tag_overlap) * 5)

    # Description-based filter — keyword presence (0-15 points)
    desc = (c.get("description", "") + " " + c.get("long_description", "")).lower()
    keyword_hits = sum(1 for kw in thesis["target_keywords"] if kw in desc)
    score += min(15, keyword_hits * 5)

    return score

Sample thesis config for a B2B-SaaS-focused pre-seed fund:

B2B_SAAS_PRESEED = {
    "target_industries": ["B2B"],
    "adjacent_industries": ["Fintech", "Healthcare"],
    "min_team": 2, "max_team": 8,
    "target_regions": ["United States of America", "Canada"],
    "target_tags": ["api", "developer-tools", "saas", "infrastructure",
                     "automation", "analytics", "data"],
    "target_keywords": ["api", "platform", "automation", "developer",
                        "dashboard", "analytics", "infrastructure"],
}

Run all 250 companies through the scoring function, sort by score descending, and the top 30 are your day-1 outbound list. Top 80 is your day-2/3 follow-up list. The bottom 140 you ignore unless something specific surfaces in a peer-investor conversation.

This whole pipeline — fetch + score + sort — runs in under 8 seconds on a laptop. By contrast, manual triage of the same 250 companies takes 3-4 hours and is biased by reading order.

Cross-Referencing With External Signals

The real edge during Demo Day comes from cross-referencing YC's company data with external signals you've been tracking. Two sources that meaningfully sharpen the YC list:

LinkedIn founder signal. For each YC company, look up the founder LinkedIn profiles. Founders with prior senior IC roles at brand-name companies (FAANG, Stripe, Datadog, Snowflake, etc.) score 1.5-2x on conversion vs first-time founders without that pedigree. Auto-adding a "founder pedigree" multiplier pulls the right companies forward without manual triage.

Hacker News engagement. YC companies whose CEO has an HN account with >500 karma and recent post history are statistically more articulate, more likely to be making something engineers want to talk about, and more likely to convert on a thoughtful cold email. The NexGenData Hacker News Scraper actor pulls user metadata including karma and post counts.

Show HN history. A YC company whose founder previously launched a Show HN post (even a different project) is, statistically, in the top quartile of demo day quality. Show HN selects for builders. Pull this with the NexGenData Show HN Tracker actor.

The Cost of Not Automating This

Most VC sourcing teams I've worked with at series-A firms don't have a real demo day automation pipeline. They send 1-2 associates to the live event, take notes, and triage by hand over the following week. By the time their shortlist is ready, the top 30 companies have already had calls with 5-10 funds and are in active term-sheet negotiations.

The cost isn't the data — YC publishes everything for free. The cost is the speed delta. A team running this pipeline can triage on the day of demo day and book first calls within 48 hours. A team triaging by hand books first calls 5-10 days later, by which time the deal is set.

Cost of building it yourself: ~1 day of engineering, then ~$5/month of compute. Cost of using the YC Companies Directory actor: $0.01/company × ~270 companies/batch = ~$2.70/batch, runnable on demand.

NexGenData publishes 195+ actors covering startup-stage signals: YC alumni, Show HN, Product Hunt, Delaware C-corp formations, SEC Form D, and more. All pay-per-result.

Google’s AI Search Demos Revealed a Ranking Crisis Hiding Inside the Web

Touhidul Islam Protik — Fri, 22 May 2026 18:12:13 +0000

The most revealing part of Google I/O 2026 wasn’t the AI.

It was what quietly disappeared from the search result.

Links.

Not completely.
Not yet.

But enough to expose a growing tension Google rarely addresses directly:

AI-native search changes the economic structure of the web itself.

And I don’t think the industry fully understands the consequences yet.

Search Results Used to Be Destinations

Classic Google Search operated on a relatively stable exchange.

Websites created information.
Google indexed and ranked it.
Users clicked through.

Everyone benefited differently:

users got discovery
publishers got traffic
Google got engagement
creators got visibility

The ecosystem depended on referral flow.

That flow shaped:

SEO
publishing
blogging
affiliate systems
journalism
tutorials
documentation
even startup growth models

Search visibility became distribution infrastructure for the internet itself.

That’s why ranking mattered so much.

AI Overviews Quietly Alter the Incentive Structure

Google’s recent AI search experiences increasingly collapse:

retrieval
summarization
synthesis
recommendation

into a single interface layer.

The user asks something complex.

The system:

interprets intent
extracts information
synthesizes responses
generates follow-up reasoning
sometimes completes the task directly

without requiring navigation across multiple websites.

From a user perspective, this feels efficient.

From a web ecosystem perspective, it changes everything.

Because the moment answers stop requiring visits,
traffic dynamics change fundamentally.

The Important Shift Isn’t “Better Search”

It’s Search Becoming an Execution Layer

This distinction matters.

Traditional search engines helped users locate destinations.

AI-native search increasingly attempts to complete objectives internally.

That sounds subtle until you realize how much software architecture depends on outbound interaction.

Historically:

search → website → action

Now the pipeline increasingly becomes:

search → synthesis → completion

That bypass layer is economically significant.

Especially for:

publishers
forums
educational sites
independent blogs
comparison platforms
long-tail creators

The web was built around referral behavior.

AI-native retrieval compresses that behavior aggressively.

Google’s Demos Kept Prioritizing Completion Over Navigation

This pattern appeared repeatedly throughout recent I/O showcases.

The system wasn’t merely finding information.

It was:

planning trips
comparing products
summarizing research
scheduling actions
organizing decisions
maintaining conversational continuity

The interaction goal shifted from:

“show relevant pages”

to:

“reduce interaction friction entirely.”

That’s a very different philosophy of search.

And honestly, it starts resembling an operating environment more than a discovery engine.

AI Summarization Creates an Attribution Compression Problem

This is where things become structurally uncomfortable.

Large models depend heavily on web-scale information ecosystems.

But synthesized outputs compress visibility dramatically.

Ten websites may contribute signal.
One interface delivers the answer.

The user experiences coherence.

The ecosystem experiences invisibility.

That creates a strange imbalance:
the systems benefiting most from the open web may gradually reduce the visibility incentives sustaining that same web.

And unlike earlier search evolution,
this compression happens conversationally.

Which makes source boundaries feel psychologically weaker.

Reddit Became Valuable for a Reason

One fascinating trend across Google’s AI search evolution:

Human discussion suddenly became premium data.

Especially:

Reddit
forums
niche communities
long-tail expertise
experience-heavy content

Why?

Because heavily SEO-optimized content became increasingly homogeneous.

A huge portion of the web started sounding structurally identical:

optimized headings
repeated keywords
templated formatting
rewritten summaries
affiliate-driven language

LLMs exposed that sameness brutally.

Human unpredictability became useful again.

Messy opinions.
Specific experiences.
Contradictions.
Actual personality.

Ironically, AI may have accidentally increased the value of authentic human context.

AI Search Quietly Weakens Traditional SEO Assumptions

For years, SEO mostly optimized around:

ranking position
click-through rates
keyword relevance
structured metadata
backlink authority

AI-native search introduces new dynamics:

chunk retrieval
semantic relevance
synthesis quality
conversational usefulness
citation selection
answer extraction

The unit of visibility shifts from:

“page ranking”

toward:

“extractable informational utility.”

That’s a much stranger optimization target.

Especially because users may consume the information
without ever visiting the original source.

This May Create a “Visibility Without Audience” Problem

A website can influence AI-generated answers heavily
while receiving almost no direct user interaction.

That’s historically unusual.

Previously:
visibility and audience were tightly connected.

Now they may separate.

A creator’s knowledge might shape millions of AI interactions invisibly while generating:

fewer visits
weaker branding
lower subscriber growth
reduced monetization opportunities

The web has never really operated under those conditions before.

And I honestly don’t think we know what sustainable incentives look like there yet.

Google Seems to Be Optimizing for Cognitive Efficiency

This became increasingly obvious during the demos.

The system’s goal wasn’t:

exploration
browsing
wandering
discovery depth

It was compression.

Fewer tabs.
Fewer clicks.
Less reconstruction effort.
Less navigation overhead.

From a usability perspective, that’s compelling.

From an internet ecosystem perspective, it’s destabilizing.

Because the open web historically depended on friction-driven exploration.

Curiosity often emerged accidentally:

related articles
side links
forum tangents
rabbit holes
unexpected creators

AI synthesis compresses those pathways aggressively.

The experience becomes efficient.

Potentially too efficient.

The Web May Slowly Split Into Two Layers

I keep coming back to this possibility.

One layer becomes:

machine-readable
retrieval-optimized
structured for AI synthesis

The other becomes:

personality-driven
experiential
community-based
difficult to compress cleanly

Because purely informational content is increasingly vulnerable to summarization abstraction.

But:

perspective
identity
lived experience
trust
humor
voice
interpretation

still resist compression much more effectively.

That may explain why personal writing suddenly feels more valuable again.

Google Isn’t Just Rebuilding Search

It’s renegotiating the relationship between information and interaction.

That’s a much larger transition than “AI answers.”

Because once search engines stop functioning primarily as traffic routers,
the structure of the web itself changes with them.

And honestly, I don’t think the final outcome depends on model intelligence nearly as much as incentive design.

Historically, the internet grew because visibility rewarded contribution.

AI-native search quietly weakens that exchange.

The difficult question now is whether the web can remain generative
after the referral loop starts collapsing underneath it.

I Got Tired of Passing --profile on Every OCI CLI Command

Amaan Ul Haq Siddiqui — Fri, 22 May 2026 18:12:00 +0000

This is a problem you only run into if you work for Oracle directly or you work at a Cloud/DevOps MSP managing OCI for multiple clients. Most people will never touch it. If you are reading this, you are probably not most people.

The OCI CLI already demands a --compartment-id on almost every command. Compartment IDs are long, they are not memorable, and you need a different one depending on what you are looking at. That was already a nightmare before you add multiple tenancies to the picture. Once you are juggling prod, staging, dev, and a handful of client accounts, passing --profile on top of --compartment-id on every single command becomes the kind of friction that breaks you.

So I wrote ocswitch.

What the OCI CLI Actually Gives You

The OCI CLI reads config from ~/.oci/config by default. You can point it at a different file with OCI_CONFIG_FILE, and select a named profile within that file with OCI_CLI_PROFILE. That is the full surface area you have to work with.

The multi-profile story in the official tooling is basically: put multiple [PROFILE_NAME] sections in one config file and pass --profile PROFILE_NAME every time. If you forget the flag, you hit whichever profile is in [DEFAULT]. This works but it is tedious, and it is session-scoped - export the env var in one terminal, open another, you are back to default.

ocswitch fixes the persistence problem by writing the active profile to ~/.oci/active_profile and restoring it at shell startup.

How It Works

Profiles are separate config files in ~/.oci/:

~/.oci/config_prod
~/.oci/config_staging
~/.oci/config_dev

One file per tenancy, named config_<profile>. When you switch:

ocswitch prod

Two things happen: ~/.oci/active_profile gets written with the string prod, and OCI_CONFIG_FILE plus OCI_CLI_PROFILE are exported in the current shell. Every oci command you run after that hits the prod tenancy.

The persistence part lives at the top of the script, outside the function, so it runs every time the shell sources the file:

_oci_state="${HOME}/.oci/active_profile"
if [[ -f "$_oci_state" ]]; then
  _oci_profile=$(cat "$_oci_state")
  _oci_cfg="${HOME}/.oci/config_${_oci_profile}"
  if [[ -f "$_oci_cfg" ]]; then
    export OCI_CONFIG_FILE="$_oci_cfg"
    export OCI_CLI_PROFILE="config_${_oci_profile}"
  fi
fi

Open a new terminal, source kicks in, reads the state file, exports the right vars. The active profile follows you across sessions without any extra steps.

What It Looks Like

ocswitch list shows all detected profiles (anything matching ~/.oci/config_*) with the active one highlighted in Oracle red. ocswitch clear removes the state file and unsets both env vars.

Tab completion is included for both bash and zsh. Hit tab after ocswitch and you get list, clear, and all your profile names.

The ocid Bonus

There is a second function in the script: ocid. It reads the active config, pulls the tenancy OCID and user OCID out of it, and calls the OCI IAM API to resolve the human-readable names:

Tenant Name: mycompany-production
Tenant ID:   ocid1.tenancy.oc1..aaaa...
User Email:  user@example.com

Useful when you have switched between a few profiles and want to confirm exactly which tenancy you are currently pointing at before running something destructive.

Install

zsh

curl -fsSL https://gist.githubusercontent.com/amaanx86/2621a181e2f4b572a1904d65748d66bd/raw/ocswitch.zsh \
  -o ~/.oci/ocswitch.zsh
echo 'source ~/.oci/ocswitch.zsh' >> ~/.zshrc
source ~/.zshrc

bash

curl -fsSL https://gist.githubusercontent.com/amaanx86/2621a181e2f4b572a1904d65748d66bd/raw/ocswitch.bash \
  -o ~/.oci/ocswitch.bash
echo 'source ~/.oci/ocswitch.bash' >> ~/.bashrc
source ~/.bashrc

Usage

ocswitch               # show help + logo
ocswitch list          # list profiles (active highlighted)
ocswitch <profile>     # switch profile (persists across all terminals)
ocswitch clear         # clear active profile

Profile Setup

Each profile is a standard OCI config file at ~/.oci/config_<profile>. The section header inside the file uses the same name as the file itself, not [DEFAULT]:

[config_prod]
user=ocid1.user.oc1..aaaa...
fingerprint=xx:xx:xx:...
tenancy=ocid1.tenancy.oc1..aaaa...
region=us-ashburn-1
key_file=~/.oci/oci_api_key.pem

So ~/.oci/config_staging has [config_staging] inside, ~/.oci/config_dev has [config_dev], and so on.

The full source is in this gist. Two files, one for bash and one for zsh, no external dependencies beyond the OCI CLI itself.

Originally published at amaanx86.github.io.

Running Flux Schnell (12B) + LLMs on a Legacy AMD RX 580 (8GB) via Native Vulkan — Full Architecture Guide [2026]

AIVisionsLab — Fri, 22 May 2026 18:09:52 +0000

Most people were told the RX 580 was dead for AI in 2026. CUDA-only ecosystems, ROCm dropping Polaris support at v5.x, DirectML abandoned before it matured. This is the full technical breakdown of how we proved that wrong.

Hardware Setup

GPU: AMD RX 580 2048SP — 8GB GDDR5 VRAM (Vulkan 1.x native)
CPU: Intel Xeon E5-2690 v3 — 12c/24t @ 3.5GHz boost
RAM: 32GB DDR4 REG ECC Quad Channel
Storage: NVMe 1TB — critical bottleneck fix
OS: Windows 10 Pro + WSL2 Ubuntu 22.04.5

Why everything else failed

Solution	Status	Reason
CUDA	❌	Nvidia-only
ROCm	❌	Dropped Polaris at v5.x
DirectML	❌	OpaqueTensorImpl crash on CLIPTextEncode
OpenVINO	❌	ldm/sgm modules missing on Forge

DirectML's fatal error:

NotImplementedError: Cannot access storage of OpaqueTensorImpl

The driver wraps memory in opaque tensors that ComfyUI's attention backends can't read. It's a dead end.

The Solution — Dual Architecture

PATH 1 — GPU Vulkan (RX 580 acceleration)

Native build of stable-diffusion.cpp compiled with -DGGML_VULKAN=ON. The ggml engine maps directly to the GPU without ROCm or CUDA. SD 1.5 GGUF models render in ~72 seconds.

PATH 2 — CPU Xeon (SOTA heavy models)

FLUX.1 Schnell at 16GB exceeds physical VRAM. ComfyUI runs via CPU inside WSL2, using ECC RAM as stable virtual VRAM. Full 768x768 generation in ~24 minutes.

Hybrid Memory Segmentation for Flux (12B Q4_K)

Component	File	Allocation Size
Diffusion Model	flux1-schnell-q4_k.gguf	GPU VRAM ~6.5GB
VAE	ae.safetensors	CPU RAM ~160MB
CLIP L	clip_l.safetensors	GPU VRAM ~235MB
T5XXL	t5xxl_fp16.safetensors	CPU RAM ~9.3GB

Production command

sd-server.exe --listen-ip 0.0.0.0 --listen-port 7860 \
  --diffusion-model "E:\models\flux1-schnell-q4_k.gguf" \
  --vae "E:\models\ae.safetensors" \
  --clip_l "E:\models\clip_l.safetensors" \
  --t5xxl "E:\models\t5xxl_fp16.safetensors" \
  --cfg-scale 1.0 --steps 4 --clip-on-cpu --vae-on-cpu --vae-tiling

--vae-on-cpu + --vae-tiling are non-negotiable. Without them: instant DeviceMemoryAllocation crash.

Real Benchmarks

Workload	Backend	Result
LLM text inference	CPU only	3–5 tokens/s ❌
LLM text inference	RX 580 Vulkan	15–16 tokens/s ✅
SD 1.5 20 steps	DirectML	~450s + crash ❌
SD 1.5 20 steps	Vulkan native	~72s ✅
Flux 1024x1024	Xeon CPU WSL2	~24 min ✅

NVMe impact: Model load time dropped from 25 minutes (HDD) to 4 minutes (NVMe). For Flux 16GB: from 25 min to ~30 seconds. Storage is as critical as compute.

Service Map

OpenWebUI Docker :3000
  ├── llama-server.exe :8081  (Vulkan — RX 580)
  ├── sd-server.exe    :7860  (Vulkan — RX 580)
  └── ComfyUI          :8188  (CPU — Xeon WSL2)

Resources

Full documentation, .bat orchestration scripts, compiled binaries and model configs:
👉 https://setup-ia-local-rx580-vulkan.firebaseapp.com/

Hardware doesn't die. It gets liberated by the right software. Are you running legacy AMD cards? Let's discuss your buffer allocation and command queue latency findings in the comments.

Investigation Reports: When Monitors Get Smarter

Patrick Londa — Fri, 22 May 2026 18:04:01 +0000

Authored by Marco Aquilanti

When a monitor fires, there's a familiar sequence of checks required to find the root cause. The engineers who set up the monitor usually know these steps by heart — they know the dependencies, the error codes, what to check and where. But for the on-call responder, these steps aren't always obvious. Historically, the solution was to force engineering teams to document the checks in a playbook and hope the responder would read it under pressure.

Today, we can offload these checks to an LLM, shifting the responder's role from gathering evidence to reviewing a diagnosis — significantly reducing MTTR.

Our new Investigation Reports feature does exactly this: an LLM completes the investigation and delivers a detailed report before the human even acknowledges the alert.

Investigation Reports builds on BrontoScope, our first AI-powered investigation feature — and on the positive customer feedback it generated.

BrontoScope vs. Investigation Reports

Both BrontoScope and Investigation Reports perform automated investigations and provide reports, but they work differently.

BrontoScope starts with a user request to investigate a specific error event in the logs. The investigation follows a defined workflow aimed at establishing when and where an error is occurring. The LLM guides the process and summarizes findings synchronously — the user is waiting for a response and gets it in seconds.

Investigation Reports is triggered by a system event (a monitor firing), with no user waiting for a synchronous response. This gives the LLM more time — not seconds but minutes — to query data and analyze results. Investigating an alert is also a more generic task than BrontoScope's focused error investigation, making it harder to define a single fixed workflow that succeeds in every scenario.

For these reasons, Investigation Reports lets the LLM operate more freely — giving it tools and context rather than a coded workflow.

Tools Are Easy, Context Is Hard

The tools side is straightforward: the LLM can call Bronto's APIs to perform lightning-fast log search, query key-value dictionaries, check monitor history, retrieve precomputed metrics, and more.

Context is the harder problem.

LLMs make good logical decisions when provided with relevant, well-explained context. But the context window is limited — and it's been demonstrated repeatedly that longer context leads to worse answers and higher hallucination rates. This is known as "context rot" (see research from Chroma and this arXiv paper).

For an effective investigation, the LLM needs more than just the monitor that fired. It needs historical context and an understanding of the monitored system. But dumping thousands of tokens of documentation into the prompt backfires — it drastically increases hallucination risk and degrades report accuracy.

User-Defined Investigation Context

The precise knowledge needed for a good investigation is hard for an LLM to infer autonomously — but it can be provided by the engineer who owns the monitor.

In a dedicated "Investigation Prompt" text area, the user instructs the LLM on what to check and what to do when the monitor fires. Free-form text makes the feature highly flexible, effectively letting users define an ad-hoc workflow for each specific use case.

Engineers and SREs commonly include:

List of dependencies of the affected service
Related log datasets and how to correlate/query them
Relevant keys and metrics to check
What to include in the report — affected components, customers, or users

The screenshot below shows an example investigation prompt telling the LLM to check datasets in a collection named "booking system":

And here's the Investigation Report generated when that monitor fired — the LLM followed the instructions, ran multiple queries, and produced a report with a potential root cause, diagnosis, and timeline:

Investigation Reports Beyond Incident Response

Bronto's own customer support and sales teams found an unexpected use case. They set up monitors to be notified when new organizations are created or contracts are updated in the system — keeping the team up to date on new sign-ups and customer onboarding.

Investigation Reports automates the task of fetching context about each event. Details like contract type, retention plan, company size, and location are queried across multiple logs and assembled into a report that arrives within a minute of the monitor notification. This lets the team quickly identify relevant events among routine ones.

Below is the investigation prompt used by the customer support team, and an example of the automatically generated report:

Investigation Reports are a great illustration of what LLMs are genuinely good at: taking a well-framed task with relevant context and producing a structured, actionable summary faster than any human could. Every monitor notification now comes with relevant information to speed up resolution.

We'll be building further on this capability in the coming months — using AI alongside Bronto's logging platform to help teams reduce toil, resolve issues faster, and extract more value from their data.

Explore Bronto Labs

Semantic Layer Best Practices: 7 Mistakes to Avoid

Alex Merced — Fri, 22 May 2026 18:03:06 +0000

Semantic layers don't fail because the technology is wrong. They fail because of design decisions made in the first two weeks — choices that seem reasonable at the time and create compounding problems for months afterward.

Here are the seven mistakes that kill semantic layer projects, and how to avoid each one.

Mistake 1: Defining Metrics in Multiple Places

What happens: Revenue is defined in a Tableau calculated field, a Power BI DAX measure, a dbt model, and a SQL view. Four sources of truth. None of them agree.

Why it's common: Teams adopt new tools without migrating metric definitions. Each tool gets its own model. Over time, the definitions drift.

The fix: Every metric gets exactly one canonical definition in the semantic layer. All downstream tools query that definition. No exceptions. When someone needs Revenue, they query business.revenue, not their own formula.

This principle extends to AI agents. If your AI generates its own metric formulas instead of referencing the semantic layer, you've just added another source of truth — the least trustworthy one.

Mistake 2: Skipping the Bronze Layer

What happens: A data engineer creates a Silver view that joins raw source tables directly, mixing data cleanup (type casting, column renaming) with business logic (filters, calculations) in a single query. When the source schema changes — a column is renamed, a type is modified — the Silver view breaks.

Why it's common: The Bronze layer feels redundant. It's just a 1:1 mapping of the source. Why add a layer that doesn't change anything?

The fix: The Bronze layer absorbs schema changes. When a source renames col_7 to order_date_utc, you update one Bronze view. The Silver and Gold views above it don't change. This insulation is worth the tiny overhead of maintaining passthrough views.

Bronze views also standardize data formats. Timestamps normalized to UTC. Strings cast to consistent encodings. Column names made human-readable. This cleanup happens once, at the bottom of the stack, and every view above benefits.

Mistake 3: Using SQL Reserved Words as Column Names

What happens: A Bronze view exposes a column called Date. Now every downstream query must reference "Date" with double quotes. Analysts forget. AI agents don't quote it at all. Queries break intermittently. Debugging is frustrating because the error messages are cryptic.

Why it's common: Source systems often use generic names. Date, Timestamp, Order, Group, Role — all are SQL reserved words. Bronze views that don't rename them propagate the problem to every consumer.

The fix: Rename early. In the Bronze layer, map Date to TransactionDate, Timestamp to EventTimestamp, Order to CustomerOrder. Use domain-specific prefixes that are unambiguous and never conflict with SQL keywords.

This small decision saves hundreds of hours of debugging across the life of the semantic layer. It also dramatically improves AI agent accuracy, since language models generating SQL rarely add appropriate quoting for reserved words.

Mistake 4: Building Without Stakeholder Input

What happens: A data engineering team builds 50 Silver views based on the database schema. They expose every table, every column, every possible metric. Business users look at the result, don't recognize any of the terms, and go back to their spreadsheets.

Why it's common: Data engineers understand the schema. They assume the schema structure maps to business needs. It usually doesn't.

The fix: Start with a metric glossary co-created with stakeholders from Sales, Finance, Marketing, and Product. Ask them: What are your top 5 metrics? How do you calculate them? What decisions do they drive? Build the Silver layer around those answers, not around the database schema.

This step feels slow. It's the fastest path to adoption. A semantic layer that uses business language and models business concepts gets adopted. A semantic layer that mirrors the database schema gets ignored.

Mistake 5: Treating Documentation as Optional

What happens: Views are created with no Wikis, no column descriptions, no Labels. The semantic layer works for the person who built it. Everyone else — analysts, AI agents, new team members — can't figure out what the views mean.

Why it's common: Documentation takes time. Deadlines are tight. Teams plan to "add documentation later." Later never comes.

The fix: Make documentation part of the view creation process, not a follow-up task. At minimum, every view gets:

A one-sentence description of what it represents
Labels for governance (PII, Finance, Certified)
Column descriptions for any non-obvious field

Modern platforms reduce this burden with AI-generated documentation. Dremio's generative AI samples table data and auto-generates Wiki descriptions and Label suggestions. The AI provides a 70% first draft. The data team adds domain context for the other 30%.

Undocumented views are invisible to AI agents. If the Wiki is empty, the AI agent has no context to generate accurate SQL. Documentation isn't just nice to have. It's an accuracy requirement.

Mistake 6: Applying Security at the BI Tool Level Only

What happens: Row-level security is configured in Tableau so regional managers only see their region. Then an analyst opens a SQL client, queries the underlying table directly, and sees all regions. The security was enforced in the dashboard, not in the data.

Why it's common: BI tools make it easy to apply filters and security rules. Data platforms require more setup. Teams take the easy path.

The fix: Enforce access policies at the semantic layer, not the BI layer. Row-level security and column masking should be applied on the virtual datasets (views). Every query path — dashboard, notebook, API, AI agent — inherits the same rules.

Dremio implements this through Fine-Grained Access Control (FGAC): policies defined as UDFs at the view level. A regional manager queries business.revenue and automatically sees only their region, regardless of how they access the data. No security gaps between tools.

Mistake 7: Trying to Model Everything at Once

What happens: The team commits to building a complete semantic layer covering every source, every table, and every metric. The project takes six months. By the time it launches, requirements have changed, stakeholder interest has waned, and half the views are out of date.

Why it's common: Ambitious leaders want a "complete" solution. Data teams want to avoid rework. Neither wants to ship an incomplete layer.

The fix: Start with 3-5 core metrics that the organization actively debates (usually Revenue, Active Users, Churn). Build one Bronze → Silver → Gold pipeline per metric. Validate that the same question produces the same answer across two different tools.

Once those metrics are stable, expand incrementally. Add new sources, new views, new metrics — one at a time. Each addition is low-risk because the layered architecture isolates changes. A new Gold view doesn't affect existing Silver views.

The fastest semantic layers reach 80% organizational coverage not by modeling everything up front, but by proving value quickly and expanding from momentum.

What to Do Next

Pick one mistake from this list. Check whether your semantic layer (or your plan for one) is making it. Fix that one thing this week. Then come back for the next one.

Try Dremio Cloud free for 30 days