i think my most sad/interesting observation about ai engineers is that many ai apps are super data hungry, but many dont have the necessary data engineering background to even know they need an airbyte or what tradeoffs to make in an etl pipeline. would love a "data engineering for ai engineers" type braindump session from someone from airbyte at AIE (https://ai.engineer/cfp )
> airbyte agents could serve as a form of MCP gateway
Exactly! And a single set of tools for agents to access both realtime (direct reads/writes) as well as cached (Context Store), bringing hopefully the best access path for each different use case.
> would love a "data engineering for ai engineers" type braindump ... at AIE
Great idea - we have a booth at AIE, and we'll submit there for a talk. Mario will reach out to you about this. :)
For my team, it has been easy. We deal with infrastructure for the entire org, so have tickets created for every request. We also gave our own backlog for internal project, so can see burn rate, and etc. Team hasn’t changed, a lot of similar/same tasks that have taken half a day has been completely automated to a point where we just do PR review after an initial ticket is created by other teams.
There are a lot of little things we’ve tracked, and it’s just faster to implement things now. To be fair, everyone on my team has decade+ professional experience (many more non-prodessional), and we understand limitations of AI fairly well.
What is your definition of faster to implement? Is it producing a plausible implementation, or is it faster at producing a correct and high quality implementation? Are you including time spent refactoring and fixing bugs in your metrics? If not, I think you are tracking a gut feeling rather than cold hard facts. I’m not saying this is easy to track, just saying that it’s hard to know for sure that you are really more productive with AI.
> to be fair, everyone on my team has decade+ professional experience (many more non-prodessional), and we understand limitations of AI fairly well.
I see this appear quite often in discussions on productivity, to the point that a conclusion may be made regarding its centrality for productivity gains.
Not the same person, but it really depends on projects. E.g. I have some projects that involve working to large specification sets where we can measure rate of delivery against the spec. If your spec is fuzzy and incomplete, then it gets hard, but then you have little insight into human productivity for those projects either.
Wouldn’t call myself an expert in either, but I think 2 things stand out far more than anything else:
1. Rust is effectively as strict as can be in terms of ownership. In Zig you can just allocate some memory and then start slinging pointers (or slices) all over. If you’re doing this then you’re presumably doing it for mutability and you don’t strictly know where that pointer ends up once you’ve passed it on.
2. Rust’s metaprogramming is split among a couple different things (e.g. traits, macros), whereas Zig’s is unified (comptime). comptime is (at least advertised as) “just normal Zig code” and Rust macros are a great example of “this doesn’t work at all like the base language”.
#1 boils down to “can the LLM solve the pointer aliasing here?” and #2 is translating between metaprogramming paradigms. Could work but a line-by-line translation is a pipe dream.
Zig doesn't have a borrow checker. It's basically C, if C had been much better designed.
Line-by-line ports to idiomatic Rust are usually not possible because of the borrow checker and Rust's ownership rules. That's the reason the Typescript compiler was ported to Go instead of Rust.
> Quota exceeded for quota metric 'Read requests' and limit 'Read requests per minute per user' of service 'sheets.googleapis.com' for consumer 'project_number:849324395320'.
maybe cache this thing my guy you're just doing a bunch of reads
---
constructive suggestions
- you have a pretty cheap process here, and HN exposes historical posts by date. perhaps worth running this back the last 2 years to reconstruct a history of sentiment?
- introduce alternative sorts around the net positive/negative sentiments and absolute positive sentiments, similar to State of JS (https://stateofjs.com) - you'll see the gpt outperformance more
Didn't expect it to get hammered like that, just added caching for the sheets request. Thanks, my guy ;)
Backfilling it further is definitely in the cards, I just want to stabilize the methodology first.
If a comment just mentions Opus without being more specific and in the absence of relevant context clues, it gets mapped to Opus Latest. So it's saying more about the model family than a specific version. Tbh I'll probably remove all "-latest" data points going forward, as I mentioned in another comment.
> This project used an absolutely ridiculous number of tokens. I had to upgrade to the Claude Code $200/month plan and carefully avoid usage in the 8 AM-2 PM 2x peak window.
that doesnt sound too terrible to be honest. TIL that 8am-2pm is 2x usage.
reply