Author name: ITMAITY

We’re in a hinge moment for AI. The experiments are over and the real work has begun. Centralizing data, once the finish line, is now the starting point. The definition of “AI readiness” is evolving as increasingly sophisticated agents demand rich, contextualized data grounded in business operations to deliver meaningful results. What sets leaders apart is the quality of the data platform experience in delivering on the shared meaning, live context and interactivity that helps systems understand the business as it is, not just as a static report. Across industries, frontier firms are dissolving silos and equipping teams with AI agents and reasoning systems that go beyond answers to help people build, explore, decide and act. The result: a new rhythm of work that’s faster, more connected, more explainable and closer to the customer. Microsoft Fabric: Powering AI‑Ready data innovation enterprise‑wide at FabCon Europe As the first hyperscaler to fully embrace this paradigm, Microsoft is introducing new capabilities in its fastest-growing data and analytics platform, Microsoft Fabric, at the European Microsoft Fabric Community Conference (FabCon). With Fabric, we are bringing together all of an organization’s data into a single, AI‑ready foundation so every team can turn data into actionable insight with the full context of their business. At FabCon, Microsoft is announcing a major leap forward in its delivery of AI data readiness with Graph in Fabric, a low/no-code platform for modeling and analyzing relationships across enterprise data; and Maps in Fabric, which joins the recently launched digital twin builder in Microsoft Fabric as part of Real-Time Intelligence and brings geospatial analytics into Fabric, enabling users to visualize and enrich location-based data at scale. We’re also expanding Fabric’s capabilities further with new OneLake shortcuts and mirroring sources, a Graph database connecting entities across OneLake, enhanced developer experiences and new security controls — providing everything needed to run mission-critical scenarios on Fabric. These capabilities mark a fundamental evolution in data strategy for business leaders scaling intelligent AI applications and agents across their organizations. Train smarter agents with Graph and Maps The foundation of every successful AI agent isn’t just data — it’s organized knowledge. As businesses accelerate into the AI era, the challenge isn’t gathering more information, but structuring it so agents can reason, connect and act with purpose. The previews of Graph and Maps in Fabric are designed to help businesses organize their raw data for real-world impact. Graph in Fabric draws on the graph design principles proven at LinkedIn to reveal connections across customers, partners and supply chains, enabling organizations to visualize and query relationships that drive business outcomes. Maps in Fabric brings geospatial analytics, empowering teams to make location-aware decisions as they respond to operational challenges in real time. But these aren’t just technical milestones, they’re strategic tools for business leaders. AI is sparking new cross-company collaboration by connecting enterprise data — uniting business functions, accelerating decisions and empowering teams to share and scale value through open data flow. Whether it’s mapping supply chain dependencies or visualizing customer journeys, Graph and Maps help businesses move from isolated data points to a connected, actionable foundation for AI. Discover how Graph and Maps in Fabric unlock real-time intelligence for AI-driven operations. Get the engineering inside scoop from Corporate Vice President of Messaging and Real-Time Analytics, Yitzhak Kesselman, in his latest blog: “The Foundation for Powering AI-Driven Operations.” Enhancing developer experiences across Fabric to accelerate AI projects Fabric is quickly becoming the go-to platform for data developers worldwide. To fuel that momentum, we’re rolling out new tools that make it easier to build, automate and innovate. The new Fabric Extensibility Toolkit simplifies architecture and automation — so every solution is secure, scalable and aligned to business needs. And with the preview of Fabric Model Context Protocol (MCP) developers can tap into AI-assisted code generation and item authoring right inside familiar environments like Visual Studio Code and GitHub Codespaces. These updates aren’t just for software developers. They’re for any business leader ready to turn organized data into competitive advantage. Fabric helps teams move from experimentation to enterprise-scale impact, with speed and governance built in. OneLake: The AI-Ready data foundation OneLake is the unified data lake at the heart of Fabric. It’s designed to ingest data once and make it instantly usable across analytics, AI and applications to accelerate insight. Today, we’re introducing new features to give teams unprecedented visibility and control with OneLake. With the addition of mirroring capabilities for Oracle and Google BigQuery, expanded support for data agents and OneLake shortcuts to Azure Blob Storage, organizations can bring all their data together, no matter where it lives. OneLake shortcut transformations can now convert JSON and Parquet files to Delta tables for instant analysis. OneLake also offers secure governance tools, including a new Secure tab in the catalog for managing permissions and a Govern tab for data oversight. We’re also releasing the Azure AI Search integration with OneLake. By making this available in the Azure AI Foundry portal, we’re streamlining the experience for developers and data teams, helping them build smarter, more context-aware agents faster. Our OneLake Table API preview allows apps to discover and inspect tables using Fabric’s security model, and OneLake diagnostics, enabling workspace owners to capture all data activity and storage operations. Microsoft Fabric and Azure AI Foundry: A complete data, AI and agent ecosystem In the AI era, every project is a data project, and success depends on reducing complexity. Microsoft is addressing this head-on by continuing to natively integrate Fabric and Azure AI Foundry together to help simplify how enterprises design, customize and manage AI apps and agents. Fabric provides a single way to reason over data wherever it resides, delivering the structured, contextualized foundation AI needs. On top of that foundation, Azure AI Foundry enables developers to work with their favorite tools, including GitHub, Visual Studio and Copilot Studio, to efficiently build and scale AI applications and agents, while giving IT leaders visibility into performance, governance and ROI. By bringing data, models and operations together,

Microsoft and OpenAI have signed a non-binding memorandum of understanding (MOU) for the next phase of our partnership. We are actively working to finalize contractual terms in a definitive agreement. Together, we remain focused on delivering the best AI tools for everyone, grounded in our shared commitment to safety. The post A joint statement from Microsoft and OpenAI appeared first on The Official Microsoft Blog. ​Microsoft and OpenAI have signed a non-binding memorandum of understanding (MOU) for the next phase of our partnership. We are actively working to finalize contractual terms in a definitive agreement. Together, we remain focused on delivering the best AI tools for everyone, grounded in our shared commitment to safety. The post A joint statement from Microsoft and OpenAI appeared first on The Official Microsoft Blog.  Featured, The Official Microsoft Blog, AI The Official Microsoft Blog

Amy Coleman, Executive Vice President and Chief People Officer, shared the below communication with Microsoft employees this morning. How we work has forever changed. I remember starting at Microsoft in the late ‘90s, always in the office, no laptops, and primarily working with the people right down the hall. As technology evolved and our business expanded, we became more open, more global, and able to scale in ways we couldn’t have imagined. Then the pandemic reshaped everything. It pushed us to think differently about work, to connect like never before (thank you Teams!), reminded us of how much we value being together, and gave us focus and autonomy in the traditional workday. We’re not going back, and we shouldn’t. Instead, we should take the best of what we’ve learned and move forward. In the AI era, we are moving faster than ever, building world-class technology that changes how people live and work, and how organizations everywhere operate. If you reflect on our history, the most meaningful breakthroughs happen when we build on each other’s ideas together, in real time. We’ve looked at how our teams work best, and the data is clear: when people work together in person more often, they thrive — they are more energized, empowered, and they deliver stronger results. As we build the AI products that will define this era, we need the kind of energy and momentum that comes from smart people working side by side, solving challenging problems together. With that in mind, we’re updating our flexible work expectations to three days a week in the office. We’ll roll this out in three phases: 1) starting in Puget Sound at the end of February; 2) expanding to other US locations; 3) then launching outside the US. Our goal with this change is to provide more clarity and consistency in how we come together, while maintaining the flexibility we know you value. We want you to continue to shape your schedule in ways that work best for you, making in-person time intentional and impactful. Importantly, this update is not about reducing headcount. It’s about working together in a way that enables us to meet our customers’ needs. For some of you, this is not a change. For others this may be a bigger adjustment, which is exactly why we’re providing time to plan thoughtfully. As part of these updates, we’re also enhancing our workplace safety and security measures so we can continue to provide a workplace where every employee can do their best work. What you need to know: Puget Sound-area employees: If you live within 50 miles of a Microsoft office, you’ll be expected to work onsite three days a week by the end of February 2026. You’ll receive a personalized email today with more details. Please connect with your manager and team to understand your organization’s plans. If needed, you can request an exception by Friday, September 19. Managers: You’ll find actions to take, and the resources to support both you and your team on the Managers@Microsoft SharePoint. All employees: You’ll hear from your EVP or organizational leadership today with specific guidance. Each business will do what is best for their team, which means some groups will deviate from our company-wide expectations. If you are outside of the Puget Sound area, you do not need to take any action at this time unless your EVP communicates otherwise. Timelines and details for additional US office locations will be announced soon. For employees outside the United States, we will begin planning in 2026. More information is available on the Flexible Work at Microsoft SharePoint. As always, we’ll keep learning together to ensure Microsoft is the best place for you to grow and have a great career. Let’s keep moving forward together. Thank you, Amy   The post Flexible work update appeared first on The Official Microsoft Blog. ​Amy Coleman, Executive Vice President and Chief People Officer, shared the below communication with Microsoft employees this morning. How we work has forever changed. I remember starting at Microsoft in the late ‘90s, always in the office, no laptops, and primarily working with the people right down the hall. As technology evolved and our business expanded, we became… The post Flexible work update appeared first on The Official Microsoft Blog.  Featured, The Official Microsoft Blog The Official Microsoft Blog

If you’ve read any of my stuff or listened to one of my presentations before, you’ve likely heard my snarky joke: “Don’t be passive aggressive with Copilot.”  My point with this joke is serious, though. Copilot works best when you give it the right context. Just like a new teammate, it can’t read your mind (even if it sometimes feels like it can). Copilot can likely figure out what you’re doing and how you’re doing it. But spelling out the essentials – what you’re building, the stack you’re using, the rules to follow, etc., will help avoid confusion and mistakes. This is why instructions files are so important. They’re your chance to give Copilot that background, that institutional knowledge the rest of your team has from their experience with the project. The centerpiece for Copilot is copilot-instructions.md, the file which is read on every Copilot chat or agent request. So how should one be crafted? To help you avoid the blank-page problem, here are five things every instruction file should include (plus a bonus tip on how Copilot can even help you write the file itself). Before we get started One important tip I want to share before we get into more details is to not overthink things. There isn’t a specific prescribed way to write instructions files. The nature of generative AI is probabilistic, meaning the same requests can actually render different results. Your goal is to tilt the scales, to help point Copilot to finding the answer you’re hoping for as often as possible. The five sections (and bonus tip) below aren’t meant as requirements, but recommendations. In my experience, having these sections, or at the very least the key information indicated by these sections, in your instructions file will vastly increase the quality of suggestions from Copilot. You should use these as a starting point, and experiment and explore based on your projects, models, and experience with Copilot. Give GitHub Copilot a project overview It’s tough to write code for an app if you don’t know what the app is! The same thing is true for GitHub Copilot, and that’s where a project overview instructions file can be exceptionally helpful.  The header for your instructions file should be the elevator pitch for your app. What’s the app? Who’s the audience? What are the key features? It doesn’t need to be long, just a few sentences to set the stage. Here’s an example of a project overview for an instructions file: # Contoso Companions This is a website to support pet adoption agencies. Agencies are onboarded into the application, where they can manage their locations, available pets, and publicize events. Potential adoptors can search for pets available in their area, discover agencies, and submit adoption applications. The above example is clear, direct, and simple. You don’t need to write the Magna Carta, but it’s important to give Copilot some context around what you’re trying to accomplish at a high level. And this example app totally isn’t a way for me to convince myself to adopt a new pet (seriously, it’s not and I’m not just telling myself that).  Identify the tech stack you’re using in your project  Once you’ve identified what you’re building, the next thing to identify is what you’re using to build it. This includes the backend and frontend tech you’re using, any APIs you’re calling, and any testing suites you’re targeting. After all, the number of frameworks alone to create a website is always growing. Case in point? Three new JavaScript frameworks have probably launched since you started reading this blog post! You don’t need to channel your inner George RR Martin when creating instructions files, crafting paragraphs upon paragraphs explaining the minutiae. Instead, think about creating a list highlighting the tech you’re using, and maybe add a note or two about how they’re being used. This will help Copilot understand the environment in which it’s creating code.Here’s a quick example from my own work for reference:  ## Tech stack in use ### Backend – Flask is used for the API – Data is stored in Postgres, with SQLAlchemy as the ORM – There are separate database for dev, staging and prod – For end to end testing, a new database is created and populated, then removed after tests are complete ### Frontend – Astro manages the core site and routing – Svelte is used for interactivity – TypeScript is used for all front-end code ### Testing – Unittest for Python – Vitest for TypeScript – Playwright for e2e tests Spell out your coding guidelines Before you create your first pull request, you need to know the guidelines you should be following. Some of this is about how the code should be written. Are we using semicolons for JavaScript or TypeScript, for instance? Type hints for Python? Tabs or spaces? (The only correct answers are yes, yes, and spaces. I won’t be taking any questions.) Depending on your project structure, you could incorporate your guidelines into your tech stack instructions file. But I generally like having a separate section for guidelines, as many of them will apply across all languages in use. I find it to be more readable, which is important for maintainability, and there’s often crossover of guidance between languages and frameworks. You can also consider using .instructions files for guidelines for specific types of files, like all .astro or .jsx files, or unit tests which might match a pattern of /tests/test_*.py. Pro tip  It’s very easy to fall into a spiral of trying to discover the perfect way to prompt Copilot or build the perfect instructions files. An “imperfect” instructions file will deliver far more impact than nothing at all. Your instructions file should also evolve over time, just like documentation. (We all keep our documentation up to date, right?) I strongly encourage you to experiment and see what works best, and to not let perfect be the enemy of good. Here’s another example from some of my own work:  ##

As coding agents have grown more powerful, a pattern has emerged: you describe your goal, get a block of code back, and often… it looks right, but doesn’t quite work. This “vibe-coding” approach can be great for quick prototypes, but less reliable when building serious, mission-critical applications or working with existing codebases. Sometimes the code doesn’t compile. Sometimes it solves part of the problem but misses the actual intent. The stack or architecture may not be what you’d choose. The issue isn’t the coding agent’s coding ability, but our approach. We treat coding agents like search engines when we should be treating them more like literal-minded pair programmers. They excel at pattern recognition but still need unambiguous instructions. That’s why we’re rethinking specifications — not as static documents, but as living, executable artifacts that evolve with the project. Specs become the shared source of truth. When something doesn’t make sense, you go back to the spec; when a project grows complex, you refine it; when tasks feel too large, you break them down. Spec Kit, our new open sourced toolkit for spec-driven development, provides a structured process to bring spec-driven development to your coding agent workflows with tools including GitHub Copilot, Claude Code, and Gemini CLI. 💡 What is spec-driven development? Instead of coding first and writing docs later, in spec-driven development, you start with a (you guessed it) spec. This is a contract for how your code should behave and becomes the source of truth your tools and AI agents use to generate, test, and validate code. The result is less guesswork, fewer surprises, and higher-quality code. What is the spec-driven process with Spec Kit?  Spec Kit makes your specification the center of your engineering process. Instead of writing a spec and setting it aside, the spec drives the implementation, checklists, and task breakdowns.  Your primary role is to steer; the coding agent does the bulk of the writing. It works in four phases with clear checkpoints. But here’s the key insight: each phase has a specific job, and you don’t move to the next one until the current task is fully validated.  Here’s how the process breaks down: Specify: You provide a high-level description of what you’re building and why, and the coding agent generates a detailed specification. This isn’t about technical stacks or app design. It’s about user journeys, experiences, and what success looks like. Who will use this? What problem does it solve for them? How will they interact with it? What outcomes matter? Think of it as mapping the user experience you want to create, and letting the coding agent flesh out the details. Crucially, this becomes a living artifact that evolves as you learn more about your users and their needs. Plan: Now you get technical. In this phase, you provide the coding agent with your desired stack, architecture, and constraints, and the coding agent generates a comprehensive technical plan. If your company standardizes on certain technologies, this is where you say so. If you’re integrating with legacy systems, have compliance requirements, or have performance targets you need to hit … all of that goes here. You can also ask for multiple plan variations to compare and contrast different approaches. If you make your internal docs available to the coding agent, it can integrate your architectural patterns and standards directly into the plan. After all, a coding agent needs to understand the rules of the game before it starts playing. Tasks: The coding agent takes the spec and the plan and breaks them down into actual work. It generates small, reviewable chunks that each solve a specific piece of the puzzle. Each task should be something you can implement and test in isolation; this is crucial because it gives the coding agent a way to validate its work and stay on track, almost like a test-driven development process for your AI agent. Instead of “build authentication,” you get concrete tasks like “create a user registration endpoint that validates email format.” Implement: Your coding agent tackles the tasks one by one (or in parallel, where applicable). But here’s what’s different: instead of reviewing thousand-line code dumps, you, the developer, review focused changes that solve specific problems. The coding agent knows what it’s supposed to build because the specification told it. It knows how to build it because the plan told it. And it knows exactly what to work on because the task told it. Crucially, your role isn’t just to steer. It’s to verify. At each phase, you reflect and refine. Does the spec capture what you actually want to build? Does the plan account for real-world constraints? Are there omissions or edge cases the AI missed? The process builds in explicit checkpoints for you to critique what’s been generated, spot gaps, and course correct before moving forward. The AI generates the artifacts; you ensure they’re right. How to use Spec Kit in your agentic workflows Spec Kit works with coding agents like GitHub Copilot, Claude Code, and Gemini CLI. The key is to use a series of simple commands to steer the coding agent, which then does the hard work of generating the artifacts for you. Setting it up is straightforward. First, install the specify command-line tool. This tool initializes your project and sets up the necessary structure. uvx –from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME> Once your project is initialized, use the /specify command to provide a high-level prompt, and the coding agent generates the full spec. Focus on the “what” and “why” of your project, not the technical details. Next, use the /plan command to steer the coding agent to create a technical implementation plan. Here, you provide the high-level technical direction, and the coding agent will generate a detailed plan that respects your architecture and constraints. Finally, use the /tasks command to make the coding agent break down the specification and plan into a list of actionable tasks. Your coding agent will then use this list to implement the project requirements. This


 اقرأ باللغة العربية 
 أصبحت تتيح وصولاً أوسع للمطورين في سوريا عقب قواعد التجارة الحكومية الجديدة GitHub قبل أكثر من أربع سنوات، اتخذنا موقفًا ظلّ في صميم عملنا لدعم حرية المطوّرين: «ينبغي أن يتمتّع جميع المطوّرين بالحرية في استخدام GitHub، أينما كانوا». واليوم نبلغ محطةً مهمةً في ذلك المسعى؛ إذ إن تخفيف العقوبات والقيود المفروضة على الصادرات تجاه سوريا أتاح إعادة فتح الخدمات الخاصة والمدفوعة على موقع بشكل واسع أمام المطوّرين في حلب، حمص، دمشق، وفي جميع أنحاء البلد. ‎ظلّ التعاون في المشاريع مفتوحة المصدر والمستودعات العامة الأخرى متاحًا دائمًا، كما يظهر في مخطط ابتكار وهي مجموعة بيانات مفتوحة تُقدم أرقامًا مجمّعة عن مساهمات المستودعات العامة من سوريا. نُعرب عن امتناننا الصادق للمطورين الذين دعوا لهذا التغيير وسعوا باستمرار للحصول على التحديثات. GitHub ترحّب بالمطورين السوريين للمساهمة بمشاريعهم في مجتمع المطورين العالمي، سواء كانت مساعيهم كبيرة أم صغيرة. نفتخر بأن نكون الموطن للمطورين الذين يدفعهم شغفهم للابتكار والبناء والتعلّم والتعليم، ونبقى ملتزمين بجعل GitHub متاحاً لأكبر عدد ممكن من المطورين ضمن إطار القانون. نقوم الآن باتخاذ الخطوات اللازمة بصورة عاجلة لرفع القيود المفروضة على المطورين في السوريا، بما يتيح استعادة وظائف الحساب الكاملة، إضافةً إلى إتاحة خدمة GitHub Copilot. التغييرات جارية ومن المتوقّع أن تصل إلى الحسابات خلال الأسبوع المقبل. 
 More than four years ago, we took a stance that has remained at the center of our work advancing developer freedom: “All developers should be free to use GitHub, no matter where they live.” Today marks one important milestone in that endeavor. With the relaxation of sanctions and export controls on Syria, private and paid features of GitHub.com will once again be broadly available to developers in Aleppo, Homs, Damascus, and the entire country. Collaboration on open source projects and other public repositories has always been available, as can be seen in the GitHub Innovation Graph, an open dataset which provides aggregate numbers on public repository contributions from Syria. We extend our sincere gratitude to the developers who advocated for this change and consistently sought updates. GitHub welcomes Syrian developers to contribute their projects to the global developer community,  whether they be big or small endeavors. We are proud to be the home for developers whose passion drives them to innovate, build, learn, and teach—and we remain committed to making GitHub available to as many developers as legally possible. We are moving promptly to lift restrictions on developers in Syria, enabling normal account functionality, as well as access to GitHub Copilot. Changes are underway and expected to reach accounts within the next week.  The post GitHub is enabling broader access for developers in Syria following new government trade rules appeared first on The GitHub Blog. ​ Company The GitHub Blog