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.
To be honest, I am past the point of wanting to convince people that AI is useful, if you want to refuse new tools other people find helpful, your loss.
(Also I stick to the original definition of "vibe coding = not looking at generated code", "LLM assisted coding = verify generated code", I do both, depending on the task)
Down the line the agent is no longer able to fix one failure without causing another and the codebase is unsalvageable, but you may not have reached that point yet.
Agents can help a lot when you carefully review everything they output and find all the time bombs they like hiding in your code and your tests. If not, then they're fine for codebases that don't need to last more than a year or two.
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)
I think this is super interesting, but i think you and the OP is talking about two different problems: presenting text to end users and structuring text for agents
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.
For my schemas, I found LLMs really wanted to just use markdown embedded in the strings, so I've been considering doing away with the schema. I also figure that embedding markdown in a string may make it perform worse as it has to juggle nested formats, and thus escaping and such (wanted: eval for this). By replacing the json tool call with basic markdown extraction, I'd lose some structured data but gain flexibility (html would be even more flexible).
Wondering if you are referring to adherence to required data in a schema when you say LLMs do better with json vs markdown, or something else? Or perhaps to tool calls and/or strict json output being more reliably formatted for clean extraction?
> Your linter should identify all issues - including architectural
If a linter could deterministically identify bad architecture, you wouldn't need an LLM, your linters could just write your code for you. The vibe coding takes are just getting more and more empty-headed...
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.
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.
You look at a fab landscape where the number of leading fabs has been dwindling as the decades go by, to the point where the only two players left are Intel and TSMC AMD even Intel is clearly struggling to keep up, and you think a good solution is "just build your own fab"? That Apple, with its complete lack of silica fabrication experience, will be the one company or one of the two companies in the world to succeed at staying competitive with TSMC, where all others have failed?
Apple has deep pockets, I'll give you that, but this seems far fetched. If the goal is to keep the US competitive, or to just ensure that TSMC doesn't become the literal only supplier of leading chips, partnering with Intel seems like the obvious choice. It's probably better for everyone if Intel and Apple were to collaborate on keeping Intel's fabs competitive than if Intel and Apple compete for the same US chip fabrication market.
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.
Samsung has experience with being a foundry and is also building a 2 nm fab in Taylor, TX. One could argue that Samsung is an even more credible alternative.
“They need their own fabs” is a very current events-biased read of the situation.
You can easily end up like AMD or Intel spending years with your own fab that’s uncompetitive.
One of the best things that ever happened to AMD was spinning off their fabs.
Intel only recently righted their ship after spending years with fabs that couldn’t keep up with competition, and even Panther Lake still contains some TSMC silicon.
The AI boom is inevitably not going to last forever. Either demand will subside or production will increase. High prices in tech rarely stick around.
> There is no scenario where not having a fab is beneficial.
Mmm, I think that's an overly strong statement.
In the scenario where Apple has a fab that's doing work at a 2030 level in 2030, that's great, especially if everyone else is, by their standards, doing work at a 2025 level. In the scenario where Apple's fab is doing work at a 2030 level in 2035, and another fab is doing work at a 2035 level, owning their own fab has suddenly become a liability. If they had used that money to hire the output of other fabs, then as soon as it became clear that another one was eclipsing the one they were using, they could simply switch. And given the way businesses operate, it would be very hard to justify closing down their own fab to use the one that was outperforming it.
Now, granted, that's not an especially likely scenario, but it is a very realistic one.
I always wonder if this is a possibility. They've worked so closely with TSMC that they've many times over the decade bankrolled R&D and equipment that TSMC uses. I would be super interested to know if that relationship has left them enough know-how of the fab process to someday control their destiny there, that would actually be pretty insane.
Apple almost certainly has entire production lines at TSMC that they effectively own. I don’t really think bringing chip fabrication in-house has any immediate benefit for them.
We can observe with Apple’s pricing staying stable that they have some of the best supplier arrangements in the industry.
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.