[GitHub Copilot] Improve handling of long tasks and quota consumption

I discovered the Golden Grail of AI-assisted development. TLDR; - Stick to @cursor_ai. - Use Opus 4 (max mode) for planning. - Use o3 (regular mode) for execution. Extreme costs saving in comparison to Max-Max mode of Claude Code. Long story. I want to migrate my tiny SaaS from React Server Actions to a proper REST-alike API. It would remove a layer of magic contributed by RSC/RSA, have a well-defined API & allow to have extension points for 3rd-party applications. I had a few iterations with TypeScript + Fastify, looked over Python + FastAPI, was seriously considering using behemoths like C#/Java/Kotlin. Once I drew the initial implementation with TypeScript, I remembered why I don't like it: - Compilation errors everywhere (woah, bro, your monorepo has 5 version of the same lib and the exactly same method signature doesn't match exact same methods of other version, I don't care of your pnpm!) - Hands are scratching to make complex types to get most of the compile-time guarantees possible which makes IDE slow (tsgo makes it fast though!), types hard to understand (as IDEs don't show the final shape, just all the type magic calls), etc. I remembered the old friend of mine - Go. The simplest mainstream language with almost no magic. The tool that I need - it would limit me endlessly and I'd not be spending time fighting the "best architecture" or "type definition". First Steps. I wanted to get OpenAPI Spec support out of the box. I a know couple of well-known & mature solutions: Swaggo and Goa (.design). While Swaggo does exactly what I need - I just write Go code as I am used to and it takes care of the rest - I didn't like two things: - Magic comments to describe everything, leading to obsolete documentation - No OAS 3.0/1 support - I need unions for my project (other new stuff like callbacks/webhook definitions are great to have too). Goa, on the other hand, seems to be able to provide OAS 3.0/1 support, but it forces to describe spec in it's own DSL. It looks nice, but quickly becomes bloated if you want to define extra struct tags, use your own structs instead of generated ones, and so on - not an option. Other options that are less mature, but rising today are either: - schema-to-code forcing their architecture approaches - are simply too verbose - leaving a space for documentation discrepancies "Look ma, I'm a Programmer!" A long time ago I promised myself that I will not develop my own frameworks and just stick to existing tooling for business applications (even for my own projects). Well... Here we go! I decided to write my own implementation of code-first OpenAPI Spec generator. I want it to be as invisible as it is possible, yet leaving space for using custom routers, JSON libs, validation approaches. I created a first version in a few evenings, as a proof of concept - to verify that it can actually be a thing. It is nice: routes are automatically detected, documentation belongs to your code (just regular comment sections!), validation by go-playground/validator is running! I understood that it can be something slightly more than just an in-house pet project. Now the code is published under gork-labs organization on GitHub: https://t.co/4MRBZalfke `Gork` -> `Go Framework` The AI Battle PoC is live, I am happy. Time to improve it and add missing features. I spent almost a day with Opus 4 analyzing the architecture, trying different approaches, making test implementations, looking closer at competitors. We created this: the first live proposal for Gork: https://t.co/QFX7XanPmy Having such a nice document I decided that it is an excellent opportunity for AI agents to show their strengths and weaknesses! All agents were getting similar, tiny prompt: Please analyze <doc>. Ultrathink. Implement the proposal. AI Battle: Opus 4 Ofc I started with Claude Code & Opus. :) Well, you could have guessed - it showed a good result. While not one-shotting, but definitely a good base. There were some mistakes in imports, generics usage (you might spot them in proposal doc), but it seems nothing major. AI Battle: GitHub Copilot + Sonnet 4 I really like the VS Code interface much more than Cursor's. It is just feels slightly more polished. Differences are minor, but anyway. This pair tried it's best, but I decided to give up just after 5 or 10 minutes since the beginning: - it stopped all the time after 25 requests, asking me whether I want to continue or not (yeah, just mid-task!) - code quality was not the best (comparing to Opus & o3), it didn't spot the generics usage error in spec. - well, premium requests quota makes me sad - almost instantly used 7% of the calls for a month; next stop - pay per token It was mostly #3 that lead me to the decision to end tests. The implementation is not even halfway done, yet you already consumed 10% of monthly quota? C'mon. AI Battle Winner: Cursor + o3 I've been with Cursor since it's first open release (used Codeium just before it). It is a great tool. Only last month I switched to Claude Code as my coding agent. This pair did an excellent job: - o3 spotted the discrepancy in spec from the first requests! - it created a good list of TODOs; comparing to Claude Code - it doesn't forget them & doesn't modify on-the-fly (sometimes I don't want it to happen) - costs. $20/mo (didn't met a limit yet). It is almost free. Hopefully @cursor_ai wouldn't run out of investor's money anytime soon to keep the price so we can enjoy the pricing - it stopped after each task execution and asked me if it should continue. Pretty much similar story to Copilot, but it is much less annoying: the feature (code change batch) is done, I can examine the "final" implementation of this part, make adjustments and it will continue where it left afterwards! Conclusion My next step is to switch back to Cursor and pair Max mode with o3's standard mode and compare cost efficiency & code quality. AI Agents are a great way to speedup the product development. Combined with smart techniques (pre-created document with detailed instructions + clean execution afterwards) allow to deliver faster & much better products.