The Weight of Proof and the Speed of Operations: How to Read Verified Polygon Intersection as a Practical Option

Source: Hacker News — https://github.com/schildep/verified-polygon-intersection

In systems where a single boundary condition can escalate into a contract dispute, “mostly correct” is weaker than it sounds.

What this Hacker News post offers practitioners is far more concrete than a question of how clever AI models have become. Based on the repository description and the RSS text, the core idea here is an attitude of, “We do not trust it because the LLM says it is right; we trust the Lean checker and a small, human-readable specification.” The author presents this as a case of formally verifying a polygon intersection algorithm, and says the web demo supports conditions such as multipolygons, holes, self intersections, and overlapping edges. The author also notes that after a recent model release, it became possible to generate larger chunks of implementation and proof in one shot, without a human having to break the proof strategy into tiny steps.

From a practical perspective, the key point splits in two. One is, “What exactly was verified?” The other is, “What still remains outside verification?” Without that distinction, it is easy either to overrate this news or dismiss it too quickly. The repository explicitly draws a line: confidence in correctness comes not from the LLM, but from the checker and a review of the small spec. At the same time, the author also directly acknowledges the limitation that this style can produce slow code or miss practical considerations. In other words, this is not a declaration that “formal verification solves everything,” but rather a signal that “it is becoming possible to shrink the trust boundary of complex logic to a much smaller surface.”

What You Miss If You Read This as Just News

On the surface, the headline story looks like “Opus 4.8 can now produce a formal proof in one shot.” But if you look a little more closely at the repository description, the real practical point is not AI capability itself, but a shift in review structure. In the past, humans had to break down and supply the proof strategy. More recently, the model was able to organize larger strategies on its own. Even so, final trust is still placed in the Lean checker, not the model. That combination matters. It means generation is an acceleration mechanism, while the basis for trust remains a separate mechanical verification system.

The reason this structure matters in practice is review cost. In complex geometry implementations, even hundreds or thousands of test cases still leave room for “some strange shape we have not encountered yet.” In particular, when holes, self intersections, and overlapping edges are mixed together, an algorithm that seems correct can easily fail on specific boundaries. By contrast, a formal verification approach lets trust be organized around a smaller specification and a clearer guarantee surface, even if humans do not follow every implementation detail. That is also the right context for reading the repository’s emphasis that “the file a human needs to read is small.”

You Need to Change the Starting Point of the Comparison

When evaluating this case, the comparison is not “did it use AI or not?” In practice, the real competing options are usually threefold.

First is using or adopting a formally verified core directly.
Second is using a conventional geometry implementation backed by tests, property-based tests, fuzzing, and regression cases.
Third is using a fast conventional implementation as the main path, while adding a separate reference path or verification core as a hybrid option.

All three aim to “avoid being wrong,” but the costs land in different places and they fail in different ways. So the right comparison criteria are not feature lists, but failure cost, reviewability, performance requirements, and the team’s maintenance capacity.

Option 1: Leading with a Formally Verified Core

This is the option the current case highlights most strongly. Based on the repository description, the implementation and proof are verified in Lean, and confidence in correctness is placed in the checker. The fact that the author also connected the verified core to a working web demo shows a direction that goes beyond a pure research artifact and reaches an actually running demo.

The biggest advantage of this option is that it changes the way you trust rare edge cases. A testing-centered approach ultimately depends heavily on observed inputs and imaginable inputs. Formal verification, by contrast, tries to guarantee certain properties for all inputs allowed by the specification. In a problem like polygon intersection, where the combinatorial space is effectively unbounded, that difference is enormous. The repository emphasizes exactly this point. Since the input space is infinite and even the meaning of the interior set is hard to capture with simple example tests alone, there is value in formally pinning down the relationship between the interior set and the intersection.

Another advantage is that it can reduce the review surface. Instead of having a human read through an entire complex optimized implementation, a structure where they inspect a smaller specification and theorem interface is much more reproducible at the organizational level. For high-risk logic, that is a very strong benefit. It shifts the conversation from “who fully understood this massive implementation?” to “what properties do we trust, and how far does the checker guarantee them?”

But this option is not all upside. The repository author explicitly notes that if you push formal verification hard, you are more likely to end up with slow code or code that reflects practical considerations less well. That point should not be underestimated. You may gain strong correctness, while performance optimization, memory usage, implementation simplicity, and integration with the outside environment remain separate problems. In other words, a “proven correct answer” and an “operationally viable answer” are not the same sentence.

There is also the issue of team capability. If there is no one who can understand and maintain Lean or a proof-assistant-based system, the long-term operating cost can rise sharply regardless of the technical achievement of initial adoption. This project shows a flow that connects a demo and a core, but for a typical organization to adopt this model as-is, the proof tooling, build chain, and reviewer skill set all have to come with it.

This option fits better when:

• the cost of a wrong result is extremely high
• rare edge cases can turn into actual incidents or legal risk
• explainable correctness matters more than raw performance
• the team can accept a culture of fixing and reviewing a small specification

By contrast, it is harder for this to become the default choice when:

• the product is in an early stage and requirements change frequently
• the latency budget for the hot path is extremely tight
• it is difficult to secure proof-based maintenance capability inside the organization

Option 2: Conventional Implementation with Stronger Testing

This is the path most teams actually take. They use a mature geometry library or build an in-house implementation, then improve quality through example-based tests, regression tests, fuzzing, and property-based testing. The strengths of this approach are clear. The ecosystem is broad, integration is easy, and performance optimization experience is abundant. Operations teams and product teams can work with tools they already know, and knowledge transfer is relatively manageable even when team members change.

This approach is especially strong when errors are not catastrophic and recovery is possible. For example, if a slightly wrong result can be manually corrected by a user, re-edited in the UI, or reviewed once more in a back-office process, then accumulated testing may be a more realistic choice than formal verification. And when performance is central to business viability, an optimized implementation and operational stability take priority over verification.

But the weaknesses are also clear. Geometry is a field where bugs hide well. As the repository description itself suggests, cases involving overlapping segments or holes quickly become more complex than expected, raising questions like “which boundary fragments should be grouped into which closed loops?” Adding more tests does not reduce this complexity in a linear way. Instead, the test suite often grows larger while the organization’s psychological confidence grows faster than the actual strength of its guarantees.

This option is appropriate when:

• performance and ecosystem integration matter more than the absolute maximum level of correctness
• there is already enough operational experience with trusted external libraries
• the cost of error recovery is low and users have a correction path
• the team needs to iterate and ship quickly

There is also an important counterexample. The attitude that “good testing is enough” can be overly optimistic in areas like financial calculation, policy engines, or geometry kernels, where edge cases can break product trust. Simply having many tests does not automatically explain the strength of the guarantee.

Option 3: A Hybrid Structure with a Reference Verification Path

In practice, this third option is likely to fit the widest range of organizations. The main processing path stays with a conventional implementation or a high-performance library, but important moments use a separate, stricter core for cross-checking or sample-based comparison. It does not have to be a fully formally verified implementation. But applying the lesson of this case, it is possible to use a small spec and checker-based core that humans can trust as a kind of truth anchor.

The strength of this structure is that it lets you optimize correctness and speed separately. The operational hot path stays fast, while a more expensive correctness path can be used only for release validation, dispute handling, suspicious input triage, or high-risk customer segments. In practice, this kind of compromise often works better. Rather than trying to prove everything, it binds only the parts that absolutely must not be wrong more tightly.

A hybrid structure is also easier to sell internally. Product teams can keep a fast user experience, while platform or reliability teams can reduce risk through a result-verification mechanism. Especially if, as in this case, a verified core for complex logic can make a trust claim based on a small spec review, “let’s add one core verification path” is much easier to accept than “let’s change all the code.”

Of course, there are cautions. A hybrid structure inherently means maintaining two implementations, so operational complexity rises. When differences appear, you need to decide in advance which side counts as correct, when to fall back, and at what threshold to alert on mismatches. Another common trap is allowing the main path’s quality to become looser simply because a verification path exists.

This option is especially useful when:

• it is hard to replace the existing system completely, but you want to reduce risk
• it is difficult to give up either performance or correctness
• only results with dispute potential need stricter handling
• you want to build formal-methods capability gradually within the organization

Practical Checkpoints You Can Pull Directly from This Case

Checkpoint 1. Can you write down what is still outside the proof before talking about what was proved?

This repository explains the basis for correctness relatively clearly. But that explanation does not imply the integrity of the entire system. Even if it is wrapped in a web demo, that should not be read as meaning the I/O parsing, data transformation, build process, wrappers, and UI interactions are all formally verified too. In practice, teams need to document the difference between a “verified core” and a “verified product.”

Checkpoint 2. Is it clear whether the team is trusting the LLM or the checker?

This is the healthiest line drawn in the case. The narrative that the model generated the implementation and proof is interesting, but the repository repeatedly makes clear that the basis for trusting correctness is the Lean checker and a review of the small spec. The same principle matters when adopting AI-assisted development in practice. Better generation quality is not a reason to shift the basis of trust onto the generation model itself.

Checkpoint 3. Do the performance requirements and the precision model conflict?

Looking at DataStructures.lean in the repository, the verified core uses rational coordinates. That is a persuasive choice from a correctness standpoint. But if the operational system is mainly floating-point-based, conversion rules and interoperability costs arise. Without a design for where rounding happens and where exact arithmetic is preserved, the meaning can become unstable at the boundaries around the verified core. In other words, it is not enough to look only at the verified center; you also have to look at the data model boundaries.

Checkpoint 4. Does the specification point in the same direction as the actual product requirement?

Formal verification is strong with respect to specified properties. The problem is that what a product wants does not always align perfectly with the most mathematically natural definition. For example, what users expect may be “a result that looks natural in the editor for the shape I drew,” and that may not mean exactly the same thing as a particular topological definition. This project puts weight on correctness in terms of the interior set, but in practice visual intuition, compatible formats, and post-processing rules may also be important requirements.

Checkpoint 5. Are operational requirements that proof does not cover being managed separately?

It matters that the author mentions performance improvement as a next step. This is less a weakness than a declaration of boundaries. Securing correctness and optimizing performance are different tasks. In practice, timeout behavior, memory usage, batch throughput, traceability, incident recovery, and observability all need to be managed as separate operational metrics.

Counterexamples That Only Become Visible If You Think in Reverse

Just because this case is impressive does not mean every team working on difficult algorithms should immediately rush toward formal verification. There are plenty of counterexamples.

The first is an early product stage where the problem definition itself is still unstable. If it is not yet clear what result representation customers prefer or which edge cases they even consider important bugs, fixing the specification too early may actually slow down exploration. At that stage, a testable prototype and usability feedback may matter more.

The second is when absolute performance is the core competitive advantage. If geometry processing sits on the critical path of a large rendering pipeline or a large-scale GIS batch system, a verified core may be excellent as a reference implementation or regression verification mechanism, but too heavy to use immediately as the main operational engine. The repository description does not hide that the current implementation is unoptimized.

The third is an imbalance in organizational capability. Even if something is technically the right choice, a different kind of risk appears if the team cannot fix it. A structure where only a small number of people can read and modify the proof raises the bus factor. This should be assessed coldly, especially in organizations with long platform lifetimes and frequent turnover in maintenance personnel.

But there are counterexamples on the conventional side as well. The belief that tests, fuzzing, and regression cases alone are sufficient often becomes overconfidence in a domain like geometry. The more cases you add, the more reassurance you may feel, but the nature of the guarantee remains empirical. If rare boundary inputs can create meaningful business loss, that approach alone is unstable.

In One Sentence: When to Choose What

The difference among the three options can be reduced to this:

• If the cost of being wrong matters far more than the probability of being wrong, you should lean toward a formally verified core.
• If speed, integration, and operational familiarity matter more, and error recovery is easy, a conventional implementation plus a strong testing system is more realistic.
• If neither side is easy to give up and the existing system must also be preserved, a hybrid structure is the most practical choice.

What matters here is not “should we adopt verification or not?” but “where should we place verification?” This case forces that question in a fresh way. You do not need to prove every system, but neither do all critical logic paths have to survive on testing alone.

Where AI Becomes a Tool, and What Humans Still Need to Do

The title of the HN post foregrounds differences between AI model versions, but the larger practical change is probably elsewhere. The experience that humans previously had to guide proof strategy in detail, while more recently the model could organize larger strategies on its own, suggests that AI can become a productivity layer even in difficult work like formal methods. But that does not automatically mean trust has been automated. If anything, this case teaches the opposite lesson: in the age of AI, trust boundaries need to be written down more strictly. More important than who wrote the code is what is guaranteed, by what checker, against what specification.

There is a clear practical takeaway here for engineering teams. Use generative models more, but leave behind a smaller and clearer basis for trusting correctness. Small specs, rerunnable checkers, interfaces humans can review, and documentation of the boundary between a verified core and an unverified surrounding layer are all likely to become more important. This project shows exactly that design instinct.

So it would be a waste to consume this case only as “AI managed to produce a proof.” A more productive reading is to ask, “How far can we reduce the human review burden in complex logic?”, “Is that reduced review surface organizationally trustworthy?”, and “What do we have to give up or manage separately in exchange?” Actual adoption decisions should be made on top of those questions. Polygon intersection is only the starting point. The real ripple effect is likely to be that the same conversation will spread across more domains where correctness matters.

Opinions

The following opinions from comments and discussion are organized as reference material. (Do not treat them as settled fact; context should be checked.)

• Hacker News · @threatripper: It uses exact rational coordinates, not floating-point coordinates in the verified core. See: https://github.com/schildep/verified-polygon-intersection/bl...
  • Link: https://news.ycombinator.com/item?id=48405584
• Hacker News · @CyLith: Does this use integer coordinates or floating point coordinates?
  • Link: https://news.ycombinator.com/item?id=48405392
• Hacker News · @olaird25: Is the web demo compiled from the lean?
  • Link: https://news.ycombinator.com/item?id=48405814

Comments

Loading comments.