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.
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.
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.
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.
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.