- Joined
- Jan 22, 2026
- Messages
- 101
- Reaction score
- 923
GPT-5.2 wrote the browser in 7 days. Why are engineers horrified by this "achievement"?
A week ago, Cursor CEO Michael Truell announced an allegedly outstanding achievement. According to him, with the help of GPT-5.2 In Cursor, they created a browser that worked continuously for a whole week. This browser consists of three million lines of code in thousands of files. The rendering engine is written from scratch in Rust and includes HTML parsing, CSS cascading, layout, text generation, rendering, and its own JavaScript virtual machine.
Truell noted that the browser works, albeit with caveats. He has problems, and he is very far from the level of WebKit or Chromium, but the team was amazed that simple sites are rendered quickly and mostly correctly. Some developers managed to compile the code after fixing bugs, while others reported success after finalizing the build instructions.
However, in general, the developers are not convinced that Cursor has made a breakthrough. Jason Gorman, director of the British consulting company Codemanship, considers this proof that agent-based AI scales to create non-functional software. Oliver Medhurst, a software engineer and former Mozilla employee, agrees with this assessment. He noted that the very fact of working with a codebase of this size is impressive, but objectively it is not a good browser engine. In addition, the code is incredibly bloated — the Ladybird and Servo projects do much more with about a million lines each.
Writing a web browser is one of the most difficult tasks for a programmer. Chromium, the open framework of Google Chrome, contains over 37 million lines of code. The Cursor browser, called FastRender, has about three million lines. Back in 2022, developer Joshua Marinacci wrote about how complicated the web has become, to the point where only a few companies are able to create a browser from scratch. The fact that Microsoft stopped developing its own browser engine and switched Edge to Chromium confirms the huge engineering resources needed to develop and maintain the browser.
Cursor engineer Wilson Lin, who worked on the browser's code, published a blog post explaining the project's goals — to understand how far the boundaries of agent-based coding can be pushed for projects that usually take teams of people months. Critics have accused Cursor of actively using Servo, Mozilla's open-source Rust rendering engine. However, Lin rejected claims that FastRender is built from libraries and frameworks, stating that the JavaScript virtual machine, DOM, rendering systems, and text pipeline are being developed as part of this project.
Gorman remains unconvinced. He points to the performance metrics in the FastRender repository that show the instability of the code. The build failure rate of 88 percent is very high and indicates a codebase that is not working. When asked about reports of successful builds, he expressed skepticism, noting that CI builds are still falling.
Gorman is critical of claims about the success of AI coding tools in general. He cites data showing that developers greatly overestimate the impact of AI on their productivity, and most teams are negatively impacted by indicators such as development time and release reliability. The minority who see modest improvements have already eliminated bottlenecks in the development processes, such as testing, code review, and integration.
Many sensational claims about the success of AI coding, according to Gorman, come from developers working on small tasks on their own, without clients, users, or dependencies on other teams. They accelerated the car to 200 mph on a straight road with no other cars and decided that faster cars meant faster traffic. Then they return to the office and demand the same speed improvements from their teams, who are actually driving during rush hour.
Gorman notes that when output is measured—lines of code, commits, pull requests - there is definitely an increase. But this does not mean a real increase in productivity. He points to the lack of evidence that AI tools lead to the creation of more software, as measured by the number of products in app stores, and the lack of revenue that can be attributed to these tools.
Gorman considers AI technology to be very impressive, but often wrong. He uses it every day as a coach and mentor to figure out how best to apply it. But does he consider it revolutionary? No. The principles and practices that made development teams effective before AI—small steps, short feedback cycles, continuous testing, code review and integration, and modular design—remain the same. Same game, different dice.
He adds: if AI agents could actually create a working product with three million lines of code in a week, when does feedback from users and customers occur in this design process? That's where real value is created.
A week ago, Cursor CEO Michael Truell announced an allegedly outstanding achievement. According to him, with the help of GPT-5.2 In Cursor, they created a browser that worked continuously for a whole week. This browser consists of three million lines of code in thousands of files. The rendering engine is written from scratch in Rust and includes HTML parsing, CSS cascading, layout, text generation, rendering, and its own JavaScript virtual machine.
Truell noted that the browser works, albeit with caveats. He has problems, and he is very far from the level of WebKit or Chromium, but the team was amazed that simple sites are rendered quickly and mostly correctly. Some developers managed to compile the code after fixing bugs, while others reported success after finalizing the build instructions.
However, in general, the developers are not convinced that Cursor has made a breakthrough. Jason Gorman, director of the British consulting company Codemanship, considers this proof that agent-based AI scales to create non-functional software. Oliver Medhurst, a software engineer and former Mozilla employee, agrees with this assessment. He noted that the very fact of working with a codebase of this size is impressive, but objectively it is not a good browser engine. In addition, the code is incredibly bloated — the Ladybird and Servo projects do much more with about a million lines each.
Writing a web browser is one of the most difficult tasks for a programmer. Chromium, the open framework of Google Chrome, contains over 37 million lines of code. The Cursor browser, called FastRender, has about three million lines. Back in 2022, developer Joshua Marinacci wrote about how complicated the web has become, to the point where only a few companies are able to create a browser from scratch. The fact that Microsoft stopped developing its own browser engine and switched Edge to Chromium confirms the huge engineering resources needed to develop and maintain the browser.
Cursor engineer Wilson Lin, who worked on the browser's code, published a blog post explaining the project's goals — to understand how far the boundaries of agent-based coding can be pushed for projects that usually take teams of people months. Critics have accused Cursor of actively using Servo, Mozilla's open-source Rust rendering engine. However, Lin rejected claims that FastRender is built from libraries and frameworks, stating that the JavaScript virtual machine, DOM, rendering systems, and text pipeline are being developed as part of this project.
Gorman remains unconvinced. He points to the performance metrics in the FastRender repository that show the instability of the code. The build failure rate of 88 percent is very high and indicates a codebase that is not working. When asked about reports of successful builds, he expressed skepticism, noting that CI builds are still falling.
Gorman is critical of claims about the success of AI coding tools in general. He cites data showing that developers greatly overestimate the impact of AI on their productivity, and most teams are negatively impacted by indicators such as development time and release reliability. The minority who see modest improvements have already eliminated bottlenecks in the development processes, such as testing, code review, and integration.
Many sensational claims about the success of AI coding, according to Gorman, come from developers working on small tasks on their own, without clients, users, or dependencies on other teams. They accelerated the car to 200 mph on a straight road with no other cars and decided that faster cars meant faster traffic. Then they return to the office and demand the same speed improvements from their teams, who are actually driving during rush hour.
Gorman notes that when output is measured—lines of code, commits, pull requests - there is definitely an increase. But this does not mean a real increase in productivity. He points to the lack of evidence that AI tools lead to the creation of more software, as measured by the number of products in app stores, and the lack of revenue that can be attributed to these tools.
Gorman considers AI technology to be very impressive, but often wrong. He uses it every day as a coach and mentor to figure out how best to apply it. But does he consider it revolutionary? No. The principles and practices that made development teams effective before AI—small steps, short feedback cycles, continuous testing, code review and integration, and modular design—remain the same. Same game, different dice.
He adds: if AI agents could actually create a working product with three million lines of code in a week, when does feedback from users and customers occur in this design process? That's where real value is created.
