Technical design docs are higher level than code, they are impricise but highlight an architectural direction. Blanks need to be filled in. AI Shines here.

Formal specs == code Some language shine in being very close to a formal spec. Yes functional languages.

But lets first discuss which kind of spec we talk about.

Also, we only allow engineers to commit (agent generated) code. Designers just come up with suggestions, engineers take it and ensure it fits our architecture.

We do have a huge codebase. We are teaching Claude Code with CLAUDE.md's and now also .spec.md (often a summary of the implementation plan).

In the end, engineers are responsible.

AI is similar to a person you dont know that does work for you. Probably AI is a bit more trustworthy than a random person.

But a company, needs to let employees take ownership of their work, and trust them. Allow them to make mistakes.

Isnt AI no different?

Claude checks multiples websites, reads them all, and answers my question.

You don’t want to be burning tokens and large files will give diminishing returns as is mentioned in the Claude Code blog.

In Claude Code you can invoke an agent when you want as a developer and it copies the file content as context in the prompt.

Both in software hardware and handing.

https://youtu.be/P-H-GJaGiUg?si=eq8YWy8gyJ5YS99X

I think it even surpasses Chinese brands.

Comments URL: https://news.ycombinator.com/item?id=43879186

Points: 2

# Comments: 1

It does not specify how “agentic” systems interact with each other. Depending on what you mean there.

Anybody with experience can give me a tip of the best way to - evaluate - manage prompts - trace calls

I see a lot of people here saying one is better than the other. But it depends on your use case and company size.

GRPC is a lot more complex to start using and hides internals. However it has some major advantages too like speed, streaming, type safety, stub generation. Once you have it in place adding a function is super easy.

The same can be said of OpenAPI. It’s easier to understand. Builds upon basic REST tech. However JSON parsing is slow, no streaming and has immature stub generation.

From my experience a lot of users who use OpenAPI only use it to generate a spec from the handwritten endpoints and do manual serialization. This is the worst of the two worlds. - manual code in mapping json to your objects - manual code mapping function parameters to get params or json - often type mapping errors in clients

Those engineers often don’t understand that OpenAPI is capable of stub generation. Let alone understand GRPC.

GRPC saves a lot of work once in place. And is technical superior. However it comes at a cost.

I’ve seen OpenAPI generated from routes, with generated clients libs work really well. This requires some time to setup because you can hardly use OpenAPIGenerator out of the box. But once setup I think it hits a sweet spot: - simple: http and json - can be gradually introduced from hardcoded manual json serialization endpoint (client and server) - can be used as an external api - allows for client lib generation

But it really depends on your use case. But to dismiss GRPC so easily mainly shows you have never encountered a use case where you need it. Once you have it in place it is such a time saver. But the same holds for proper OpenAPI RPC use.

However my inner engineer hates how bad the tooling around OpenAPI is, the hardcoded endpoints often done instead of server stubs, and the amount of grunt work you still need todo to have proper client libs.