I think this is the challenge and the dissonance. For something to truly run autonomously you need to provide it some many constraints that it almost loses its usefulness. I've tried using AI, or at least looked into what I could use AI for to automate marketing tasks and I just don't think I can seriously set up a workflow in n8n or AgentKit that would produce sufficiently good results without me jumping in. That said, AI is incredibly helpful in this semi-autonomous mode with the right parameters, to the point of the parent comment.
HN user
mfdupuis
Observability is a good guess, but I'd venture to guess that the conversations going on internally are about how to capture value across the entire stack. I wouldn't be surprised if we hear about them acquiring either a database/warehouse company and/or an analytics solution. Or vice versa, them getting acquired by a bigger player that wants to offer more connectors and data modeling functionality.
This is a really great comparison to draw. This actually made me think that this feeling of going from mastering a craft to working on large scale systems is probably how someone who was passionate about cars felt when they went from building cars one by one, knowing how the whole machine works to then having to take a job on an assembly line.
Fortunately I think anything pertaining to vibe coding/engineering/analytics is still more enjoyable and less grim than working on an assembly line, but the human feelings remain nonetheless.
I think the sentiment in this post is shared with most folks: We don't need yet another workflow tool. That said, I don't think no and low (or even all) code are mutually exclusive. Today these tools definitely speak to an audience that's technical enough to know how to get around in these tools but not so technical that they know how to deploy, monitor and maintain these workflows. What will happen with time is that any complexity that does exist in these low-code tools will be abstracted away with AI but you can dig into deeper layer if you are technical. This might be that very last point you're making?
How can we make code generation models better at writing LLM powered workflows/agents
For context, the approach we've taken at Fabi is that you can manually build the workflows or you can ask the AI to entirely build it out for you and you can pick up where the AI left off at any point and edit the code yourself -- we're not a generic workflow solution like n8n or AgentKit, we're 100% focused on data analysis, but the same should be easily applicable to these solutions.
The best way to avoid the red ocean is to build for an obscure and complex niche.
This seems like the counter-argument... You need to build something incredibly different. You need to message differently, you need to distribute differently.
If the argument is that convincing the world that you're different is harder than ever I buy that. So much fluff and noise out there that it's harder than ever to break through that noise and cut through the skepticism. But for that, it's more important than ever to be different.
Disclosure, I'm a founder in the data space[1]
Have you thought about how you would handle much larger datasets? Or is the idea that since this is a spreadsheet, the 10M cell limit is plenty sufficient?
I find WASM really interesting, but I can't wrap my head around how this scales in the enterprise. But I figure it probably just comes down to the use cases and personas you're targeting.
Fabi.ai | https://www.fabi.ai/| Senior front end engineer | Full-time | Hybrid SF or Remote (US)
We're looking for a senior front end engineer to join our mighty and growing team.
We're transforming the way data analysis is done in the enterprise and already have some amazing customers and are growing rapidly.
This person should have extensive React and Typescript experience be able to operate with minimal design supervision (we're a small team and we expect this person to have a sharp eye).
Full job description: https://www.linkedin.com/jobs/view/4093878394
This feels like a good opportunity for a startup. I've seen a lot of startups crop up around Snowflake cost management, I wonder what's in the AWS space.
Love DuckDB. Definitely a great place to start.
A common pattern I’ve seen over the years have been folks in engineering leadership positions that are not super comfortable with extracting and interpreting data from stores
I think this extends beyond just engineering, and I wish more data teams made the raw data (or at least some clean, subset) more readily available for folks across organizations to explore. I've been part of orgs where I had access to read-only replicas, and I quickly got comfortable querying and analyzing data on my own, and I've been part of other orgs where everything had to go through the data team, and I had to be spoon-fed all the data and insights.
This is actually one of the more interesting LLM observability platforms I've seen. Beyond addressing scaling issues, where do you see yourself going next?
Apple vision sales surpass iPad
I'm curious to see how this plays out when it comes to deploying and maintaining production-grade apps. I know relatively little about infrastructure and DevOps, but that's the stuff that actually always seems complicated when it goes from going to MVP to production. This question feels particularly important if we're expecting PMs and designers to be primary users.
That said, I'm super excited about this space and love seeing smart folks putting energy into this. Even if it's still a bit aspirational, I think the idea of cutting down time spent debugging and refactoring and putting more power in the hands of less technical folks is awesome.
Are you looking to validate a market idea? If so, are you thinking of more of a consumer use case? You mentioned Cursor, so it sound like you're maybe thinking more enterprise, but embedded ads are basically not a thing in the enterprise. Most solutions offer freemium mostly as a loss-leader, but this isn't AI specific IMO.
Congrats on the launch!
I'm building in this space[1] and I'm intrigued. When I checked out the repo, this actually looked like possibly a really convenient way to fine-tune models, but I'm trying to understand the piece about "products simply don’t have datasets, and datasets can’t keep up with product evolution". What does this mean in practice and how does this relate to fine-tuning?
Personally I find plotly hard to beat. Unless you're doing really fancy stuff, it gives you everything you need. Seaborn also a great option IMO.
As a non-programmer who likes to work on one-off projects or personal projects, I completely agree with you. If someone is still doing some of these things after 10 years of experience in the industry, then yes, they probably are a bad programmer. But if they're new, this can just be chalked up to a lack of experience. I think this relates to the industry's general tendency to shut out anyone who "doesn't know what they're doing". The language used to answer some of the more basic questions on Stack Overflow is a perfect illustration.
Very good post. Refreshing.
I think that the hype and buzzwords around Big Data and data science cause more than just bad business decisions. I believe they are also damaging the industry and creating a larger sense of disillusionment (I'm mostly thinking of "deep learning"). Not sure what this means for data science in the long term though, just thinking out loud.
I'll also add that I frequently see sledge hammers being used to hang a picture frame. By that I mean using huge clusters to run algos that would actually run in Tableau, Excel etc.