HackerTrans
トップ新着トレンドコメント過去質問紹介求人

lucfranken

11 カルマ登録 10 年前

投稿

One Prompt, Zero Engineers: Your New Internal Dev

a16z.com
3 ポイント·投稿者 lucfranken·11 か月前·0 コメント

コメント

lucfranken
·18 時間前·議論
Just out of curiosity: How did you mentally keep oversight of so many terminal doing things all around the place? Or is this done without too much oversight and do you just look at the results like sales volumes?
lucfranken
·16 日前·議論
Totally agree on that, if you have to look constantly at something 95% there is no value. The expectation of course is that it will be better. But if not at a certain level useless.

Not sure how that research compares to the claims being made by many that a second opinion via ai in the end led to changes in treatment. Likely people spent quite some time searching and figuring out. That would be a different and n=1 result. Don't have enough knowledge of that research to determine how much result can be gained when the models are managed in a way that produces better results.

And of course how much time/effort/cost that would take. How much is custom and how much is an automated programmable flow.
lucfranken
·16 日前·議論
That does make sense but the order of it might be: doctor analysis. Then show LLM as double check to doctor. Doctor assesses and may keep en improve the doctors first analysis?
lucfranken
·16 日前·議論
Why wouldn’t you as a doctor by standard run the images through a certified compliant LLM? The actual cost won’t be it and then you can see if you get any new ideas from it. See if it’s just wrong or that it spotted a little detail you missed?

The LLM doesn’t need to be leading or whatever but then you can have a conversation with the patient. If their ChatGPT reports has differences it can be analyzed as well.

It feels like the time constraint of the 15m doctor sessions is the thing. But if prepared immediately after the scan then why not?

There is always time needed to factor in new developments and innovations and that’s fine. Just moving blindly work from human to LLM is wrong. But learning on and testing with all the ai tools incoming constantly won’t be a waste. There will be more and more tools in those processes outside of human judgement, better improve the workflows now to be able to test and plugin new models and systems when they are ready.
lucfranken
·19 日前·議論
For many thinkers it's in a way a very relaxing occupation in some way. Would have to think about why.
lucfranken
·3 か月前·議論
It is a real issue. Makes sense. How are your experiences with it and keeping up with the constant changes in Claude for example? There are many tools which can be installed but it's difficult to imagine how Claude internal develop themselves.
lucfranken
·4 か月前·議論
Would be interesting to think about what startups are not on the list. There should be a tremendous amount. Really interesting to see what you already got.

Also interesting would be that this is map-based, so physical location but I think you will find a lot of startups with unclear physical locations.
lucfranken
·4 か月前·議論
Being curious is always fun right.
lucfranken
·4 か月前·議論
Cool work! Would be so interested in what would happen if you would put the data and you plan / features you wanted in a Claude Code instance and let it go. You did carefully thinking, but those models now also go really far and deep. Would be really interested in seeing what it comes up with. For that kind of data getting something like a Mac mini or whatever (no not with OpenClaw) would be damn interesting to see how fast and far you can go.
lucfranken
·4 か月前·議論
This is interesting to see from multiple sides. The method (voice/chat/whatever) is one piece but the other is:

You already show many questions on one issue (a ticket).

Would you need to think about those? With the secretary the task is split: you decide you need the ticket, the secretary handles the rest while you focus on what you do.

Presenting all options, getting all callbacks, confirm e-mails etc does not change that. It puts all load on you.
lucfranken
·10 か月前·議論
I am currently testing the app. Maybe, for more engagement, start processing cards faster just after installation. It feels weird to have to wait 30 minutes, just show me at least a card. Like the fact that I am installing DayFlow would be a positive experience.

Compliments for the Wizard - that one works perfect at least with Gemini. One little detail: You have a Github Star button in it, that really was at a non-logical place and made me think.
lucfranken
·10 か月前·議論
Really cool!

As already seen in the comments there are lots of desires to add more data compared to just screen input.

Could be things like:

- Apple HealthKit / watch - custom apps - Phone logs

Also you stated, and true, that there is much focus needed on improving your core feature.

It might be interesting to allow some kind of API / plugin area. So that people can expand on your core feature and add the desired parts. Might in the future expand to some kind of AppStore like feature with plugins.

That would keep your work focused and allows others to make it complete in their vision, and for others.
lucfranken
·11 か月前·議論
Generally an archive link under it is posted which is kinda fine. Not all news is available on public websites which would be a negative if it is not there actually maybe?
lucfranken
·11 か月前·議論
One of the most challenging things I currently find is that it’s complicated to keep the ai tools focused and at the same time with enough understanding of the full project.

In small parts they excel really quickly but in bigger apps they seem to write for example helpers everywhere which are already available. Think date formatting.

So that would worry me a bit, it would literally explode the code size of the own project.

There are solutions off course but in general that’s for now a thing I would be careful of. Later that will be better I’m sure.
lucfranken
·11 か月前·議論
Not sure if it matches your vision but I just took a look at the react example:

https://www.embedpdf.com/docs/react/getting-started

I would suggest that you start with a more simple example. like:

<EmbedPDF url={https://snippet.embedpdf.com/ebook.pdf}/>

It would just take one additional component in your NPM package which contains all the more "internal" stuff. Just put the advanced example you have now in one component.

The example with the engine etcetera looks more like an advanced example.

It gets a developer to a quick result in their own app. If they want to go further they can nothing changes there.

A sidenote: That same though might be something with your NPM import - just one would be a better dev experience to start while I understand why you offer them separately for more advanced.
lucfranken
·11 か月前·議論
Seems to work great!

Little note: when you switch from redaction to view with the redaction tool (red lines) active it stays active in the view mode. Impossible to scroll because it still redacts.

Refresh fixes it.
lucfranken
·昨年·議論
Not really if an URL link is added to the post in the comment response.

Also it is possible to embed a sub resource (or part of it).

Think a blog post.

/blogPost/:blogPostId

You can embed a blog object with the url and title so you can show the blogpost on a page with the name of the blog in one go.

If you need more details on the blog you can request /blogs/:blogId
lucfranken
·昨年·議論
Generally only /companies/:companyId/buildings

And then you get a list of all buildings for this company.

Every building has a url like: /buildings/:buildingId

So you constantly get back to the root.

Only exception is generally a tenant id which goes upfront for all requests for security/scoping purposes.
lucfranken
·昨年·議論
Do you also cache all request in your store in for example the situation:

Shopify delivered. You cannot deliver to shipstation.

What happens when then the dunk restarts?
lucfranken
·昨年·議論
Did you try running some ai over it to see if it is capable of being useful?

Legacy code is a statement but in the end it only matters if it works and is maintainable.

It might surprise you.