This looks promising. I think building on the foundation of Cursor, Claude Code and friends and bringing back what made development fun again. I've seen the cycles of command line development in VI to IDEs to Dreamweaveresque development. I think the tools need to match the jobs to be done. I would argue the traditional IDE was a poor approximation of the job of be done, which is why we struggle today with developers thinking the code is the product. And they spend time debugging, instrumenting, tooling etc and rightfully so, investing in developer experience around these tools. The problem with the old paradigm is that investment took our eyes of the customer and the job to be done.
AI-driven development has also gotten to the point where you need to be a wizard at .cursor.]/rules/*.mdc files, CLAUDE.md, GUIDELINES.md, JUNIE.md etc. Our product compatriots are commiserating with their technical counterparts seeing that the developers are now struggling with their own version of the "A/Cs aren't clear enough" when talking with LLMs, so to compensate we build lots and lots of context to suffice for bad A/Cs in our prompts.
I love not even starting with the code per-se. Just the tasks or jobs to be done. I could see many developers struggling to see how this fits in with existing codebases. I think that's okay, this makes going from zero to one a lot easier.
Excited to see more tools like this solve the core problem of focusing on the jobs to be done. Looking forward to seeing more.
Congrats Marc! We've been using Langfuse for about 6-months for our LLMOps tooling. While its SDKs are limited to python and typescript, their openapi specification is pretty easy to implement in any language.
The team behind it is amazing, and their product being OSS is one of the reasons we chose it. But it just keeps getting better.
We're incidentally only using part of the product because we've implemented most of these new features, prompt caching, execution etc in our app. But with the API you can decide what parts are core to your business logic and outsource the parts you don't want to deal with to Langfuse.
Being unopinionated and API-first has been a core design decision. We want to build the building blocks that everyone needs while acknowledging that most Langfuse users are very sophisticated teams that have a clear idea of what they want to achieve. Over time we will build more abstractions for common workflows to make it easier to get started but new features will always start API-first.
Outfit Labs | West Loop, Chicago IL - Hybrid | https://outfitlabs.com | Frontend/Backend/ML
We're a venture-backed startup in Chicago exploring how AI can transform people's experiences.
Although we’re still pre-market, we’re building products to help people see themselves in the world around them. We believe the following:
* That humans are unique and deserve to be heard and listened to
* That where folks choose to go - or stay, or eat, or work, or play, you get the idea - ought to be a reflection of who they are as a person
* That new advancements in technology can make our collective experiences more human and personal, not less
If you share any of our beliefs - or our love for people, maps, recommendations, and listening - then we’d love to talk to you!
Just because they have the same parent company doesn't make them the same company imho. Pretty much like how the Ritz Carlton is not the Four Points, although they are both Marriott companies.
Rocketmiles wants to turn frequent travelers into heroes by helping them take more vacations. Our team is headquartered in Chicago's West Loop with a satellite office in Park Slope, Brooklyn New York City.
Our stack is JVM based on the backend: Java, Groovy, Kotlin and AngularJS and node on the frontend.
We're currently looking for:
* Java/Kotlin engineers
* UI engineer
If you are interested, we're expanding out team, and it's a great time to join. Please reach out to me (Director of Engineering) at kirk@rocketmiles.com to say Hello!
All you can eat, so in the case of music/movies etc, am I owning or leasing the content for that period. That would determine the price for me.
Taking that I pay $79/yr for Amazon, with free movies, tv + shipping, then I spend about $40/mo on movies, music and books at Amazon, then I'd spend $50/mo.
Of course there are people who will spend more, and people who will spend less. I like to think of my spending as conservative. And since I get my TV over the air, I can't fathom for a second why anyone pays for TV.
> since I get my TV over the air, I can't fathom for a second why anyone pays for TV.
Here are some reasons people might buy cable:
1. Cable has many more channels, many of which don't exist on over-the-air TV.
2. If you grew up in a cabled household, you may think of it as a "standard" utility and buy it without thinking about whether you really need it.
3. Depending on where you live, the over-the-air channels you receive may be limited. I've discussed this problem before on HN [1].
4. Many homes and buildings no longer have antennas for receiving over-the-air signals. Many new TV's have no or poor built-in antennas. So you may have to buy a bulky antenna with no idea how well it will work.
5. If your TV is more than five years old, you may have to get a converter box to receive TV over the air, since TV transmissions changed format in 2009 [1]. New TV's have hardware to read the new digital TV signals, but old TV's don't.
Here are some reasons people might decide against getting, or discontinue a cable subscription:
1. You can save a substantial amount of money.
2. You may spend less time watching TV if you have less content available (whether this is good or bad is subjective, but for many people, reducing TV time is a plus).
3. Losing access to cable-TV content is less painful if you have a broadband connection, because much content is available freely and legally online -- Youtube, Hulu, Crunchyroll, etc. You can usually* send your computer's video output to your TV.
I'm writing from a USA point of view; if you're in another country, your mileage may vary.
*You need the computer and TV to have the same port, and the proper cable. An astonishing number of video ports have come into existence, many in the last 10-15 years, including traditional antenna, component, composite, VGA, S-Video, DVI, HDMI, and DisplayPort. A computer and TV built around the same time are likelier to have the same port, but your best bet is to check the specs before you buy.
Well in a startup the responsibility of research should be shared by everyone. In our case engineering actually did the competitive analysis AFTER we finished our MVP, while waiting on bizdev. What I'm asking is, is this normal or somewhat abnormal in the startup world, and an isolated problem?
Or are there startups that proceed without doing their homework so to say?
Yeah, you've got to do solid competition research before building something.
(It sometimes happens that there's something out there that you've never heard of (and no-one you know has heard of it either), in which case you discover the competitor later. Really nothing you can do about this.)
AI-driven development has also gotten to the point where you need to be a wizard at .cursor.]/rules/*.mdc files, CLAUDE.md, GUIDELINES.md, JUNIE.md etc. Our product compatriots are commiserating with their technical counterparts seeing that the developers are now struggling with their own version of the "A/Cs aren't clear enough" when talking with LLMs, so to compensate we build lots and lots of context to suffice for bad A/Cs in our prompts.
I love not even starting with the code per-se. Just the tasks or jobs to be done. I could see many developers struggling to see how this fits in with existing codebases. I think that's okay, this makes going from zero to one a lot easier.
Excited to see more tools like this solve the core problem of focusing on the jobs to be done. Looking forward to seeing more.