标签：#engineering

You do not have a camera. You have a machine that dreams a short motion out of a single still image, and it dreams badly the moment you ask it for something the still does not already contain. I learned this across a 10-episode series, and every rule below was paid for in failed generations. None of it is theory. The medium's real physics A real camera moves through a space that exists whether or not you point at it. The model has no space. It has one flat image and a statistical guess about what "zoom out" tends to look like in its training data. When the frame widens, the model is not revealing more of a room that was always there. It is inventing pixels to fill the new area, drawn from everything it has ever seen. That single fact reorganizes everything you know about directing: There is no coverage. Every "angle" is a separate generation from a separate still. Continuity is not captured; it is engineered, frame by frame. Nothing survives the cut for free. The model does not know that shot 12 and shot 13 are the same character in the same room. Anything you want to persist (damage state, light, color) must be re-declared or re-anchored every single time. The model abhors an empty frame. Its deepest reflex is to resolve ambiguity: a silhouette becomes a face, fog becomes a mountain range, a clean retro interior grows drips and cobwebs because "analog" reads as "abandoned". Spawn pressure is constant. Background figures flicker into existence in any populated-looking scene. Every motion prompt in my pipeline ends with an anti-spawn guard: "Do not add extra characters. Keep everything as pictured." Drop that guard and the figures come back. A widening or traveling frame is an invitation for the model to hallucinate. Direct this camera and you are not choosing what to show. You are choosing what to withhold from its imagination. The classical grammar, re-pointed If you carry film vocabulary, it all still applies. The mechanism just changes completely. Classical tool

For a long time, whenever we hear 'User Experience', we instinctively think of UI/UX designers, product designers, or maybe frontend engineers. Why? Because we tend to think users interact first with a graphical or command-line interface, while the backend engine plays little to no role in how they experience the product. The first half is correct. The second half, incorrect. A user doesn't experience your frontend in isolation. They experience the entire system. As I continue to compound my experience building products as a backend-leaning engineer, I've found it increasingly necessary to think beyond whether an endpoint works or whether an architecture is technically sound. I have to ask: How does this technical decision affect the user's experience? Here's how. 1. API Response Times Become UX A user doesn't care that your endpoint executes 17 database queries, that your service is making five downstream requests, or that your server is experiencing a cold start. They care that they clicked “Pay” three seconds ago and nothing has happened. Eventually, they may refresh the page, click the button again, or abandon the application altogether. The frontend can add a beautiful loading animation, but it cannot completely hide a system that is fundamentally slow. 2. Error Messages Become UX One of the easiest ways to see the relationship between backend engineering and UX is through errors. Imagine trying to make a payment and receiving: 400 Bad Request Technically, something has gone wrong. But the user has learned almost nothing. Compare that with: “Your payment could not be completed because your card was declined. Please try another payment method.” Good backend error handling should therefore answer three questions: What happened? Why did it happen? What can the user do about it? 3. API Design Becomes UX API design can feel very far removed from UX. After all, users don't see JSON responses. But, developers build products using those responses. The decisions we make

Have you ever stopped to think about the risk of having a pipeline where any merge into the main branch deploys straight to production without a single safety gate? For a long time, our workflow here was that classic setup almost every developer has used at some point: merge on main triggering an SSH script with git pull and pm2 restart It worked for day-to-day tasks, but it gave a false sense of stability lol The reality check hit when I found a critical blind spot in the automation: remote SSH scripts were running without strict error handling. In other words, if a git pull caused a conflict or a database migration failed halfway through, the script simply ignored the failure, ran to the end, and GitHub Actions marked the pipeline as green The absolute worst-case scenario for monitoring: the pipeline reported that everything went smoothly, while production was already completely down On top of that, the execution order was inverted: database migrations were running before the application build. If TypeScript threw a type error right after, the database schema had already advanced while the new code never booted. And since Prisma has no native down migrations, rolling back meant a high-risk manual intervention I decided to stop everything and redesign our delivery pipeline from scratch, starting from one clear premise: a tag is a release, a merge is not Today, nothing touches the production server without an annotated SemVer tag, going through 6 tightly coupled stages: Strict tag validation: only accepts annotated tags matching vX.Y.Z, ensuring author, timestamp, and audit trail for every single release Quality gates across PR and Release: automated tests with Vitest, strict typechecking, builds, and migration validation against a clean database via workflow_call Decoupled backups: an independent daily scheduled routine combined with a mandatory safety snapshot right before touching production Real migration dry-run: the most valuable gate, where the pipeline resto

Ian Nowland discusses why conventional CI/CD practices break down for stateful, core infrastructure. Drawing from his leadership at AWS and Datadog, he shares actionable techniques for safe progressive deployments, synthetic testing in production, and mitigating blast radius in complex software platforms. By Ian Nowland

Data has become one of the most valuable assets for modern enterprises, powering everything from business intelligence dashboards to machine learning models and generative AI applications. However, the biggest challenge organizations face today is not collecting data — it is trusting it. Enterprise data often contains duplicate records, missing values, inconsistent schemas, outdated information, and inaccurate entries that silently reduce the quality of analytics and AI predictions. These hidden data quality issues can lead to poor business decisions, increased operational costs, compliance risks, and unreliable AI outcomes. While most organizations implement basic validation rules, traditional data quality frameworks are largely rule-based, difficult to maintain, and unable to detect complex anomalies that continuously evolve across modern cloud data platforms. This article introduces the Data Trust Score Engine, an AI-powered cloud-native solution designed to automatically measure and improve enterprise data reliability. Instead of relying solely on manual validation or predefined rules, the platform combines metadata intelligence, large-scale analytics, and machine learning to calculate a dynamic Trust Score (0–100) for every dataset. The score is generated by evaluating multiple quality dimensions, including data completeness, consistency, uniqueness, freshness, schema compliance, null-value distribution, statistical anomalies, and AI-detected outliers. As a result, organizations can quickly identify fake, duplicate, corrupted, or low-quality datasets before they impact reporting, business intelligence, or downstream AI models. Learn about Medium’s values The solution is built entirely on Google Cloud Platform (GCP) using BigQuery as the scalable analytical data warehouse, Data Catalog for centralized metadata management and governance, and Vertex AI for intelligent anomaly detection and predictive quality analysis. BigQuery processes billions of records efficie

AI coding agent Cursor has launched Origin, a git based code hosting platform embedded inside its AI-powered editor, positioning it as an alternative to GitHub for teams that already work in Cursor. Origin is rolling out in early beta on Pro, Teams and Enterprise plans, and lives inside a new Codebase tab within the Cursor application. By Matt Saunders

Jalapeño is a custom inference chip from OpenAI that delivers faster, more power-efficient AI inference, with higher throughput and lower latency for modern models.

Building a working tender documentation system for yourself is one project. Turning that same system into a template the rest of the team can pick up and use correctly, without needing to ask you what a particular instruction actually means, is a completely different project wearing the same clothes. The Gap Between Personal Use And Handoff A prompt template that only you use can carry a lot of implicit knowledge safely, because the missing context lives in your head and gets filled in automatically every time you run it. An instruction that says something like ensure the response addresses compliance requirements directly means something very specific to the person who wrote it, shaped by dozens of past examples of what counting as directly actually looks like in practice. That same instruction, handed to someone on the team who was not present for any of those past examples, is just as likely to be interpreted in a way that is defensible on its own terms and still wrong relative to what was actually meant. The template worked perfectly for months before it needed to be handed off, which made the gap invisible until the moment it actually mattered. The first time someone else on the team ran it independently and produced a response that technically followed the instructions but missed the actual intent behind them, the problem was not that the instructions were poorly written in any obvious sense. It was that they had been written for an audience of one, and that audience had context nobody else on the team had access to. What Actually Needs To Be In A Handoff Ready Template Fixing this meant rewriting a significant portion of the template with a different question in mind at every step, not does this instruction produce the right output when I run it, but does this instruction contain enough of the reasoning behind it that someone without my accumulated context could apply it correctly to a new tender they have never seen before. That meant replacing instructions

Building a custom GPT for one ministry client teaches you something specific about that ministry. Building the third or fourth one for a different government or enterprise client teaches you something much harder, which is how much of what worked the first time was actually general, and how much of it only worked because it happened to fit that particular institution. The Temptation That Causes The Most Damage After the first successful deployment, the obvious next move is treating that system prompt as a proven template and adapting it lightly for the next client. Swap the knowledge base, adjust a few tone instructions, change the scope boundaries to match the new domain, and ship it faster than building from scratch. That instinct is not wrong exactly, but acting on it without first separating what was actually general from what was incidentally specific to the first client produces a second deployment that quietly inherits assumptions nobody meant to carry forward. The clearest example of this showed up around scope boundary language. The refusal and redirection instructions built for the first ministry deployment had been carefully tuned against that specific institution's culture, a fairly formal, procedurally strict environment where a firm, precise boundary read as competent and appropriate. Carrying that same boundary language into a private enterprise deployment, where the internal culture was considerably less formal and staff expected a more conversational tone even when the bot was declining to answer something outside its scope, produced a tool that technically enforced the correct scope but felt oddly cold and bureaucratic to an audience that had no institutional reason to expect that register. Nothing about that was a bug in the traditional sense. The logic was sound, the boundary was correctly enforced, and it still felt wrong, because the tone calibration underneath the logic had been implicitly trained against one specific institutional culture and

In the professional world—especially in high-stakes tech environments—we are conditioned to believe that career advancement is a direct result of having the right answers. From the moment we step into our first junior role, we feel the pressure to be the "smartest person in the room." We equate confidence with certainty and value with the ability to provide instant solutions. But after years of working with founders, engineering leaders, and product builders, I have discovered a fundamental truth: The most valuable professionals are not the ones with all the answers. They are the ones asking the right questions. The Trap of the "Answer-First" Mindset When you focus solely on providing answers, you inadvertently limit your scope. You become a bottleneck. You are only as capable as your own knowledge base, and you discourage those around you from thinking critically. This "answer-first" culture often leads to: Superficial Solutions: You solve the symptoms, not the root cause, because you didn't take the time to explore the underlying complexity. Stifled Innovation: When leaders provide all the answers, team members stop proposing ideas. They wait for instructions rather than taking ownership. Fragile Trust: People trust those who are curious and transparent about what they don't know far more than those who bluff their way through uncertainty. Shifting to Inquiry-Led Growth Moving from an "answer-first" mindset to an "inquiry-led" mindset is not just a soft skill; it is a tactical advantage. When you shift your focus to understanding the problem, the entire dynamic of your work changes. 1. From Directive to Generative Instead of telling a developer how to implement a feature, ask, "What are the trade-offs of this approach compared to X?" This forces the engineer to think through the architecture, improving their skills while often revealing a better solution you hadn't considered. 2. Building Psychological Safety When you ask, "What am I missing here?" or "What does t

Originally published on hexisteme notes . I built a YouTube upload stage for a video pipeline, and the flow looked clean enough on paper: start a resumable session, PUT the file, get back a video ID, verify the upload actually landed the way it was supposed to, then write a local record marking the episode as uploaded. Four steps, each one depending on the last. It was the dependency between the last two that turned out to be the problem. The sequence, and where it breaks Verification here means re-querying the video through videos.list after the upload finishes, to confirm the visibility wasn't silently demoted, the upload wasn't rejected, and the metadata actually propagated. That's a reasonable thing to check — YouTube's upload API can report success at the transport layer while the platform-side processing does something you didn't ask for. But if that verification call raises, the exception propagates straight up, and the local record — a JSON file I'll call upload.json — never gets written. Not "gets written with an error flag." Never written, period. By the time that exception fires, though, the video already exists on YouTube. The PUT succeeded. The video ID is real. There's a public (or not-quite-public) video sitting on the channel, and there is exactly nothing on disk that knows about it. Run the same command again after that, and the guard that's supposed to answer "have I already uploaded this?" — a check for whether upload.json exists — sails right through, because it doesn't exist. The result isn't a retry. It's a second, completely independent upload of the same video. What "retries don't duplicate" actually meant The module's docstring said retries don't create duplicate videos. That line wasn't wrong, exactly — it was scoped narrower than it read. It was true for retries inside the low-level file-PUT function, which reuses the same resumable session URI on retry, so transport-layer hiccups during the upload itself are genuinely safe to retry. What

We built a plugin for the GitHub Accessibility Scanner to make sure your alt text is actually accessible. Here's how it works. The post Your alt text passes automated checks. That doesn’t mean it’s any good. appeared first on The GitHub Blog .

As C++ codebases scale, housing utility routines, state management, and primary execution logic inside a single main.cpp file inevitably leads to technical debt. Code duplication increases, compilation times degrade, and testing isolated features becomes virtually impossible. Modular architecture solves this problem by enforcing a strict separation of concerns. By decoupling function declarations from their definitions and compiling utility modules into reusable static libraries, developers can achieve clean abstraction boundaries, simplify unit testing, and eliminate memory corruption vulnerabilities associated with unvalidated inputs. In this tutorial, you will learn how to build a production-grade C++ utility module from scratch, complete with boundary guards and static compilation. Prerequisites Before diving in, ensure you have: A modern C++ compiler supporting C++17 or higher (GCC, Clang, or MSVC). Basic familiarity with header files ( .h ) and translation units ( .cpp ). A Code Editor or IDE such as Visual Studio Code or Visual Studio . Project Structure To keep boundaries clean, we structure our workspace by isolating public headers from implementation units: text ModularCppLib/ ├── include/ │ ├── ArrayUtils.h │ └── ValidationUtils.h ├── src/ │ ├── ArrayUtils.cpp │ └── ValidationUtils.cpp ├── main.cpp └── README.md Phase 1: Structural Abstraction and Memory-Safe API Design Separating Interfaces from Translation Units In production C++ engineering, headers ( .h ) serve as explicit architectural contracts. They declare what operations are available without leaking how those operations are executed. All utility routines are scoped inside the explicit CoreUtils namespace to prevent global namespace pollution: namespace CoreUtils { // Contract: Accepts array pointer and length, // returns calculated mean safely double CalculateAverage ( const int * arr , std :: size_t size ); // Formats and prints array content void PrintArray ( const int * arr , std :: size_t si

AI coding agents are getting better at writing code. But I think we are approaching a more difficult question: How do we know that an AI agent made the right engineering decision for the current state of a software system? Passing tests is important. But passing tests alone does not necessarily tell us whether an agent understood: the current architecture, project constraints, previous engineering decisions, repository conventions, dependency relationships, security requirements, or why an existing implementation looks the way it does. This becomes particularly important as AI systems move from generating isolated code snippets toward modifying real repositories. The Problem: Correct Code Is Not Always Correct Engineering Consider a simple example. A project initially has: Architecture v1 API ↓ Service ↓ Database An AI agent is asked to add a feature. It studies the repository, follows the existing pattern, writes the code, and all tests pass. Then the architecture changes: Architecture v2 API ↓ Event Bus ↓ Service ↓ Database The same task is requested again. If the agent still generates code based on the old architecture, the implementation may be: ✓ Valid syntax ✓ Compiles ✓ Existing tests pass ✗ Violates current architecture ✗ Ignores current constraints So we have an important distinction: Functional Correctness ≠ Contextual Correctness ≠ System-Level Correctness This is the problem I want to explore. This Is Already Becoming a Real Engineering Problem This isn't simply speculation about future AI systems. Modern coding agents already depend on repository-level context. OpenAI's documentation for Codex recommends using persistent repository instructions such as AGENTS.md for naming conventions, business logic, known quirks, dependencies, and other information that may not be inferable directly from code. It also recommends providing file paths, component names, diffs, and documentation when describing tasks. OpenAI has also described a broader approach where rep

Get ready for a bit of a ramble about looking for a job as a software engineer in 2026. No, it's not about AI changing the definition of software engineering in 2026. But there's obviously some truth in that. It's about product engineering. Specifically, it's about the challenges engineers face when searching for new opportunities because of the massive shift toward product engineering. I should preface what comes next with this: Searching for a software engineering job in 2026 is really hard. Scroll through LinkedIn or any software career blog and you'll see plenty of posts about how the recruitment system is broken, how good engineers are being ghosted, how CVs are being filtered out by AI screening for keywords. These frustrations are valid, but... you know what else is really hard in 2026? Being a software engineering recruiter. Being a software engineering hiring manager. And software engineering is about solving problems. With that said, you can't solve a problem you don't define. So to lay the foundation, I want to address some challenges I've recognised before addressing what can be done about them. The Problem Space First, the thing that's been haunting me for the last 6 months. Impact articulation . I suspect this isn't a problem that's unique to product engineering, but it's certainly one I've faced as a product engineer. Earlier this year, I completed full interview processes with two separate companies. I felt confident about both. The roles were the type of engineering I'm great at: sitting close to users, working through ambiguity and owning product areas end to end. But neither resulted in a job offer. The feedback I received was surprisingly consistent: I demonstrated strong technical execution, methodical problem-solving, clear communication and product judgement, and consistently sought to understand the "why" behind the "how". But also, I struggled to connect my product decisions to business or user outcomes. It was clear that I was a great engin

One of the biggest transitions in a software engineer’s career is moving from “How do I implement this?” to “How should we design this?” As developers, we naturally focus on writing clean code, implementing features, fixing bugs, and improving performance. But as you move toward an architect role, the questions become different: 🔹 Scalability — Will this solution work when the number of users or transactions increases 10x? 🔹 Maintainability — Can another team understand and extend this solution two years from now? 🔹 Security — Are authentication, authorization, data protection, and secrets management considered from the beginning? 🔹 Performance — Where could bottlenecks occur, and how can we identify them before they become production issues? 🔹 Resilience — What happens when a dependent service goes down? 🔹 Integration — How will this solution interact with existing enterprise systems? 🔹 Technology choices — Does the technology solve the actual business problem, or are we choosing it simply because it is popular? 🔹 Trade-offs — What are we gaining, and what are we giving up with each architectural decision? A senior developer asks: “How can I build this feature?” An architect asks: “What is the right solution for the business, technical, operational, and long-term requirements?” The most important lesson I’ve learned is that architecture is not about creating complicated diagrams or using more technologies. Good architecture is about making the right decisions at the right level , understanding trade-offs, and creating solutions that can evolve with the business. And you don't suddenly become an architect because of a designation. You gradually become one by thinking beyond your code. Java #SoftwareArchitecture #SpringBoot #Microservices #SoftwareEngineering #JavaDeveloper #TechnologyLeadership #Architect

Disclaimer Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de um vídeo do canal Dev Eficiente, apresentado por Alberto Souza. Se preferir acompanhar por vídeo, é só dar o play. Introdução O vídeo que deu origem a este texto foi gravado há quase três anos. Na época, o que me incomodava era simples de descrever: log é um tema comum no dia a dia, mas resolvido de forma artesanal. Cada pessoa da equipe decide, no momento em que escreve o código, se aquela linha merece registro, se o nível é info ou debug, e quais informações vão junto. A comparação que eu fazia era com testes automatizados. Você juntava dez pessoas para escrever testes sobre o mesmo conjunto de classes e saíam baterias completamente diferentes, com abordagens diferentes, às vezes deixando uma branch de fora. Cada pessoa tinha uma opinião sobre o que era importante, e não havia um modelo de pensamento compartilhado por trás disso. Com log eu sentia algo parecido. Como a resposta não estava clara para mim, passei uns dois dias procurando o que o mercado discutia e o que a pesquisa acadêmica tinha investigado sobre práticas de log. Reuni umas cinco ou seis referências e é isso que este post organiza: o que cada referência contribui e quais práticas dá para extrair delas. Mantive as referências e as conclusões como estavam na época. Acrescentei apenas uma seção sobre algo que mudou bastante desde a gravação e que torna esse assunto mais relevante hoje do que era então: a quantidade de código escrito com apoio de IA e a investigação de problemas feita com apoio de agentes. Por que log bem feito importa mais hoje Nos últimos anos mudou bastante quem escreve o código e, principalmente, quem investiga o problema quando ele aparece. Quando parte relevante do código é gerada com apoio de IA, a familiaridade de quem mantém aquele trecho com cada decisão tomada ali tende a ser menor. Você definiu a intenção, revisou o resultado, aprovou. Mas não construiu, linha a linha, o modelo m

📚 This is part 2 of a series. Part 1: The Origin Story Part 2: [Current Article] Part 3: Coming soon... Let me tell you about the day my crash reporting UI crashed. The Grey Screen One afternoon, my Android app's crash screen rendered all-grey. No content. No report button. Just a blank slate where the app's last line of defense should have been. The root cause? A stale file from Gradle's build cache after a major refactor. The compiled resource IDs no longer matched the packaged resource table. ViewBinding inflated the wrong layout, and a silent NullPointerException killed the crash screen itself. It was invisible in CI. It only appeared in specific rebuild scenarios. And it took hours to trace. That bug taught me something important: The fix isn't done when the patch ships. It's done when the lesson becomes automated. So I wrote a build-time task that reads the compiled class files directly, compares them against the final packaged resources, and verifies every constant matches. It runs automatically after every packaging step. You never have to remember to invoke it. That was the first of many incident-driven tools I built. The FAB That Disappeared A few weeks later, a developer tools Floating Action Button vanished from consumer apps. Debug menus inaccessible. Secure screens incorrectly enabled. Turns out, my shared library's BuildConfigUtils was reading the library's own BuildConfig —which is baked as "release" at publish time. An AAR can never know the consumer's build type. 25 files across 34 call sites were silently broken. I built a Gradle plugin that generates a SskBuildConfig object per consumer module, per variant, using AGP's onVariants callback. It registers generated source via KotlinCompile.source() —not reflection, which broke across AGP versions. It detects Android plugins by extension type, not hardcoded IDs, so it works with com.android.application , com.android.library , com.android.dynamic-feature , and any future Google plugin. Same package as

Originally published on hexisteme notes . A user complaint sent me into a caption pipeline: "the subtitles cut to two words in places where the sentence doesn't make sense." The fix I shipped for that complaint introduced a second bug, one word narrower and easy to miss, because the code that measured whether a line of text would fit reproduced an assumption about the text that the code drawing the line didn't share. Every test passed the whole time. I only found it by watching the rendered video. The bug the complaint pointed at The captioning system splits a transcript into short chunks that pop onto screen a few words at a time. The chunking function was doing fixed-size slicing — take the next N words, regardless of what came before or after. That's blind to sentence boundaries, so two unrelated sentences could land in the same chunk: loss. Today reads as one visual unit even though it's the tail of one sentence and the head of the next. The fix was a rule set, not a single tweak: hard break after terminal punctuation ( . ! ? … ) soft break at commas, semicolons, and em-dashes extend or push a chunk rather than let it end on a function word ( of , the , than , is , and about thirty others) target three words per chunk, four as a ceiling a pixel-width cap on the rendered chunk, measured against the actual caption font (Montserrat ExtraBold), with a budget of 1080 × 0.92 = 993.6px The first four rules are about where a line is allowed to break. The fifth is a physical constraint: however good the break points are, a chunk still has to fit on screen at the font size actually in use. That's the one that went wrong. What the width guard actually measured To get the pixel width of a candidate chunk, the guard rendered the chunk's text through the font and measured the result — which is the correct approach in principle, not a shortcut. Text width isn't a fixed number of pixels per character; it depends on the specific glyphs, so measuring the real string through the r

Engineers who only understand the technology, and never the business it serves, hit a ceiling early. The best ones develop commercial awareness — a real sense of how value is created, funded, and sold. Two days at 21BY72 Season 4, one of Bharat's leading startup summits — eighty-five ventures on the floor and live pitches in front of six hundred investors — was a concentrated lesson in exactly that, and I wrote about it in this reflection . Technology is a means; the business is the point It's easy, as an engineer, to treat the product as the whole world and the commercial side as someone else's problem. Sitting in a room where eighty-five ventures pitched to investors makes the truth obvious: the technology is a means to a business end, and understanding that end makes you a better engineer, not a distracted one. Watching founders pitch — being judged not on how clever the build was but on whether it solved a real problem people would pay for — reframes how you think about your own work. It pushes you to ask "who is this for and why does it matter" before "how do I build it." What the summit floor teaches an engineer Investors buy problems solved, not features built. The pitches that landed were about a real need and a credible path to meeting it — a discipline that improves engineering priorities directly. Commercial context sharpens technical decisions. When you understand the business constraints — cost, speed to market, who the customer actually is — you make better trade-offs in the architecture, not worse ones. Exposure recalibrates ambition. Being around people building real ventures at scale resets your sense of what's possible and what "serious" looks like. The takeaway The most rounded engineers I've come to admire pair technical depth with genuine commercial awareness. Spending two days inside a major startup summit, watching how businesses are pitched, funded, and built, was a deliberate investment in the half of the picture that a pure engineering educ