SkyPuncher

Owning property through a corporation is trivial. 3 of my nearby neighbors are owned via an LLC (rentals).

* Start an LLC/C-corp for a trivial amount of money.

* Purchase land, but instead of paying with it via a personal check, you need a touch of foresight so you can "capitalize" the corporation you just started. Write the check from the corporation, instead of your personal checkbook.

HIPAA is completely irrelevant to any of this. Ours is technically HIPAA complaint because the data they process is not subject to HIPAA.

In overly simple terms, if insurance is not involved, then it’s not subject to HIPAA.

> If you're not already applying static analysis and linters to your codebase

Because most issues are in business logic that static analyzers aren't going to catch.

Yes, there's an em-dash, but it reads fine to me.

I've settled in on the opinion that it's much more creative and able to run agentically for longer periods of time. So, despite it not having drastically better "hard skills", it's able to combine those together in more effective ways.

Right now, many of these vulns are identifiable by Opus, but they still require a human-in-the-loop (and often a skilled one) to guide towards complex exploits. Without a human in the loop, this means it's a lot easy for the average person to identify and leverage an exploit.

For #2, I’d expect you’d use this through an organization/business account that has data retention turned off by default.

Not sure what laziness has to do with this. It’s all about tradeoffs.

Auth isn’t something I want to think about. There are a lot of hidden traps.

Yep, it’s just a drag. It’s not our core product value so any effort we put into it is a drag.

I strongly disagree. If you’re selling to other businesses, much of that is an expectation.

It’s just a few fields until it’s not.

SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.

For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.

Yes, it can. I do this regularly.

I have literally built and shipped multiple things that would have taken me many many months to do and I’ve done it in under a week.

Many of these are LLM heavy features where the LLM can literally self-evaluate and self-optimize. I start with a general feature, it will generate adverse, synthetic data, it will build a feature, optimize it the figure out new places to improve. 1 year ago, this would have taken an entire team months to do, now, it’s 2 or 3 days of work.

I might be the outlier, but this PR feels like heaven to review. It's a complete, all encompassing PR that I can work through with the entire context right in front of me.

If the initial development bar is relatively high, it's far, far easier to identify flaws and gaps when you have the whole thing in front of you all at once.

Thanks for sharing those. They look interesting.

For me, sometimes faster/sometimes slower, but there are a lot of other benefits besides speed:

* I can work in code I'm not familiar with much easier

* LLMs often identify confusion or uncertainty upfront, so I can address it earlier.

* I'm much less mentally taxed so I can go for longer at my top end.

* Meetings, disruptions, end of day is WAY less critical since I can lean on the LLM to get back into things.

* I can do something else productive while the LLM is running. Bug fixes, documentation, PR reviews, etc.

I'm working on something similar as a side project. I'm finding frustration with a lack of repeatability in my LLM flows. 90% of my code is AI written, but most of my guidance to LLMs is not particularly specific. It's "make sure you've read this file", "how does that match against existing patterns", "what's the performance like".

I've ended up building my workflow engine directly in Python, despite YAML being the default choice for LLMs.

I found that YAML had some drawbacks:

* LLMs don't have an inherent understanding of YAML conventions. They tend to be overly verbose. Python code solved this because "good" code is generally as short as you need.

* YAML isn't really composable. Yes, you can technically compose it, but you'll be fighting the LLM the entire time. Python solved this because the LLM knows how to decouple code.

* I want _some_ things to be programatic still. Having Python solves that

* Pretty much any programming language would do. Python just feels like the default for LLM-centric code.

I’ve noticed a few times that when I get the LLM into a really niche situation, it will start spitting this out verbatim from the internet.

They're like reading a projector. It's not very good, but it's better than awkwardly staring at the computer screen.

It's really no different than managing people.

Managers simply cannot know all of the details of what their reports write. They have to build abstractions.

I’m in the cutting edge of agentic dev at my company, but there’s no way they could have rolled this out in a meaningful way in two weeks. I can barely get a repeatable process, let alone one that I can actually teach everyone else.

“Decide upfront” is a load of crap. I can write the “perfect” spec plan, but we always, always miss something or misunderstand something. Agents will follow a high confidence spec blindly because they think it’s the blessed pattern.

To me, it sure looks like they took a “best practice”, stuck it in the flow chart then demand everyone use it.

I see zero details about how they actually learned what their devs need, how they know devs are getting value out of this, and what problems devs are trying to solve with agentic tooling.

Same here. 4.6 was a downgrade in thinking quality, but I appreciated the extend context at first.

Over time, I realized the extended context became randomly unreliable. That was worse to me than having to compact and know where I was picking up.

AGT dm12x-plus.

I liked that it had the dual speed walk mode. Don't want to be creeping around the yard.

Mine comes in tomorrow. When researching, I was amazed at the simplicity of these machines. The engine is essentially available at Harbor Freight, then it’s basically just a hydraulic pump and valves. When things break, I’m sure I can find a replacement part or hack something together.

Defense in depth. Layers don't inherently make something less secure. Often, they make it more secure.

I find this critique extremely odd. Sure, Apple isn't perfect, but literally every thing they do is top tier in the category they enter.

I started writing out a list of Apple's products and it was simply [x device] in [y category] is either the best or consistently rated in the top of that category.

We're using rails, so it mostly just comes down to pulling main and running migration.

I don't really worry about conflicts on branches since most features aren't long lived enough.

> they don't even understand that design is NOT outputs.

Correct, design is really about understanding something and curating a solution for it. In tech, that just happens to mostly be distilled as mockups.

That being said, my team is increasingly not needing Figma itself for many features:

* The first pass is often a lovable prototype or some low-fidelity mockup. These are enough to get us all aligned on what's being built.

* Engineering takes a first pass. Gets a UI base in place.

* Designer (who can vibe code) or UI engineer comes in to put the high fidelity touches on things.

Basically, the product itself becomes the mockup.

I actually just did this recently. I looked at a bunch of solutions for my dev environment, but Claude kept pushing me back to a really simple one: use Postgres.

Postgres has template database that effectively give you a really easy means of "cloning" a database. On AFS (and several other file systems), copy-on-write is pretty much native.

Yes. I actually noticed my token usage go down on 4.6 when I started switching every session to max effort. I got work done faster with fewer steps because thinking corrected itself before it cycled.

I’ve noticed 4.7 cycling a lot more on basic tasks. Though, it also seems a bit better at holding long running context.

Hmm. All of the examples simply describe what the code is doing. I need a tool that explains the intent and context behind a change.

> What's your basis for thinking that codex is best for planning, but opus is best for implementing?

I for one work on an agentic product where we use all 3 of the major frontier models. The models absolutely have preferences and "personality" that lead to different characteristics.

In my eyes:

* Gemini - consistently the best at pure reasoning and tunability. Flash models are particularly good at latency sensitive small-scale reasoning. The tradeoff is they struggle with some basic behavior, like tool calling.

* Claude - consistently good at long standing sessions. Opus may or may not be the best model, but it was the first model that crossed the "holy shit" threshold. I understand it's quirks/nuances and it's consistently solid. It's the best for me because I've learn how to be incredibly effective with it.

* ChatGPT - Probably really good, but probably not worth switching from Claude. Last time I used their frontier model, it was a bit random. It would have moments of brilliance immediately followed by falling flat on it's face.