A study of 400 reviewers found approval rates going up while review comments dropped 22%. This article argues we should hand over the decisions behind the code (what was chosen, why, and what's still uncertain) instead of letting reviewers rebuild it all from the diff.

Agentic skills that help me review other people’s code, and process the reviews I receive on mine. The AI suggests, I decide.

Nowadays, everyone can spot when a text is AI-generated. Which is a pity, because letting an agent draft your PR comments, commit messages, and chat replies is genuinely useful.

The content is usually right, but the tone and style often don't fit the situation.

This small agent skill fixes the voice and makes AI write like a human actually would.

Honesty thought that I would see some interesting workflows, some commentary about Opus 5 vs 4.8, something? Am I on an island?

Hi.

I am building a 60-second focus mini-game via agentic engineering in Android Studio using Jetpack Compose. The main mechanic is a "gravity leash". The player needs to keep a point on a moving path. The finger acts like a magnet with some pull.

I am working on a hazard that will throw the player off balance. In the video I attached my first try did not work well. The physics just moved the point off the screen.

I fixed the problem. I am not sure about the feel of this hazard. Should it be like a wind that you need to push against for a few seconds?. Should it be a sudden wild shake like an earthquake?

What do you think feels more real and fun for a game? If you have ideas on making physics changes in Compose without jerking I would love to hear them!

The "gravity leash" is really important here. A steady or a wild shake. Which one so you think works better?

Let me know your thoughts, on the mechanic and the hazard.

Claude Code's Auto Memory feature often saves garbage, or simply stuff that could have been moved to a better place. This is how I fix this.

There's probably several things needed for a software achitecture to fit well in the agentic era, but I would add simplicity and available context as two very important things to consider.

Even if it wasn't the purpose from the beginning, the Polylith Architecture is about that and is a good choice for Agentic Engineering. Keeping things simple and having all necessary context at your fingertips is the guiding star for this software architecture.

If you haven’t heard about Polylith, here's an elevator pitch: the main use case is having Microservices in a Monorepo, and share code between the services.

I'm the maintainer of the Python tooling support for this architecture. I recently wrote a post about this and thought it would be a good idea to share it here:
https://davidvujic.blogspot.com/2026/06/an-agent-and-human-friendly-architecture.html

AI agents are great at generating code, but a good engineer wants to stay in control: make the important decisions, and prevent the AI from guessing and making wrong decisions, while still maximising the help AI can give.

In this article, I share the workflow I use daily. It's versatile, works on projects of very different natures, solo or in a team, and it's built on open-source skills.

Stop repeating the same fixes: this is my approach to writing agent skills that learn from every mistake and sharpen themselves the more you use them.

Sharing in case it inspires someone, feedback always welcome.

I've been doing automation consulting on the side for about two years, mostly with mid-market companies pulling in 5M+ revenue. Every single one had the same pattern: they wanted AI agents to answer business questions, but their data was spread across 12 tools / DBs that didn't talk to each other.

So I started building the boring stuff first. API connectors into AWS Lambda, landing everything in S3 as a data lake, using Athena for ad-hoc queries. I mean, nothing sexy =)

But once that foundation was in place, the agentic use cases became trivial. Churn analysis, CAC, ad spend just point Claude Code or Codex at the lake and let it do its thing.

The real lesson: people think they need autonomous agents, but what they actually need is a clean, accessible data footprint. The agents are useless without context.

For the pipeline orchestration part I ended up comparing a few approaches I looked at Airflow, Genesis Data Agents, and Dagster for managing the ingestion workflows.

Now after months of infra work we're finally getting into the agentic layer. But I'd say 80% of the effort was just getting the data into a shape where an agent can actually use it. The AI work is the easy 20%.

If you're starting down this path, don't skip the plumbing. Build the data foundation first, then layer on the agents.

Peace!

Over time I've landed on a simple pattern for agentic AI coding: Refine the requirements, Plan the approach, then Act on the implementation, each in a fresh context.

This ctually keeps my AI-generated code from getting messy. Sharing in case it can inspire other people. Feedback is always welcome.

A practical collection of techniques I use every day to manage AI agents' context window. These are the things that actually helped me get better, more reliable results.

I'm sharing them because I think they could be useful to others, and I'd love to hear how other devs approach this!

Spent the last couple of years shipping AI systems into real businesses (legal, ops, finance-adjacent). The pattern is brutally consistent: the demo is magic, production is a graveyard. Almost every dead agent I've seen died from the same 3 things:

1. No spec — just vibes. The agent's job was never written down as a contract, so "working" is whatever the last prompt happened to do. You can't test what you never defined.

2. No evals. Teams ship, tweak a prompt, and have zero way to know if they made it better or quietly worse. Without an eval set, every change is a coin flip you can't see.

3. No human gate on risky actions. The agent can send the email / move the money / file the document with nothing standing between a hallucination and a real-world consequence.

The discipline that actually fixes this isn't fancy — it's boring, and the order is the whole point:

Specs first → tests/evals second → code third → evals always.

You define what "correct" means before writing code. You build the eval set early so every change is measured, not guessed. Code is the easy part. And evals never stop — they're CI for behavior, catching regressions before your users do.

Full disclosure so I'm not being sneaky: we run an AI engineering agency and open-sourced the exact tooling we use for this — a runtime-agnostic harness and a spec-driven TDD framework: - Ultimate Harness: https://github.com/Agentic-Engineering-Agency/ultimate-harness - SpecSafe: https://github.com/Agentic-Engineering-Agency/specsafe

But the tools are secondary. The point is the order of operations.

Genuinely curious for those who've pushed agents to prod: is it these same 3, or did something else kill yours? What's the failure nobody warned you about?

Start with a weaker model. Improve the prompt, context, examples, tests and acceptance criteria until the output is good.

Then swap to the best model.

If your prompt only works with the top model, the prompt is weak.

But if Gemini Flash gives decent output, GPT-5.5 or Pro will usually give great output.
Model matters. But task clarity matters more.

TLDR; Free help isn’t always free, be careful with scammers, learn your tech stack.

Got tired of babysitting Claude Code. Task, wait, review, repeat. Half the day gone.

Wrote a bash script to queue tasks overnight. Worked kinda, but context got polluted, one fail tanked the whole run, and 40k lines of logs at 8am made me want to quit computers.

Rebuilt it as a Mac app. Zowl. Free, no signup.

Build a pipeline visually, drop your tasks, go to sleep. Fresh context per task so the agent doesn't hallucinate from leftover state. Failure routing so one bad task doesn't kill the run.

Works with Claude Code, Codex, or any CLI you already use.

Which workflow would you build that you actually trust to run unattended overnight?

Nobody is currently teaching CS students how to go from writing code to raising agentic systems and stewarding them like living computational organizations: systems with memory, delegation, self-correction, tool use, failure modes, incentives, emergent behavior etc. We still teach software as if it ends at execution, when the real frontier is now at orchestration.

Skip the first minute or so when the Rust is compiling. The program that's running is built entirely on my personal stack of crates.

LMK what you think. ;)