readitalready

How do you think the tests were generated?

You don't actually think I look at the code, do you?

I don't micromanage it. I let my projects custom linter micromanage it.

Every project should have a custom linter for their tech stack. It would check for not just syntax errors, but architectural choices as well as taste guidelines.

Whenever the LLM writes bad code, I add it to my linter to check against in the future.

I let agents break things 30 changes down the line. If something breaks, I add a check to my project validator and start over, with the validator providing instructions on what was wrong and how to fix it. It's all automatic, and now I have a guard against the exact same error in the future.

Some of these checks have caught thousands of the same error, even with the latest Opus 4.7 writing the original code.

This flow is really for LLM consumption, since Markdown spec documents are for LLMs anyways. And you can always write a JSON-to-markdown converter for human use (actually, LLMs remember Markdown content better than JSON, so you should use that in your flow a well).

The real change is in generation side, and now the spec docs are LLM generated JSON based on other spec docs or human prompts. LLMs seem to write JSON better than Markdown or YAML, if you tell it to follow a schema.

I moved from Markdown to JSON for all spec writing about 9 months ago. Although not HTML, it still has the same benefits. Claude and the other models are just so much more reliable in a structured format like JSON/HTML/XML.

The most important thing is that I can run static analysis on a structured format. This is important even for my spec documents. I can write data fields and have static analysis analyze it. For example, to confirm database fields match across various spec documents, etc.. The static analysis is also why you use JSON/XML instead of HTML, since you can now have your own custom schema.

Also don't use YAML, as that's far more unreliable. (If you chop a YAML file in half, it's still valid)

Not for me. 2 Claude Max 20x accounts here both at high usage on weekly allotments.

This probably started because of Andrej Karpathy's complaint about deployment being more painful than coding itself.

The point isn't to save money. The point is to make money. And all those companies that are failing because of their fabs, they MADE money because of the fabs.

Intel is now on its way to become another AI chip company. They have no incentive to supply Apple either.

Your custom linters don't check architectural design?

linters statically check code and provide deterministic recommendations. LLMs are used to make judgement. I specifically write my linters for my project to make recommendations for LLMs.

This is how you save on token usage, so your LLMS aren't wasting tokens on static analysis that a linter could do for free.

That's at least how I make my linters.

No fixing the mess definitely does not take longer than writing it oneself.

Your linter should identify all issues - including architectural and stylistic choices - and the AI agents will immediately repair them.

It's about 1000x faster than a human code at repairing its own mess.

Come on Apple at least start the process of building your own fabs. License some of the processes if you must. Otherwise you will always be at the mercy of fabs that are more focused on AI.

I think companies are charged API prices vs individual prices. That alone is 10x for Anthropic. Not sure though.