Not really a requirement, if you did fine without the tools before you would do fine again. The difference is you would know which ones are worth manually maintaining
I have no use for this, however I am stunned by the simple and effective solution of using json+sse instead of an API to allow agent interaction
Amazing work
> Code bases that you "work in" (maintain, etc) solve real world problems, and solving those problems should trump cleanliness every time
Only if you value your time more than the users’ time and your fellow developer time. Code are run and read more than they are written. You may need to do some hacky coding, but they should be small in scope, surrounded by warning, and have a ticket filed for properly resolving the issue. Otherwise, it’s not worth it.
Outside of opensource developers do not suggest what code is written.
Sales does.
If the developers say something like "well this will take 3 weeks longer to do correctly". They'll be replaced by the code monkey that can turn a POC over to the customer in 3 days.
You must have worked in some pretty dysfunctional organizations. Nobody just says "it will take 3 weeks longer to do correctly" - they'll say "if we skip X, then it will potentially result in Y; or we can do Z which will take a little longer but will not have this potential business risk".
You gotta use the language that folks speak in order to get your point across.
> “well this will take 3 weeks longer to do correctly".
Well, I haven’t met any experienced developers that say this sentence. It’s career suicide in most cases. More often, an agreement about scope and delivery is reached and workload gets reshuffled. Customer battling with POCs to get their tasks done are soon to be ex-customers.
I have a (relatively well informed) view that people who aledge that "if you used an llm you did no thinking or problem solving" have never in fact used an a llm to generate anything particular complex.
You do indeed need to do quite a bit of thinking and problem solving, to build things with an llm.
If you disagree, repeat this project, so you can share with us how little thinking it required.
I was stubbornly of the same mindset, but had friends and colleagues that raved about skills, i thought it was hype cycle context management - i'm happy to be proven wrong
haha interesting - the article is 99% written by me, but i had gemini review it and sharpen up the send off because it felt weak.
I guess this goes to show that even a subtle touch of an LLM can undermine authenticity.
edit: i've removed that line. I don't like to edit articles after publish (call me old fashioned, but i try to be honest and transparent), in this case though the line adds nothing and your call-out has taught me a good lesson: shit human writing is better than "good" AI writing.
I personally don’t think there is anything wrong with this. To the critiques I would say; this is the world we live in now. There are LLMs capable of essentially perfect writing skills. We need to get used to seeing a lot more content either written by or finished by LLMs.
The best practise for writing docs with LLMs in my opinion, which you have done, is to write as much as you can first then feed that into an LLM for context, and then work with the LLM to finalise it. Maybe half the time is spent writing and half the time is spent going back and forward polishing the doc.
Finally I think it’s important to give the LLM very clear writing guidelines based on your own writing style. I did this by feeding Claude around 20 of my handwritten docs and asked it to analyse my writing style and then add thy to its Claude.md. After a free round of iterations you can get great results!
Good advice. After seeing the capability of the skills for frontend design by impeccable crew ( https://impeccable.style ) i am tempted to make my own `/blog-polish` skill or similar
> It looks like someone just pointed a LLM at the codebase and asked it to write an article.
Not entirely true. I pointed an LLM at the codebase to get me to the right files for understanding skills, and to map out the dependencies and lifecycles - Then I spent quite a bit of time reading the code myself and writing about it.
An AI review at the end of the writing (to "sharpen" the language) unfortunately brought in a couple of AI fingerprints (note the "mic drop" comment above)
Not really a requirement, if you did fine without the tools before you would do fine again. The difference is you would know which ones are worth manually maintaining