标签：#Engineering

Everyone says our job got easier. The people doing it are quietly falling apart. Here's the part nobody at the dinner table wants to hear: AI didn't make software engineering easy. It made it relentless. Your uncle thinks you press a button now. Your PM thinks the estimate should be half what it used to be. LinkedIn thinks you're either an "AI-native 10x engineer" or a dinosaur waiting for the meteor. And somewhere in the middle of all that noise is you, doing two jobs at once and wondering when you stopped recognizing the one you signed up for. If that landed, keep reading. This one's for you. 💡 The Lie Everyone Has Agreed To Believe The story the world has settled on is simple: AI writes the code now, so the hard part is over. It's a comforting story. It's also wrong in a way that's hard to explain to anyone who hasn't sat in the chair. Yes, the blank-file problem is mostly solved. Boilerplate, scaffolding, the first rough pass at a function, all of that is faster than it's ever been. The problem is "writing the lines" was never the expensive part of this job. The expensive part was always judgment. Knowing what to build, knowing why it breaks, knowing which of the model's three confident suggestions is the one that quietly corrupts your data at 2 AM is where the engineer earns their salt. AI didn't remove that work. It buried it under a pile of plausible-looking output you now have to review, verify, and own. So the meter didn't slow down. It moved. You spend less time typing and far more time deciding, validating, and cleaning up. To everyone watching from outside, that looks like less work. From inside, it's a heavier cognitive load on a shorter clock. Sound familiar? The Treadmill Nobody Put On the Job Description The cost no one talks about is the half-life of what you know is collapsing. Five years ago you could learn a framework and ride it for a few years. Now a tool you mastered in January has three competitors and a new paradigm by June. New model, new c

I joined a team where the controller was 800 lines long, the business rules were scattered between the controller and the DbContext , and "to run the tests, spin up a SQL Server in Docker" was a sentence I heard every week. The fix was Clean Architecture. The argument I had with the team lead was about how to actually structure it. We argued for two weeks. Then I built this template so the next person wouldn't have to. This is the Clean Architecture .NET 8 starter template I wish someone had handed me on day one. Four projects, strict dependency direction, domain entities that own their own invariants, and an Application layer you can unit test with Moq — no database required. The whole repo is on GitHub , MIT-licensed, runs with dotnet run , and ships with xUnit tests, JWT auth, Swagger, Docker, and CI. This post is the explanation of why each project exists, what goes in it, and what I learned the hard way about getting Clean Architecture right in .NET. The problem Clean Architecture solves The naive way to build a .NET Web API is one project, one folder structure, and "everything talks to everything": MyApp/ Controllers/ ProductsController.cs ← HTTP stuff OrdersController.cs ← HTTP stuff + business rules Services/ ProductService.cs ← business rules + DbContext.SaveChanges Data/ AppDbContext.cs ← EF Core, entities Models/ Product.cs ← POCO with public setters This works for the first 1,000 lines. By 5,000 lines, the controller is doing five things at once. By 10,000, "to test this, I need a database" is the answer to every test question, and your CI takes 20 minutes because every test run spins up SQL Server. Clean Architecture says: separate the business rules from the HTTP boundary, separate the database from the business rules, and enforce it with project references. A controller is allowed to call a service. A service is allowed to call a repository. A repository is allowed to know about EF Core. Nothing is allowed to know about anything "above" it in the chai

I had used LangChain's RAG chain in production for six months. I could not have told you, off the top of my head, what chunk_overlap did, or why cosine similarity is the right distance metric, or how nomic-embed-text actually turns a sentence into a vector. The high-level library abstracted all of it away. So one weekend I deleted the LangChain dependency and wrote a RAG pipeline from scratch in ~500 lines of plain Python. No framework, no magic. pypdf for text extraction. A 60-line chunker. ChromaDB for the vector store. Ollama for embeddings and the LLM. The whole thing is on GitHub — every module is under 200 lines, every test is deterministic, and you can read the whole thing in one sitting. This is the build log. Not a tutorial — the build log, with the parts that surprised me and the parts I got wrong the first time. Why bother The honest reason: I was using LangChain's RetrievalQA chain and getting answers I didn't trust. Sometimes the model would say "according to the document" when the document didn't say that. Sometimes the citations were wrong. I had no way to know if the chunker was dropping important context, or if the cosine similarity was picking the wrong neighbors, or if the prompt was actually constraining the model. The library was a black box. When you build it yourself, every layer is inspectable. When the answer is wrong, you can add a print statement in pipeline.py line 102 and see exactly which chunks were sent to the LLM. When the chunker cuts a sentence in half, you see it in the test fixtures. When the embedding model gives garbage for some inputs, you can swap in a different model with one constructor parameter. None of that is possible when the whole thing is RetrievalQA.from_chain_type(llm=..., retriever=...) . The other reason: the code I wrote is 500 lines, and it covers the same ground as a 50-line LangChain script. The extra 450 lines are comments, type hints, tests, and explicit error handling. That's the actual complexity. LangCha

I uploaded a 40-page PDF of an internal API spec, asked "what's the rate limit for the search endpoint?", and got back: "100 requests per minute per API key, with bursts up to 200. See section 4.2 of the document." With citations. In about three seconds. The whole stack runs on my laptop. It cost me $0 in LLM credits during development because Ollama is free and local, and the embedder I used is also free and local. The repo is here — issues and PRs welcome. This is the build log. Not a tutorial where every step works the first time — a build log where I tell you which decisions held up and which ones I redid. The problem most "chat with your PDF" demos have Every "chat with your PDF" tutorial I read in early 2025 had the same shape: open OpenAI, paste your API key, call gpt-4 with a 50-page PDF stuffed into the context window, get an answer, pay $0.03 per question, repeat. That works for a demo. It does not work for a tool you'd actually use at work, because: The PDF might contain customer data, internal pricing, or unreleased features. You do not want that going to OpenAI's training pipeline or anyone's logs. The cost adds up. If your team uses it 50 times a day, that's $45/month per seat. The model hallucinates on long PDFs anyway. Stuff 100 pages into a 128k context window and the model starts forgetting the middle. The fix is RAG (Retrieval-Augmented Generation) — don't send the whole PDF, send only the 3-5 chunks that are actually relevant to the question. The rest of the work is the same: embed the chunks, embed the question, find the closest matches, send those to the LLM with the question. But the cost and the privacy story both improve by 100x. The actual ask: Upload a PDF. Ask questions. Get answers from the document with citations, in under 5 seconds, with no data leaving my laptop and no monthly bill. The architecture One .NET 8 solution, one React app, one Ollama process, zero cloud dependencies. [ PDF Upload ] | v +-------------------+ chunks +-------

Everyone is asking whether AI can write code. That question is already answered. The more important question is: Can AI understand the system it is changing? The biggest limitation of AI coding tools isn't code generation. It's system understanding. That is no longer the interesting question. AI can already generate APIs, tests, database migrations, infrastructure files, and entire services. The better question is: Does your AI understand the system it is changing? For most engineering teams, the answer is no. And that is where many AI-assisted workflows quietly fail. The illusion of understanding Ask an AI assistant to: create a new endpoint add a background worker generate a service layer write a migration Most models will produce something that looks correct. The code compiles. The tests may even pass. But production systems are not collections of files. They are collections of relationships. The real questions are: Which service owns this capability? Which projects depend on it? Which runtime executes it? Which release gates are affected? Which verification steps must pass? What breaks if this change is wrong? These questions are rarely visible in source code. They exist in architecture, operational knowledge, deployment rules, contracts, and team conventions. That is why an AI agent can generate valid code and still make the wrong change. Bigger context windows won't solve this The common response is: Give the model more context. But more context is not the same as better context. A million tokens of source code still do not explicitly answer: What projects exist? Which commands are safe? What evidence is trusted? What is currently blocked? What is ready for release? The issue is not missing tokens. The issue is missing structure. The missing layer Most AI tools understand: files functions repositories Production systems require understanding: ownership architecture dependencies operational boundaries verification requirements change impact This is the gap betw

Last Tuesday my API gateway caught a NullReferenceException , streamed it to a dashboard in real-time, and pushed a draft code fix to the browser tab of the on-call engineer — before I finished reading the error myself. That sentence used to be vendor marketing. Now it's just my Program.cs . This is the architecture post-mortem. I built it on weekends. It runs in Docker. It cost me exactly $0 in LLM credits during development because Groq's free tier is generous and Ollama works as a swap-in. The repo is here — issues and PRs welcome. The problem most .NET teams have Production errors are caught, logged to a file, and forgotten. Engineers find out from a Slack ping twenty minutes later, if at all. By the time someone looks, the original request context is gone, the user's session has expired, and the stack trace is buried four layers deep in System.* calls. "Self-healing" is a word vendors use to mean "auto-restart the pod." I wanted something better. The actual ask: When an exception is thrown in service A, give the engineer (a) a clear root cause, (b) a suggested fix, and (c) a draft code patch — in under 30 seconds. Not a magic black box. Not an auto-applied patch. Just: catch the error, give the model the right context, push the analysis to a human in real-time, and let the human close the loop. The architecture One .NET solution, four projects, four NuGet packages, no new infrastructure beyond what you probably already have. [ HTTP request ] | v +-------------------+ enqueue +---------------------+ | SmartLogAnalyzer. | ---------------------> | Hangfire (Redis) | | Api | +----------+----------+ | (ErrorHandling | | | Middleware) | v +-------------------+ +---------------------+ | SmartLogAnalyzer. | | Worker | | (ErrorProcessingWorker) +-----+-------+-------+ | | AI call | | persist v v +-----------+ +-----------+ | Semantic | | MSSQL | | Kernel + | | (ErrorLog | | Groq LLM | | table) | +-----+-----+ +-----------+ | v +---------------------+ | SignalR Hub | | (

GitOps policy drift is what happens when a control plane keeps a policy perfectly reconciled long after the reason for that policy has stopped being true. Every commit is applied. Every pull request is merged cleanly. Every dashboard reads green. And the rule being enforced no longer reflects anything anyone would choose to enforce today — it just hasn't been told to stop. That gap is the subject of this post. Not configuration drift — the thing GitOps was built to kill — but a second, quieter failure mode that lives one layer above it: the policy is right by every technical measure and wrong by every practical one, and nothing in the reconciliation loop is capable of telling the difference. The Promise GitOps Actually Kept GitOps earned its place in the infrastructure as code architecture stack by solving a real and expensive problem: state drift. Before declarative reconciliation, infrastructure diverged from its source of truth constantly — a console change here, an emergency hotfix there, a manual override nobody logged. The git repository said one thing. Production said another. Reconciling the two was a forensic exercise. GitOps closed that gap with a simple, durable mechanism: a controller that continuously compares declared state to actual state and corrects the difference without waiting for a human to notice. That's not a small win. It's the reason platform teams can run infrastructure at a scale that would have been operationally unmanageable a decade ago, and it's why GitOps controllers sit at the center of nearly every modern infrastructure as code architecture built since. This post isn't an argument against that mechanism. It's an argument that the mechanism's success created a blind spot nobody designed for. What GitOps Never Promised to Solve Here's the boundary GitOps was never built to cross: reconciliation proves that declared state and actual state match. It says nothing about whether the declared state should still exist in its current form. A

In this article, the author explores data poisoning as a threat to machine learning systems, covering techniques such as label flipping, backdoors, clean-label poisoning, and gradient manipulation. The article reviews real-world incidents, discusses the challenges of detecting poisoned data, and presents practical defenses, tools, and operational practices for securing ML training pipelines. By Igor Maljkovic

AI makes us faster, but does it make us better engineers, or just more dependent? As a follow-up...

This is an adapted English version of an article I first wrote in Japanese. I work with AI to shape and review my drafts, but the argument and the field observations are my own. The numbers are cited from public surveys (linked at the end). I built an aggressive prompt-injection block to stop my AI agent from repeating the same mistakes. It worked, so I kept adding rules. By the time I noticed, the file had ballooned to 56,000 characters — and the agent had quietly stopped functioning. Too much context, attention spread too thin to act on any of it. I gutted it back to under 1,200 characters, and here's the part that still stings: it behaved better with fewer rules. That was the day I learned my whole mental model was backwards. This isn't a post about making your AI more accurate. It's about designing so that accuracy stops being the thing you depend on. The mistake I made for months My agent kept skipping the same step in a workflow. So I did what every engineer does on instinct: I added a rule. "Don't skip this step." Then it did something else dumb, so I added another rule. Then another. I was treating the rules file like a conversation with a colleague — as if the agent would remember yesterday's correction and carry it forward. It doesn't. Every run starts cold. "Be careful next time" assumes a next time that shares state with this time. For a stateless model, there is no continuity to appeal to. You are talking to a counterparty with no memory of the conversation you think you're having. So the rules pile up, because each correction feels like progress. And for a while the numbers even improve. But adding rules has a ceiling, and I blew straight through it: at 56,000 characters the agent wasn't reasoning over my guardrails anymore — it was drowning in them. Knowing a rule and stopping at it are different things Here's the distinction that took me far too long to see. Putting a rule in the context window means the model knows the rule. It does not mean the mod

Originally published on Mohamad Alsabbagh's Blog . AI coding assistants are excellent at compressing known work into fast drafts. That speed is the preface boost : routine implementation arrives almost immediately. The hidden risk is that teams begin treating the model's first plausible answer as architecture. Because LLMs are trained and aligned around historically common patterns, they can pull engineering teams toward Generative Monoculture : less diverse solutions, narrower exploration, and fewer designs shaped by the exceptional constraints of the system in front of them. Give the same prompt to three engineers using the same assistant and you often get the same shape back: a tidy service layer, a familiar API boundary, a conventional retry wrapper, and code that looks clean enough to merge. That answer is useful. It may even be the right answer for ordinary work. The danger is what happens when ordinary work becomes the default posture for extraordinary constraints. Large Language Models are not neutral architecture engines. They are probabilistic systems trained over historical work and tuned toward answers people tend to reward. Used well, that makes them extraordinary accelerators. Used passively, it creates an optimization paradox: teams gain immediate implementation velocity while becoming anchored to a consensus baseline that may be too average for the actual system. 1. The Default Is a Local Optimum Wu, Black, and Chandrasekaran define Generative Monoculture as a narrowing of model output diversity relative to the diversity available in the training data. That matters because software architecture is rarely a search for the most common answer. It is a search for the answer that fits the exact failure modes, latency envelope, team topology, regulatory constraints, and operational reality of a system. The model's default is often a local optimum: a solution that is statistically likely, syntactically polished, and broadly acceptable. That can be excellent

Most engineering reading lists are optimized for knowledge accumulation. Modern engineering rewards bottleneck elimination. Last week, a junior engineer showed me a "Top 10 Books Every Engineer Should Read" list. It looked almost identical to the lists I saw ten years ago. The same classics. The same process books. The same assumption: Read enough books and you'll become a better engineer. That's not how most high-performing teams learn. The best engineers I know don't build learning plans around books. They build learning plans around constraints. The Problem with standard reading lists Most reading lists assume that knowledge is universally valuable. In practice, engineering value is highly contextual. A backend engineer struggling with database contention does not need another chapter on Agile. A team spending thousands of dollars per month on LLM inference does not need a generic software craftsmanship book. A startup fighting latency issues does not need a leadership framework. They need solutions to the bottleneck directly in front of them. Reading lists rarely account for this. They optimize for completeness. Engineering rewards relevance. The Shift Most Engineers Miss The fundamentals still matter. Distributed systems matter. Databases matter. Networking matters. Operating systems matter. They are not obsolete. But they are no longer sufficient. Modern systems introduce constraints that barely existed a few years ago: AI inference costs Context window limitations Agent orchestration Evaluation pipelines Semantic caching Non-deterministic workflows Model routing Human-in-the-loop systems Many traditional reading lists never touch these problems. Yet these are exactly the problems teams are solving every day. The challenge is no longer simply writing correct software. The challenge is building reliable systems on top of components that are inherently probabilistic. What Changed For decades, engineers mostly worked with deterministic systems. Given the same inp

Working with AI Means Thinking More, Not Less Yes, this text is long. Yes, it repeats itself in places. I did not clean that up. A text that sounded too smooth while arguing that AI forces you to think more, not less, would be at least slightly dishonest. This is not fast food for quick consumption. And yes, don’t worry: you won’t hear anything especially new here. That is part of the problem too. There is a popular and very seductive story about AI in software development. Now that the machine can write code, the human gets to think less. You just point it in the right direction, and the model will quickly and cheaply do a significant part of the work on its own. In that picture, AI is primarily an accelerator for code production, and human thinking gradually shifts from necessity to optional extra. I keep feeling more and more strongly that this description is dangerously wrong. A more accurate formula for my own experience right now is this: I’m the tech lead, the AI is the entire team in one body . And if you take that metaphor seriously, the conclusion is the exact opposite of the mainstream narrative. Working with AI is not a way to think less. It is a mode in which you need to think more, not less . Not because the AI is bad. But because it is too good at one very treacherous thing: it confidently and smoothly fills in what was left unsaid. I’m the tech lead, the AI is the team At first this metaphor felt like a neat formulation. Now it feels like a literal description of what is going on. If you treat AI as a very fast and very capable executor, a lot of things become clearer immediately. It really can wipe out months of routine work. It can spin up prototypes quickly, take over test scaffolding, try out alternatives, make local edits, help break a task into parts, and sometimes even suggest a decent direction. On the surface, this really does look like a silver bullet. Especially if the human knows the stack and can read code. The pace becomes so extreme th

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

A working prompt library is the main event, not an appendix. The industry still treats prompts as some half-baked spitball left in a README, or, worse, a plaintext blob stapled to package.json and forgotten. That's a waste of compute and credibility. What powers reliable AI-assisted refactoring, onboarding, or even next-gen code IDEs is not the size of the model but the clarity and context supplied by the actual, shipped prompt set. OTF kits turn this lesson into a repeatable deliverable: every paid template includes 20+ production-tested prompts tied to the real file structure, component API, and product-specific conventions. This is not a suggestion; it's structural. The takeaway: a real prompt library is as important as your component library. Treat it like one. Start with the pain: why blank chat boxes don't scale The web is full of “integrations” that paste a blank chat input over your codebase and call it an “AI coding assistant.” The result: hallucinated function names, invented conventions, broken import paths. Here’s what happens in real life: Dev: "Add a social login button." AI (blank prompt): "Sure! Insert <SocialLoginButton> in your LoginScreen.js." Dev: (There’s no such component. There's not even a LoginScreen.js.) Short: A generic prompt with zero context simply can't know your conventions, files, or patterns. The agent will either fail, hallucinate, or pepper you with clarifying questions you have already answered in your product architecture. Takeaway: Prompting without context is coding without types — fragile guesses instead of structured outcomes. What a first-class prompt library enables When the prompt library ships with the codebase, it looks like this: Every prompt knows the folder structure (e.g., features/auth , screens/Settings/index.tsx ). Conventions are hard-coded: naming, import styles, design token usage. Endpoints and integration points (e.g., “update the Stripe webhook handler in api/webhooks/stripe.ts ”) are spelled out. The promp

Most agents drag their entire past into every turn. A better default: keep a thin index of what was said hot, and fetch only the few turns you actually need — intact, on demand. Code: github.com/NirajPandey05/jit_context There is a quiet assumption baked into how most agents handle memory: that more context is safer than less. If the model might need something, put it in the window. The conversation grows, every prior turn rides along on every new request, and we trust the model to find the part that matters. That assumption breaks twice. It breaks on cost , because an agent loop re-sends its whole window on every step — a hundred stale turns aren't paid for once, they're paid for on turn 101, 102, and every step after. And it breaks on quality , because models don't read a long window evenly. Relevant facts buried in the middle get underweighted; irrelevant bulk competes for attention with the thing that actually answers the question. Past a point, a bigger context produces a worse answer, not just a costlier one. So the interesting question isn't "how do we fit more in?" It's "how do we keep the window small and dense without losing the one old turn that matters?" This post is the design we built around that question — for the specific case of long conversation history — plus the benchmark we used to keep ourselves honest. 01 · The mechanism: a hot index over a cold store The design borrows directly from how computers have always managed memory that doesn't fit: a small fast tier that's always present, a large slow tier that holds the bulk, and a rule for moving things between them. Virtual memory pages between RAM and disk. We page between the context window and an external store — for attention instead of address space. Concretely, there are two tiers. The cold store holds every turn at full fidelity, keyed by id — nothing is thrown away. The hot index holds one compact entry per turn: a short summary, a little metadata (entities, whether the turn recorded a dec

A few months ago, I was overwhelmed by everything happening in AI. Every week there was a new coding assistant, a new workflow, or someone claiming they built an app in just a few hours. It felt like if you weren't keeping up, you'd be left behind. I tried almost everything. Cursor. ChatGPT. Claude Code. Lovable. At first, I kept switching between tools, hoping one of them would magically make me a better developer. It didn't. The biggest lesson I learned wasn't about choosing the best AI tool. It was learning how to work with AI. These days, I don't start by asking AI to write code. I start by explaining the problem. I describe the feature, the business requirements, the edge cases, and what I want the final result to look like. Sometimes I ask ChatGPT to help me plan the implementation first. Once everything is clear, I pass that plan to an agentic coding assistant and start building. That one change made a huge difference. I spend less time writing boilerplate and more time thinking about architecture, user experience, and solving the actual problem. AI still gets things wrong, so I review everything before it goes into production. But instead of writing every single line myself, I'm guiding the process. Looking back, the first few months were the hardest. Now it just feels normal. The tools will keep changing, but I think the real skill is learning how to communicate with AI and use it as part of your development process. That's something worth investing in.

OpenAI’s Bonnie Xu discusses Kepler, an internal AI data analyst agent built to query 600+ petabytes of data. She explains how they overcome context window limits using MCP, automated code crawling, and RAG. Xu also shares how their team leverages scoped semantic memory for self-learning and utilizes AST-based LLM grading to build a robust, regression-free evaluation pipeline. By Bonnie Xu

CircleCI has launched Chunk Sidecars, a new capability designed to bring CI-style validation directly into an AI coding agent's inner development loop By Craig Risi

In a new Windows Developer Blog post titled "Windows platform security for AI agents", Microsoft positions Windows as the trustworthy operating system for autonomous agents and introduces the Microsoft Execution Containers (MXC) SDK as the core of that strategy. The post argues that containment, identity and manageability must be built into the operating system. By Matt Saunders