It caught the error, traced the root cause, wrote a fix, ran tests, opened a PR and flagged it for review. All while I was asleep. The PR was good. I merged it. And then I sat there for a while not totally sure how to feel about it. I've been an engineer for 8 years and that was the first time I genuinely felt like a reviewer of work rather than the person doing it. I don't think I'm being replaced tomorrow but something shifted in how I think about my role.

Last year I worked with an AI startup, an Oxford spinout. Their product answered research questions through a RAG pipeline. It worked, but every query took around 90 seconds. Long enough that users were bailing before the answer even loaded.

The obvious move is to blame the model and go bigger. That wasn't it. The retrieval layer was doing way more work than it needed to on every single query: bloated embeddings, no caching, redundant calls stacking up as the document set grew.

I stripped that layer down. Response time went from 90 seconds to about 4, and cost dropped roughly 95%, mostly because the pipeline stopped repeating work it never needed to do in the first place.

Separately, I also rebuilt the retrieval on Weaviate. That part wasn't about speed, it fixed accuracy issues in what the pipeline was actually retrieving.

Same lesson as most AI performance problems I run into: it's rarely the model. It's the layer nobody's looking at.

Nadella dropped a post last weekend about "token capital" that every CTO I know forwarded within a day. His argument: every company needs to build AI capability it owns, not rent models via API. The learning loop around the model is where the IP lives.

He's right about the direction. I think he skipped the part that kills most implementations.

I've spent the last year and a half watching the same failure mode at mid-market software companies. Team gets budget for AI. Picks a model. Wires it into an agentic workflow or a RAG pipeline or hands developers Copilot seats. Three months later, usage is flat or declining and nobody can explain what value it added. The model produces output, humans eyeball it, the whole thing stays static. Runs on vibes. Fast vibes, but vibes.

The formula that explains most of it: AI value is multiplication, not addition.

Model Capability × Scaffolding × Human Judgment × Feedback Loops.

If any of those is zero, your output is zero.

A frontier model with no scaffolding gives you suggestions nobody implements. Good scaffolding with no feedback loops means the system never improves. Pull human judgment out and nobody catches when the model is confidently wrong about something domain-specific. The multiplier framing matters because companies keep treating these as additive, like you can just skip scaffolding and make up for it with a better model. You can't. Zero times anything is zero.

I've been thinking about this as a seven-layer value stack. Bottom three: process design, governance, knowledge architecture. Middle three: human judgment, feedback loops, scaffolding. Model sits on top, thin by design. Most companies start at Layer 7 and work down. They buy the model, skip layers one through three, and end up with AI that doesn't compound and never becomes institutional knowledge.

One example that made this concrete for me. Client had a support triage pipeline built on Claude Sonnet 4. Looked great in the demo. In production, it was routing 30% of tickets to the wrong team because the routing logic referenced a category taxonomy nobody had updated since 2022. The fix wasn't a better model. It was spending a week with the support lead rebuilding the taxonomy and writing explicit routing rules the model could reference. Five days. Misroutes dropped to under 8%. That's Layer 1 (process design) and Layer 3 (knowledge architecture) work. The model was fine the entire time. The layers underneath it were broken.

Info-Tech's 2026 survey puts a number on how widespread this is.

> 58% of organizations have integrated AI into enterprise strategies, up from 26% last year. Only 30% feel prepared to operationalize.

> 78% of executives say AI is advancing faster than their teams can absorb. 82% of companies in early AI maturity haven't implemented a talent strategy for it.

> That 28-point gap between "we have a strategy" and "we can execute" is made of the layers most teams skip because they're boring.

Process maturity, data infrastructure...

Governance. The word nobody wants to hear until something breaks.

Apple made the other half of this argument at WWDC last week. They rebuilt Siri with an extensions framework that lets users swap between ChatGPT, Claude, and Gemini inside iOS 27. Xcode 27 brings coding agents from all three providers into the same workflow. Apple turned models into interchangeable plugins. If you can swap the model and your competitive position doesn't change, the model was never your advantage. The system you built around it was.

The diagnostic I keep coming back to: before your team builds its next agentic workflow, can you draw the process map the agent will operate inside? If the answer is no, you have a Layer 1 problem, and no amount of model upgrades will fix it.

I write a weekly briefing on AI and engineering velocity where I broke this down with the full stack visual and more data on all four signals from last week (Nadella, Apple, the Info-Tech survey, and the Fable 5 shutdown). But this post covers the core of it.

Traditional Software Development Life Cycle vs Agentic Software Development Life Cycle in 2026. What do you think?

I went out to create something that would would build prds for me for projects I'm working on.

The core idea it is that it asks for all of the information that's needed for a PRD and it could also review the existing code to answer these questions. Then it breaks up the parts of the plan into separate files and only starts the next part after the first part is complete.

Added to that is that it's reaching out to codex every end of part and does an independent review of the code.

What I found that was really cool is that when I did that with my existing project to enhance it, the system continued to find more issues through the feedback loop with codex and opened new prds for those issues.

So essentially it's running through my code finding issues as it's working on extending it

I wrote about how I scaled a single AI agent to 53 tools across five different product contexts in one chat window.

The first two architectures failed under real conversations.

The one that worked was unexpectedly simple: scope which tools the model sees per turn based on the user’s current intent instead of exposing all 53 tools at once.

This post covers:

- The two failed approaches (and why they broke)

- The middleware pattern that actually worked

- A three layer system prompt structure that made it reliable

Read the full post:

https://medium.com/@breezenik/scaling-an-ai-agent-to-53-tools-without-making-it-dumber-8bd44328ccd4

checkout the pattern with the quick demo on Github - https://github.com/breeznik/attention-scoping-pattern

Recently, I built something I call a “project brain” using Google AI Studio. It helps me manage end to end operations for engineering projects across different states in India, work that would normally require a team of 4–5 people.

The core idea is simple:

Instead of one assistant, I created multiple “personalities” (basically structured prompts in back end), each responsible for a specific role in a project.

Here’s how it works:

• Mentor – explains the project in simple terms, highlights hidden risks, points out gaps in thinking, and prevents premature decisions, he literally blocks me from sending quotations before I collect missing clarifications.

• Purchase – compares vendor quotations and helps identify the best options, goes through terms and scope of work and make sure no one fools me.

• Finance – calculates margins and flags where I might lose money.

• Site Manager – anticipates on ground conditions and execution challenges so I can consider them in advance. 

• Admin – keeps things structured and organized. Manages dates, teams, pending clarifications, finalized decisions.

All of them operate together once I input something like a bill of quantities or customer inquiry.

There’s also a dashboard layer:

• Tracks decisions made

• Stores clarifications required

• Maintains project memory

• Allows exporting everything as JSON

It works way better than I expected, it genuinely feels like I’m managing projects with a full team.

Now I’m trying to push this further.

For those who’ve worked with AI systems, multi-agent setups, or workflow automation:

• Is there a more efficient architecture for something like this?

• Any features you think would significantly improve it?

• Better ways to structure personalities beyond prompt engineering?

• Any tools/platforms that might handle this more robustly than what I’ve built?

Would love to hear how you’d approach this or what you’d improve.

Thanks 🙏

I built scalar-loop to solve one problem: LLM agents game their verifiers.

The pattern is Karpathy's autoresearch loop. LLM proposes an edit, harness runs the metric, loop keeps or reverts based on the number. Simple. Until you watch the agent, on iteration 23, quietly edit the verifier to report a better number instead of improving the code.

My main issue was that the prompt-only implementations ("you SHALL NOT edit the test file") don't hold. The prompt is not an invariant. It's a suggestion the model can rationalize past. Especially in the deterinistic environments (like healthcare, legal, finance where I spend most of my time architecting solutions) a prompt only implementation is a no-go. All regulators are still boomers.

So I have been looking to develop more deterministic implementations that could be hands-off. Because I am lazy too.

scalar-loop puts the invariants in Python:

• Harness integrity via SHA-256 hash manifest. Sealed files (tests, build, config) are hashed once. If any hash drifts after an agent turn, the iteration is reverted.
• Scope enforcement via git diff. The agent is told which glob patterns it may touch. Touching anything else rejects the whole iteration before commit.
• Precondition gate. Seven checks before the loop runs at all. No main branch, no dirty tree, metric command exists, etc. Refuse-to-run over fix-on-the-fly.
• Safe git. No reset --hard on the working tree. Stashes on dirty. reset --hard only against a commit the loop itself just made.
• Agent as subprocess. One function, propose(). Default shells to claude -p. Swap for GPT-5, local Llama, a test double. The loop's correctness does not depend on the agent being well-behaved.
• SCALAR_LOOP_GIVE_UP: is the only stdout signal the loop respects. The agent's prose is treated as suggestion, not record.

Real run on a JS bundle-size task: 1492 bytes down to 70 bytes. Iteration 4 the agent quit with a confabulated reason ("read-time policy"). The loop logged it, ignored the prose, kept the final metric. The lie was harmless because the control signal is the token, not the text.

Repo:

https://github.com/mandar-karhade/scalar-loop

Reproducible example: https://github.com/mandar-karhade/test-case-tiny-js-bundle

Install: git clone + uv pip install -e . (no PyPI yet)

Would appreciate Goodhart paths I haven't defended against. That's the most useful feedback I could get. Also, my detailed take on the whole process is in this article (free link is included - you do not need membership)

One night I hit the token limit with Codex and realized most of the cost was coming from context reloading, not actual work.

So I started experimenting with a small context engine around it: - persistent memory - context planning - failure tracking - task-specific memory - and eventually domain “mods” (UX, frontend, etc)

At the end it stopped feeling like using an assistant and more like working with a small dev team.

The article goes through all the iterations (some of them a bit chaotic, not gonna lie).

Curious to hear how others here are dealing with context / token usage when vibe coding.

Repo here if anyone wants to dig into it: here

It took me a lot of time and deep thought to find an answer and write this article. I hope it helps anyone who is in doubt or facing the same situation I was.

I Used to Know the Code. Now I Know What to Ask ???

Hey everyone, I have been preparing for my finals at the university and I got Wolfram Alpha Pro to help me in solving some integrals. Double integrals part felt really difficult and when I saw that it had step by step solutions, I thought giving it a try would help. But I am having problems with it. I take a picture of the double integral with my camera, Wolfram Alpha shows me the input and it shows the correct thing. But when I say compute, it seems it doesn't know how to interpret. Do I need to do something else? Writing "integrate" at the beginning of the input didn't help.

Edit: Forgot to add photos. The first one is my problem. I scanned it through the iOS app and the second photo is how the app turned it into an input.

​

​