Klarna started rehiring those positions in May 2025. The CEO went on the record about why a few months later: “Cost unfortunately seems to have been a too predominant evaluation factor… what you end up having is lower quality.”

Read that twice. A sitting CEO publicly admitting the AI-first headcount strategy did not work. Eighteen months of “AI is replacing humans” reversed in a single sentence.

Klarna’s reversal is about customer service, not software engineering. But it is the loudest single signal that the headcount math companies have been telling themselves for the last two years does not survive contact with reality. And what is happening in customer support is what is starting to happen in engineering teams — slower, less visibly, but in the same direction.

Last month I wrote about why the unit economics of AI today are broken. This post is the other half of that story — what AI is actually doing to engineering teams in real time. The shape is shifting fast, junior hiring is collapsing, several role categories are being absorbed, and the senior IC role is pivoting in ways most seniors have not yet caught up with. I am going to be blunt about it, with the data, and let you draw your own conclusions.

Let’s go.

The numbers nobody is showing the board

Not the CEO quotes. Not the LinkedIn thinkpieces. The actual hiring data.

Indeed Hiring Lab’s April 2026 labour market snapshot shows US software-development postings still roughly 28% below the February 2020 baseline — a partial recovery from the deeper trough but still well below pre-pandemic levels. At the same time, AI-related postings have climbed to 5.4% of all listings, past the 3.3% peak from 2022. So the headline is not just “fewer jobs”; it is “the few jobs that are opening are heavily skewed toward AI work.”

US Bureau of Labor Statistics shows the smaller “Computer Programmer” category fell 27.5% between 2023 and 2025, while the much larger “Software Developer” category was essentially flat (−0.3%). The displacement is concentrated in the entry-level and mid-level “Programmer” titles — not the senior software developers.

Stanford’s 2026 AI Index puts a number on the demographic angle: software-developer employment among workers aged 22-25 has fallen nearly 20% since 2024 — the first white-collar category showing measurable AI-attributable contraction at the entry level.

A 2025 LeadDev survey found 54% of engineering leaders expect long-term junior hiring to decline because of AI — though only 18% planned to cut junior hiring in the next year. The gap is leaders saying out loud what they have not yet acted on.

Now look at the other side. Forward-Deployed Engineer postings — a Palantir-pioneered role now standard at OpenAI, Anthropic, and Cohere — went from 643 in April 2025 to 5,330 in April 2026, a +729% year-on-year jump, with Google and Deloitte accounting for roughly 40% of openings. Lightcast’s March 2026 GenAI job market update tracks around 10,000 unique GenAI-skill postings per month, and LinkedIn data has AI Engineer as the fastest-growing role for young workers for the second consecutive year. Forrester’s 2026 Predictions project a 20% decline in CS enrollments going forward — the pipeline that was meant to feed entry-level hiring is shrinking too.

Put it all together: the junior side is in collapse, AI-specialty roles are exploding by orders of magnitude while total hiring shrinks, and the middle is flat. And nobody is in a hurry to mention any of this when they pitch their AI strategy to the board, because the public story is supposed to be that AI is helping engineers do more — not that it is being used to avoid hiring entry-level engineers entirely.

Smaller teams, more senior. And more fragile.

The new team is smaller. The new team is more senior. The new team is supposedly faster. And by most accounts, the new team is also more fragile.

Look at what the leading companies are doing. Shopify has made AI usage a fundamental expectation — performance reviews include it, and teams must prove a job cannot be done by AI before backfilling. Shopify’s VP of Engineering Farhan Thawar reports a ~20% productivity gain and uses weekly demos as the primary velocity signal, not PR counts. Stripe runs an “Experimental Projects Team” of about two dozen senior engineers operating fleets of agents through their internal “Minions” harness. Google’s Pichai stated in April 2026 that “75% of new code at Google is AI-generated” — treat the exact figure as directional, but the direction is unmistakable. Microsoft’s Nadella said in April 2025 that 20-30% of code in some Microsoft projects is AI-written.

The pattern across all of them: smaller pods, more senior on average, embedded AI infrastructure. Anthropic’s 2026 Agentic Coding Trends Report describes the model as dynamic surge staffing — specialists pulled onto problems for short periods rather than kept on a permanent roster. The new shape of an engineering team looks more like a Big Four consulting bench than like a traditional product team.

The consequence — almost nobody puts this on the slide — is that teams shaped this way are more brittle. Fewer people know how systems work end to end. Less long-tenure knowledge. Less of the cross-pollination between juniors and seniors that historically built the next senior layer. Faros AI’s 2026 telemetry of 22,000 developers and 4,000+ teams calls this “Acceleration Whiplash.”

Teams ship more code, review less of it, and take longer to review what they do not skip. That is the kind of efficiency that looks great on a slide and miserable on a Friday afternoon.

The roles, growing and absorbed

If hiring volume is down overall but specific role categories are exploding, which roles? The chart shows the shape; here is what each one means.

Six roles that are growing — all senior by intent:

• AI Engineer — integrates LLMs into products. Prompts, RAG, fine-tuning, evals. About 80% of postings are senior-level. UK salaries £110-180K, US higher.
• Forward-Deployed Engineer (FDE) — Palantir-pioneered, now standard at OpenAI, Anthropic, Cohere. Embedded with customers, translating AI capability into systems that work in production.
• Context Engineer — Stripe / Shopify / ThoughtWorks discipline. Owns the documentation, knowledge graphs, and prompt scaffolding that make agents reliable inside a specific organisation.
• Agent Orchestrator — designs harnesses, MCP servers, and feedback loops for operating fleets of agents in parallel. Simon Willison calls this vibe engineering.
• RAG Engineer — grounded outputs from trusted sources. The defence against hallucination. Every regulated industry is hiring for this.
• AI Governance Lead — NIST AI RMF, ISO/IEC 42001, EU AI Act, OWASP Top 10 for Agentic Apps. Used to be a corner of security; now its own function.

If your career strategy was “get to senior in five years, then specialise”, the new strategy is “specialise in one of these while getting to senior.” The market is not waiting.

Four roles being absorbed:

• Boilerplate-focused junior coding — the CRUD work that used to be the first-year-junior path. AI does it for free relative to a junior salary.
• Dedicated Scrum Master — at smaller and mid-sized companies, absorbed into Engineering Manager responsibilities.
• Manual QA — click-through testing replaced by AI test automation. Indeed eliminated dedicated QA Engineer roles in March 2023 and reportedly saw test quality drop afterward — cautionary tale.
• Pure documentation specialist — first-draft documentation goes to AI. The role survives at large companies but has shifted toward content strategy and DevEx.

QA strategy is growing fast: Tesla expanded QA from 260 to 390 between 2020 and 2025; SDETs and reliability engineers are among the fastest-growing roles for 2025-2026. The mechanical work goes; the judgment work stays.

None of this is a judgement on the people doing those jobs. The shift is real and fast, and the honest thing to do is name it.

The skill bar is moving up

The skill bar is moving up at every level. Here is what specifically matters now.

Juniors need what they used to learn in their second year on day one: computational thinking, code-review judgment, production-deployment skill, and AI-tool fluency. The fastest CV upgrade available right now is deploy something real and maintain it for six months. Stack Overflow’s 2025 survey shows 84% of developers use AI tools — your fluency with them is table stakes, not differentiation. Writing boilerplate, basic debugging, syntax fluency: still required, no longer enough.

Mid-level engineers face the sharpest squeeze. Implementation throughput used to be your differentiator; it is now cheap. The shift is toward implementation judgment — writing precise specs, supervising agents, refactoring with discipline, knowing when to override. Kent Beck’s line is sharp: “today’s AI assistants lack taste.” Your job at mid-level is increasingly to be the taste. Mid-levels who do not make that shift will plateau in ways that are hard to articulate.

Senior, staff, and principal engineers pivot from depth-of-implementation to architecture, judgment, and reviewing at scale. Simon Willison’s vibe engineering essay describes it: “researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review.” If your senior identity is “I can code anything” — you are competing with AI. If it is “I know what matters in this specific organisational context” — AI amplifies you.

Engineering managers have acquired three new buckets nobody warned them about: token economics (engineers can spend $1,000+/month on tokens without approval — manage it before finance does), new performance metrics (lines, PRs, and AI acceptance rates are all gameable now; weekly demos are not), and hiring-process redesign (whiteboarding is dead; live debugging and reading AI-generated PRs is the new format).

CTOs and VPs of Engineering need three things at strategy level: platform thinking (DORA’s January 2026 ROI report frames AI as an amplifier of underlying engineering quality — platform quality directly correlates with realising AI value, so do not let your CFO treat platform investment as overhead), compliance mastery (NIST AI RMF, ISO/IEC 42001, the EU AI Act — not optional in 2026), and talent-pipeline strategy, which is the next section.

The pipeline trap

If you only take one thing from this post, take this.

Stack Overflow’s blog put it bluntly in late 2025: “if you don’t hire junior developers, you’ll someday never have senior developers.”

The problem is structural and time-delayed. The juniors you do not hire in 2026 are the seniors you do not have in 2031. By the time the gap is visible on the org chart, it is too late to fix in the same hiring cycle.

Two camps on this in tech leadership right now.

Camp A — Anthropic’s Dario Amodei: up to 50% of entry-level white-collar jobs eliminated within five years. Treat as a forecast, not a measurement, but it is the camp informing the headcount decisions you can see in the data above.

Camp B — GitHub’s Thomas Dohmke and Google’s Sundar Pichai: AI makes juniors more valuable, not less, because it amplifies what they can produce. GitHub continued early-career hiring through 2025. Pichai has said Google plans to hire more engineers because AI is making them more productive. And IBM has tripled entry-level hiring in 2026, with CHRO Nickle LaMoreaux explicitly framing the additional juniors as the human oversight layer their AI investments require — including for roles “AI can do.”

Both camps read the same data and reach opposite conclusions because they are running different bets. The honest answer is we do not yet know which bet wins, but the cost of being wrong is wildly asymmetric. If Camp A is wrong, you have a senior shortage in 2031 you cannot hire your way out of. If Camp B is wrong, you have slightly higher headcount cost in 2026 that you can fix at any time.

One of those mistakes is reversible. The other is not.

If you are running an engineering organisation, the implication is simple. Do not freeze junior hiring entirely. Slow it, redesign it around AI-augmented work, raise the bar on what juniors are expected to do, but do not freeze it. The people who get this right in 2026 are going to look like geniuses in 2031.

What I tell clients

Here is what I tell engineering leaders right now, on every project where it comes up.

• Hire juniors. Just hire fewer, and redesign their first six months. The traditional first-year path of “write CRUD to learn the codebase” is gone. Replace it with “review AI-generated PRs”, “deploy and operate something small in production by month three”, and “be the person who can explain how an agent went wrong”. Juniors out of that program in two years are more useful than juniors from five years ago, not less.

• Set token budgets per team or per feature, with observability. Tag every AI resource with cost-center, project, environment, and owner. Without that, the AI bill is one line item nobody can interrogate. Engineers will spend $1,000+/month per head if you don’t.

• Replace PR-count and line-count metrics with weekly demos. Activity metrics are gameable in ways they were not three years ago — anyone can submit a hundred PRs of AI-generated boilerplate now. Demos cannot be faked the same way.

• Enforce the explainability rule. Simon Willison’s golden rule: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.” Make this an org-wide policy. Anything an engineer cannot explain at PR review does not merge. This single rule prevents most of the worst AI-coding disasters I have seen — including the Cursor-Claude agent that wiped PocketOS’s production database in nine seconds last month because nobody was in a position to override the destructive command before it ran.

• Document the team you would hire if you were starting over right now, not the team you have. Then plan the next two years of hiring against the gap, not against attrition. This is the single highest-payoff exercise an engineering leader can do in 2026.

Build the team you want to be running in 2031

AI is rebuilding engineering teams in real time. The shape is smaller, more senior, more cross-functional, more brittle, more dependent on a few specialists at the top of the stack. Junior hiring is in collapse. Several role categories are being absorbed. The senior IC role is pivoting toward judgment, architecture, and review. The CTO role is pivoting toward governance, platform, and talent strategy.

None of this is reversible at the level of any single company. It is a market-wide shift driven by the same economics I wrote about last month, and it is going to keep moving in this direction whether or not your org chart is ready.

What is reversible is the choices you make this year. Hire some juniors. Redesign their onboarding. Pay your senior people for judgment, not output. Tag every AI resource. Demo your work weekly. Tell your team the truth.

Build the team you want to be running in 2031, not the one your headcount spreadsheet defaults to in 2026. That is the whole game.

GitHub paused new sign-ups for Copilot Pro and a week later moved the whole product to usage-based billing. Tom’s Hardware reported that up to half of US data center capacity slated for 2026 is at risk of slipping. DRAM contract prices jumped 90% in a single quarter. The chief economist of Goldman Sachs went on the record saying AI added “basically zero” to US GDP in 2025. MIT published a preliminary study finding that 95% of enterprise GenAI pilots delivered no measurable business return.

Any two of these in isolation could be coincidence. All five together is a pattern. And we have not even gotten to OpenAI’s actual numbers yet.

The pattern is this: the unit economics of AI today are broken. Not “tight”. Not “rounding-error tight”. Broken. And the most interesting part — not even the vendors are pretending otherwise anymore.

By “broken” I mean the simple thing: the prices people pay today, the plans the vendors sell today, and the capex projections funding all of it do not reconcile to a profitable business at scale. Somebody downstream is going to absorb the difference. The interesting question is who, and when.

The canary just keeled over

If you want to know whether a market is healthy, you do not look at what the analysts say. You look at what the company at the top of the value chain does when nobody is watching. And on April 20, 2026, GitHub did something interesting.

They paused new sign-ups for Copilot Pro, Pro+ and Student plans. They pulled Opus models out of Pro entirely. They announced that even Pro+ would be losing Opus 4.5 and 4.6 — only Opus 4.7 stays. They tightened premium request limits. And they offered everyone a refund window until May 20.

You can read GitHub’s framing of this and it is — let us say — diplomatic. They blame “agentic workflows”, they talk about “service reliability”. But buried in the announcement is the most honest sentence I have read from a vendor in months:

“Long-running, parallelized sessions now regularly consume far more resources than the original plan structure was built to support… a handful of requests can exceed the plan price.”

Read that twice. A handful of requests can exceed the plan price.

This is not a marketing line. This is GitHub admitting that flat-rate pricing on agentic AI workloads does not work. The math broke under their feet. They are the company that built Copilot, that runs on Azure, that has the closest commercial relationship with OpenAI of anyone in the market — and they could not make the monthly Pro fee cover the cost of the product they were selling.

If GitHub cannot make Copilot’s unit economics work, what makes you think your in-house GenAI feature is going to?

And then, one week later, GitHub did the other thing.

On April 27, 2026 — the day before this post went out — GitHub announced that effective June 1, 2026, the Premium Request system is gone. Copilot is moving to token-metered GitHub AI Credits: Pro $10 a month, $10 in credits. Business $19, $19 in credits. Enterprise $39, $39 in credits. Sit with that for a moment. That is a base subscription with zero margin baked in. They are passing the compute through at par.

The framing in the announcement is more candid than the April 20 one. From GitHub’s own post:

“A quick chat question and a multi-hour autonomous coding session can cost the same amount.”

The previous structure, GitHub says, is “no longer sustainable”. Vendors do not write the words “no longer sustainable” about their own product unless the spreadsheet has truly stopped balancing.

There is a pattern here that goes well beyond GitHub. Anthropic raised Claude API prices last year. OpenAI walked back the cheap GPT-4o tier. Cursor restructured. Replit changed their plans twice. The flat-rate, all-you-can-eat era of AI assistants is over and it lasted about eighteen months. The vendors gave you a taste of what AI could do at a price that did not reflect what AI actually costs, and now the bill is being recalibrated in public.

The physical world is hitting back

But ok, GitHub repricing is one thing. Maybe it is a marketing problem. Maybe agentic workflows just need a different commercial model. What about the fundamentals — the actual cost of running this stuff?

This is where it gets ugly.

Tom’s Hardware, summarising research from Sightline Climate, reports that 30 to 50% of the US data center capacity slated for 2026 is at risk of slipping — only about 5 GW of the roughly 16 GW announced for that year is visibly under construction. The bottlenecks are not what you read in keynote slides — they are not “talent shortages” or “regulatory complexity”. They are reinforced concrete and 230 kV transformers and copper bus bars and parts coming out of factories in Shenzhen.

Specifically:

• Power infrastructure — utilities cannot deliver enough capacity fast enough. Substations take three to five years to build. Transformer lead times are measured in years, not months.
• Parts from China — despite years of “onshoring”, the actual components that go into a hyperscale data center still depend on Chinese factories. The political class has not solved this problem. Maybe they will. But not before the buildout slips.
• Water — the cooling infrastructure for AI clusters consumes water at a rate that local jurisdictions are starting to push back on, hard.
• Local opposition — communities are saying no. Loudly. Especially in the places that have already absorbed one or two hyperscale builds.

Sam Altman talks about insatiable demand. Satya Nadella talks about Azure capacity. Jensen Huang talks about a billion GPUs. Those are nice numbers. But you cannot build a data center with a press release. You need permits, switchgear, transformer windings, water rights, and concrete pours. The physical world has limits that do not move because someone in San Francisco wishes they did.

The buildout schedule that all the AI revenue projections depend on — that schedule is slipping. It is slipping right now, in real US counties, with real planning departments. Nobody is going to mention it on the next earnings call.

The RAM crisis nobody warned you about

Ok let us say the data centers do get built. Slower than promised, but built. There is still a problem: you have to put memory in them. And memory just got really, really expensive.

The numbers from TrendForce, IDC and IEEE Spectrum are not subtle. DRAM contract prices went up 90% in Q1 2026 compared to Q4 2025. Server DRAM specifically went up more than 60% quarter-over-quarter. Memory shortages are projected to last through 2027 and possibly into 2028.

Why? Because:

• Data centers now consume over 70% of high-end memory chips produced worldwide. Seventy. Percent.
• AI is projected to consume nearly 20% of global DRAM supply in 2026 on an equivalent-wafer basis (TrendForce). That number was effectively zero five years ago.
• HBM — the high-bandwidth memory that ships next to GPUs — uses approximately 3× the wafer capacity per bit compared to DDR5. Producing HBM is brutally inefficient at the silicon level. Manufacturers are dedicating wafer lines to it because they make more money per wafer, but every HBM bit produced means three DDR5 bits the rest of the world does not get.

You see where this is going. It is not just “AI is expensive”. It is “AI is making everything else expensive too”. The laptop your developer needs. The server hosting your boring CRUD app. The gaming PC you bought your kid. They all just got more expensive because hyperscalers are vacuuming up the wafer pipeline to feed inference.

This is a cost that does not show up on your Azure OpenAI invoice. It shows up two years from now, when you go to buy hardware for an unrelated project and the quote comes back 40% higher than it would have been. The architect who shrugged at AI pricing in 2025 is now also explaining to the CFO why the on-prem refresh budget exploded.

Goldman Sachs, MIT, and the GenAI Divide

Now you might say — Tomasz, this is all anecdote. The vendors will figure out pricing. The data centers will get built eventually. The memory market will normalize. Show me the macro evidence.

Ok. Let me show you the macro evidence.

Goldman Sachs. Jan Hatzius, the chief economist of Goldman Sachs, said publicly that AI’s contribution to US GDP growth in 2025 was “basically zero”. His words. Not mine. Not some bearish blogger. The chief economist of Goldman Sachs.

The reason is interesting: most of the AI investment in the US is going into hardware imported from Taiwan and Korea. So when Microsoft buys 50,000 GPUs from NVIDIA — those GPUs are largely fabricated on TSMC fabs. The dollars leave the country. The investment shows up in Taiwanese and South Korean GDP, not American GDP. A more recent Goldman note is more careful — visible productivity gains so far appear concentrated in a small number of localized use cases, with broader economy-wide effects expected later, not now.

So the trillions in capex are not, so far, producing macroeconomic returns to the country doing the spending. That is awkward. To be clear, this is a macro-accounting and timing observation. A weak GDP signal does not by itself prove that any specific AI vendor is unprofitable — that is a different argument, and the OpenAI numbers are coming up.

MIT NANDA. A preliminary “State of AI in Business 2025” report from MIT’s NANDA initiative looked at 52 executive interviews, 153 leader surveys, and 300 public AI deployments. The headline finding: 95% of enterprise GenAI pilots delivered no measurable P&L impact.

Read that one again. Out of every twenty AI pilots run inside enterprises in 2025, nineteen produced zero detectable business return. And those nineteen pilots spent an aggregate $30 to $40 billion to do it.

If you have been on the practitioner side of this — running these projects, presenting to steering committees, watching the ROI numbers slip every quarter — you already knew. The MIT report just put it in writing. Buying tools from specialized vendors works about 67% of the time. Internal builds work about a third as often. The technology is real. The corporate path to value through it is mostly broken.

So we have the vendors repricing because the unit economics do not work. The physical buildout slipping because of power, water, and supply chain. The memory market in crisis because of the wafer math. The macro economists saying GDP impact was basically zero in 2025. The academic researchers saying 95% of corporate pilots return nothing.

That is not a few warning signs. That is the whole instrument panel lit up red.

OpenAI, the $1.4 trillion bill

I want to come back to the vendor side, because this is the part that affects you most directly when you quote an AI workload to a client.

The biggest pure-play AI company in the world is OpenAI. Whatever runs in your Azure OpenAI deployment is, ultimately, running on top of OpenAI’s economics. So those economics matter to you.

Here is the picture, broken out by what each number actually measures. Revenue and operating spend are P&L figures. Cumulative burn is a multi-year cash-flow projection. The $1.4 trillion is a multi-year capex commitment, not a 2025 line item. They live in different accounting buckets and they should not be added together — but each one is bad on its own:

• 2025 revenue: ~$13 billion (Reuters)
• 2025 reported operating spend: ~$8 billion (Reuters), with the operating math already negative once cost of revenue is layered in
• Cumulative cash burn projected through 2029: ~$115 billion (Reuters)
• Eight-year compute commitments: ~$1.4 trillion (Sam Altman, public statement)

That last number is more than the GDP of Mexico. With a T.

Then there is the most-cited, least-clean figure. From leaked Microsoft revenue-share documents, OpenAI was reportedly burning roughly $2 in compute for every $1 of inference revenue. The direction of travel is clear — inference is structurally expensive, OpenAI’s adjusted gross margin reportedly collapsed from around 40% to 33% in 2025, and inference costs reportedly quadrupled over the year. But the precise compute-to-revenue ratio depends on Microsoft figures that TechCrunch has flagged are net of royalties Microsoft pays back to OpenAI, which means the headline number is contested. Treat that ratio as directionally damning, not audited.

Now ask yourself: when you call your Microsoft account team for an Azure OpenAI quote, what do you think is in that price? Microsoft’s margin? OpenAI’s margin? Or two-thirds of an “investment thesis” that someone is hoping the next round of investors pays for later?

OpenAI’s path to profitability requires one of three things:

1. Massive price increases — which break their customers’ unit economics, which is exactly what GitHub had to admit last week
2. Massive efficiency gains in inference — which require new hardware that is bottlenecked by data center buildout and HBM wafer constraints we just walked through
3. Something else materializing — a productivity miracle, government contracts, an IPO greater-fool exit, a breakthrough that bends the cost curve

None of those are guaranteed. Most of them are not even probable on the timeline OpenAI needs them. And while they figure it out, the price your client pays for that token is partly funding the $115 billion hole.

One honest disclaimer before we move on: most of the OpenAI numbers above come from Reuters reporting, leaked documents and public statements, not audited financial filings. OpenAI is not a public company. Some of these figures will move when better data appears, and a few of them — especially the leaked compute-to-revenue ratio — are explicitly contested. The qualitative picture holds up: very large operating losses, very large multi-year commitments, structurally expensive inference. The exact decimal places, less so. I would rather you walk away with the right shape of the problem than with one wrong number you remembered for the wrong reason.

What I am actually doing in projects right now

Now — and this is where I want to be careful — I am not telling you to walk away from AI. I use Claude every day. I use GitHub Copilot every day. I build AI solutions and I help organizations run their AI programs in production. The value is real. My productivity is up. The teams I work with are shipping faster. None of that is in question.

What is in question is the economics underneath all of it. And those still do not add up. So I am building like I know the bills are coming.

The good news here is that you do not have to invent a cost-control playbook. Every major vendor has published one. Microsoft, AWS, Google Cloud, OpenAI and Anthropic all converge on roughly the same handful of practices. The bad news is that most teams I see do not actually do most of them. Here are the ones I follow on every project, with the receipts:

• Right-size the model. Aggressively. This is the single biggest cost lever you have, and every vendor agrees. Microsoft Learn puts model selection at the top of the cost optimisation list. AWS calls it “the single most impactful FinOps decision”. Google’s Vertex AI guidance is to run your task on Gemini Flash first and only escalate to Pro for the things that genuinely need complex reasoning. The pattern is the same everywhere — most workloads do not need a frontier model. Default small. Promote to big only on the high-value paths.

• Turn on prompt caching. This one almost feels like cheating. OpenAI documents up to 90% reduction in input token cost and 80% reduction in latency with prompt caching enabled, and it is automatic on recent models. Anthropic charges 10% of base input price for cache reads — they pay back after a single cache read. AWS Bedrock reports the same up-to-90% number. The implementation rule is identical across all of them: put static content (system prompt, instructions, large context) at the start, variable content at the end. Most teams I see have not flipped this switch yet, which is wild.

• Use the Batch API for anything that does not need to be real-time. Across OpenAI, Anthropic and AWS Bedrock, batch inference is roughly 50% cheaper than synchronous inference. Microsoft’s guidance is direct: any workload tolerating 24-hour latency should go through the Batch API. Document analysis, embedding generation, nightly content pipelines, scheduled summaries — push them all to batch and recover half the bill.

• Set max token limits on every deployment. Microsoft’s cost-management guidance for Azure OpenAI is direct on this: applications that do not cap output leak tokens at every call — text gets generated, gets billed, and most of it never reaches the user. The fix is one configuration parameter. The exact size of the saving is workload-specific, but the direction is always one way.

• Tag every AI resource and pipe it into the vendor’s cost tool. Azure Cost Management, AWS Cost Explorer and Google Cloud cost tracking all do per-tag chargeback. If your AI features are not tagged with cost-center, project, environment and owner, you do not actually know what you are spending — you have a number, but you do not have a story. The aggregate “Azure OpenAI bill” tells you nothing useful. You need to know which feature, which user segment, which session generated which percentage of that bill.

• Hunt down idle deployments and ghost endpoints. Fine-tuned model hosting in Azure incurs hourly fees regardless of traffic. A Vertex AI notebook with an attached GPU keeps billing whether anyone is using it or not. AWS Bedrock provisioned-throughput models keep billing whether you call them or not. The pattern across all three clouds is identical — AI infrastructure rots into ghost charges faster than any other category of cloud spend, because everyone is afraid to delete things they “might need”. Run a monthly sweep.

And then there are two things I add to every project anyway, that you will not find in the vendor docs — because the vendor docs assume their pricing is stable, and we have just spent six sections establishing that it is not:

• Pin model versions in client contracts. When we agree on a price for an AI feature, the contract spells out exactly which model version that price assumes. If the vendor deprecates the cheap tier or quietly swaps the underlying model, the price changes too. No surprises in month six.
• Abstract the model boundary so swaps are cheap. If your prompt templates and orchestration logic are so coupled to one provider that switching is a six-month project, you have built yourself into a corner. Eighteen months from now, you will use that abstraction. Guaranteed.

This is not paranoid. This is how you architect for a market where the vendor’s own unit economics do not work. You do not bet your client’s product on the vendor figuring out their pricing before your runway runs out.

The party is not over. But somebody is about to get the check.

AI is not going away. The good models will keep getting better. The productivity gains for individual developers and individual workflows are real and I will keep using them.

But the spreadsheet behind all of it does not balance. The vendors know it. The economists know it. The data center planners know it. And starting last week, even GitHub knows it.

Build like you know it too. Make sure the architecture you ship today still works when the price doubles. Because it will.

So I spent some time poking around both the framework repo and the template catalog, and here’s what I think.

What is Spec2Cloud?

At its core, Spec2Cloud is an agent-driven workflow that takes you from a product idea to a deployed application on Azure. It does this by orchestrating a team of specialized GitHub Copilot agents – think of it as a virtual dev team where each agent has a specific role.

There are six agents:

• PM Agent (@pm) – takes your product idea and turns it into a Product Requirements Document and Feature Requirements Documents
• Dev Lead Agent (@dev-lead) – consolidates engineering standards and ensures architectural compliance
• Dev Agent (@dev) – breaks features into tasks, writes code, or delegates work to GitHub Copilot coding agent
• Azure Agent (@azure) – generates Bicep templates, GitHub Actions workflows, and handles deployment to Azure
• Tech Analyst Agent (@tech-analist) – reverse-engineers existing codebases into specifications
• Modernization Agent (@modernize) – assesses technical debt and creates modernization strategies

The agents communicate through a set of slash commands: /prd, /frd, /plan, /implement, /deploy, and so on. You start by telling the PM agent what you want to build, and the system walks you through a structured pipeline all the way to deployment.

What’s interesting is that Spec2Cloud supports three distinct workflows. Greenfield is for new projects – idea to production. Greenfield Shell-Based starts from predefined architectural baselines (they have .NET and Python reference shells) and implements your requirements on top. Brownfield is for existing codebases – it reverse-engineers your code into specs and documentation, with optional modernization planning.

The whole thing installs into your repo with a one-liner curl script and adds agents, prompts, MCP server configuration, and optionally a dev container setup. It’s MIT licensed and not an official Microsoft product, though it clearly has Microsoft DNA all over it.

Here’s how the greenfield workflow looks end to end:

Real-world potential – beyond the demos

Ok, so the demos look cool. “From idea to production in minutes.” But let’s talk about where this could actually help in the real world.

The brownfield workflow is where I see the most immediate value. Every team I’ve worked with has at least one legacy app that nobody fully understands anymore. The original developer left three years ago, documentation is either nonexistent or hilariously outdated, and everyone is terrified to touch it. Running /rev-eng on that codebase to generate structured specs, feature docs, and technical task breakdowns – that’s genuinely useful. Even if the output isn’t perfect, having a starting point for documentation that links back to actual code files is better than what most teams have today, which is nothing.

The greenfield workflow is more interesting for rapid prototyping and proof-of-concept work. If you need to spin up a demo for a customer or validate an architectural approach quickly, having agents handle the scaffolding, infrastructure-as-code generation, and CI/CD pipeline setup saves real time. The fact that the Azure Agent generates Bicep templates and GitHub Actions workflows means you’re not starting from scratch on the infrastructure side.

For platform engineering teams, the standards integration through APM (Agent Prompt Management) is worth paying attention to. You can encode your organization’s engineering standards, security requirements, and architectural patterns into the system so that every generated project follows your guardrails. That’s the kind of thing that could scale well across larger organizations.

The template catalog and the VS Code extension add another layer – curated, production-ready templates for common scenarios like AI apps, data solutions, and app modernization. Think of it as Azure quickstart templates but with the spec-driven workflow baked in.

Shortcomings – and there are a few

Let’s be honest about where Spec2Cloud falls short right now.

It’s early. Very early. Several features are marked as “TODO” – including the VS Code extension installation method and the APM CLI. The template catalog showed zero templates when I checked the web interface. That’s not confidence-inspiring for anyone looking to adopt this in a production workflow today.

The agent quality problem. This isn’t unique to Spec2Cloud, but it’s a real issue. AI agents frequently don’t follow all the instructions you give them. The spec-driven approach assumes that specifications will be faithfully translated into code, but in practice, the gap between what you specify and what gets generated can be significant. You still need someone reviewing every step of the pipeline.

GitHub Copilot dependency. You need GitHub Copilot access, specifically the agent capabilities. That’s not free, and depending on your organization’s licensing situation, it might be a blocker. The agents themselves are configured to use specific models (o3-mini for PM, Claude Sonnet 4 for most others), which adds another dependency layer.

Azure lock-in. This is by design – Spec2Cloud is an Azure-first framework. If you’re multi-cloud or not on Azure, this isn’t for you. The deployment workflow generates Bicep and targets Azure services specifically. There’s no Terraform option, no AWS or GCP path.

Documentation gaps. While the repo has a decent structure with architecture docs, workflow guides, and examples, the actual depth of documentation is thin. The examples show two scenarios (elderly care AI agent for greenfield, marketing campaign app for brownfield) but don’t go deep enough to understand what the output actually looks like in practice.

No versioning. There are no release artifacts or version numbers. You’re pulling from main. For a tool that’s supposed to help you build production applications, that’s a bit ironic.

Spec2Cloud vs GitHub Spec Kit

The obvious comparison here is GitHub Spec Kit, GitHub’s own spec-driven development toolkit. They’re both in the same space but take notably different approaches.

Spec Kit is agent-agnostic, Spec2Cloud is not. Spec Kit works with 17+ AI coding environments – Claude Code, Cursor, Gemini, Windsurf, Copilot, you name it. Spec2Cloud is tightly coupled to GitHub Copilot agents. If you want flexibility in your tooling, Spec Kit wins here hands down.

Spec Kit is cloud-agnostic, Spec2Cloud is not. Spec Kit doesn’t care where you deploy. It’s purely about the specification and planning workflow. Spec2Cloud goes all the way to Azure deployment with Bicep generation and GitHub Actions CI/CD. If you’re an Azure shop, that’s a feature. If you’re not, it’s a wall.

Spec2Cloud has more structure. Six specialized agents with defined roles vs Spec Kit’s simpler slash command workflow (/specify, /plan, /tasks). Spec2Cloud’s multi-agent approach is more opinionated but also more automated – it tries to handle the entire lifecycle. Spec Kit is more of a planning tool that then hands off to whatever coding workflow you prefer.

Maturity. Spec Kit has a Microsoft Learn training module and has been analyzed in depth by Martin Fowler’s team and Scott Logic. Spec2Cloud still has TODOs in its README. The gap in community validation is significant.

The criticism applies to both. Independent reviews of Spec Kit found it generated excessive markdown (thousands of lines of specs for simple features), was significantly slower than iterative prompting, and didn’t result in better code or fewer bugs. Scott Logic’s review found traditional vibe coding was about ten times faster. These fundamental questions about whether the spec-driven approach actually delivers value apply equally to Spec2Cloud – maybe even more so, given that Spec2Cloud adds additional complexity with its multi-agent orchestration.

Here’s how they stack up side by side:

My take: if you just want to experiment with spec-driven development in general, start with Spec Kit. It’s more mature, more flexible, and has way more community feedback to learn from. If you’re specifically an Azure shop looking for an end-to-end framework that goes from idea to deployed infrastructure, Spec2Cloud is the more opinionated and Azure-native option – but you’re betting on a much earlier-stage project.

Where this is going

Spec-driven development as a concept isn’t going away. The idea of adding structure to AI-assisted coding makes sense, especially for teams where consistency and compliance matter. The question is whether dedicated frameworks like Spec2Cloud and Spec Kit are the right way to do it, or whether this functionality will just get absorbed into the AI coding tools themselves.

I think Spec2Cloud has potential, specifically because of its Azure-native approach. The brownfield reverse-engineering workflow solves a real pain point. The multi-agent architecture is ambitious and, if the agent quality improves (and it will – models are getting better fast), the idea of a coordinated virtual team handling different aspects of the SDLC could become genuinely practical. The fact that it comes from Microsoft’s GBB team and has landed in the Azure-Samples org suggests there’s organizational backing, even if it’s not an official product yet.

But right now? It’s a prototype. The TODO items, the empty template catalog, the lack of versioning – this is a framework that’s showing its vision more than its readiness. If you’re the kind of person who likes to get in early on tools and give feedback that shapes the direction, go for it. If you need something production-ready today, you’ll be disappointed.

My recommendation: bookmark it, try the brownfield workflow on one of your legacy apps to see what it generates, and keep an eye on the repo. Don’t build your team’s development process around it yet. The spec-driven development space is moving fast and Spec2Cloud’s tight Azure integration could make it the go-to choice for Azure teams – but it needs a few more months of baking.

Have you tried Spec2Cloud or Spec Kit? I’m curious what your experience has been. Drop a comment below :)

But before we begin let us get the obvious things out of the way which will surface for sure:

• Tomasz – are you an MVP?
• No.
• Have you ever been an MVP?
• No.
• So how you can say anything valuable about this program and all of this?

I have been actively taking part and engaging in Microsoft tech communities since more or less 2007 as a speaker, group leader, event organizer and many more. After joining Microsoft, I have been taking part in various communities as a speaker and was also supplying feedback to the MVP program about current and future MVPs. And now almost two years outside Microsoft I am also fully engaged in the Azure community in Poland in various aspects, so I strongly believe that I have a thing or two to say about what is going on and I can clearly see the bad things happening.

Cheating the system

No system is perfect, every system no matter what it does can be compromised, broken, “hacked” or however you want to call it, and the same thing happened to the MVP nomination and acceptance program. And what is the most common way to cheat the system nowadays to get your “dream MVP badge”? Online videos! Academies, schools, courses, online trainings. Especially now in “COVID times” it got super popular. But you may ask – what is the problem with that? It is a simple mechanism – people produced a whole bunch of usually shorter, sometimes a bit longer videos on a given subject – Azure, Office, Power Platform – you name it, they are usually well produced in terms quality but not in terms of content they try to show. But the main issue here is that always they are just a marketing campaign for fully paid courses of that author. True community work was never in any way connected so much to commercial work as it is now. People were doing things after hours, sacrificing their evenings, nights, weekends to do something valuable for the community and it was not promoting any of their businesses. And now? You produce useless videos for a couple of months, promote your paid course/academy/school whatever thanks to that and boom – MVP badge awarded – sic! IMHO all such activities should be banned from counting into the MVP recognition program – you either do something fully community based, or you do it commercially.

Forced diversity

This is a super sensitive topic in today’s world but important to point out. And I am talking here about gender diversity. All big corporations - tech included - struggle with diversity. They have different approaches to how to change that – most of them unfortunately are completely stupid and this has also touched the MVP program. Microsoft wants to drive diversity in this program which is super cool – I also believe that there should be more woman in IT in general but that is another topic – but just do not force it! There are instances where Microsoft awards the title in a category in which the girl/woman does not specialize in! Yes, there are more and less important MVP categories for Microsoft according to current trends, marketing plans etc. It is both surprising for that person and for the community. Microsoft – get it together – this not the way to go.

[UPDATE 2020-09-16] This paragraph does not imply in any way that girls/woman don’t produce high quality community engagements. It says that MSFT is not recognizing them in the right category because they want to built diversity in the category which is more important to them from a business/marketing perspective.

Low quality content

Back in the days – I sound old now – being an MVP meant to the other people, community, job market – wow! This person really knows their stuff. It was given to people with super in-depth knowledge about a particular piece of tech. You were THE person to go to. And now? Many of the MVPs produce entry level documentation-based content. Is that bad in itself? No, but it is time for Microsoft to change a bit the program, titles they give and for people who do basic stuff for communities which is valuable, get some other kind of award name. Also, the level of questions which are asked by MVPs on various forums, user groups etc. many times is just scary that they lack the basic knowledge about the technology that they are supposed to be experts in. Raise the quality not the quantity Microsoft!

The notorious requests for nominations

There are people believe it or not, who notoriously ask for an MVP nomination. Like literally they go around other MVPs in a particular category and ask each and every one of them to put a nomination for them (FYI currently only an active MVP or a Microsoft employee can nominate someone for the award). The only effect they get besides being annoying is that they cancel themselves out of the potential MVP nominees. How weak must be your contributions to the community that you have to ask around for a nomination? Don’t you think that if you are doing a good, quality job you will not be noticed? How, after receiving such an award, you can look at yourself in the mirror and say – god job XYZ! And another thing regarding this point – getting an MVP award should never be your driver for community work. Why? Because you may not get one and then what? Disappointment? Anger? Community work should be done with a “community focused” mindset. I want to do stuff for other people, share my knowledge, give them my time in various ways. Don’t think about awards. This is not a competition. Remember that you are giving, but also receiving a lot from others. As mentioned before, I have been doing tech community related activities for many, many years, and the most valuable thing I ever got from that time is the community itself. I have developed many relationships, done super cool things with so many people. The three letters you can put on LinkedIn will never give you that. And I know that even after many years I have so many friends around the globe that if I have a problem with anything – I can just “pick up the phone” (does anyone do that anymore?) and ask for help. That is the true value of taking part in tech communities.

The community leaders

Another category of people who get an MVP award are not necessary technology experts in the area they get the award in. They do a lot of community activities, they run user groups, meetups, organize events. Should they be recognized and awarded? Sure! But it is time for Microsoft to modernize and acknowledge this and create some more MVP categories for such people – something in the lines of “Most Valuable Community Leader/Member” (not everyone needs and can be a leader) maybe?

The summary

“Tomasz, why are you complaining about this? This is their [Microsoft] award. They can do with it whatever they want.” Sure, I understand that, but the problem is that they are not giving it to their employees but to the community which they are not running, not creating etc. so people in those communities shouldn’t just blindly be bound and respect all the rules that someone has put in place many years ago and now for multiple reasons they are lowering the bar, quality and the meaning of the program. With so many bad MVPs “on the market” in a couple of years this title/award will lose its value completely – it will not mean that you know the tech, it will mean that you fell into corporate buckets, rules and you just fit with what is the vision of someone far away and your contributions are meaningless to the real community.

For a lot of people being an architect is a step in their career… for some it is an end goal. There is nothing bad about this but most of the people which are “architects” are not Architects and only got lucky, where taken advantage of by some companies for many different reasons.

Let us start with consulting - this is the biggest pool of pseudo architects. Why you ask? Super simple - it is always better to send to a client or potential client an architect than a senior /software developer/engineer/IT specialist because:

1. it just looks better - “look - we have given you AN ARCHITECT”. Omg what a blessing I got form this amazing consulting company. No, you did not. You got scammed!

2. and the second reason which comes out of the first one is money - you can easily charge more for that kind person on a project.

The problem companies get with this kind of architects is that usually they do not do the actual job an architect should do… Many times, they are “just” senior (in terms of technical knowledge) employees which is also important part of being an architect role but lacking all the other skills. And the projects even when are done (can a project ever be done? ;) )… suck. They deliver, they code but nothing more what is needed from an architect.

Wanna be architects are another of my favorite “architect” type. People who have that title may even have the right experience, skills etc. but still… day to day delivery, coding/delivering solutions. Or on the other hand they do not have the right experience to be an architect and the things they propose, suggest, enforce is just full of non-sense. But “the architect has decided, we need to deliver this now…”.

All of this is not without the fault of recruiters. The amount of “architect” offers I get weekly is just insane. First of all, the required skill set… this goes both ways - it is either junior or so vast that it is impossible for a single person to have in-depth experience and knowledge about so many different technologies, products, solutions. Second issue is the money they offer for that kind of role. Having required experience to be an architect will not allow you to earn 15k PLN / month… c’mon people (yes, recruiters are also people) be serious and do not waste people time.

Ok… I have ranted a bit on bad architects on the market so what I would suggest for an architect to be? Here are some (not all) skills required from an architect IMHO:

• deep technical experience - only with that you can have success, you need to understand the technology you are going to work with, no matter if its software, cloud, solutions, infrastructure - you need to know your game!
• able to see the dots, lego bricks or puzzle pieces (however you want to call it) from a higher level - deep tech is super important but without the ability to step back and look at the big picture, the tradeoffs you need to make, sacrifice sometimes your beliefs in things that need to be “done by the book” in order to satisfy stakeholders is crucial
• this segways nice to the next point which is interpersonal skills and working with stakeholders. This part most of “architects” lack - you need to be able to talk to people, write to people, manage their expectations and satisfy them. If you cannot play “politics” in an organization - you will not succeed.
• not only do tech - some people are super hyped about doing tech all the time - the “sad” reality is that an architect needs to work in PowerPoint, Word documents, multiple charting solutions and more, and more…

And a general remark for those who are senior dev/IT pros who are trying to make that final “jump” to be an architect - seriously - do not force it! You may not have the required skills. You want more money? Architect role is not the way to go. There are plenty of companies which think in the proper way and will pay a good senior employee the money they deserve. If your company does not see that in you - change it! You want more recognition? Start doing extra stuff, showing in the team, organization that you think out of the box and it will be valued and respected.

Agree/disagree - feel free to leave a comment down below! :)

As Azure DevOps consists of 5 major buckets of features (Boards, Repos, Pipelines, Artifacts and Tests) I’ve put on a list of the 5 most useful extensions that everyone using Azure DevOps should install in their organization.

Boards

Ok… I will start by cheating a bit. Currently the most valuable extension for Azure Boards is Delivery Plans but as Microsoft announced some time ago this is going to become a full GA feature of Azure DevOps soon so you are getting an extra recommendation for now ;)

So the main extension I would recommend in in this section is Azure DevOps Open in Excel. Seems pretty obvious to have that functionality especially when you are a project manager / scrum master and you need to quickly work with a lot of work items for the team as this is a bidirectional feature so after making changes to the work items you just click_Save_ and it’s saves the changes back to the service.

The only problem with that extensions is that Microsoft claims it’s experimental and hasn’t been updated in some time now so use it at your own risk but for now - it gets the job done! :)

Repos

I think I had the biggest problem choosing a single extensions for this part of Azure DevOps but after long thinking it just has to be Code Search.

The way this extensions enhances your search experiences vs “not having” it is just amazing. No matter if you have a single project in your organization or hundreds of projects this is so great being integrated into various parts of the UI/UX experience and in addition giving you features like semantic ranking or filtering - you just can’t live without it after you’ve tried it!

Pipelines

Azure Pipelines is also pretty hard to choose just a single extension because it really depends on what you are developing so your needs may be different. But at the same time the amount of different extensions for this part of Azure DevOps is super impressive.

So as I mostly do Azure related stuff my pick goes to an extension which is currently in Private Preview and that is Azure Cosmos DB Emulator.

Azure Cosmos DB is a great non-relational cloud database with a bunch of amazing features (to put it lightly). It can also be run locally for you development purposes but with this extension you can incorporate it into your pipelines and for example execute tests during those pipeline runs and report back the results. This of course this runs in the most popular (and sometimes overheaped) technology these days which are containers but in this case it makes sense as it’s light and efficient :)

Artifacts

With this I will bend the rules a bit again. Why? Because Azure Artifacts is the youngest of the bunch and to be honest there are not that many extensions for this part of Azure DevOps. So I want to take this opportunity and recommend something which allows you (amongst many other things) interact with Azure Artifacts - Azure DevOps CLI.

This command line interface is great if you need/want to interact with Azure DevOps in a programmatic way and you don’t want to fiddle around with REST calls to the Azure DevOps API - which you can always do if needed or something is missing in the cli.

Tests

Here I had no doubts which extension it will be and the final one for today is Test & Feedback.

This is a great tool to give to your stakeholders/testers to test out what you have created, provide them with an easy way to create bugs/issues or other work item types directly in your project and tied to your test cases. The extension has two cool features:

1. First is that people with a Stakeholder license in Azure DevOps can do almost all the same things as people with paid licenses so this can cut down your cost quite a bit if you have a lot of non-developer people who need to test your solution
2. And the second part is that it also has a disconnected mode which means that you can use it not being even connected to a project in Azure DevOps and just export and share your feedback session.

Summary

So those are my Top 5 Azure DevOps extensions you should install. What are your favorites and recommendations? Feel free to leave a comment bellow the post :)

Girls in Tech - together with Adam and Maciek we have are super happy to invite you for an all day training which will prepare you for the AZ-203: Developing Solutions for Microsoft Azure exam. We will focus on the most important aspects of the exam, you will have a chance to do some hands-on-labs and ask us questions about the exam itself, technology it covers and learn Azure in general :)

If you are interested please register here and hope to see you on the 16th of December!

If you don’t do it you basically can’t solve errors properly or make new development decision based on your users behaviors, problems and needs. The easiest way to deploy APIs in Azure is to use API Management and the easiest way to monitor apps and APIs is Application Insights. One of the cool features of APIM is that you can have multiple Application Insights instances connected to it and assign them to specific APIs.

When you go to your APIM instance click on the Application Insights section in the menu in the Monitoring section. There you will find an option to add Application Insights instances to your APIM:

When you check the “User as default…“ this Application Insights instance will log requests and traffic for all of your APIs.

Now let’s add another Application Insights instance to our API Management

As you can see there is no option to have all APIs use this instance. Now what we need to do is go the API of interest -> Click on it -> go to Settings tab -> Scroll down. In the Application Insights section click Enabled and from the drop down section select the Application Insights instance of interest:

IMPORTANT: As the documentation states - using 100% sampling on production scenarios is not recommended as there is a potential of performance decreases.

I would recommend a trial&test approach for this to find the sweet spot for your logging needs and the performance impact on your environment.

Scenarios You can think of many but one of the most common ones is having an Application Insights instance per environment like Dev/Test(UAT/Staging)/Prod. Thanks to this you can use all the great features of Application Insights like bulging maps, handling request start to finish and tracing down any issues while te request reaches your API and/or backend.

This time with Kamil and Piotr we are pleased to invite you to a great all day workshop which will take place during Microsoft Tech Series 2019 - Microsoft Azure Training Day: Modernizing Data, Applications & APIs to the Cloud. If you want to learn how to utilize the DevOps approach for developing, deploying and maintaining modern applications this workshop is for you.

The whole day workshop will take place on the 22nd of November 2019 in Warsaw, it’s FREE so hurry and register on the event website!

Sessions

The conference was divided into multiple tracks:

• Dynamics 365
• Modern Desktop
• Optimize Your Teamwork
• Azure development

As you can imagine I went for the Azure track ;)

“Zarzadzanie tozsamoscia w chmurze hybrydowej (Managing identity in hybrid cloud)” by Michal Smereczynski

First session of the day and Michal did a great job as always despite the problems he had. What was the problem you ask? Well… I don’t who is to blame here but there was no cable prepared for the speaker to connect his/hers laptop (sic!). I don’t know if it was the fault of the organizers or tech crew but on a tech conference done by Microsoft which they do in Poland all year around this is so obvious… and when they finally got the cable to the speaker the cable didn’t work… Well… Too bad as Michal couldn’t do any demos but as I said - he did a great job anyway! :)

• IAM in Azure
• Hybrid identity
• Hybrid identity with Azure Stack

“Nowa odslona Azure Time Series Insights (The new edition of Azure Time Series Insights)” by Dawid Detko

This was a session I was super interested in as I didn’t have much chance to play with this part of Azure. Dawid did a great job of explaining the basics, scenarios where it can be used and showed a good demo for this with many new features on the plate. Fortunately the cable was working here so demos could happen ;)

• Azure Time Series Insights

“Zarzadzanie urzadzeniami IoT oraz IoT Edge z uzyciem uslugi IoT Hub (Managing IoT devices and IoT Edge using the IoT Hub service) by Kamil Mrzyglod, Daniel Krzyczkowski

Kamil and Daniel have some cool experience with this subject especially while working on the famous AzureTruck :) The session was again the type of “zero to hero” session where the guys showed some theory of IoT, how it is layed down in Azure, what is possible and went through a scenario showing some IoT devices and Azure Sphere on stage connecting to Azure and looking at the data that they pump there and how it can be aggregated, viewed. Good job guys!

• Azure IoT
• Azure IoT Hub
• Azure IoT Central
• Azure Sphere

“Modern computing in Azure” by Marek Grabarz, Lukasz Kaluzny

The last session of the day (must say that i didn’t even noticed how fast all of it went). Marek and Lukasz basically did a recap of new things in terms of computing which where announced at Build so Virtual Nodes in AKS, new things in Azure App Service, Service Fabric and the “Atlas” project and where it’s going into the future and some new API management goodness. Very good ending session for the day!

• Azure Kubernetes Service Virtual Kubelet
• Project Atlas - jump to 0:47:20
• API Management new features - jump to 45:30

Logistics

Venue

Let’s start with the place where the conference took place - Mala Warszawa. A very climatic place but I think not the best choice for this kind of conference. A pretty outer location in Warsaw which made a lot of travel in the morning for many people. Of course - many people on that side of Wisla were happy but still not an easy place to get to.

The second thing was the organization and guidance at the venue. The registration was super slow as the different tracks were not labeled so clearly. Second thing was that the rooms were all over the place - which is fine - as there were lines on the floor guiding to them and even more - they were in color! But… We had this badges for the conference

Why did no one thought about corelating the line colors with some color on the badge? It would be so much easier for starters to have a yellow indicator (that was the Azure track line color) on the badge and it would be clear were to go.

Also the rooms had pillars all over them so comfortable viewing was not possible from all seats.

Lunch

Lunch was served in a form of foodtrucks which I’m all in for! Great idea to spread people around, it’s always better tasting then the catering lunch provided by different companies and gives interesting options. The only issue this time was that we are having some heavy rains recently in Warsaw but fortunately after heavy rains in the morning it stopped so we could enjoy the food outside or just take it into the venue as there was space to eat comfortably standing or sitting. Good job organizers!

Also outside we could explore the Azure Truck mentioned already in this blog post :)

Expo

There was also a small expo section where you could visit booths of some Microsoft partners, Microsoft hardware so a nice addition to the whole experience.

Summary

Overall it was a good event to attend. A lot of familiar faces, a lot of possibilities to network and interact which is also a very crucial part of such events besides the sessions which are presented.

I think that the overall conference score would be 7/10 so there is a place for improvement for the organizers next time ;)