Nuno Bispo (aka Developer Service)

I'm Nuno Bispo, a Senior Software Engineer and Solutions Architect with 15+ years building Python systems, AI integrations, and production backends. I write for Real Python and Unstract. I build and ship hardware. I've seen what breaks in production and what doesn't. I take on a small number of advisory engagements with teams that are serious about getting their Python and AI stack right.

Good point, it is not just the model, it is the whole ecosystem around it.

True, need to captivate the user in 10 seconds 😄

Periodic evals should be done to check the drift of any AI model, even in a pinned version.

Correct. For traceability and logging purposes, log as many variables that make sense as possible. Better to all more data to analyze than lacking the crucial data.

That is a good point. Sometimes the output can be 100% accurate, but maybe the AI model run a marathon in the background to achieve. If you don't have the proper logging, you will never know.

AI systems are just like any other system. There is always trade-offs. I would always prefer reliabilty over other goals. Not everything needs a balance, sometimes being safer is better than anything else.

Software lives of boring checks, unless you want to be putting out fires all the time.

Just becausea user signup, doesn't mean he will continue. The onboarding flow of any app can be the deal breaker.

There’s a kind of engineering skill that rarely appears on a CV: knowing what not to automate. AI makes almost everything feel automatable, and the temptation is to let the model handle each new decision simply because it can. But every decision handed to a model is a decision you can no longer fully explain, test exhaustively, or guarantee. The teams I’d trust most draw that line deliberately. They let the model draft, summarise, classify, and suggest, and they keep a human or a plain piece of code in charge of anything that moves money, deletes data, or speaks to a customer in the company’s name. That isn’t timidity. It’s an honest account of where being wrong is cheap and where it isn’t. Capability will keep growing, and the line will keep moving. The skill is in knowing, at any given moment, where it currently sits, and being able to say why. #SoftwareEngineering #AI #TechLeadership #CTO #Python

The best compliment an AI agent can get in production is that nobody talks about it. No Slack threads about weird outputs, no surprise on the monthly bill, no one asking “wait, did something change”? Getting there is unglamorous work. It means defining exactly what a valid output looks like and rejecting everything else. It means running evals on every change instead of trusting a few manual tries. It means knowing what a normal day costs, so an abnormal one stands out. And it means having a rollback you’ve actually practiced. None of it makes a good demo, which is why most agent content skips it. Production AI Agents with PydanticAI is about that part of the work: the typed contracts, the evals, the observability, and the rollout discipline that turn an exciting prototype into something quietly reliable. Free sample chapters: leanpub.com/production-ai-ag… #PydanticAI #LLMOps #AIEngineering #PythonEngineering

Three things I check for scope bugs in every Python code review: 1. Any function that both reads and assigns the same name. If a variable is assigned anywhere in the function, Python treats it as local everywhere in that function. Read it too early and you get an UnboundLocalError. 2. Any lambda or inner function created inside a loop. Closures capture the variable, not its value, so every one of them sees whatever the loop variable holds when they finally run. 3. Any global or nonlocal keyword. Sometimes it's the right tool. Often it's a sign that state should be passed in explicitly or moved into a class. None of these are exotic. All of them regularly slip past reviewers who haven't internalised how Python resolves names. I wrote all of this up in a free Python Scope Guide: the LEGB rule, closures, late binding, and global vs nonlocal, with examples you can run. 🎁 Free: python-variable-scope.develo… #Python #CodeReview #SoftwareEngineering #PythonDevelopment

A pattern that quietly causes trouble in Python AI integrations is trusting whatever the model returns when it’s asked to call a tool or fill in arguments. The model proposes a function call with parameters, and the code executes it as written. That works until the model invents a field, passes an ID that doesn’t exist, or supplies a value outside the range your function was ever designed for. The fix is to treat tool arguments as untrusted input, exactly as you would data from a web form. Validate them against a strict schema before anything runs, check that referenced records actually exist and belong to the current user, and enforce limits in your own code, such as maximum amounts, allowed actions, and rate caps. If validation fails, return a clear error to the model so it can correct itself, rather than letting a malformed call reach your database or an external API. The principle is the same one that applies everywhere else in a backend: the boundary between a component you don’t control and your own systems is where the checks belong. A model is just another component on the wrong side of that boundary. #Python #AI #PydanticAI #Security #SoftwareEngineering

Your support team is spending hours on CSV imports that fail with "something went wrong". If your product lets customers upload data, you've seen this. A customer exports a spreadsheet from their old tool and imports it into yours. Row 4,812 has a date in the wrong format, so the import fails. Or worse, it succeeds and quietly loads a wrong value. The customer opens a ticket, support escalates it to an engineer, and the engineer spends an hour finding one bad cell. Multiply that by every customer onboarding. Imports are often the first thing a new customer does with your product, so they're also the first impression you make. Validating each row against a defined schema fixes most of this. The import either succeeds or returns a report listing the row number, the column, the value it found, and what it expected. Customers fix their own files. Support stops being a debugging service, and engineers stay out of the loop. The same pattern covers webhooks, partner feeds, and any other data that arrives from outside your control. You can't clean up other people's data, but you can tell them exactly what to fix. Practical Pydantic covers how to build this kind of validation for Python systems, including error reporting your users can act on. 👉 leanpub.com/practical-pydant… #EngineeringLeadership #SaaS #ProductEngineering #DataQuality #Python

You don’t need a VPS to run a script once an hour. You probably already have a scheduler, a clean Linux machine, and a secrets store sitting in your GitHub account. A lot of side projects need the same small thing: run a script on a schedule. Pull some data from an API every hour. Render a chart every morning. Ping a service every five minutes. The usual answer is a $5 VPS with a crontab, and that works, until you have to patch it, monitor it, and remember what you installed on it two years ago. GitHub Actions can do the same job with no server to maintain. A scheduled workflow gives you a fresh Ubuntu machine on a cron schedule, with Python preinstalled, encrypted secrets, logs, and failure notifications. For public repositories it is free, and for private ones the free allowance goes further than you might expect. In this article, you’ll build two real examples: - A data collection job that fetches readings from an API and stores them in a cloud Postgres database. - A dashboard renderer that draws a chart as a 1-bit image sized for an e-ink screen, which a small ESP32 device downloads whenever it wakes up. developer-service.blog/stop-… #Python #GitHub #Workflow #VPS #Neon #Postgres

A useful question for any team running an AI feature is what happens to the system when its owner is unavailable for a week. Not gone, just unavailable: on holiday, ill, or pulled onto another project. In many teams the honest answer is that small problems wait, changes freeze, and everyone hopes nothing breaks until that person is back. The feature is running, but it is effectively unsupervised. That isn’t a staffing failure so much as a design one. Systems that depend on one person’s memory tend to have no runbook, no documented fallback, and alerts that go to a single inbox. The risk stays invisible while things are calm, then shows up all at once on the one week it matters, usually at the least convenient moment. If your AI feature has a single point of failure with a name and a calendar, it’s worth fixing that before the calendar decides for you. #AI #CTO #TechLeadership #SoftwareEngineering #Python

That is true. Yes, you should monitor cost per request as a SLI.

Experienced engineers tend to get quieter about certainty over time. Early in a career, confidence comes from knowing the answer. Later, it comes from knowing how often your own answers have been wrong, and building habits that catch the misses before anyone else does. That shift matters more with AI systems than with conventional software, because the failure modes are less obvious and the feedback is slower. A system can look fine for weeks while quietly drifting from what you intended. The engineers who handle this well aren’t the most certain ones. They’re the ones who’ve learned to treat “it seems fine” as a hypothesis rather than a conclusion. If I could change one thing about how teams ship AI features, it would be replacing “are we sure this works?” with “how would we know if it stopped?” The second question has an answer you can actually build. 🔍 If you don’t have a good answer to that second question yet, that’s a conversation worth having => developer-service.blog/work-… #SoftwareEngineering #AI #TechLeadership #CTO #Python

An AI agent looks like a chat interface, but operationally it behaves like a distributed system. It depends on a remote service you don’t control. It has variable latency and occasional timeouts. It retries on failure, sometimes in ways that multiply cost. And it can return something that looks like success while being subtly wrong. Engineers already know how to handle that: contracts at the boundaries, tests that catch regressions, budgets and alerts, staged rollouts, and a plan for when things degrade. What’s missing is applying those habits to agents, because most agent tutorials stop at the point where the model returns a response. Production AI Agents with PydanticAI picks up where those tutorials end. You build a GitHub issue triage assistant and give it the same treatment as any service you’d put on call: typed output contracts, eval suites in CI, cost and latency observability, canary rollouts, and a runbook. Free sample chapters: leanpub.com/production-ai-ag… #PydanticAI #LLMOps #AIEngineering #PythonEngineering

True. But it is amazing the lack on proactive monitoring in Production systems. Every monitors for error messages but noboby monitors for business failures.

A question I keep getting from Python developers: "Why does my function see a variable I never passed in, but crash when I try to change it?" It's a great question, because it points at exactly how Python thinks about names. Reading a variable is easy. Python searches Local, then Enclosing, then Global, then Built-in, and uses the first match. But the moment you assign to that name inside a function, Python decides it's local for the entire function. Reach for it before the assignment and you get an UnboundLocalError, even though a perfectly good global exists. Two rules, one confusing symptom. And once you've seen it explained clearly, you can't unsee it. That's the kind of thing I cover in my free Python Scope Guide: LEGB, closures, late binding, and global vs nonlocal, with examples you can run and break yourself. 🎁 Free: python-variable-scope.develo… What's the scope bug that got you? Tell me in the comments. #Python #PythonTips #SoftwareEngineering #LearnPython