Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
52 minutes ago in Dropping compression makes bid requests bigger, yet it lets the bidder use less memory. It sounds backwards, but once a request arrives uncompressed, the bidder can read it in place instead of copying it into its own memory, and that becomes practical when the bidder runs inside the exchange's cluster.
Over the internet, a bidder decodes every compressed request. Decoding means copying each field into new objects in the bidder's memory, about 4.4 KB per request with protobuf, and dropping them once the bidder has decided. It is like printing a whole document to check three lines and throwing the paper in the bin, for every request. In Go, Java or C# the garbage collector, the part of the program that frees unused memory, empties that bin. Each time it runs it has to walk through everything the bidder keeps, to see what is still in use. After each cleanup Go counts the data still in use, and by default it starts the next cleanup when memory reaches twice that. With 2 GB of campaigns the bidder can use 4 GB, and half of it is a full bin. The setting can be tuned either way, but it only trades memory for CPU: less garbage held means more cleanups.
There is little to do about it there, since requests are usually gzipped to save on egress and gzip must be unpacked before anything can be read. Inside the exchange's cluster compression becomes optional, and a zero-copy format like FlatBuffers, SBE or Karmem from my last two posts lets the bidder read fields straight from the bytes it received. There is nothing to copy, so there is nothing to clean and no trade between memory and CPU to tune.
I tested it with the exchange and the bidder in one program on 4 cores, without a network between them, sending the same 20,000 real bid requests over and over until 2 million per format, 3 runs each, with 2 GB of data standing in for campaigns. With protobuf, memory peaked at 6.4 GB. With FlatBuffers, SBE or Karmem it stayed at 2.6 to 2.8 GB, and the garbage collector never ran once. The slowest 1 in 1,000 requests also dropped from 122 µs to 5 to 9 µs, because during a cleanup the collector takes a quarter of the cores, and requests that arrive then must help it clean before they continue.
A few microseconds matter little in the auction. Memory matters more: about 4 GB less for every bidder pod in this test. That memory can hold a bigger model, and inside the exchange the bidder also has more time for decisioning, since the request no longer spends that time reaching the bidder.
A bidder running inside the exchange's cluster can drop compression and read requests in place, so its memory and CPU go to bidding, with almost none spent holding and cleaning garbage. The same machines do more useful work, so the bidder can take more of the exchange's traffic without asking for more of them. The bidder needs less memory, keeps its slowest requests fast, and has room for a bigger model.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 hour ago in We had 277 plan files in our repo. Around 123,000 lines of documentation.
Together, they represented roughly 2 million tokens - twice the size of the agent's entire context window.
So we did something simple: we deleted almost everything.
We kept 12 decisions.
→ 8 became Architecture Decision Records (ADRs).
→ 4 became constraints in CLAUDE.md.
→ Everything else went.
Why did we keep those 12?
A decision had to meet three criteria:
Hard to reverse.
Surprising to someone who knows the tech stack.
Chosen over a real alternative.
The principle is simple: don't document what a capable coding agent already knows. Document what makes your codebase different.
A React app doesn't need instructions explaining how React apps usually work. But if your system has a non-obvious registration point, generated code, or an architectural constraint, that's worth documenting.
Context is not free. Every unnecessary token competes for attention, consumes resources, and can be carried through subsequent model calls.
We're exploring what this means for agentic coding at Appliscale . More experiments to come.
Full story, including our benchmark across 37 tasks and 5 codebases:
https://www.appliscale.io/blog/ai-agents-dont-need-a-map
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
16 hours ago in Today I presented at the IAB Tech Lab Agentic Bootcamp at IAB UK in London. I showed how we at Bedrock Platform bridge agentic and programmatic: one campaign, live, in two steps. Our buyer agent agreed private auction deals with two seller agents in a few minutes, and then our bidder decided each impression in real time.
The idea behind it is to take the best of both worlds: agents for making the deal, programmatic for buying each impression. Publishers keep control over how they package and price their inventory, and who can buy it. Buyers keep the decision on every bid. A deal is agreed once, but a campaign keeps changing: the list of people who already saw your ad grows every minute. Deciding per impression lets the buyer follow that, and move budget or raise a bid without a new negotiation.
The main topic of the bootcamp was OpenProposal, IAB Tech Lab's new spec for how publishers describe what they sell, so agents can read it, compare it and buy it. Our buyer agent in the demo already speaks it: it read the sellers' proposals, picked from their options and asked for more where the brief needed it. The discussion after it showed where the open work is, trust and pricing still need rules both sides agree on before agents buy at scale.
Thanks to IAB Tech Lab and IAB UK for organizing the event and for having us on stage, in a room full of people exploring agents. And big thanks to Appliscale, who built and shipped the whole seller side of the demo: two seller agents that speak OpenProposal, and a live screen where the room could watch the agents negotiate.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
5 days ago in One of the most interesting roles we're hiring for at Appliscale right now is a Senior Anti-Cheat Engineer.
A bit of context: we're known for our work in AdTech, but we also work with some pretty serious gaming companies.
We don't make games ourselves. We build the backend systems behind them - the infrastructure that has to work when millions of people are playing, competing, and interacting at the same time.
This particular role is for a global entertainment company with a platform reaching 100M+ users.
The challenge? Keeping competition fair when real money is at stake.
Think reverse engineering, detecting cheats and bots, analysing suspicious behaviour, hardening mobile clients against tampering, and building systems that can detect fraud in real time.
You're not just fixing bugs or implementing features. You're working against people who are actively trying to break the system - and who have a financial incentive to do so.
If you've worked with reverse engineering, game security, anti-cheat systems, mobile security, or low-level debugging, this might be one of those roles worth taking a closer look at.
We're hiring in Kraków, with remote work available.
Senior Anti-Cheat Engineer - 30,000–38,000 PLN net/month (B2B).
Job details and application: https://www.appliscale.io/career/senior-anti-cheat-engineer-xw2k
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
6 days ago in This month Safari began refusing some ad-tech requests before they leave the device. Most talk is about tracking IDs, but a conversion pixel is that kind of request too. A conversion API sends it from a server, where the browser takes no part.
Inside WebKit, a request from a page to another domain is refused when that domain is on a list Apple keeps (more on WebKit's network process in my post from 15 October). If an advertiser puts a buying platform's conversion pixel on shop.com, the request goes to that platform's domain, so only the list decides. In an independent test on Safari 27.2 the pixels of the large ad platforms still went through, and only identity vendors were blocked. The check reads nothing but the domain, and the WebKit tracking policy lists ad measurement among the things its protections may affect. The pixels that go through already carry less, because cookies written by scripts live seven days and click IDs are removed from some links.
A conversion API moves the same event to the server. IAB Tech Lab’s Event & Conversion API (ECAPI) is the spec for it: how an advertiser's server reports events to the ad platforms it buys on, so they can measure campaigns and optimize toward results. After the purchase, the shop's server sends the event as JSON straight to the platform's server with an HTTPS POST, one at a time or in batches. No browser takes part in that call, so no engine rule or blocklist can see it or stop it. Version 1.0 defines one shape for every platform: an account (data_set_id), an event id, a time, the value with its currency, user_data, and one of 28 standard event types that cover the whole funnel, from page_view and add_to_cart to purchase and qualify_lead. A properties object adds the details, such as the items, the coupon or the shipping cost.
The platform still has to link the purchase to an ad, so user_data carries what it can match on: the click_id from the ad click, or an email and phone number, normalized and hashed with SHA-256. When the pixel and the server both report the same purchase, both carry the same id and the platform merges them into one. There is also a field for the GPP consent string, so the user's consent can travel with each event.
For an advertiser this means one event format for every platform they buy on, and conversions that don't depend on what the browser allows. It also covers what a pixel never could: a purchase in a physical store or a lead closed in a CRM. The work moves too. A pixel was one tag on the thank-you page, while ECAPI needs a connection to each platform and the click_id kept from landing to purchase. Browsers will keep deciding more of what a page may send, and each browser update can change it. A conversion sent from the server where the sale happens doesn't depend on the browser, so that is where conversions will be counted.
Bedrock Platform
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
6 days ago in The "In Progress" column is a lie.
Startups can move fast slinging prompts at greenfield code. But for teams with real systems and two-approval PR gates, AI adoption hit a plateau: we gave everyone coding agents, but kept our 2015 SDLC.
Nobody writes code by hand anymore. Yet an engineer still moves a ticket to In Progress and spends time babysitting a CLI agent, figuring out the architecture on the fly.
We stopped writing code, but we're still babysitting the implementation.
The shift I've been experimenting with: isolate the only part that is truly automatable - translating a hardened spec into code.
That shouldn't be an interactive terminal session. It should be a headless background job.
The workflow flips:
- Review moves upstream. An agent interrogates the ticket for edge cases, and engineers review the ticket itself - marking it "ready to implement" before any code exists.
- "In Progress" is just a trigger. A headless pipeline generates the code and opens a PR.
Engineers only re-enter at the PR to evaluate the high-level mental model, not proofread syntax.
Prompting in a terminal was just the transitional phase. The real shift is detaching spec translation entirely and treating it like a background build step.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
6 days ago in We gave a coding agent a map. It read it, then searched anyway.
Together with Filip Sobala and Maksymilian Koleśniak we tested this across 37 tasks and 5 codebases and the results were counterintuitive, for example:
1) Adding a codebase map made finding the right place cost up to 65% more tokens.
2) On Metabase, the agent carried 41% more context with the map.
3) Code quality? Essentially unchanged.
Why? The agent read the map, then ran its usual searches anyway so the extra documentation became overhead, not guidance.
Full write-up, methodology and results from our experiments at Appliscale : https://www.appliscale.io/blog/ai-agents-dont-need-a-map
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in Most bid requests still cross the internet to reach a buyer, and both sides pay for that distance. On 5 November at 11:55, at the IAB Tech Lab International Summit in London, I'll show what changed on live campaigns when Bedrock Platform moved its full bidder inside the exchange. I'll also look at what it opens up next, starting with more time for each decision and room for much richer signals.
Two days earlier, at the Tech Lab Agentic Bootcamp, I'll show how we bridge agentic trading and programmatic.
I hope to see you there!
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in "We price products, not people"
“We’re not waiting to see what shopping becomes – we’re helping shape it”
“We want to be wherever customers choose to shop”
Interesting read from Walmart who's introducing dedicated Agent Profiles that will allow customers to:
- See purchases made by each AI agent separately
- Require approval for every purchase
- Authorize purchases within a predefined spending limit, such as $50, $100, or $200
- Revoke an agent's access at any time
So instead of fighting it off, Walmart is building an MCP-based gateway so AI agents can shop directly, without navigating a website designed for humans, something Amazon wasn't very fond of. Neither approach is inherently irrational. But let's keep in mind that Amazon's advertising business generates $68.6 billion in annual ad revenue compared to Walmart's $6.4 billion (11x larger) and agents are not watching ads (at least not yet).
Link: https://corporate.walmart.com/news/2026/10/Making-It-Possible-for-Agents-to-Shop-on-Behalf-of-Customers
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in Bid requests are compressed because bytes between data centers cost money. Once the bidder runs inside the exchange, that reason is gone, and the message format becomes a choice with real trade-offs.
I already tested one such format, FlatBuffers, on real traffic, and checking a request became more than ten times cheaper than decoding it with protobuf. A bidder says no to most requests it gets, so a cheaper no lets the same servers look at more of the exchange's supply.
This time I compared four of them: FlatBuffers (Google), Cap'n Proto, SBE (a standard from trading systems) and Karmem (a small Go project). All four let the bidder read a field straight from the received bytes, and both sides must share the same schema. They differ in three things: how a field is found inside the bytes, how much the reader checks before it trusts them, and how much work the exchange does to build the message. I ran all four on the same 20,000 real requests from our traffic, with the checks of the four line items that bid in that sample, and every format picked the same bids, so they differ only in cost and safety.
FlatBuffers puts a small table of positions at the start of every object, so the bidder looks up where a field is and reads it, in any order.
Cap'n Proto connects objects with pointers and checks each pointer before it follows it, so it is designed to return an error on a broken message instead of crashing.
SBE keeps numbers at fixed places but writes text and lists one after another, so the order of reading matters: a late field like the country is reached only by stepping over everything before it, and SBE is fastest when the bidder reads fields in the order they were written.
Karmem lays out the bytes so a Go struct fits directly on top of them, which makes reading almost free, but it writes every nested object, even an empty one.
Counting both sides, the exchange that builds the message and the bidder that checks it (and reads in full the one request in a hundred we bid on), protobuf costs 5.3 µs per request. SBE and Karmem cut that by about 75%, and SBE by about 80% when the bidder reads in layout order. FlatBuffers cuts it by about half, because its builder is slow, and Cap'n Proto by only 15%, because it pays for its pointers on both sides. At a million requests per second, SBE or Karmem saves about four CPU cores. The gains are real, but only if the exchange and the bidder both switch.
Inside the exchange's cluster both sides want the trade to happen, so the bidder can trust the bytes it gets, and Cap'n Proto's checks matter less. That points to SBE or Karmem: SBE needs both sides to agree on the order of fields, and Karmem has had no updates since 2023, though results like these may be a reason to bring it back. The format also changes how much work the garbage collector has, and that deserves its own post.
Thanks to Brian Tomasette, whose question about Cap'n Proto gave me the idea for this experiment!
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in Underdog Bark 3.0 is 163 MB, transcribes 1 minute of audio in <250 ms on a MacBook, and reports 7.82% word error on AMI meeting recordings vs. 9.42% for NVIDIA Parakeet and 13.63% for Whisper large-v3. Phonon from Gradium (gradium.ai/phonon) has less than 50 mln parameters reaching 28 ms to first audio and 15x faster than real time.
tl;dr The pace of open-source voice AI is super impressive so I'd speculate:
1) voice becoming a local capability, not a cloud dependency
2) small, specialized models > giant omni models e.g. voice, reasoning, and tool use can be separate components rather than one giant model
3) real-time voice ads: a super-low latency voice-generation model to generate an audio ad on the fly (, tailored to the user's context rather than a predefined audience segment?
Underdog: http://underdog.ai/bark
Phonon: https://gradium.ai/phonon
View on LinkedIn
Maksymilian Wojczuk
Technical Engineering Manager @Appliscale | Co-founder @DiPA
1 week ago in Git spent 15 years convincing the industry that centralized version control was obsolete.
Anthropic just migrated their entire monorepo off Git to an in-house centralized system because AI agent swarms made Git unusable.
Their numbers explain why: 30,000 merges a day - up from 2,500 five months ago - and 25 million CI checkouts daily. Operating hundreds of internal Git mirrors couldn't keep up with packfile compression and clone traffic.
The mismatch is architectural. Git assumes human engineers working offline on laptops who need a full, self-contained copy of the repository. When your committers are autonomous agents and ephemeral CI runners, that peer-to-peer symmetry becomes pure overhead.
So Anthropic built Scion - borrowing lessons from Google's Piper and Meta's Sapling, but structurally resurrecting the philosophy Perforce stood for all along.
Asymmetric client-server. The server owns the graph and answers diff, blame, and ancestry over an API. The client is a thin cache. And the working copy on disk is sparse, virtualized, or skipped altogether.
The big departure from old Perforce is concurrency. No pessimistic file locking. Changesets land in a lock-free distributed log. Even the classic merge queue was dropped - agents merge optimistically, and Claude resolves conflicts post-merge faster than humans can triage them.
This is a huge change in how we approach version control to match the way software is actually being built now.
Link in comments.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 week ago in 2.11× faster than OpenCV. 575.4× faster feature matching. 96.9% fewer vision tokens.
I think solidcv is an interesting bet on how computer vision should be built:
1) Local: Rust implementations of image processing and OpenCV-like primitives, no C++ dependency, free to run
2) Cloud: specialized vision workloads exposed through a binary WebSocket API, billed per operation
Of course, the numbers are project-reported benchmarks, but the direction is interesting: not everything needs a general-purpose vision model, and not every operation needs to run in the cloud.
+ LLMs are great but in 90% of cases good old deterministic compute is just fine: less inference / more compute before inference.
Repo: https://github.com/solidsf-inc/solidcv
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
1 week ago in I'm stepping into a new role at Bedrock Platform as CTO! Thank you to the Bedrock leadership for the trust, and to the engineering team I've had the privilege to work and build with.
In April we became the first containerized DSP, running our bidder inside Index Exchange's Index Cloud. More of the decisions in programmatic are now made inside the exchange, where models and data sit next to the auction.
We're just scratching the surface of what this enables and how much potential lies in it. Close to the auction, the time that used to vanish in transit goes back to the decision, leaving room for richer models and for balancing several objectives at once. The bidder can also combine the exchange's signals and models in a way that keeps the data private, while agentic trading orchestrates and negotiates the deals the bidder then executes inside the auction. In this role, I will help set Bedrock's direction and drive innovation that moves the industry forward, turning it into real value: smarter decisions and stronger performance for our customers, more demand reaching publishers, and a more efficient ecosystem.
I will share what we find along the way, as always with real data behind it. Looking forward to what comes next!
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
1 week ago in An agent without structure starts every run from scratch. It guesses, goes in circles and burns tokens on each lap. And blows up your AI bill.
That’s why agent harnessing is close to home for us. We work on a couple of agentic projects, and every run makes our harness better.
Last week we went deeper. Our former colleague Mateusz Polnik joined Appliscale's Weekly Knowledge Session and shared his approach to building a coding agent from scratch with pi, an open source harness. He spent half a year building a commercial one, so he speaks from experience.
His closing slide sums it up.
The model generates responses and tool calls.
The harness supplies context, runs the tools and keeps the loop going.
What a good harness adds:
- Context the agent has before it starts.
- Templates for work that repeats.
- The right model for each task.
And the line Mateusz put in bold: when the agent stops, check the result. You’re the human behind it.
#KnowledgeSharing #AgenticAI #AIAgents #AgentHarness
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in Running the bidder inside the exchange's cluster allows something that is not an option between two data centers. The exchange and the bidder can sit on the same machine and talk through a file instead of the network, and in my test that cut the time of a gRPC call by about a third.
Between two pods, even on the same machine, messages usually go over TCP: the bytes are cut into packets with headers and checksums, and the other side confirms what it received. In Kubernetes those packets also pass through the pod network, a virtual link for each pod plus the cluster's routing and network policy rules. A Unix socket is a file that both programs connect to, and the bytes never touch the disk. The kernel, the core of the operating system, copies the bytes from one program to the other and skips all of that work. It only works inside one machine, so over the internet it was never an option.
Inside the exchange's cluster it needs two things: the bidder pod on the same machine as the exchange pod, and a shared folder on that machine for the socket file. gRPC stays the same, with the same messages, and only the address changes, from bidder:9090 to unix:///sock/bid.sock.
I tested it on real Kubernetes nodes in GCP, with 20,000 real bid requests sent over gRPC and a real bid on 1 in 100 of them. The bidder sat in three places: on another machine, on the same machine over TCP, and on the same machine over a Unix socket. Every case ran three times at 10,000 requests per second. A call took 235 µs between machines, 204 µs on the same machine over TCP and 141 µs over the Unix socket. CPU work dropped by 9 µs per request across both sides, about 4%, most of it on the bidder's side, which at a million requests per second is about 9 cores. Memory did not change.
It also makes placing pods and balancing traffic more challenging, since the exchange and bidder pods have to land on the same machines and Kubernetes does not spread requests across socket files.
In practice, sharing a machine with the exchange is only possible for a bidder that runs as a container inside the exchange's cluster. From a separate data center the bidder stays at least one network away, however fast that network is. Next to optional encryption and compression and formats read in place, the socket is one more efficiency that the distance used to rule out, both for the exchange and the bidder.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
2 weeks ago in From Tokenmaaxing to AI
Our Head of Operations @Magda Sleboda came back form XDS and it feels like Tokenmaaxing is over.
After a happy period of experimenting and encouraging engineer to use AI now larger companies are looking to make a budgeting decisions about AI and of course for a software consultancy like ours, this raises some interesting questions: not just about how we use AI internally, but also about how we work with our clients.
1) who pays for AI tools and tokens - the client or the software house?
2) if AI cuts delivery time in half, who captures the productivity gains?
3) should we still charge by the hour when AI fundamentally changes how long things take?
4) how do we measure actual productivity gains (rather than token consumption or lines of code)?
5) if your client could use the same AI tools as your engineers, why would they still need you?
6) who decides which AI tools engineers can use - us or the client?
7) are we making junior engineers more productive at the expense of how they learn?
8) if everyone has access to similar AI tools, what will differentiate one software consultancy from another?
9) does AI make specialist domain knowledge more valuable as writing code becomes easier?
10) "if a new model drops next month, does your company get better or worse?" (by Greg Isenberg)
I don't think there are universal answers to these questions yet but it's worth asking.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
2 weeks ago in iOS 27 started blocking a list of ad-tech domains, and the block reached every browser on the iPhone, not only Safari. It is a good moment to look at how browsers are built, because that structure decides what an ad call is allowed to do.
A browser has two parts: what you see and the engine underneath, an extremely complex piece of machinery made of several programs running side by side. In WebKit, one process draws the page and runs its scripts, another talks to the network, a third handles graphics. The page process is locked down, and the network process is its only door to the internet. It opens the connections, keeps the cookies, and decides what leaves the device: send the request, send it without cookies, or drop it. Almost every browser in use runs on one of three engines:
1) Blink runs Chrome, Edge, Opera and Samsung Internet,
2) Gecko runs Firefox,
3) WebKit runs Safari.
On iOS, Apple requires every browser to use WebKit. Chrome on an iPhone keeps Google's interface and services, but the page, its scripts, its requests and cookies all run through Apple's engine.
All three engines are open source and each is led by one company, and browser makers can add their own rules on top (Brave and Edge block trackers that Chrome lets through). The rules the network process applies come in a few forms: a list of known tracker domains to refuse, an on-device classifier that spots domains showing up across many sites and limits their cookies, and storage rules such as keeping each site's cookies in a separate box. Some lists are public, and some ship only in the company's own builds.
Each owner set these rules differently, and this changes how users are counted. In Safari, a cookie written by a script lives at most seven days. A reader who visits every eight days loses that cookie between visits, so the frequency cap and the conversion have to recognise them some other way. Firefox keeps each site's cookies separate, and in Chrome third-party cookies still work.
The engine controls everything the page sends from the device: the ad tag, ID scripts, cookie syncs and measurement pixels. A cookie sync, for example, has to run in the browser, because the ID it looks for sits in a cookie the browser sends only to the domain that set it. So the engine can block the sync or send it without the cookie.
IAB Tech Lab’s open-source Trusted Server is one answer to this from the publisher side. There are several clever ideas inside it, and they are worth a few posts of their own. Frequency capping and measurement both assume you can recognise the same person twice. On the open web, the engine has a large say in whether you can.
Bedrock Platform
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in "/fine-tune-and-serve-llm I want to fine-tune Qwen for payments risk review. help me get started"
Brian Armstrong , CEO of Coinbase , recently shared an interesting point on X:
Coinbase took an open-weight model (Qwen3.5-9B), fine-tuned it on their proprietary internal data, and it outperformed frontier models on a specialized task (fraud prevention) - fraction of the cost + lower latency (+55% faster).
- frontier models are amazing generalists, but they are not the endgame
- latency and margins matter (especially in fintech or adtech)
- fraud is excellent usecase: proprietary data + high risk, probably won't share this data with a lab
I'm expecting more companies embracing this within next quarters.
PS. And what's really cool is that they built a slash command directly into their internal developer harness so any team can spin up and fine-tune models on company data.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Running the bidder inside the exchange's cluster opens options the internet never allowed. One of them makes saying no to a bid request almost free, and a bidder says no to most requests it gets.
Over the internet, bid requests are usually compressed with gzip, because every byte between exchange and bidder costs money. Inside the exchange's cluster the bytes stay on a private network, so compression becomes optional. That allows a format the bidder can read in place without unpacking it first. The one I tested is FlatBuffers, built at Google in 2014 for games. Gzip would break it, since the whole message must be unpacked before anything can be read.
Today a bidder decodes every request before checking it. Decoding means reading the request from start to end and copying each of its fields into the bidder's memory, and a real request in the traffic has about 95 fields. Later the garbage collector, the part of the program that frees unused memory, has to clean those copies up. All of this happens before the first check, and the checks use little of it: targeting reads a few fields (deal, country, device type, video size), the price check reads the floor, and the budget check reads none.
A zero-copy format lets the bidder read a field straight from the bytes it received. In FlatBuffers every object starts with a small table of positions, so reading the country means looking up its position and reading those bytes. Fields the bidder never asks for are never touched. Protobuf, the format behind gRPC, writes fields in a row, so a reader walks past everything before the field it wants.
I tested it on 20,000 real bid requests, with one schema for both formats, running the same checks against the four line items that bid in that sample. All formats made the same decisions, and all 225 requests we really bid on passed. Reading and checking a request cost 3.7 µs with JSON, 3.1 µs with protobuf and 0.26 µs with FlatBuffers. On the exchange, building the request took about the same in both, 2.2 µs in protobuf and 2.6 µs in FlatBuffers, so most of the gain is on the bidder's side.
Multiplied out to a million requests per second, that is about 3 cores against 0.3 cores spent reading requests. Memory shows a bigger gap: protobuf decoding copied 4.4 KB per request into memory, FlatBuffers 1.1 KB, and that was in a test where one in five requests passed targeting and was read in full. The garbage collector's work per request dropped about four times with it.
Exchanges often cap the requests a bidder gets because handling each one costs too much. When a no costs a fraction of a microsecond, a bidder can take more of the supply on the same machines. For buyers and advertisers, a deal can then be seen in full, without the impressions a cap drops before the bidder ever sees them. For publishers, every request a bidder can afford to look at is one more chance for an impression to find a buyer.
Bedrock Platform Index Exchange
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in "My Claude is better than yours"
I am seeing a strange, counterproductive pattern among engineering and product teams (of course not all):
instead of collaborating, individuals tend to retreat into private silos with their personal AI agents/harness and develop isolated habits, some "dogmatic" convictions that eventually hurt the team.
Let me give you some examples:
1/ The validation bubble - when an engineer or PM brainstorms an architecture with an LLM in isolation, they walk away convinced they have thoroughly researched the problem. They forget that LLMs are sycophantic by design ("you're not only thinking strategically, you..."). The model is trained to please the user, validate their assumptions, and gloss over edge cases so people are taking half-baked ideas, getting them rubber-stamped by an agreeable model, and bringing them to team meetings as absolute ground truth.
2/ "Prompt hoarding" - with tech layoffs and management constantly demanding AI productivity gains, engineers are incentivized to hoard their workflows. So instead of asking "how we can build a shared software factory that elevates the whole organization", the mindset becomes: "how can my private setup help me ship more tickets than the person sitting next to me?".
3/ The benchmark illusion - because LLMs are non-deterministic, models update silently, and custom harness skills alter behavior daily, nobody can objectively prove whose setup is actually better. Discussions about best practices --> religious debates based on vibes.
Yes, AI/LLMs democratize knowledge across engineering orgs in most cases, but rarely we talk about the side effect of creating these individual echo chambers with "yes-men" machines.
View on LinkedIn
M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
3 weeks ago in Frontier AI just surpassed accountants on realistic tasks and the gap is already widening.
A new study hired CPAs to complete four realistic accounting tasks, then ran the same work through AI models released over the past few years.
tl;dr as of May 2025, accountants still outperformed AI but today’s frontier models score near 100% on the same tasks, while the average accountant (without AI) scored 37% (!)
On these detail-oriented tasks, models like Opus 5 are both faster and more accurate than the accountants in the study; of course, it doesn't mean accountants are obsolete, but they point to a shift toward higher-level, less verifiable work as routine tasks get automated.
Full write-up and paper: https://www.mercor.com/blog/human-baselines-for-benchmarks-ai-now-outperforms-junior-accountants/
View on LinkedIn
M
Magdalena Śleboda
Head of Operations | Scaling Tech Organizations with AI, Automation & Data-Driven Execution | Global Ops & Transformation Leader
3 weeks ago in Just back from London, where Konrad Kaplita, Appliscale's CTO, and I met with our business partners. In person - still our preferred way of building strong business relationships.
Surprisingly, we spotted a Waymo on Oxford Street, getting ready for its London launch.
In LA it was our go-to between client meetings. Curious to see how it does on London streets.
View on LinkedIn
