roberttod

I created my own version with an inner llm, and outer orchestration layer for permissions. I don't think the OTP is needed here? The outer layer will ping me on signal when a tool call needs a permission, and an llm running in that outer layer looks at the trail up to that point to help me catch anything strange. I can then give permission once/ for a time limit/ forever on future tool calls.

Mostly, it's not the model that is lacking but the visibility it has. Often the top level business context for a problem is out of reach, spread across slack, email, internal knowledge and meetings.

Once I digest some of this and give it to Claude, it's mostly smooth sailing but then the context window becomes the problem. Compactions during implementation remove a lot of important info. There should really be a Claude monitoring top level context and passing work to agents. I'm currently figuring out how to orchastrate that nicely with Claude Code MD files.

With respect to architecture, it generally makes sound decisions but I want to tweak it, often trading off simplicity vs. security and scale. These decisions seem very subtle and likely include some personal preferences I haven't written anywhere.

It's unintuitive, but having an llm verification loop like a code reviewer works impeccably well, you can even create dedicated agents to check for specific problem areas like poor error handling.

This isn't about anthropomorphism, it's context engineering. By breaking things into more agents, you get more focused context windows.

I believe gas town has some review process built in, but my comment is more to address the idea that it's all slop.

As an aside, Opus 4.5 is the first model I used that most of the time doesn't produce much slop, in case you haven't tried it. Still produces some slop, but not much human required for building things (it's mostly higher level and architectural things they need guidance on).

I remember such a project, and due to our large and aging TypeScript frontend projects it would have added a couple of weeks to adjust all the types affected. All IDs in many places deep in code caused thousands of errors from the mismatch which was a nightmare. I can't remember exactly why it was so tough to go through them all, but we were under intense time pressure.

To speed things up we decided to correct the ID types for the server response, which was key since they were generated from protobuf. But we kept everything using number type IDs everywhere else, even though they would actually be strings, which would not cause many issues because there ain't much reason to be doing numeric operations on an ID, except the odd sort function.

I remember the smirk on my face when I suggested it to my colleague and at the time we knew it was what made sense. It must have been one of the dumbest solutions I've ever thought of, but it allowed us to switch the type eventually to string as we changed code, instead of converting the entire repos at once. Such a Javascript memory that one :)

I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.

As much as I agree with the sentiment, I can buy a firestick, Apple TV or Roku for a very small cost. Sure, a dumb TV would be lovely, but only because of a quicker boot time.

Given a dumb TV is going to be more expensive, I can't see a market for it based on a small marginal gain for the consumer. And 90% of people don't even care enough about the poor user experience vs the marketing that hypes up features no one uses or needs.

I wasn't sure what an "interlock" was, and it's a breathalyzer that prevents the vehicle from starting. Was that a mistake?

Edit: ah! I think you meant engine immobilizer

HN post here claims this paper may not exist https://news.ycombinator.com/item?id=36848605

Do these providers really bring enough value to use them over a colocated managed db? (Not just the same region, but subnet etc)

I was under the impression for quite some time that it wasn't that bad to have 2-3ms latencies compared to a co-located DB which is typically <1ms. However, we recently switched from Neon to a colocated, managed db and there was a huge improvement. Some of our queries were executing sequentially (due to our ORM, Prisma), and so what was a 3 second transaction was reduced to only 1 second. Yes this could be rearchitected better, but it illustrates a major floor in my mind for these companies providing only a DB.

Managed vs. unmanaged is a massive difference and would be worth it. But these days I was under the impression most hosting companies also offer managed DBs.

All the awful reviews of united here, and yet it's reviewed as one of the highest rated insurance agencies (for example see https://www.forbes.com/advisor/health-insurance/best-health-...)

Are these reviews completely paid for? What's going on here? Or are all the options awful.

I am in the position to choose our provider at our (small) company, but between Gusto and JustWorks and the majority of our employees being in Texas there was slim to none options except united.

Thanks for mentioning this. I did a bit of reading about the special alignment - very interesting stuff!

It seems like the alignment you refer to inspired the launch of Voyager 1 and 2 because they could visit so many planets at one time, and indeed it did slingshot them at quite some speed. However newer launches have reached similar speeds, and will escape the solar system due to improvements in launch technology.

Bomello | Hybrid, ~3 days a week in office | Austin | Full-time

$160-185k base, with founding engineer equity

Looking for a founding fullstack engineer who will work alongside me (CTO of Bomello), as a peer, to build out a product from scratch. As revenues grow, I am committed to only hiring experienced and self-starter type engineers so that we can do more with fewer people.

Starting date Jan 2024, but we are flexible.

Message me via the email on my profile, or https://www.linkedin.com/in/roberttod/

Tech stack (open to change): Vercel, Typescript, React, RedwoodJS, Postgres, GraphQL

Agree that for a while at least it seems you'll need to understand the domain it is helping you with. That said, with the improvements in GPT4 over 3 in such a short time, and with plugins, I would be surprised if it takes any longer than a couple of years to be much much better at this to the point it is correct most of the time. You will probably still need domain knowledge at that point, not quite sure if that will last either.

I think you need to try it out, with GPT4, because it is so obviously much better than Google. Simple queries are fine with Google, not much difference, but especially for things like coding problems (where you can e.g. specify the environment you are running in) it has always responded with the correct answer the first time. It's already saving me over an hour a day, and as far as I understand there is much more things it can do I am not using.

It's an open source library, I assume that logic is abstracted within it and that the "basic mistake" was one of the maintainer's.

Piggybacking your piggyback, that graph for the temperature throughout the day looks pretty but damn terrible UX in comparison to dark sky. Hourly temperatures/rain/etc gives me everything I need at a glance without having to drag my finger to the time I am interested in.

Given a few conditions I completely agree with this sentiment.

If this does indeed become world-changing, leading to AGI, then the best hope we have is that those with all the power are ethical. Giving it to everyone could be chaos. Giving an advantage to other superpowers would be terrifying.

Not ideal, but in their position I can't think of a better alternative. I am not saying I want anyone to have AGI btw, just that this is going to happen eventually (perhaps not via OpenAI/GPT) and getting there first may be game over for all other parties.

Taking this with a pinch of salt given the nature of our current situation vs. 2008.

Technology progresses more or less independently of the stock market.

Progress could be defined in many ways, but sure as hell there is less money in the tech sector, and funding is very difficult right now as far as I understand.

I do agree with the sentiment that the market shouldn't affect your timing if it can be avoided, but I wouldn't expect it to be very easy to start something capital intensive with a long road to profit right now...

We do generate the protobuf from a different repo which gets published on npm, and we could generate it for different versions of TS. I suppose all of this work is part of the overhead I am not so happy about using TypeScript.

Where I work, everything on the frontend is TypeScript, everything Nodejs is TypeScript. I did create a nice little bash utility using Standard style i.e. vanilla js in Node and that's worked out well.

Although I'm senior enough to start a new project without TS within my team, I think it would be a little egotistic. Although I am not convinced by TS benefits, most people at my company are convinced it's necessary and I don't think it's worth going against the grain. There's many more important decisions when starting a new project, and I think the architecture is much more important than whether to type or not. Besides, I now choose to use Go on anything server side, and try to shy away from the frontend because I don't find it as fun to code as I used to (partly because of things like TS, partly because the kind of work doesn't feel as engaging, and feels like busywork).

I worked at a company previously that had a large NodeJS codebase that was largely created before TypeScript was so popular. That's what I mostly have to compare against, and so I do know what it is like to do massive projects with many people without TypeScript. I don't think we ever felt the need for types, and building and pushing code was always simple and safe.

Unfortunately I think he's conflating typescript's role and a library with broken type definitions (I have no idea whether the type definitions he's had problems with are provided by the library or a community effort that may not keep pace with the official library). When the type definitions don't match the official library it can definitely cause a tremendous amount of frustration and make one doubt the usefulness of types.

I am not trying to cast blame on any part of the TypeScript system. I have tremendous respect for the TS team and the problems they have had to solve to get this far. My point is, is it actually worth it? Whether people document their libraries is part of the equation, even if it may not be a direct responsibility of the TS team.

I thought things might get better as the community matures, but I am still dealing with issues that seem to sometimes outweigh what I get from it.

And I want to be clear as well that I mean to shed light on this thought and hear people's opinions. I am still open minded, and will continue to decide whether to use JS or TS depending on many variables whenever that decision comes my way. For personal projects I am currently in the boat that I would not choose TypeScript.

It's the original, which is being compiled on our internal protobuf definitions in a different repository and then installed post compile as an npm module.

I spent a while trying to grok the TS error but started to suspect that it didn't make a lot of sense, so I rm -rf node_modules, reinstalled, and it went away.

It would be hard to figure out what was at fault, but it's probably a combination of the node module system, protobuf, ProtobufJS and TypeScript. I do sometimes get funny type errors and restarting TypeScript makes them go away, in this case I had to go a step further.

I'll let you know if I get this again, or figure out what happened.

I've been continuously frustrated by it - but the projects I'm working with are large, or leverage some more complicated dependencies. For example both ProtobufJS and Apollo can be very tricky.

I also do a lot of refactoring and improvement on these codebases, often updating packages, so perhaps I run into more issues more frequently than many. I accept that a lot of the time it can be smooth sailing, but anything tricky and it's a real time sink.

I spent 6 years programming production JS delivered to millions of people before I went to TS and it just wasn't that bad. The code was clean, and the team didn't ship many bugs - this was for a big frontend and ~12 microservices.

Webpack added a lot of overhead - but if you know what came before it, it was a godsend. React added a super complex library, vs Backbone which was only a few hundred lines of code but React is totally worth it.

I'm not just trying to hark back to "the good old days", I think the ecosystem is a big improvement from where it came from but I just haven't seen enough benefit from TS for all the work you need to put in.

Yes, 100%. This is exactly how I feel about it - and the idea it has become some unfalsifiable religious ideology is particularly poignant. It's such a drag on development and personally I just don't see the upside that much, just some assertions from people that seem to be repeating something they've heard elsewhere without much experience weighing in on the discussion (except for autocomplete and self documentation which imo is the best part, although could be replaced by something like JSDoc).

Sure, I'm okay to live with TS, and it has its uses, but I thought it was about time we had a discussion about how much harder it can make development.

This is absolutely on point and just had me cry laughing. Thank you.

I am thinking of the case where you are passing an object or class to an API that needs to be shaped a certain way. In this case you need to know which type to import/use to pass it through.

For many simple libraries it's not too much of an issue, but for more complex things like Apollo (which also doesn't include much TS in their docs) it's a lot of hit and miss until you get it right.

Good code takes a lot of thought and care, and won't materialize just because you use static typing.

So why am I spending so much time applying static typing instead of thinking about how the code should flow, about what's the best abstraction, writing thorough documentation.

Typescript comes at a much higher cost than built in static typing, and I don't think it's worth the investment.

That's a lot of layers for a codebase... I see that it could be useful in that situation, but since you presumably need to test and QA your code anyway you could also throw in a console log statement.

There is also JSDoc.

Although these solutions might not be quite as nice, I'd wager they'd save quite a bit of headache and time.

I worked many years before TS too and happened to have been working on very neat codebases back then, though I did have the luck of working with a really talented set of people.

I conceed that perhaps you are correct about this - it does force people to write less strange code. JS gives you so much freedom that if you don't keep it simple you can really hang yourself. However if you put care into your code and keep it simple, I don't think TS helps all that much.

There have also been situations where I have had to do something a little bit strange, and TypeScript made it an absolute mess. And if you do enough JS you'll know that sometimes you do need to write a function that needs to leverage dynamic typing pretty hard, even if it's quite rare.