M
Michał Nieć
CEO of Appliscale | AI in AdTech Expert | LP & Angel Investor in AdTech/GameTech
1 hour 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
21 hours 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
21 hours 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
1 day 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 day 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 day 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
2 days 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
2 days 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
1 week 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
1 week 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
2 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
2 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
2 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
2 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
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Once bidder runs inside the exchange's cluster, two things bid traffic normally can't go without become optional: encryption and compression. Encryption costs almost nothing once a connection is open. Compression is the expensive one, and both sides pay for it.
On the bid path, both are there because the traffic crosses the internet. TLS encrypts each request, so the networks it passes through between the exchange and the bidder can't read or change it. Compression shrinks the bytes you pay to send. Inside one zone of a cluster, the network is private and the bytes are free, so neither reason holds anymore.
Compression finds text that appears more than once and writes it only once, with a short note wherever it repeats. JSON bid requests repeat a lot, because every message carries the same field names, so a real request shrinks from 2.4 KB to 1.2 KB. gRPC works the same way, with smaller gains: protobuf sends short numbers instead of field names, so there is less to repeat. The price is CPU on both ends: the exchange compresses every request, and the bidder decompresses it.
I tested both on 20,000 real bid requests and real bids, replayed at 5,000 requests per second between an exchange and a bidder in separate containers, with 1% of requests getting a bid. Every combination of TLS on or off and compression on or off, three runs each.
TLS made no measurable difference on warm, reused connections, neither in CPU nor in latency. Its cost is the handshake on a new connection: when 10% of requests opened one, CPU rose 18% on the exchange and 12% on the bidder.
Compression cost about 72 µs of CPU per request on the exchange and 56 µs on the bidder. At a million requests per second, that is around 130 cores, spent shrinking bytes that cross a free network. It trades CPU for network capacity, and inside a zone there is usually plenty of capacity, unless all traffic goes through one node or the two sides sit in different zones.
Co-location is about efficiency and performance. The bid request travels a few meters inside one data centre instead of across the internet, so the answer comes back faster. And once the traffic stays inside the cluster, the exchange and the bidder can stop doing work that only the internet made necessary: guarding every request against networks they don't control, and shrinking bytes that no longer cost anything to send.
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 Parallel agents are the new microservices.
"One agent was too slow, so we added 10. Then we discovered they need shared state, coordination, queues, retries, ownership, conflict resolution and observability"
I think it sounds familiar to everyone who's been there in 2015 because we spent the last decade learning that distributed systems are hard. Now we're giving every service a language model and starting the exercise again.
The interesting part is that the analogy goes further than the number of boxes in the architecture e.g. microservices split software into independent units of computation - multi-agent systems split work into independent units of reasoning.
And in both cases, the moment you split things up, coordination becomes the system. I'm not saying that the lesson from microservices was “never build monoliths!”. Perhaps it was don't distribute something until you have a good reason to distribute it.
I suspect we'll have to relearn that one with agents.
View on LinkedIn
Damian Naglak
Head of Engineering | Bedrock Platform | AdTech
3 weeks ago in Lower latency on the bid path means fewer resources on both sides, the exchange and the bidder. It sounds backwards, since going faster usually costs more. For HTTP/1.1 it follows from a simple rule called Little's law.
Little's law says how many requests are open at the same moment: requests per second times the time each one takes. If 10 requests arrive every second and each takes one second, 10 are open at any moment. If each takes a tenth of a second, only one is open. Same traffic, less time, fewer open requests.
HTTP/1.1 carries one request at a time per connection, so every open request holds a connection on both ends. At 100,000 requests per second, an 80 ms round trip keeps about 8,000 connections busy. At 5 ms, with the bidder in the same cluster, it is about 500. Newer protocols put many requests on one connection, but switching has a cost, so HTTP/1.1 is still common on the bid path.
An idle connection is cheap. A busy one also holds buffers with the data and, on the exchange side, the request itself until the answer comes back. Latency also jumps: a resent packet or a short slowdown, and the same traffic suddenly needs more connections. If every connection is busy, the request waits and loses part of its deadline, or a new connection opens and pays a handshake at the worst moment.
I tested it. Two containers, an exchange and a bidder, 5,000 HTTP/1.1 requests per second, with added delay from 0 to 80 ms. Busy connections followed Little's law: 15 at 0 ms, 405 at 80 ms. Memory grew with them, 2.7x on the exchange and 2.1x on the bidder, while CPU stayed flat.
Then I capped the pool at 480 connections and slowed the bidder by 15 ms for one second in every ten, still inside the 100 ms deadline. Up to 50 ms, the pool absorbed it. At 80 ms, timeouts closed connections faster than new ones could replace them. After the first slowdown, not a single request was answered in time for the rest of the run. A real exchange would likely throttle the bidder first, which also means fewer bids.
A containerized bidder running inside the exchange's cluster removes most of the distance from the bid path. The exchange needs a smaller pool for the same traffic, and a short slowdown no longer turns into lost requests. The bidder holds fewer open connections and less memory, and does not spend CPU on a wave of new handshakes.
Bedrock Platform
View on LinkedIn
