That&#x27;s a valid point, but if the compilation&#x2F;IDE pipeline is arranged sensibly, you&#x27;ll get those errors and insert a couple of &quot;)&quot; and get to the real meat of the issue a few seconds later...?<p>On the other hand... with an AST-only editor I now have to mentally tune in even more to the way the editor will behave <i>while typing code</i> and any deviation from the expected behavior becomes absolutely <i>crippling</i>[1]. For me, personally, this can become more overhead than it&#x27;s worth to correct a few misplaced &quot;)&quot; or &quot;]&quot; or &quot;;&quot; or whatever when I&#x27;ve finished typing the gist of my idea. (I honestly don&#x27;t know what would be faster overall, and I suspect it depends on hideously complex factors like &quot;how much time do you intend to spend on learning IDE-X vs. learning to &#x27;edit files&#x27;, etc. I guess we could start with studies on &quot;does it work?&quot; as in medicine, even if we have no clue as to <i>how</i> it supposedly works.)<p>I&#x27;m saying that given the enormous success (all things considered, etc.) of text-based editing the claimants have the burden of proof.<p>(Actually, I&#x27;ll happily admit that I <i>was</i> at one point on the hype-train regarding AST-editing, but I&#x27;m more skeptical these days. The thing is that it&#x27;s easy to produce the 80% solution at to make it look awesome, but the problem is that getting those last 10% is a killer. Just look at Chris Granger&#x27;s project for an example of just how difficult it is to get to 90%.)<p>[1] The <i>machine</i> is a machine and can do ASTs perfectly all day long, but if I&#x27;m a bit sleepy or drunk it suddenly becomes impossible to <i>edit</i> and <i>type in</i> code because I can&#x27;t do a perfect job at prediction...? That would be strange indeed!