We do have an MCP but all it does is wraps our OpenAPI endpoints using a bunch of tools (not exposing the 100(0?)s of endpoints as tools), but just list_resources, list_endpoints, describe_endpoint, describe_ref, execute.
The primary reason we have this is because its easier for non-tech people to connect it to their AI Claude/ChatGPT/etc. than it is to have them generate an API key and give it the base url and the openapi spec/etc.
The MCP also allows us to add expose a couple of recipe/skill tools (list_skills/read_skill) which describe common workflows on how to use to do things that might be unclear.
I would expect, although have no evidence, that any obviously high entropy crap like base64 and so on probably would get removed whether it's a secret or not.
not saying they do have a beefier pro, but even if they did, isn't the delta between flash vs pro models reduced quite a bit? (e.g glm 5.3 flash vs 5.3, v4 flash vs v4 pro, sonnet 5 vs opus 5)?
Something i read in the earlier paragraphs about llms being easier to work with in greenfield projects…
My experience has been the opposite. They work well on existing projects but are not so great at new ones (unless you are just vibe coding something simple).
I think it has something to do with it being able to rely on years of established structure/conventions on existing projects that makes them better IME
Agreed! I hate the start of a project with an LLM. The code it writes is always expletive, and wrangling it with rules, hooks, plans, and what have you is just a series of half measures. I'm basically in a fistfight with a cheerful drunk keyboard.
Once there's enough code, tests, and docs to appease the prefill gods and give it an understanding of what I expect in terms of code quality, style, and TDD etiquette, I can expect more consistent performance.
That said, I've never been comfortable enough with it to let it write more than a few of functions at a time without a diff/checking-in.
I've seen folks with 500K LOC branches written by an LLM and my heart just sinks...
My experience with greenfield is that when you're just starting out, you have to be really strict and careful about overall architecture, establish a framework, provide structure, separate concerns well.
If the project is not throwaway, this first set of iterations is critical, without guidance LLMs will just bolt on things and produce special-cased spaghetti, even the very-frontier models.
Once the framework is established, it's smooth sailing.
But I haven't gotten to "very large" size yet, I expect it produces another kind of coherence problems.
I’ve had a good experience with a greenfield project.
The single thing that seems to have helped is that we all agreed to use OpenSpec early on, and to commit the specs alongside the code.
I have no affiliation with OpenSpec and I don’t suspect it’s doing anything unique here, but having the intent develop alongside the code in the repository seems to have ensured that agents have a more holistic view of the project.
It’s a night/day difference when I use an agent against this codebase that integrates its changes using OpenSpec and those that ignore it.
Hmm, I'm still undecided when it comes to the best approach: commit or not commit. Now I'm leaning toward the second one, as the implementation can diverge from the spec files, even though I store some impl logs in specs. As a part of feature delivery, I update the main repo docs based on the spec and code written. IMO it makes context for the LLM a bit cleaner.
If you start with architecture docs that outline the high level goals and what the core abstractions should be for a greenfield project and refine it as you fill in the actual code, you can get pretty good results.
That gives the first few agents the "north star" and then subsequent agents have the actual code, the runtime behavior, and the user experience expectations to work against after that, in addition to the architecture docs, that provide hard boundaries to vibe off of.
Depends on what the existing project looks like ;-)
One repo at my work is DDD-esque, clean architecture, modular monolith.
It suuuucks to work on. Even without AI, editing any feature requires navigating through a bunch of app, infra, domain layers instead of living in a vertical feature slice. Indirection from cargo cult design patterns we don't need, like Mediator. With AI, degradation in quality and accuracy is plainly obvious. Everything needs hand-holding. AI is dumber than our average human dev so the creaky architecture made things 10x worse
The greenfield one we started with AI a few months ago is kicking along nicely. Warts exist, there are some really large files and questionable bits, but it's way easier to work on because we didn't make the architecture some convoluted dwemer mine thingy
A few weeks ago, I lost my bluetooth earbuds in my house somewhere. It was still connected and nowhere to be found.
In my case, it wasn't able to come up with it, but fortunately I was, and had it build a local webpage that does "hot or cold" with a 0-100 score. And it worked first try! Found them in like 2-minutes.
Also made for a fun day of hot-and-cold hide-and-seek games with my niece after i had it built that concept as a sideloaded ipad app :)
Yes -- if direct P2P fails, everything rides the TURN relay that gets inserted automatically -- it's DTLS end-to-end so the relay only sees ciphertext, never plaintext or the access code.
On cost: I pay for it on bitba.ng and it's capped right now at 10 minutes per connection (mostly to prevent people from connecting and walking away). But you're not stuck with mine -- the signaling server is open source, so you can self-host and point it at your own TURN. The Python library supports "bring your own TURN" by specifying (--turn-url, --turn-user, --turn-credential); adding the same flags to the CLI is a small gap I need to close. There are TURN providers that have reasonably generous free tiers.
The primary reason we have this is because its easier for non-tech people to connect it to their AI Claude/ChatGPT/etc. than it is to have them generate an API key and give it the base url and the openapi spec/etc.
The MCP also allows us to add expose a couple of recipe/skill tools (list_skills/read_skill) which describe common workflows on how to use to do things that might be unclear.