disintegrator

This is in part why I've been developing inside a VM for the last 2 years. Interestingly, VS Code has nice support for installing and running extensions on the remote. Only themes live on the host.

Yep, no dispute here. It's just that my and other people's experience is that SOC2 controls are usually passed down by edict and whether you review before or after merge, there's typically (from my experiences at SaaS/Fintech) some form of reviews happening. I've done both styles in the same company for different reasons.

I generally think most of the points made in the article are a little too extreme. Even feature flags are valuable if you’re trying to get something up for certain key customers to give feedback on while you iterate as an example. There is some hygiene required around maintaining and removing flags but I think that’s in the same bucket as writing tests, updating dependencies and refactoring code: worthwhile effort that additionally unlocks testing in production.

My understanding is code reviews are needed as part of SOC-2 compliance. More to supplement automated testing than explicitly mandated. In other words, it makes auditors happy to check off the requirement about verifying changes going to prod.

The remarks about code comments are little too extreme in my opinion. Some code can be difficult to understand at face value. Like I’m writing a Vite plugin and it has code like this:

    const moduleId = "virtual:mypkg";
    const resolvedModuleId = "\0" + moduleId;

Unless you’ve written Vite/rollup plugins, which many folks haven’t, you’re going to appreciate a comment that at least points to some docs.

If anything, succinct code comments that explain obscure conventions or describe relevant critical requirements are worth their weight in gold because they are valuable tokens for a coding assistant.

Disclaimer: I work at Speakeasy but not the author.

It probably needs better wording because it's sort of the wrong complexity metric. Many customers have gigantic OpenAPI documents with large numbers of deep and wide JSON Schemas that contain things like allOf/oneOf/anyOf sub-schemas, all of which need to be parsed into an object model for use by downstream tooling (e.g. code generation). For those customers, we want generation time to be super speedy and since this is a core aspect of Speakeasy, it made a ton of sense to us to take full control of OpenAPI parsing and optimize it.

When you turn on exhaustive, exhaustruct and wrapcheck linters in golangci-lint. You get such a massive safety boost and it makes you fly through writing Go.

One of the team members working on Gram here.

I initially worked on a code generator for OpenAPI -> MCP in January but very quickly we found issues relating to poor quality operation (tool) names and descriptions. Not to mention that each API endpoint does not cleanly map to an MCP tool and yet it all gets dumped into the context window - sometimes exhausting it if you have hundreds of schemas and endpoints.

Gram is our attempt to make better use of API by adding a curation layer:

- You upload your OpenAPI document, or any number of other OpenAPI documents. - You then subset them into "toolsets" by selecting only the ones relevant to a domain (e.g. reading stripe charges) or business process (e.g. understanding customer health by reading info from your CRM, data warehouse and so on). - Optionally, you create custom tools (these are prompt templates under the hood) that describe how to make a series of tool calls to solve a problem. - Finally, every toolset is automatically exposed as a hosted/managed MCP server. No waiting for build or deploy steps. - You can edit the names and descriptions of all imported tools and they are instantly reflected in the MCP server.

The net result is you have a rapid iteration loop to create effective tools from your API.

I hope you have a chance to try it out. Will be around to answer any questions in the mean time :)

I just love how this language marches forward. I have so many colleagues that hate many aspects of it but I sit here combining Go, Goa and SQLc writing mountains of code and having a fairly good compiler behind me. I understand what I’m missing out on by not using stricter languages and so often it’s a totally fine trade off.

Not a Firefox user I take it?

The introduction of WWW-Authenticate challenge is so welcome. Now it's much clearer that the MCP server can punt the client to resource provider's OAuth flow and sit back waiting for an `Authorization: Bearer ...`.

It's somewhat disappointing to see a bunch of "well, duh" comments here. We're often asking for research and citations and this seems like a useful entry in the corpus of "effects of AI usage on cognition".

On the topic itself, I am very cautious about my use of LLMs. It breaks down into three categories for me: 1. replacing Google, 2. get a first review of my work and 3. taking away mundane tasks around code editing.

Point 3. is where I can become most complacent and increasingly miscategorize tasks as mundane. I often reflect after a day working with an LLM on coding tasks because I want to understand how my behavior is changing in its presence. However, I do not have a proper framework to work out "did i get better because of it or not".

I still believe we need to get better as professionals and it worries me that even this virtue is called into question nowadays. Research like this will be helpful to me personally.