HN user

DouweM

406 karma

Pydantic AI Lead, previously founder/CEO of Meltano, founding engineer at GitLab

Posts14
Comments93
View on HN

(Pydantic AI lead here) That’s exactly what we built this for: we’re implementing Code Mode in https://github.com/pydantic/pydantic-ai/pull/4153 which will use Monty by default, with abstractions to use other runtimes / sandboxes.

Monty’s overhead is so low that, assuming we get the security / capabilities tradeoff right (Samuel can comment on this more), you could always have it enabled on your agents with basically no downsides, which can’t be said for many other code execution sandboxes which are often over-kill for the code mode use case anyway.

For those not familiar with the concept, the idea is that in “traditional” LLM tool calling, the entire (MCP) tool result is sent back to the LLM, even if it just needs a few fields, or is going to pass the return value into another tool without needing to see (all of) the intermediate value. Every step that depends on results from an earlier step requires a new LLM turn, limiting parallelism and adding a lot of overhead, expensive token usage, and context window bloat.

With code mode, the LLM can chain tool calls, pull out specific fields, and run entire algorithms using tools with only the necessary parts of the result (or errors) going back to the LLM.

These posts by Cloudflare: https://blog.cloudflare.com/code-mode/ and Anthropic: https://platform.claude.com/docs/en/agents-and-tools/tool-us... explain the concept and its advantages in more detail.

(Pydantic AI lead here) We’re implementing Code Mode in https://github.com/pydantic/pydantic-ai/pull/4153 with support for Monty and abstractions to use other runtimes / sandboxes.

The idea is that in “traditional” LLM tool calling, the entire (MCP) tool result is sent back to the LLM, even if it just needs a few fields, or is going to pass the return value into another tool without needing to see the intermediate value. Every step that depends on results from an earlier step also requires a new LLM turn, limiting parallelism and adding a lot of overhead.

With code mode, the LLM can chain tool calls, pull out specific fields, and run entire algorithms using tools with only the necessary parts of the result (or errors) going back to the LLM.

These posts by Cloudflare: https://blog.cloudflare.com/code-mode/ and Anthropic: https://platform.claude.com/docs/en/agents-and-tools/tool-us... explain the concept and its advantages in more detail.

Hey munro, Douwe from Pydantic AI here. Our docs have a page dedicated to observability: https://ai.pydantic.dev/logfire/, which is all based on OpenTelemetry and its gen_ai conventions.

The Logfire SDK that Pydantic AI uses is a generic OTel client that defaults to sending data to Pydantic Logfire, our SaaS observability platform: https://pydantic.dev/logfire, but can easily be pointed at any OTel sink: https://ai.pydantic.dev/logfire/#logfire-with-an-alternative...

Temporal is one of multiple durable execution solutions (https://ai.pydantic.dev/durable_execution/overview/) we support and its SDK is indeed included by default in the "fat" `pydantic-ai` package, as are the SDKs for all model providers. There's also a `pydantic-ai-slim` package that doesn't include any optional dependencies: https://ai.pydantic.dev/install/#slim-install

All I know is that with the same LLM models, `openai.client.chat.completions` + a custom prompt to pass in the pydantic JSON schema + post-processing to instantiate SomePydanticModel(*json) creates objects successfully whereas vanilla pydantic-ai rarely does, regardless of the number of retries.

That's very odd, would you mind sharing the Pydantic model / schema so I can have a look? (I'm a maintainer) What you're doing with a custom prompt that includes the schema sounds like our Prompted output mode (https://ai.pydantic.dev/output/#prompted-output), but you should get better performance still with the Native or Tool output modes (https://ai.pydantic.dev/output/#native-output, https://ai.pydantic.dev/output/#tool-output) which leverage the APIs' native strict JSON schema enforcement.

I'm curious what issues you've run into, do you happen to have GitHub links so I can have a look? (I'm a maintainer.)

Pydantic still sees multiple commits per week, which is less than it was at one point, but I'd say that's a sign of its maturity and stability more than a lack of attention.

I'm not sure how long ago you tried streaming with Pydantic AI, but as of right now we (I'm a maintainer) support streaming against the OpenAI, Claude, Bedrock, Gemini, Groq, HuggingFace, and Mistral APIs, as well as all OpenAI Chat Completions-compatible APIs like DeepSeek, Grok, Perplexity, Ollama and vLLM, and cloud gateways like OpenRouter, Together AI, Fireworks AI, Azure AI Foundry, Vercel, Heroku, GitHub and Cerebras.

Pydantic AI maintainer here! Did you happen to file an issue for the problem you were seeing with Azure OpenAI?

The vast majority of bugs we encounter are not in Pydantic AI itself but rather in having to deal with supposedly OpenAI Chat Completions-compatible APIs that aren't really, and with local models ran through e.g. Ollama or vLLM that tend to not be the best at tool calling.

The big three model providers (OpenAI, Claude, Gemini) and enterprise platforms (Bedrock, Vertex, Azure) see the vast majority of usage and our support for them is very stable. It remains a challenge to keep up with their pace of shipping new features and models, but thanks to our 200+ contributors we're usually not far behind the bleeding edge in terms of LLM API feature coverage, and as you may have seen we're very responsive to issues and PRs on GitHub, and questions on Slack.

Hey HN, Arch CEO here! Our team has been working at the intersection of data engineering and software engineering for a few years now with Meltano (https://meltano.com), and this year, the rise in Generative AI has made it clear that the bottleneck in unlocking the potential value of data has shifted from data integration on data teams to data engineering on software teams, so we’ve decided to do something about it.

This post is about the high-level motivations and long-term vision for https://arch.dev; please let me know if any of it resonates or if you think I’m totally off the mark :) We’ve also got a post that goes into more detail on the Arch product itself: https://www.arch.dev/blog/announcing-arch-the-data-backend-f...

Thanks! Meltano is primarily focused on EL, but we let you run any Python data tool or custom script as well, including dbt (Core) for transformation. So we occupy a space somewhere between EL tools like Fivetran and workflow orchestrators like Airflow/Astronomer, and depending on what you add to your Meltano projects, you can use it for either EL, ELT, just T, or anything you can come up with.

Meltano is an open source platform for ELT (Extract, Load Transform) pipelines that leverages Singer for data integration and dbt for transformation. It may not be clear from the blog post (since it's not focused on introducing the product), but I hope the homepage would get that across: https://meltano.com/

Please let me (Meltano CEO) know how we could make that more obvious!

And the GitLab Data Team is not alone! The Meltano Slack community (link on the homepage) is about 800 strong right now, and every day we've got people discussing their production deployments and helping new users set up their own.

PS. Like Taylor, I'm on the Meltano team at GitLab.

I think that if the wider open source community can maintain API client libraries for every imaginable SaaS API and every popular programming language, there's no reason that it can't maintain open source ELT connectors for all of these sources as well.

I work at GitLab as project lead of Meltano (https://meltano.com/) — which embraces Singer instead of abandoning it — and we've seen a lot of interest from data consultancies looking for mature tooling around deploying and developing Singer taps, many of whom have expressed that they'd be happy to maintain open source ELT connectors for data sources that are commonly used by their clients, if they can significantly save on ELT costs that would otherwise get passed on to those clients.

Of course, only one data consultancy (or data team at a company) would need to maintain an open source tap, and others that need the same source for _their_ clients can contribute and help keep it up to date.

At GitLab, we're not ready to give up on the Singer spec, community, and ecosystem yet, which is why I've been working on Meltano for the past year: https://meltano.com/

We think that the biggest things holding back Singer are the lack of documentation and tooling around taking existing taps and targets to production, and around building, debugging, maintaining, and testing new or existing high-quality taps and targets.

Meltano itself addresses the first problem, and provides a robust and reliable platform for building, running & orchestrating Singer- and dbt-based ELT pipelines. It's built for developers who are comfortable with CLIs and YML files, and want their pipelines to be defined in a Git repository so that they get the benefits of DevOps best practices like code review and CI/CD.

At the same time, we have been working with some members of the community on a new framework for building taps and targets: https://gitlab.com/meltano/meltano/-/issues/2401, which we have decided to call the Singer SDK: https://gitlab.com/meltano/singer-sdk. We are moving as many Singer specification-specific details around things like incremental state replication and stream/field selection into the framework, so that individual taps only need to worry about getting the data from the source and can be expected to behave more consistently and correctly across the board.

If you're looking for open source, self-hosted ELT, I suggest you check out Meltano (https://meltano.com), which we've been working on at GitLab since 2018!

We've decided to focus primarily on the CLI for the moment, which you can see showcased through the example code on the homepage: https://meltano.com, but we're working on a UI as well, as evidenced by today's release blog post: https://meltano.com/blog/2020/08/17/now-available-meltano-v1...

---

Meltano uses open source Singer taps and targets (https://singer.io) as its extractors and loaders, so to put together something similar to DropBase (which looks amazing, by the way), you could use:

- tap-spreadsheets-anywhere (https://github.com/ets/tap-spreadsheets-anywhere, https://gitlab.com/meltano/meltano/-/merge_requests/1813), which supports CSV and XLS over S3, HTTP(S), (S)FTP (etc),

along with:

- target-postgres (https://github.com/meltano/target-postgres, https://meltano.com/plugins/loaders/postgres.html),

- target-jsonl (https://github.com/andyh1203/target-jsonl, https://meltano.com/plugins/loaders/jsonl.html), or

- any of the others you find on https://meltano.com/plugins/extractors/, https://meltano.com/plugins/loaders/, or https://www.singer.io/.

---

For transformation, Meltano currently supports only dbt (https://www.getdbt.com/), which means that unlike DropBase, it's built for ELT rather than ETL, since transformation takes place inside the loading database, rather than in between the E and L steps.

I'm very interested in exploring the ETL direction more, though, because as DropBase clearly shows, there are still a lot of companies and people who may not be experts on SQL, but would benefit tremendously from sturdy ETL with an accessible interface and flexible integration points.

As I just wrote on our Slack workspace (there's a link on https://meltano.com):

I’d love to see Meltano UI develop into that direction for simple transformations over Singer tap stream/entity schema and record JSON, so that we can do ETL as well as dbt-backed ELT.

We’d probably start with a way of specifying transformations in `meltano.yml`, similar in spirit to the `select`, `schema`, and `metadata` extra’s (https://meltano.com/docs/command-line-interface.html#extract...), and/or by pointing at a Python file that can process each Singer message. Building a DropBase-style UI over that would be on the horizon too, once we’ve brought the Entity Selection interface back (https://gitlab.com/meltano/meltano/-/issues/2002) and add interfaces for metadata rules and schema overrides.

I'll create some more issues around this potential direction tomorrow :-)

---

If you or anyone else interested in open source, self-hosted ETL/ELT end up giving it a try, I'd love to hear what you think, so that we can figure out how to build it into this direction together!

I am excited to announce that Meltano (which has been discussed here before: https://news.ycombinator.com/item?id=17667399) is heading in an exciting new direction as an open source platform for ELT pipelines!

Our goal is to make the power of data integration available to all by turning Meltano into a true open source alternative to existing proprietary hosted ELT solutions, in terms of ease of use, reliability, and quantity and quality of supported data sources.

Dive right in by following the examples on our homepage at https://meltano.com, or read on for further details and context:

If you've been following Meltano for a while or would like to have some historical context, start here:

Revisiting the Meltano strategy: a return to our roots: https://meltano.com/blog/2020/05/13/revisiting-the-meltano-s...

If you’re new to Meltano or are mostly interested in what’s coming, start here:

Why we are building an open source platform for ELT pipelines: https://meltano.com/blog/2020/05/13/why-we-are-building-an-o...

We're building this for people like you, and we literally won't be able to do it without you, so please give it a try and let us know what you think!

Note that GitLab _does_ adjust compensation when relocating: https://about.gitlab.com/handbook/people-operations/global-c... + https://about.gitlab.com/job-families/move/

That means that as someone working at GitLab, my current wage is competitive compared to local companies, + I get all of the perks of remote work, working on open source, developer tooling, etc, and all of this will still be the case if I were to move elsewhere.

The exact amount of money deposited into my account each month would go up or down, but my lifestyle would stay roughly the same.

I know I’d make a lot more money if I lived in, say, the Bay Area, and if I made that same amount of money pretty much anywhere else I could live like a king, but I honestly don’t care. I quite like my decidedly not-king-like life today, and I love that with GitLab, I can have this same life and job wherever I choose to live.

I’m currently living in the Netherlands, but am planning to move to Mexico in a few years to be closer to my fiancée’s family. If all goes well, GitLab will travel there with us, and while my compensation will see a decrease, our life style won’t.

GitLab’s compensation philosophy is one of competing with the local market, instead of putting a fixed price on the value I or anyone else provides to the company, and that’s totally fine by me. If it wasn’t for GitLab, I’d probably be working at one of those local companies, so aren’t I still better off? For the company, it means that it/we can hire great people wherever they may be on earth, without being limited to the subset of great people who also happen to or want to live in the specific city the company happens to be based in.

This may come as a surprise to some, but there are some amazing engineers out there who have zero interest in living in the Bay Area, and who don’t particularly care about maximizing their yearly take home pay, as long as they make enough money to provide for themselves and their family, and can live in whatever city or country or continent that they prefer. The map on our team page is a testament to that: https://about.gitlab.com/team/ (mobile-friendly: https://gitlab-com.gitlab.io/teampage-map/)

FWIW, I know of colleagues who have moved to locations with both lower and higher cost of living compared to the location they were hired in, and I’ve never heard about requests to move being rejected.

GitLab Direction 8 years ago

I also feel like you're painting companies outside Silicon Valley with a pretty broad brush.

There's nothing about a healthy engineering culture that makes it unique to Silicon Valley, and there are many, many companies in those regions you mention that would take significant issue with that generalization.

If you want to optimize for annual salary, Silicon Valley is probably the place to be, but if you want to optimize for happiness (however a developer may define that for themselves), it's just one of many potential places to go, and if you want to optimize for work/life balance, it's probably not even in the top 10.

GitLab Direction 8 years ago

I'll leave the subject of compensation to the threads dedicated to it, but 'software engineers [...] are treated more like "code monkeys" who report to their managers and don't have any self-direction' absolutely does not apply to GitLab. Have you had a chance to check out our values (https://about.gitlab.com/handbook/values/) or our section on making decisions (https://about.gitlab.com/handbook/leadership/#making-decisio...)? What you're describing is pretty much the opposite of how we actually work :)

GitLab Direction 8 years ago

Hey Nathan, I'm very curious about what you mean by "I also don't think they have a very good company culture".

I've been at GitLab since early 2015 (employee #10), and the culture is one of the major reasons why I joined, and stayed. :)

Would you mind elaborating?

For anyone else reading along, our Handbook (https://about.gitlab.com/handbook/) covers our culture (and every other aspect of working here) very well.

Just to verify, are you talking about the _real_ Peppa Pig videos, or the fake, weird ones?

Because as far as I can gather using Wikipedia, Entertainment One is the company behind the _real_ Peppa Pig. If you're saying that there is also reason to believe that they are behind the _fake_ Peppa Pig, that would be much larger news, which (looking at the amount of interest in the story), it isn't.

Edit: Ah, mFixman suggests a plausible explanation:

Entertainment One owns Peppa Pig[1]. It's likely that Content ID thinks Elsagate is legitimate Peppa videos.

[1] https://en.wikipedia.org/wiki/Entertainment_One

That makes more sense :)

GitLab engineer here: our CEO has responded to exactly that concern in https://twitter.com/sytses/status/1003415290368028672 and https://twitter.com/sytses/status/1003337681668005888. To quote:

We'll have a liquidity event. We're aiming for an IPO https://about.gitlab.com/strategy/#goals but we can't rule out an acquisition.

And it's worth pointing out that you can run GitLab on your own server, so even if GitLab.com ever ends up disappointing you, you don't need to go through the trouble of migrating to the next best thing.