LLM coding agents moved fast from cloud demos to tools running on developer workstations. They don't just suggest code anymore. They execute it. They start shells, install packages, edit repos, run tests, and sometimes open PRs. All with the same permissions you have. In the first part of the miniseries, Jakub Bocheński will look at Context, Motivation, and available sandboxing tools.
AI agents are powerful: they can execute many day-to-day tasks thanks to their understanding of the surrounding context. That's what sets them apart from ordinary automations. However, they can also go wrong in various ways. That's why giving an agent free access to your computer might not be the best idea. For many reasons: starting with agent incompetence, where a "photo cleanup" request ends up with all of your photos permanently removed, instead of neatly organized into folders. There are several options for restricting the actions an AI agent can perform. Safe Scala provides tools to achieve just that. Let's take a short overview of how Safe Scala works and what the alternatives are.
This is post #3 in The Agent-Ready SDLC series. In post #1 we laid out the Ferrari-in-a-Fiat-500 problem - the engine is great, the chassis isn't. In post #2 we covered the first bottleneck: context. Now we're at the second bottleneck - the one that sits between your agent and reality.
As AI tools take over more and more of the actual coding work, a new question emerges: who's watching what they do? Visdom Governance is a tool designed to bring that control back. Krzysztof Grajek, Principal Software Developer at SoftwareMill and the lead engineer behind Visdom Governance, talks about why the rise of AI-generated code demands a completely new approach to trust, auditability, and documentation.
AI-generated code creates cognitive debt as developers accept code they don't understand. Learn how this hidden risk threatens teams and how to fight back.
As AI accelerates code generation, many teams are discovering that speed gains often come with hidden costs in review, validation, and complexity. We sat down with Krzysztof Romanowski to unpack what’s really happening inside modern engineering organizations.
As developer experience (DX) becomes a competitive advantage, many organizations are investing in internal platforms and tooling. However, building and maintaining DX capabilities in-house is costly and complex. This raises a key question: when should organizations manage developer productivity internally, and when is it more effective to engage external partners?
Shipping a working interface has never been easier. Design tools, AI, component libraries, and modern scaffolding have dramatically lowered the barrier to getting something on screen. This article is a practical, hands-on collection of workflow improvements, UX patterns, and implementation-level pro tips - all from a frontend developer’s perspective. No lengthy theory lectures (though a few concepts need a quick explanation to make sense). Jump in and try these techniques in your own projects to measurably improve how your interface feels.
Your interface may look right in a static mockup - but users don’t experience static pages. They see content appear, load, and shift. Perceived performance often matters more than raw performance metrics. A page that loads in 800ms but shows a blank screen feels slower than one that takes 1.2 seconds but shows skeleton placeholders from the first frame.
All the interactions discussed so far need to work across devices - and on mobile, they face a different set of constraints. More than half of all web traffic comes from mobile devices, yet many developer-built interfaces are designed cursor-first and touch-optimized as an afterthought. Mobile isn’t a smaller desktop - it has its own interaction model, constraints, and opportunities.
Discover how TypeScript is becoming the language of intent, reshaping engineers into system designers who define contracts while AI handles code.
Open any README in your repository. That flagship one. The one that's 800 lines long with a "Getting Started" section written in 2022. Read it with fresh eyes - as if you were a new developer, or better yet - as an AI agent who's never been to a standup, never seen Slack, never heard the legend of why we don't touch the InvoiceReconciler class in the payment service. Now ask yourself one question: based on this README, can you safely modify anything in this service?
