Wow, that is a deep level of commitment and learning/exploring; I love it. While I'm sure this is informed by deep preexisting knowledge (to a point -- it's still badass in its own right), I can't help but admire these skills and feel a little inferior about my own.
Adding on to this question, do you anticipate the same people capable of tapping phones to think less of you for a dirty joke? The people whose opinion of me would lower for something off-color and the people who possess the ability to wiretap me are a disjoint set lol.
Absolutely. I love building things, but sometimes I want something built. LLM assistance is great for when I want a personal tool, code quality be damned, for a specific purpose, without it taking over a weekend.
I develop an open-source self-hosted client (very mobile friendly) for base-station radios that you want to use from anywhere, and also support MQTT/community observers/bots/webhooks/etc. It spawned out of my need for a daily-driver client that wasn't chained to the radio, and turned into a super fully featured companion client for power users.
The radio API and firmware is open; I have no ire for people who choose to make software closed source so that it can be monetized when there are SO many other options that in many cases supersede the functionality of the closed source option.
For sure. This is a straight copy-paste of my prompt which references my architecture, codebase, references folder (God, that's so golden -- .gitignored, but saving the tokens of googling or cloning and just having the codebases we depend on locally is killer) so this is not ready to be copy pasted. However, with the context that this is an interface for a peer-to-peer encrypted radio mesh client (for MeshCore; my code is https://github.com/jkingsman/Remote-Terminal-for-MeshCore), that can maybe give you a mote of context around things that are obviously key (e.g. sending/receiving) or important but not a topline acceptance criteria (message ordering, async radio operations, etc.) to port this and try it out on your codebase.
Also, I say "prior to public release" and obviously, this codebase is super publicly released, but that doesn't matter -- what I'm doing in the prompt is priming my agents for a this matters tone. I have no opinions I'd state publicly on the consciousness argument, but I generally dislike deception; in this case, I find declaring this to be our last ditch review before public release puts it in a context state to be more details-oriented than other primers I tried ("this is our final release" led to too many interoperability/future-proof finds; "this codebase has subtle bugs introduced by an adversarial engineer" had too many security false positives or true-but-absurd positives; "please be detailed and carefully dig deep" just wasn't as good. Plus, the "public release" paradigm helped it to do innate classification of "gotta fix before release" vs. "fix soon after" vs. "fix when able" which maps pretty well to my personal taste in the severity of bugs it's found I've evaluated, so I've kept it).
I really identify with this. As an engineer, I really do enjoy building things. However, a lot of times, what I want is a thing that is built. A lot of time, that means I build it, which sometimes I enjoy and sometimes I don't; so many of my half finished projects are things that I still think would be awesome to have but didn't care to invest the time in building.
LLM-driven develop lets me have the thing built without needing to build the thing, and at the same time I get to exercise some ways-to-build I don't use as often (management, spec writing, spec editing, proactive unblocking, etc.). I have no doubt my work with LLMs has strengthened mental muscles that are also be helpful in technical management contexts/senior+principal-level technical work.
Absolutely. I've got a nice multi-paragraph prompt on hunting for subtle bugs, user expectation breaks, crufty/repeated code, useless tests (six tests that actually should be one logical flow; assertions that a ternary is still, indeed, a ternary; etc.), documentation gaps, and a few other bits and bobs.
I sick Opus, GPT5.4, and Gemini on it, have them write their own hitlists, and then have a warden Opus instance go and try to counterprove the findings, and compose a final hitlist for me, then a fresh context instance to go fix the hitlist.
They always find some little niggling thing, or inconsistency, or code organization improvement. They absolutely introduce more churn than is necessary into the codebase, but the things they catch are still a net positive, and I validate each item on the final hitlist (often editing things out if they're being overeager or have found a one in a million bug that's just not worth the fix (lately, one agent keeps getting hung up on "what if the device returns invalid serial output" in which case "yeah, we crash" is a perfectly fine response)).
Absolutely. Effective LLM-driven development means you need to adopt the persona of an intern manager with a big corpus of dev experience. Your job is to enforce effective work-plan design, call out corner cases, proactively resolve ambiguity, demand written specs and call out when they're not followed, understand what is and is not within the agent's ability for a single turn (which is evolving fast!), etc.
It really is incredible. I've been playing through my childhood games on retro handhelds, and recently jumped from <$100 handhelds to a Retroid Pocket Flip, and it's incredible. Been playing WiiU and PS2 games flawlessly at 2x res, and even tackling some lighter Switch games on it.
I think they're saying that OpenSSL is NOT elegant, but that it is successful regardless; hence, code elegance is irrelevant to whether a product is successful or not (and thus that horribly ugly LLM-generated code has a shot at becoming successful).
Big fan of MeshCore; been using it recently and it Just Works. Especially where I am in the USA Pacific Northwest, the mesh is always hopping with conversation. I have run into delivery issues a single digit number of times over hundreds of messages.
Crazily, I only stumbled upon this because I ordered some discount blood labs and the requisition had Health Gorilla on the letterhead, which I found an absurd company name, so I googled them, and found the lawsuit which was filed the day prior. Absolute chance.
It took me a bit to get my head around this one; https://healthapiguy.substack.com/p/epic-v-health-gorilla-a-... has a great alternative breakdown. This is my understanding of the situation; if someone has any corrections, I would love to be enlightened!
Essentially, Epic, a massive healthcare company running the majority of electronic healthcare/medical record systems for hospitals/etc. makes data available to various data brokers, who then subcontract to other healthcare providers. The goal of this subcontracting is that if you e.g. come into an emergency department unconscious, but with identification, doctors can pull data from the broker, solemnly swear that they're treating you, and gain access to your whole medical record. Generally, good actors in this space will seek signed consent paperwork, or have policies in place with narrow carve-outs for emergency access, but there is (to my understanding) not a centralized, standardized system of access request, patient approval, and auditing.
There have been many issues in the past with shady providers who are, indeed, treating the patients, also turning around to sell the data they have to legal firms looking for plantiffs for lawsuits under the guise of "we're helping the patient by potentially giving them access to lawsuits that will advocate for them."
This current lawsuit alleges that the data brokers this time were simply turning a blind eye to completely fraudulent actors who never had the patient under their care, and that their access was knowingly used to bulk-mine patient data for lawsuit opportunities.
You mentioned working on it — do you have a particular strategy, venue, or opening line/guiding ethos that you find works well?
I love making friends with strangers, but usually rely on the "handshake protocol" of a casual observation or small talk that is then accepted (with a similar slight-deepening or extension of the thought) or rejected (casual assent or no response at all), until the bandwidth opens and I can foster a more meaningful moment of connection with a pivot like "Oh awesome that you do $THING for work. Do you enjoy what you do?" or "Oh I don't know much about $LOCATION_YOURE_FROM. Good spot for a vacation, or good spot to drive straight through?"
As somewhere between "thinks like an engineer" and "on the spectrum," I really enjoy hearing others' strategies or optimizations (optimizing for quality, connection, warmth) for social situations.
I think it's intended as a comparison of cost when building a gaming-capable computer vs. a console of somewhat equivalent power.
It used to be a general rule of thumb that you could build a computer of roughly equivalent power for the cost of a game console, or a little more — now the memory costs more than the whole console.
Privacy is vital, but this isn't covered under HIPAA. As they are not a covered entity nor handling medical records, they're beholden to the same privacy laws as any other company.
HIPAA's scope is actually basically nonexistent once you get away from healthcare providers, insurance companies, and the people that handle their data/they do business with. Talking with someone (even a company) about health conditions, mental health, etc. does not make them a medical provider.
I find it especially helpful during refactors — understanding the significance/meaning of the variable and what its values can be (and are constrained to) and not just the type is great, but if typing is complete, I can also go and see everywhere that type can be ingested, knowing every surface that uses it and that might need to be refactored.
What a badass level of deep dive.