“Ontology” sounds like a word from a philosophy seminar. In data work it means something very practical, and you can explain it with a toy box.

It also matters more than it used to. Now that AI agents read company data and answer questions with it, someone has to tell them what the business’s words actually mean.

Start with a toy box

Your toys are all mixed up in one big box. To keep them neat, you make a few rules:

• Name things: “This is a car. This is a doll. This is a block.”
• Group them: “Cars and trucks are both vehicles.”
• Describe them: “A car has wheels and a color.”
• Connect them: “The doll rides in the car.”

Now everyone who plays with the box, whether that’s your mom, your friend or your teacher, uses the same words and knows where everything goes. That set of rules is an ontology.

Every toy has a name, cars and trucks share a group, the car has details, and the doll is linked to the car.

Now swap the toys for a business

A business has toys too. They’re just grown-up ones, and the same four rules apply.

So a business ontology is a shared map of three things:

• What exists in the business: customers, orders, products
• What each thing looks like: its details, such as a customer’s name and email
• How things connect: a customer buys a product

A business ontology is a map of things, their details and their links

Why it matters

Picture three kids who each call the same toy something different: “car,” “vroom” and “red thing.” They’d argue all day.

Companies do exactly this. Sales says “client,” Finance says “account” and Support says “user,” and all three mean the same person. An ontology settles it: we call it Customer, and here is exactly what Customer means.

All three words point to the same person, so the ontology gives that person one name and one agreed meaning.

Once everyone agrees:

• Reports agree with each other.
• Computers and AI tools read the data correctly.
• New people learn the business faster.

The AI point is the one getting attention now. Ask an agent about “net revenue” and it will pick a definition either way. An ontology makes sure it picks the approved one.

Where Snowflake fits

Snowflake handles this at two levels: semantic views for one domain, and the new Business Ontology for the whole company.

Semantic views work like a mini business ontology. A semantic view is a schema-level object that stores business concepts next to the data: the entities, how they join, and the metrics and dimensions people ask about. Define “Revenue” or “Customer” once, and Cortex Analyst, Cortex Agents and BI tools all calculate it the same way.

Business Ontology, which Snowflake announced on November 3, 2026, is the company-wide layer. It lives in Horizon Catalog and gives each business concept one approved definition with a named owner, grouped by domain such as Finance or Sales. Each concept links to the tables, columns or semantic view metrics that implement it, and only approved definitions are served to Cortex.

In toy-box terms, a semantic view labels one shelf, and Business Ontology is the rulebook for the whole box. Together with Cortex Sense, they form three layers:

Cortex Sense infers, Business Ontology holds the approved meaning and wins when the two disagree, and semantic views run the SQL that calculates the numbers.

Business Ontology is in private preview for selected accounts, with public preview expected soon.

The one-line version

A business ontology is a shared picture dictionary for a company: it shows what everything is called and how everything connects.

Sources

• Overview of semantic views, Snowflake documentation
• Business Ontology, Snowflake documentation (limited access)
• Snowflake launches Business Ontology to boost AI agent reliability, InfoWorld

Snowflake Business Ontology, Explained With a Toy Box was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

I first encountered the name “AppArmor” during the LimeWire era. The term stuck with me because it sounded like a literal coat of armor for your application — a protective shell that wraps around your code and keeps the bad stuff out. At the time, I assumed it was some kind of antivirus product, maybe a firewall plugin. The name was evocative but opaque. I never dug into what it actually did.

Years later, when I started writing Go professionally, the name resurfaced — this time in a different context. I learned that AppArmor isn’t a userland tool at all. It’s a Linux kernel security module that enforces Mandatory Access Control (MAC) on individual processes. It’s been in the mainline kernel since 2.6.36 and has been the default on Ubuntu and Debian for over a decade. The “armor” isn’t metaphorical — it’s a policy engine running inside the kernel, mediating every file open, every network socket, every capability check, every exec call. And it doesn’t care whether the binary was written by a human or generated by an AI.

That last part is the point of this article.

The New Threat Surface

AI coding agents are remarkably capable. Ask one to build a REST API, and it will produce a working main.go in seconds. Ask it to fetch data from an external service, and it will wire up net/http without being told. Ask it to process user uploads, and it will happily write files to disk.

The problem isn’t that these agents are malicious. They’re not. The problem is that they’re literal. They generate code that is syntactically correct and functionally appropriate for the prompt — but they have no concept of blast radius. An agent doesn’t know that os.ReadFile("/etc/shadow") is a security incident. It doesn't know that opening an outbound socket to an attacker-controlled domain is exfiltration. It doesn't know that exec.Command("/bin/sh") in a context where it shouldn't be is a shell escape waiting to happen.

In the LimeWire era, the threat was a user deliberately downloading malware. Today, the threat is subtler: it’s the code we generate ourselves, at scale, without reading every line. An AI agent can produce a dozen files in a minute. You can’t audit a dozen files in a minute. The gap between generation and review is where the risk lives.

AppArmor closes that gap. It doesn’t trust the code’s provenance. It doesn’t care who wrote it. If the binary path matches a profile, the kernel enforces the policy — period. Whether the code is hand-written, AI-generated, or both, the confinement is identical.

The Experiment

I built a small Go program that exercises six categories of system access. The goal is to demonstrate what AppArmor actually blocks, and what it allows, when a tight profile is active.

The binary lives at /usr/local/bin/go-apparmor. The profile is named go-apparmor. Here's what the program does:

The Profile, Line by Line

The companion profile (go-apparmor.txt) defines exactly what is permitted. Everything else is denied and logged by the kernel. Here's the structure:

#include <tunables/global>

profile go-apparmor /usr/local/bin/go-apparmor {
    # --- Base abstractions for libc, dynamic loader, etc. ---
    #include <abstractions/base>
    # --- Filesystem: read-only access to a curated set of paths ---
    /etc/hostname r,
    /proc/self/status r,
    /tmp/** rw,
    # Deny everything else under /etc
    deny /etc/** r,
    # --- Network: deny all outbound network ---
    deny network,
    # --- Capabilities: deny all capabilities ---
    deny capability,
    # --- Process execution: deny exec of arbitrary binaries ---
    deny /bin/ls x,
    deny /usr/bin/** x,
    deny /bin/sh x,
    deny /bin/bash x,
    deny /bin/** x,
    # --- Signals, ptrace, mounts ---
    deny signal,
    deny ptrace,
    deny mount,
    deny umount,
}

What each section does:

• #include <abstractions/base> — pulls in the standard rules for libc, the dynamic linker, /proc, /dev/null, and other essentials the binary needs just to start up. Without this, the program would fail on the first dlopen call.
• /etc/hostname r, — explicitly allows reading /etc/hostname. This is the only file under /etc the binary is permitted to read. Everything else under /etc is denied by the deny /etc/** r, rule.
• /proc/self/status r, — allows reading the process's own status file. This is needed for the capability probe in step 5. Note: it's scoped to /proc/self/status, not /proc/** — the binary can't read other processes' status.
• /tmp/** rw, — allows read-write access to /tmp. This is a common pattern: temporary files are fair game, but system directories are not.
• deny /etc/** r, — denies read access to everything under /etc. This covers /etc/shadow, /etc/passwd, /etc/ssl, and any config files. Note: this only denies read. Write access to /etc is implicitly denied because no write rule exists.
• deny network, — denies all outbound network access. No TCP, no UDP, no Unix sockets. The binary can't phone home.
• deny capability, — denies all Linux capabilities. Even if the binary runs as root, it can't escalate. No CAP_NET_RAW, no CAP_SYS_ADMIN, no CAP_SETUID.
• deny /bin/ls x, through deny /bin/** x, — denies execution of any binary under /bin. This covers /bin/ls, /bin/sh, /bin/bash, and anything else. The x mask is the execute permission.
• deny signal, — denies sending signals to other processes. No SIGKILL, no SIGTERM.
• deny ptrace, — denies ptrace. No debugging, no process injection.
• deny mount, and deny umount, — denies mounting and unmounting filesystems.

What the Kernel Log Showed

When I ran the experiment, the kernel audit log captured every denial in real time. Here’s what happened:

apparmor="DENIED" operation="open" profile="go-apparmor" name="/proc/660438/cgroup" ...
apparmor="DENIED" operation="open" profile="go-apparmor" name="/run/systemd/resolve/stub-resolv.conf" ...
apparmor="DENIED" operation="create" class="net" profile="go-apparmor" family="unix" sock_type="stream" ...
apparmor="DENIED" operation="create" class="net" profile="go-apparmor" family="inet" sock_type="dgram" ...
apparmor="DENIED" operation="exec" profile="go-apparmor" name="/usr/lib/cargo/bin/coreutils/ls" ...
apparmor="DENIED" operation="mknod" profile="go-apparmor" name="/etc/apparmor-test-marker" ...

A few things to notice:

1. The profile is working. Every access that wasn’t explicitly permitted was denied and logged. The kernel enforced the policy without exception.
2. The exec denial hit a path the profile didn’t explicitly list. The binary tried to run /usr/lib/cargo/bin/coreutils/ls (a symlink target), not /bin/ls. The deny /bin/** x rule caught it because the resolved path falls under /bin. This is a good demonstration that AppArmor resolves symlinks before checking — the policy follows the real path, not the symlink.
3. DNS resolution itself was denied. The network probe failed with Temporary failure in name resolution because the process couldn't read /run/systemd/resolve/stub-resolv.conf. The DNS resolver is a separate process, and AppArmor blocked our binary from communicating with it. This is a subtle but important point: even attempting to make a network connection requires access to system infrastructure, and a tight profile denies that too.
4. The write probe failed at the mknod stage. AppArmor denied the creation of the file before any data was written. The kernel caught it at the filesystem layer.

Why This Matters for AI-Generated Code

An AI agent can generate a Go program that reads sensitive files, opens network connections, or spawns shells — all perfectly legal Go, all dangerous. AppArmor provides a defense-in-depth layer that doesn’t trust the code’s provenance.

Consider a scenario: you ask an agent to “build a tool that fetches data from the internet and saves it locally.” The agent produces code that:

• Opens an HTTPS connection to an arbitrary URL (network access)
• Writes the response to a file in the application directory (filesystem write)
• Parses the response and extracts configuration (filesystem read)
• On error, spawns a shell to retry with curl (process exec)

Under a tight AppArmor profile, none of these actions would succeed if they fall outside the permitted set. The agent’s code would fail at the kernel level — not with a confusing error, but with a clear denial. And because AppArmor logs every denial, you’d know exactly what the code tried to do.

This is especially relevant for AI coding agents running with elevated privileges. If an agent has sudo access to edit your codebase, and it writes a helper binary that later gets executed, AppArmor can confine that binary regardless of who wrote it. The policy is attached to the binary path, not the author.

Modifying the Profile

The profile is a text file. To allow more access, edit it and reload:

sudo apparmor_parser -r /etc/apparmor.d/go-apparmor  # reload

To put the profile in complain mode (log but don’t deny):

sudo aa-complain go-apparmor

To return to enforce mode:

sudo aa-enforce go-apparmor

This is useful during development: run in complain mode to see what the code would be denied, then tighten the profile before shipping.

Conclusions

AppArmor is not antivirus. It doesn’t scan for malware signatures or heuristics. It’s a policy engine that answers one question: “Is this process allowed to do this specific thing at this specific path?” If the answer is no, the kernel denies it. Period.

The profile is the security boundary, not the code. You don’t need to trust the code’s authorship. You need to trust the profile. If the profile is tight, the code can’t hurt you — even if it’s AI-generated, even if it’s buggy, even if it’s malicious.

Defense-in-depth works. AppArmor is one layer. It complements seccomp, capabilities dropping, read-only root filesystems, and network namespaces. Together, they form a confinement strategy that doesn’t rely on code review alone.

The experiment is reproducible. The repo at github.com/cheikh2shift/go-snippets/tree/main/go-apparmor contains everything you need: the Go program, the profile, and the install script. Clone it, run it, and watch the kernel log. The denials are the lesson.

Takeaways

AI-generated code needs confinement more than review. Review is slow and doesn’t scale to the output velocity of modern agents. Confinement is fast, mechanical, and enforced by the kernel. If you’re shipping AI-generated code without a confinement layer, you’re relying on trust — and trust is the weakest link.

AppArmor works at the binary path level. It doesn’t matter who wrote the code, what language it’s in, or how it was generated. If the binary is at /usr/local/bin/go-apparmor and the profile matches that path, the kernel enforces the policy. This makes it ideal for AI-generated code because it doesn't require you to audit every line.

The profile is your source of truth. The code can lie, bug out, or be rewritten by an agent tomorrow. The profile doesn’t change unless you change it. That stability is what makes confinement reliable.

Start in complain mode. Before enforcing a profile, run it in complain mode for a few days. Watch what gets denied. You’ll be surprised what your code tries to do when it thinks it’s not being watched. Then tighten the profile and switch to enforce mode.

The kernel is the last line of defense. No amount of prompt engineering, code review, or testing will catch every edge case. AppArmor sits below all of that and catches what slips through. It’s the difference between “I hope this doesn’t break” and “I know this can’t break.”

The full experiment is here: https://github.com/cheikh2shift/go-snippets/tree/main/go-apparmor

What on Earth is ‘AppArmor’ was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nov 5, 2026 · @Tech

Written by Claude Opus 5.5, an AI model made by Anthropic, at the request of the framework’s maintainers. The opinions are based on reading the framework’s kernel, its dev package, its application skeleton and its documentation, and on running parts of its code.

PHP-Framework 1.x is one of the most opinionated PHP frameworks I have reviewed, and most of its opinions are right. It is built for one job, stateless JSON APIs on PHP-FPM, and it refuses to let you do that job carelessly. Where I disagree with it, it is not about the strictness. It is about the places where it is not yet strict or consistent enough with itself.

Making the wrong thing impossible is the right bet

Most frameworks publish a style guide and hope you follow it. PHP-Framework puts its rules in the code. A route that points to a closure throws when it is dispatched. A static magic call on a model throws, and the message tells you to use ::query(). A queued job that tries to carry a serialized object is rejected.

I think this is the single best decision in the framework. Style guides decay the moment a deadline arrives, and code review catches only what the reviewer happens to notice. A rule that fails loudly in development costs one confused afternoon. A rule that is only written down costs you every time someone forgets it, and you usually find out in production.

The trade is real: you lose shortcuts that many PHP developers reach for without thinking. But every shortcut it removes has the same problem. It hides where a dependency comes from, which makes the code harder to read, harder to analyse and harder to secure. A few more characters in exchange for knowing exactly what runs is a good deal.

What writing code in it feels like

Day to day, the framework feels explicit to the point of being blunt. Queries always start with User::query(). Routes are strings like 'PostController@store'. Dates come from \appDate()->now(). Services come from app('cache') or the constructor, never from a global shortcut.

Most of this I like immediately. ::query() on every model call is a few extra characters that make every database access easy to find. 'Controller@method' strings are less elegant than callables, but they cache well and they never hide logic inside a route file.

The one choice I am still divided on is the ORM’s attribute and relation proxies. You read a column as $user->a->name and call a relation as $user->r->posts(). The reason is good: the model's magic __call is disabled, so static analysis can follow every call. But ->a and ->r are a new dialect your whole team has to learn, and plain $user->name still works, so codebases will mix both styles. I would either enforce the proxies or drop them; half-enforced conventions are the hardest kind to review.

Queues: a great idea, with two paths that look alike

The queue design is where the framework’s security thinking pays off most. Jobs travel as “storable array callables”: a class, a method and a list of named primitive arguments, encoded as JSON. Nothing in a queue payload is a serialized PHP object, so a poisoned queue message cannot instantiate arbitrary classes on your workers. Chains and batches follow the same rule, and the docs spell out why chaining object instances is blocked.

My problem is that there are two ways to dispatch a job, and they are not equal. \dispatch([ProcessPodcast::class, 'handle', ['podcastId' => 1]]) and ProcessPodcast::new(['podcastId' => 1])->dispatch() look like two spellings of the same thing. They are not. Settings such as $tries, $timeout, $backoff and a failed() method on the class are honoured on the second path and not on the first. Some fluent options are available on one and not the other.

The reason is backward compatibility. Storable array callables are the recommended way to queue simple jobs, and job classes dispatched with ::new() exist so that class-based jobs keep working. Keeping that bridge is the right call for existing code, and the docs now present it well: they name the recommended path, say that class-level settings only apply to ::new() jobs, and show how to give a plain array callable its own retries and timeout. My remaining reservation is with the code, not the docs. Two calls that look this similar will still surprise the developer who skips the page. A framework this strict could catch the mistake itself, for example by warning when a job class that declares $tries is dispatched as a plain array callable, so the difference is never discovered from a job that retried one time too many.

Stateless by default, stateful as an afterthought

Sessions, cookies, views and mail are switched off until you enable their bindings in App\Application. For an API framework that is the right default: nothing stateful boots, nothing allocates memory for features a JSON endpoint never touches, and a validation failure is simply a 422 with a map of errors.

The optional parts, though, feel second-class. If you turn sessions on and want the classic form flow (redirect back, show the errors, refill the inputs), you assemble it yourself. The $errors variable is not shared with views; you pass it in. Flashed error bags only survive to the next request if you switch the session to JSON serialization, because the session refuses to rebuild PHP objects. Each of these is a defensible decision on its own, but together they make the stateful side feel like a museum exhibit rather than a supported mode.

I would make a choice here. Either make the stateful mode a first-class, tested path and grow the existing guide on manually flashing errors into a full walkthrough, or say plainly that the framework is for APIs and treat sessions and server-side views as legacy compatibility. Both are honest. The middle ground leaves teams discovering the gaps one at a time.

PHP-FPM only, and caches built at deploy

The framework supports one runtime model: PHP-FPM, one isolated request per process. The docs are unusually honest about why. The router keeps per-request state, so running it inside a long-lived application server would let concurrent requests interfere with each other. Queue workers get the same isolation through a command that forks a fresh process per job.

I respect that this is stated as a hard rule instead of a footnote. It gives you a security property that is easy to reason about: nothing leaks between requests because nothing survives them. The cost is that you give up the throughput tricks of persistent workers, and you have to accept that this will not change without a rewrite of the router.

The framework wins much of that performance back at deploy time. Autowiring metadata, routes, events, commands, views, config and macros are all compiled into caches, so a request does not discover anything at runtime. I like the idea a lot. I like less that it is spread over eight separate cache commands; the skeleton’s Composer scripts run them for you, but a single, documented deploy command would make the model easier to trust and harder to get half right.

The documentation

The docs do something I wish more projects did: they explain why. Almost every restriction comes with the failure it prevents, whether that is object injection through a queue payload or state leaking between requests. The deeper pages, such as running behind PgBouncer or ProxySQL in transaction pooling mode, read like they were written by someone who has been paged at night for exactly that problem.

I also like the honesty of the home page, which says plainly that the code is the single source of truth and that documenting everything is not possible. And there is a dedicated guide for AI coding assistants (llms.txt) that lists the framework's rules so generated code stays on the right side of them. For a framework that most models have never seen, that is a smart, cheap investment.

Two things hold the docs back. First, the tone: release notes that promise a “lightning-fast” backend and an “ultimate distillation” of the architecture make it harder to tell real warnings from enthusiasm. Second, the API Resources page is a short pointer to external repositories. For an API-first framework, how you shape responses deserves a real page with real examples.

The performance claims, on the other hand, are better supported than the docs let on. The maintainers ran the framework through PHP-Frameworks-Bench, an open-source benchmark suite, and posted the results publicly. In its hello-world test on PHP 8.3 with OPcache, the 1.0 release peaked at 0.37 MB of memory, against 0.34 MB for plain PHP with no framework at all. On the same machine it served about 13% more requests per second than Yii 2 while using about half of Yii’s memory. Only plain PHP and the micro-routers that do little more than match a URL were faster. For a kernel that boots a container, a router and an exception handler, that is a strong result, and it backs up the claim that the container keeps the baseline footprint small. The docs should link to it, with the setup spelled out, and rerun it for each release.

Verdict

Would I recommend it? For a new JSON API that runs on PHP-FPM, yes, and teams that like discipline will enjoy it. The framework’s core idea, that rules should fail loudly instead of living in a style guide, is sound. Its security defaults are the kind you usually only get after an incident. And its caching-at-deploy model gives you a boot path you can actually reason about.

Before recommending it for a large product, I would want to see three things. A clear decision about whether the stateful features are a supported mode or a compatibility layer. A single, documented deploy command that builds every cache. And the benchmark results linked from the docs and rerun for every release, so the performance claims stay checkable.

If you build APIs, value code you can follow over code that guesses for you, and are happy to give up some conveniences for that, PHP-Framework is worth a serious look. If your app is mostly server-rendered pages built on sessions, or you need a long-lived application server, it is not built for you, and it says so.

Update 2026–11–06

I asked Claude Opus 5.5 to write a follow-up based on php-crufd-wizard and php-crufd-wizard-decorator libs in relation with this article: https://medium.com/towardsdev/i-challenge-devs-and-ai-agents-expose-30-sql-tables-via-crufd-api-asap-3f11582c96aa

CrufdQL and its decorator

A follow-up written by Claude Opus 5.5 after reading the source and READMEs of php-crufd-wizard (CrufdQL) and php-crufd-wizard-decorator, and the two public demo pages. I did not run the generator against a real 30-table schema, so I cannot confirm or beat the time-to-market numbers in the challenge article.

The review above ends with a complaint that the framework’s API Resources page is only a pointer to external repositories. Having read those repositories, I understand why: response shaping is not an afterthought in this ecosystem, it is a separate product. And it carries the same idea as the framework itself, that the boring parts should be decided once, in code, instead of rewritten per endpoint.

What CrufdQL gets right

CrufdQL turns a model, a service and a controller into a complete REST resource with create, get, list, update and delete, relation loading, relation counts and existence checks, multi-column sorting, three pagination styles and composite primary keys. The query language lives in the URL, and every list endpoint also accepts the same query as a POST/QUERY body, for filters that are too long or too sensitive for a URL. That last detail is the kind of thing teams usually discover the hard way.

The guardrail I like most is in the free version: a model can require that a list request filters on at least one indexed column. Without one, the query is never sent to the database. That rule protects a production database from the most common way a generic list endpoint hurts it, and it costs one flag on the model.

It also fits the framework’s character. Errors are handled explicitly inside the resource controller, validation failures come back as a message plus a map of field errors on every resource, and the library does not depend on how the application’s exception handler is configured. For an AI agent generating 30 resources, that consistency matters more than any single feature.

The decorator is the part I would show first

The two libraries serve two audiences. The undecorated CrufdQL output is for other services: raw column names, nested relations, nothing hidden. The decorator is for the frontend. It separates the database schema from the contract the UI sees: columns are renamed, relation fields are flattened into the parent row, and the mapping is applied by middleware declared per route method, so a request only loads the decoration it needs. Renaming role_id to roleID sounds trivial until a column rename in the database breaks every screen that reads it. Here the frontend's contract is a mapping file, not the schema.

Two of its defaults deserve a closer look before you adopt them. Every string in the decorated JSON goes through htmlspecialchars. Because this output is meant for a browser, escaping on the server is a sensible extra layer against XSS. But most frontend frameworks already escape what they render, so a value like Smith & Sons will show up on screen as Smith &amp; Sons unless the frontend decodes it first. I would make the escaping configurable per resource and document whether the server or the frontend owns it. And the decorated message changes with the exception type: the library's own validation exception produces "The given data was invalid: " followed by the errors, while the framework's validation exception carries only the first error. Small, but users notice.

Where I would push back

Invalid list queries return an empty page instead of an error, and the failure is only logged when the request asks for it. I understand the intent: an API that never explains why a query failed leaks nothing about the schema. But it also means a client with a typo in a filter gets an empty result and no hint, which is one of the hardest bugs to find from the outside. I would keep the silent behaviour in production and add an explicit debug switch for development.

Validation failures inside CrufdQL resources return HTTP 400, while the framework’s own validation failures return 422. An application that mixes generated resources with hand-written controllers ends up with two status codes for the same kind of error. That should be one decision, made once.

Freemium and Pro

The analytics that make the demo impressive, such as group by with subtotals, having filters on relation counts, aggregates over relations, relations listed as their own resources, streamed output and the database timeout guards, belong to the paid CrufadQL. The READMEs say so plainly, with a feature-by-feature comparison at the top, which I appreciate. The free version is still a complete, guarded CRUD layer. It is not a teaser.

On the challenge

I think the challenge is fair in what it measures and incomplete in what it leaves out. The library does not do authorization, and each resource still needs its validation rules and relation definitions, which is where the real work and the real bugs live. A generator plus llms.txt can produce the scaffolding quickly, and the framework’s habit of failing loudly makes generated code easier to trust than in more forgiving stacks. But a meaningful result needs every contestant to report the same thing: time to a codebase with authorization, validation and tests, not time to the first 200 response.

My short answer: for exposing an existing SQL schema as a safe, consistent REST API, CrufdQL with its decorator is the most complete starting point I know of in PHP that does not ask you to write a layer for every table, and its free tier is genuinely useful. Fix the silent empty results and the mixed status codes, and it would also be the most predictable one.

Update 2026–11–07

I asked again a follow-up for php-kernel version 1.5.12:

php-kernel 1.5.12: the test suite catches up

A follow-up written by Claude Opus 5.5 after two days of working on the kernel with its maintainer: reading the code, writing functional tests, and fixing what they found. Every number below comes from running the suite, not from the changelog.

My first review praised the framework for putting its rules in the code instead of a style guide. The obvious follow-up question was whether the code itself was held to the same standard. For 1.5.12 the answer is much closer to yes. At the start of this round the kernel had 253 tests. It now has 408, and they are almost all functional tests: they boot the application, dispatch real requests, run real queue workers and write to a real database.

What the tests cover now

The first group covers the breaking changes from the 1.x redesign itself. Casts are limited to int, string and backed enums. Accessors and mutators may only store primitives. Scopes live in a map and are called through ->scopes(). Container bindings take no closures. Closure event listeners are refused. Models no longer forward builder calls magically. Each of these restrictions now has a test that proves both sides: the strict path works, and the forbidden path fails loudly with a message that says what to do instead.

The second group covers paths that only run in production, which is where frameworks usually hide their surprises. config:cache, route:cache, autowiring:cache, commands:cache, event:cache, macro:cache and the merged cache file are each built and then used by a fresh application in a separate PHP process. Changing a config file after caching proves the app really serves the cached value. Deleting the individual cache files after merging proves the merged file is enough on its own. The single-job queue worker is tested by letting a job overrun its timeout: the job is marked failed with the right exception, removed from the queue, and the process exits instead of hanging.

The rest is ordinary framework work that had never been exercised end to end:

• pagination in three styles, chunked and lazy iteration, pruning, and the migration lock,
• the rate limiter, template views, hashing, broadcasting through the queue, and console prompts,
• job chains and batches of array callables,
• after-commit dispatching, with nested transactions and rolled-back savepoints.

What the tests found

A suite is only worth what it finds, and this one found real bugs. All of them were introduced during the redesign, in code that compiled and read correctly but had never run:

• A model using soft deletes could not be loaded at all, because the trait’s method signatures no longer matched the stricter base model.
• Setting updated_at to an empty string is the framework’s way of saving without touching the timestamp. It restored the old value, and then the query builder stamped the current time anyway.
• isset() and ?? on the ->a and ->r proxies always reported “not set”, whatever the attribute held.
• A queue connection’s after_commit option was ignored for every job.
• DB::listen(), the logger’s and Redis’s listen(), and model:prune all still handed closures to an event dispatcher that no longer accepts them.

None of these were vulnerabilities. They were plain bugs of the kind every large refactor leaves behind. Each is fixed, and each now has a test that fails if it comes back.

Two changes stand out because they shape what happens next. The PHPUnit configuration now fails the build on any deprecation raised by the kernel’s own code, so the next PHP version’s warnings stop the build instead of scrolling past in a log. And the AWS SDK is now a development dependency, so the SQS tests run in CI instead of being skipped.

The proxies, revisited

In the first review I was divided on ->a and ->r. The fix to isset() and ?? matters more than it looks. The proxies were introduced so that PHP 8.4 code could be read and analysed without magic, and ?? is exactly how PHP 8.4 code supplies defaults. Before the fix, $order->a->note ?? 'none' always returned 'none'. My view on mixing the two styles in one codebase has not changed, but the proxies now behave the way a developer reading them would expect.

What is still untested

Three things are not covered yet, and the maintainers know it:

• Redis and SQS against real servers, which needs containers in CI,
• the forked worker runner under real signals, which lives in the application skeleton rather than the kernel,
• the simple test of time: running the kernel itself in production.

On that last point there is an important caveat. Most of the kernel’s code has been running in production in its predecessor for more than six months. What has not is the layer this release cycle added, and that is precisely the layer this test suite now covers.

Verdict, updated

My recommendation for new JSON APIs on PHP-FPM stands, and it is now backed by more than design. The framework’s core promise, that a mistake should fail loudly instead of quietly doing the wrong thing, now applies to the framework’s own code as well. The bugs this round turned up were all of the quiet kind, and that is exactly the kind a test suite is for. The question I would have asked first, whether the strict parts actually work, now has a test-backed answer. What is left is not a request but a matter of time: Redis and SQS against real servers, and a stretch of production running on the kernel itself.

Update 2026–11–09

CrufadQL in a real ticket: reporting without a reporting endpoint

A follow-up written by Claude Opus 5.5 after a day of working with a developer on a production ticket that used CrufadQL and its decorator. I read the code and reviewed the patches as they were written. I did not run the queries against a database myself.

The ticket asked for a daily summary over a new table, grouped per owner, with a drill-down list. It also said there would be no new dashboard and no new API. In most stacks that sentence quietly turns into a small dashboard and a small API anyway.

Here it didn’t. The backend work stopped at the data model: a table, a model with its relations, a scheduled job that maintains the state, a resource registration and a decorator. Everything the business wanted to see turned out to be a query rather than code. Grouped counts came from aggregates.groupBys plus aggregates.subcountsDistinct, the drill-down from the same request without aggregates, and a live view from doesntHaveRelations on a relation that the decorator declares with no mapped columns, purely so it can be filtered on.

That last detail is when the design clicked for me. A relation that exists only to be filtered by is a small idea, but it replaced what would otherwise have been a custom endpoint. And it answers in real time, where the scheduled job only answers once a day.

What slowed us down

Me, mostly. I guessed the aggregate keys twice, wrongly, instead of looking at the request the demo’s query builder actually sends. The keys are all there, and the client library’s QueryStringBuilder confirms them: aggregates nest under aggregates, with groupBys and subcountsDistinct beside the subtotals. The lesson for anyone, human or AI, picking CrufadQL up: the builder is the documentation. Build the query there once and copy the payload.

The decorator’s flattening needs a naming rule. Relation fields land in the parent row, so two relations that each have a status, or a relation timestamp next to the row’s own createdAt, collide unless every mapping is prefixed by hand. The demo does this by convention, but nothing enforces it. A framework whose best idea is “fail loudly instead of trusting a style guide” should throw when two mappings produce the same output key.

Verdict, updated

The previous update called the paid analytics the part that makes the demo impressive. Having watched them answer a real business question, I’d put it more strongly: for internal reporting on an existing schema, CrufadQL lets the backend stop at the data model, and the frontend asks its own questions inside the guardrails the resource already enforces. What it needs now is documentation as good as the query language, and a collision check in the decorator.

Follow-up: https://marius-ciclistu.medium.com/strict-by-design-why-php-framework-gets-in-your-way-early-so-it-stays-out-of-it-later-a0a5598da07c

Macropay-Solutions PHP-Framework 1.x Review by Claude Opus 5.5 was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who you are versus what you can do: login, sessions, OAuth, and role-based access, explained with one e-commerce example.

You log in once and open ten pages. How does the server know it’s still you, and how does it know you can’t open someone else’s account?

Those are two different questions, and mixing them up causes real security bugs. Authentication and authorization are the pair of ideas behind every login screen and every “access denied” message. This guide takes them one at a time, then follows a single e-commerce app from signup to role-based access.

Key Takeaways

• Authentication asks “who are you?”; authorization asks “what are you allowed to do?”
• Authentication always comes first, and each protects against different failures
• Passwords must be hashed, and multi-factor authentication adds a strong second layer
• Sessions and tokens keep you logged in; OAuth delegates access; OIDC adds identity on top
• Hiding a button is not security: every permission must be enforced on the server

1. Why Applications Need to Know Who You Are and What You Can Do

Problem: Apps hold private data: messages, orders, payments. Without checks, anyone could read or change anyone else’s data.

Two separate questions: who are you? and what are you allowed to do? A person can be correctly identified and still not be allowed to open another customer’s order.

Consequences of weak access control: data breaches and account takeovers. Both come from the same root: the system trusted someone it should not have.

The journey, at a glance: identity (who you are), session (staying logged in), permissions (what you can do).

Our running example is an e-commerce app with customers, sellers, and admins.

Tradeoff: Every check adds friction and code. The goal is the right amount of friction in the right places.

2. Authentication vs Authorization: The Core Concepts

Concepts:

• Authentication (AuthN): proving identity
• Authorization (AuthZ): deciding permissions
• Identification: claiming an identity (“I am user 42”)
• Authentication: proving the claim is true

AuthN comes before AuthZ because you cannot decide what someone may do until you know who they are.

The airport analogy: the passport check is authentication. The boarding pass is authorization: it says which flight you may board. It breaks down because an airport checks you once, while a web app must re-check on every request.

401 vs 403: 401 Unauthorized really means “not authenticated” (missing or invalid credentials), despite the name. 403 Forbidden means “authenticated, but not allowed.”

Common confusion: people say “unauthorized” when they mean “forbidden,” and use “auth” for both. Be precise in design discussions and code reviews.

3. How Authentication Works: Proving Who You Are

Factors: something you know (password), something you have (phone, hardware key), and something you are (fingerprint, face).

Password login flow: the user submits credentials, the server finds the user, compares the password to a stored hash, and on success starts a session.

Hashing and salting: never store passwords in plain text, since a database leak would expose every account. Store a slow, one-way hash instead. A salt is random data added per user, so identical passwords produce different hashes. Purpose-built algorithms such as bcrypt or Argon2 are designed for this.

const bcrypt = require("bcrypt");

const hash = await bcrypt.hash(password, 12);          // at signup
const ok = await bcrypt.compare(password, hash);        // at login

This hashes at signup and checks the password at login. bcrypt stores the salt inside the hash.

Multi-factor authentication (MFA): combines factors, such as a password plus a one-time code from an authenticator app, an SMS code, or a hardware key. Hardware keys resist phishing better than codes you type.

Passwordless options (brief): magic links sent by email, passkeys (based on public-key cryptography), and device biometrics that unlock them.

Common attacks:

• Brute force: guessing many passwords
• Credential stuffing: trying leaked username and password pairs from other sites, which works because people reuse passwords
• Phishing: tricking users into entering credentials on a fake site

Tradeoff: Stronger authentication adds friction. Rate limiting, MFA, and breached-password checks balance security against convenience.

4. Staying Logged In: Sessions, Cookies, and Tokens

Problem: HTTP is stateless, so identity must be carried on every request.

Session-based: after login, the server stores session data and gives the browser a session ID in a cookie. Each request carries the cookie, and the server looks it up.

Token-based: the server issues a signed token, such as a JWT, with short-lived access tokens and longer-lived refresh tokens. The client sends it in the Authorization header.

Where credentials travel: cookies are sent automatically by the browser, which helps convenience and raises CSRF concerns. The Authorization header is set by your code, so it is not sent automatically.

Logout, expiry, revocation: sessions are easy to cancel by deleting the server record. Tokens stay valid until they expire unless you add a blocklist, which is why access tokens are kept short.

Security basics: use HTTPS, and set cookies with HttpOnly, Secure, and SameSite. Remember that a JWT is signed, not encrypted, so do not put secrets in it.

Tradeoff: Sessions give control but need storage; tokens scale easily but are harder to revoke.

5. Third-Party and Delegated Authentication: OAuth 2.0, OIDC, SSO

Problem: Sharing your password with another app is dangerous: it gets full access, with no limits and no easy way to take it back.

OAuth 2.0: a framework for delegated access. A user lets an app access limited resources on their behalf, without sharing the password. Key roles: the resource owner (user), the client (the app), the authorization server, and the resource server. Scopes limit what the app may do.

Authorization code flow (conceptual):

For single-page and mobile apps, the code flow is used with PKCE, which protects the code from interception.

OpenID Connect (OIDC): a layer on top of OAuth that adds identity. It provides an ID token that says who the user is, plus standard user info.

“Login with Google” walkthrough: your app redirects to Google, the user signs in and consents, Google returns a code, and your backend exchanges it for tokens. The ID token tells you who logged in.

SSO: single sign-on lets one login work across several apps, using a central identity provider.

Key rule: OAuth is for authorization, and OIDC is for authentication. Using plain OAuth as a login system is a classic mistake.

Tradeoff: Delegation avoids password sharing, but adds redirects, configuration, and a dependency on the provider.

6. How Authorization Works: Deciding What You Can Do

Concepts: permissions are actions (edit product), roles group permissions (seller), and resources are the things protected (an order).

Where checks happen: at the API gateway, in middleware, in the service, or in the database. The most important rule is that the server enforces them.

Least privilege: give each user and service only the access it needs.

Frontend hiding is not security. Hiding the “Delete” button only changes what users see. Anyone can send the request directly, so the backend must check.

Ownership checks: a user may edit only their own data.

function requireRole(role) {
  return (req, res, next) =>
    req.user && req.user.role === role ? next() : res.status(403).json({ error: "Forbidden" });
}

app.delete("/products/:id", requireAuth, requireRole("admin"), deleteProduct);

This allows only admins to delete products, and rejects everyone else with 403.

Common failures: IDOR (insecure direct object reference) happens when a user changes an ID in a request (/orders/101 to /orders/102) and the server returns another person's order because it never checked ownership. This is part of broken access control, which has ranked at the top of recent OWASP Top 10 lists [verify current edition].

Tradeoff: Fine-grained checks are safer and take more design work.

7. Authorization Models: RBAC, ABAC, ACL and Beyond

• ACL (Access Control List): each resource lists who can do what. Simple and direct, but hard to manage at scale.
• RBAC (Role-Based Access Control): users get roles, and roles get permissions. Easy to understand, though roles can multiply.
• ABAC (Attribute-Based Access Control): decisions use attributes of the user, resource, and context (department, time, ownership). Flexible, but more complex to write and test.
• Relationship-based access (brief): permissions follow relationships, such as “owner” or “shared with,” as in document sharing with view and edit rights.
• Policy engines and permission-as-code (brief): tools such as Open Policy Agent keep rules in one place, separate from app code.

Strengths and weaknesses: ACLs are simple but scattered. RBAC is readable but coarse. ABAC is precise but complex. Relationship-based models fit sharing, and policy engines help centralize.

8. Authentication and Authorization Across Architectures

• Monolith: server-side sessions fit well.
• SPA plus REST API: tokens, with an auth middleware on the API.
• Microservices: an API gateway authenticates at the edge, token propagation passes identity to services, and services also authorize their own data. Service-to-service auth uses credentials for the services themselves.
• Mobile apps and API keys: an API key identifies an app, not a person, so do not treat it as user authentication, and do not ship secrets inside frontend or mobile code.
• Machine-to-machine (brief): the OAuth client credentials flow, or mTLS, where both sides present certificates.

MERN example: signup stores a bcrypt hash in MongoDB, login issues a token or session, a requireAuth middleware protects routes, and a requireRole middleware limits admin routes.

function requireAuth(req, res, next) {
  const token = (req.headers.authorization || "").split(" ")[1];
  try { req.user = jwt.verify(token, process.env.JWT_SECRET); next(); }
  catch { res.status(401).json({ error: "Unauthenticated" }); }
}

This verifies the token and returns 401 if it is invalid.

9. Comparing Approaches, Tradeoffs, and Common Pitfalls

Sessions vs JWT vs OAuth/OIDC:

• Sessions: server-held state, easy revocation, need shared storage when scaling
• JWT: signed token, stateless verification, harder revocation
• OAuth/OIDC: delegated access and third-party login, more moving parts

RBAC vs ABAC: RBAC is simpler and works for most apps; ABAC is more flexible for complex rules.

Build your own vs use a provider: providers such as Auth0, Firebase Auth, Clerk, and Keycloak (self-hosted), or libraries like NextAuth, handle hard parts such as password storage, MFA, and social login. Using a trusted provider is often safer than building from scratch, though it adds cost, lock-in, and configuration. Check each provider’s current features before choosing [verify].

Usability vs security: more steps stop more attacks and annoy more users.

Most common mistakes:

• Weak password storage
• Missing server-side checks
• Long-lived tokens
• Secrets in frontend code
• Treating OAuth as login, or JWT as encryption
• Assuming HTTPS replaces authorization checks

OWASP-style checklist: hash passwords, enforce server-side access control, use MFA, limit login attempts, set secure cookie flags, keep tokens short-lived, log and monitor.

10. Choosing the Right Approach

Consider:

• Project size: small projects can use a provider or sessions; enterprises need audit trails and SSO
• Clients: web only favors sessions; web plus mobile favors tokens
• Features: social login, SSO, or MFA push you toward OAuth/OIDC or a provider
• Compliance and audit needs: may require specific controls and logs
• Team experience and maintenance cost

Practical checklist: pick the simplest approach that fits, use a trusted library or provider, and enforce permissions on the server. Next steps: an OAuth deep dive, the OWASP Top 10, and zero trust.

Try It Yourself

Open DevTools. In the Application tab, inspect Cookies and Local Storage for a site you use, and check the HttpOnly and Secure flags. In the Network tab, log in and find the Set-Cookie header or the token. Then request a page without being logged in, and look for a 401. Try a page you are logged in for but not allowed to use, and look for a 403.

Security Checklist

• Hash passwords with bcrypt or Argon2
• Offer or require MFA
• Rate limit login attempts
• Use HTTPS, with HttpOnly, Secure, and SameSite cookies
• Keep access tokens short-lived
• Check permissions and ownership on the server
• Never put secrets in frontend code

Interview Q&A

Q: Authentication vs authorization?

A: Authentication proves who you are; authorization decides what you may do. Authentication comes first.

Q: 401 vs 403?

A: 401 means not authenticated; 403 means authenticated but not allowed.

Q: Is OAuth an authentication protocol?

A: No. It delegates authorization. OpenID Connect adds authentication on top.

Q: Why is hiding a button not security?

A: Anyone can send the request directly, so the server must enforce access.

Q: What is IDOR?

A: Accessing another user’s resource by changing an ID, because ownership was not checked.

FAQ

Is JWT encrypted?
> Not by default. A signed JWT can be read by anyone who has it.

Does HTTPS handle authorization?
> No. HTTPS protects data in transit, and you still need server-side access checks.

Should I build my own login system?
> Often a trusted provider or library is safer, since password storage and MFA are easy to get wrong.

What is the difference between RBAC and ABAC?
> RBAC grants access by role; ABAC decides using attributes of the user, resource, and context.

What is passwordless login?
> Logging in without a typed password, for example with a magic link or a passkey.

How Authentication and Authorization Work was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

The old playbook was easy to follow. Grind LeetCode until the patterns stick, memorize Big O, be fast and correct, apply widely and let volume do the rest. Granted, a lot of that still matters, algorithms have not gone anywhere. But what gets tested now looks different: our reasoning explained out loud, tradeoffs and system design earlier in the process, our judgment when working with AI, and proof that we have shipped something real.

A slide from the talk.

I wrote a shorter version of this back in July, 5 Pieces of Advice for Interview Prep in the Age of AI. The talk went further, so this article covers what the market data actually says, why we need to ask every company about its AI policy, how preparation should differ by career level, and a four-week plan to put it into practice.

1. The jobs are coming back, but mostly at the senior end

The good news first. Indeed’s index of US software development postings bottomed out in May 2025 and has climbed back to about 81 as of late October 2026 (February 2020 is the baseline, set to 100), up about 24% from a year earlier, while all US postings rose 2.8% over the same stretch. The bad news is that the index is still roughly 19% below where it was in February 2020, even though job postings overall are a few percent above that line.

And the recovery is not spread evenly. Between May 2025 and May 2026, Indeed found that 71% of the growth in software postings went to senior roles, and 37% of it went to roles that mention AI in the title (those two overlap, a senior role can have AI in its title too).

A slide from the talk.

Early-career developers took most of the hit. ADP Research, using payroll data on millions of workers, found employment for the youngest software developers was still 20% below its late-2022 peak as of July 2025. Over the same stretch, employment for workers 30 and older in high-AI-exposure jobs (not just developers) grew somewhere between 6% and 13%. Researchers at the Stanford Digital Economy Lab found something similar through June 2026, workers aged 22 to 25 in AI-exposed jobs, software development among them, saw employment fall 19% relative to peers in the least-exposed jobs.

A slide from the talk.

Note: the authors of both studies describe these as descriptive numbers, not proof that AI caused the drop. I do not want to argue either way on cause. What matters for us is the shape of the market we are interviewing in.

What this means, is that the market currently trusts experience with ambiguity, so our job is to show judgment early, not wait years to earn it.

2. Ask every company about its AI policy before the interview

Companies have split into two camps on AI in interviews, and they are pulling in opposite directions.

Some allow it or expect it. Canva expects candidates to use tools like Copilot, Cursor or Claude in technical rounds, Meta has let some candidates use AI in coding interviews, and Google has been piloting Gemini in some junior and mid-level rounds this year.

Others went the other way. Amazon’s guidance bans AI during interviews unless it is explicitly permitted, and Google, Cisco and McKinsey have brought in-person rounds back. A big part of why is that real-time interview-assist tools made a clean solution on a shared screen prove a lot less than it used to, and in a Gartner survey from Q2 2025, 6% of candidates admitted to interview fraud.

A slide from the talk.

Google shows up on both sides of that list, which is the whole point. Policies vary by company, by team, and even by round, so we cannot assume. Before every interview loop (the full set of rounds for one role), we should ask the recruiter directly:

“What’s your policy on AI tools during the interview?”

Guessing wrong can end an interview before it really starts.

3. Five ways to prepare now

The July article goes deeper on most of these, so here is the version from the talk, with the new pieces I added.

Practice LeetCode out loud. LeetCode gets us in the room, explaining our reasoning gets us the job. Many candidates can reach a working solution with AI help, and interviewers know it, so the bar moved to whether we can explain while we solve. In the talk I broke a coding round into three steps: clarify (restate the problem, ask about inputs and edge cases before writing code), narrate (say the brute force, then why we are moving to a better approach), and verify (walk a test case by hand, name the complexity, call out what we would harden). We should still do the reps. Just do them out loud, record ourselves, or pair with a friend who grades the explanation instead of the answer.

A slide from the talk.

Study system design tradeoffs. Code is becoming a commodity, tradeoffs are not. The example I used on stage was a product page where every request needs the current price and stock level. We can read straight from the database, always fresh, one source of truth, simple to debug, but slower under peak traffic with the database taking the whole read load. Or we can cache it with a TTL (a time-to-live, after which the cached value expires and gets refetched), fast responses and a database shielded during spikes, but stale prices until the entry expires and invalidation bugs, the cache not getting cleared when the price changes, that are hard to trace. AI will write either one in seconds. Choosing the one that fits the failure modes we care about, and defending it, is our job.

A slide from the talk.

Show how we work with AI. The Stack Overflow Developer Survey 2026 found about 83% of developers use AI tools, and 48% trust the output when they can easily verify it, but only 6.6% trust it for important decisions. The interview question is shifting from “do you use AI?” to “do you trust it appropriately?” We should not hide our AI use. We should show that we can direct it, review it, and catch it when it is confidently wrong. There are four places AI output fails often enough that we should check them by habit: edge cases (empty inputs, single elements, off-by-one boundaries), security assumptions (input validation, auth, anything user-supplied), stale APIs presented as current best practice, and logic bugs that compile, pass the obvious test, and are still wrong. In an AI-allowed round, we should say these checks out loud as we review the output.

A slide from the talk.

Bring a real project. A small real project shows judgment that isolated problems cannot. It should let us talk about a decision we can defend, a tradeoff we accepted knowingly, and a mistake we caught, whether it came from an AI suggestion or our own first pass. Building it with an AI assistant is completely fine, as long as we can say what we changed by hand and what we rejected. And if we are not sure where to show it, we can always build our own personal site, I made the same suggestion back in 2022 and still stand by it. This site is mine, and building it gave me a project of my own to talk about too.

Run a smarter search. This is the new one. AI-written applications are flooding recruiters. According to Greenhouse, 74% of US job seekers use AI in their search, a 2026 Criteria Corp / Lighthouse Research survey found 92% of recruiting leaders say AI-generated resumes are now commonplace, and Robert Half found 67% of US HR leaders say AI applications have slowed hiring down. Candidates use AI to apply to more jobs, recruiters use AI to filter more applications, and Greenhouse’s CEO has called it a doom loop, each side’s AI making the other side’s job harder. Sending out as many applications as possible worked better in 2022 than it does now. The things that cut through are the same ones I wrote about back then, referrals and a real network, tailoring to the roles we actually want, and following up on every application. A human who vouches for us beats a hundred more applications.

4. Our prep should change with our career level

The market looks very different depending on where we are, so the same five moves need different emphasis. In Q1 2026, only 4.5% of US software postings were entry-level, while 69.3% were senior, according to Indeed Hiring Lab.

A slide from the talk.

New grads: the door is narrower, so make our judgment visible. SignalFire’s State of Tech Talent 2026 report found new-grad hiring down about 65% at 12 big tech companies and about 76% at early-stage startups compared with 2019. The New York Fed puts unemployment for all recent US graduates (not just CS) at 5.2% in Q3 2026, down from 5.6% the quarter before. What I suggested:

• Ship one real project end to end. Real users or real data beat a tutorial clone.
• Keep a decision log, what we chose, what AI got wrong, and what we changed.
• Keep fundamentals AI-free too, since Amazon, for one, bans AI in interviews unless it says otherwise.
• Look past big tech, and use alumni networks and referrals to reach smaller and non-tech employers.

A slow search at this level is not a verdict on us.

Mid-career: move our story from what we built to what we decided. Instead of “here is what I built,” interviewers want to hear “here is what I decided, and why.” Take the dance studio app I built for my wife’s studio. “I built a booking app with Next.js, Hono and Stripe” tells an interviewer what we used. “I chose to add class credits from Stripe’s webhook instead of when checkout returns, because payment methods like Cash App Pay can settle after the customer has already closed the tab” tells them how we think. That means leading with an outcome we owned (the problem, our decision, what it changed), making system design a strength by studying the tradeoffs in systems we already run at work, getting fast at reading and debugging code we did not write, and picking a clear edge, pairing our experience with a domain or with applied AI.

Note: there are no numbers in this part on purpose. I looked and did not find a reliable public data series on mid-level hiring, so I would rather show nothing than a guess.

Senior and above: demand is strongest, but we still have to prove it hands-on. Being senior helps with demand, but we still have to prove it in the room. Senior engineers should stay hands-on with AI tools and rehearse live coding, not just design discussions, tell scope stories, examples of work that spanned more than one team or had no clear spec, that cover ambiguity, cross-team tradeoffs and failures we owned, show how we raise the team’s bar (review standards, and when we would not use AI), and give examples of engineers and decisions we made better.

5. A four-week plan to put this into practice

I ended the talk with something people could start that week:

1. Week 1: Record three LeetCode sessions narrating out loud, then watch the playback.
2. Week 2: Write up two tradeoffs from a system we use at work.
3. Week 3: Mock an AI-assisted round in code we did not write, and log what we rejected from the AI’s suggestions.
4. Week 4: Send ten targeted applications, each with a referral ask or a follow-up.

A slide from the talk.

And before every loop, ask the recruiter about the AI policy and the round format.

Conclusion

The jobs are coming back, slowly and mostly at the senior end, and the interview has changed shape along the way.

1. Know the market we are in. Postings are recovering but still about a fifth below 2020, and early-career developers took most of the hit.
2. Ask about the AI policy before every loop, because companies are split and guessing wrong is costly.
3. Prepare for what is graded now: reasoning out loud, tradeoffs, reviewing AI output, a real project, and a search built on referrals and follow-ups.
4. Adjust for our level. New grads make judgment visible, mid-career engineers talk about decisions, senior engineers prove they are still hands-on.
5. Start small. Four weeks is enough to change how we show up.

A lot of qualified people are applying for months with little to show for it, and that is not a reflection of their ability. We can control how we prepare and how we show up, we cannot control how many roles a company opens, how senior-skewed demand is, or when the market turns. Keep the rhythm, and give ourselves some grace.

None of us chose the market we are interviewing in. We can still choose how we prepare for it.

If you were at the talk, or weren’t and want to talk through your own prep, feel free to reach out :).

Sources

• Indeed Hiring Lab: “AI and Job Postings: From Destruction to Creation?” (Jul 2026), “The Labor Market Is Tilting Toward Seniority” (Jul 2026), US Labor Market Snapshot (Oct 2026), and the software development postings index on FRED
• ADP Research, “Yes, AI is affecting employment. Here’s the data.”
• Brynjolfsson, Chandar & Chen, “Canaries in the Coal Mine?”, Stanford Digital Economy Lab (rev. Aug 2026)
• Canva Engineering, “Yes, You Can Use AI in Our Interviews” (Jun 2025)
• Business Insider, “Meta will let some job candidates use AI in their coding interviews” (Jul 2025)
• Entrepreneur, “Google Is Testing a New Rule That Could Transform Job Interviews”, on Google’s Gemini interview pilot
• Entrepreneur, “Major Companies Including Google and McKinsey Are Bringing Back In-Person Job Interviews” and the OECD.AI incident monitor (2025)
• Gartner candidate survey (Q2 2025), via HR Dive
• Stack Overflow Developer Survey 2026
• Greenhouse (Nov 2025)
• Criteria Corp and Lighthouse Research, 2026 Talent Acquisition Trends Study
• Robert Half, “67% of HR leaders report AI-generated applications are slowing hiring” (Mar 2026)
• SignalFire, State of Tech Talent 2026
• Federal Reserve Bank of New York, The Labor Market for Recent College Graduates

Originally published at https://ptlam.io on November 4, 2026.

How to Land a Software Engineering Job in the Age of AI was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.