Now that Copilot Cowork is generally available, a lot of us in Healthcare & Life Sciences are putting it to work — drafting summaries, running research prompts, moving through tasks faster than ever. But with GA comes something worth paying attention to: Cowork now runs on billing and credit usage. And if you're not keeping an eye on that, it's easy to burn through credits without realizing it.

Here's the good news: you don't need to dig through settings or a billing portal to check (as an end user). There's a command built right into Cowork.

The trick: /cost

I actually picked this up from a peer this morning, and it's about as simple as it gets:

1. Open your Copilot Cowork session — one you've already been working in.
2. Go down to the prompt box at the very bottom.
3. Type /cost and hit enter.

That's it. Cowork instantly shows you the credit usage for that task, right inline. No extra clicks, no leaving your workflow.

 

 

Why monitoring can matter

In healthcare, we're mindful of how we use every resource — and AI consumption is no different. As teams lean on Cowork for more of their day-to-day, a quick credit check helps you:

• Stay aware of what a given task actually costs.
• Budget intentionally across sessions and projects.
• Have the data when someone asks, "How are we using this?"

A 10-second habit now saves you from surprises later.

One honest heads-up

A heads up: a few of my peers haven't gotten /cost to work just yet, so your mileage may vary. In the cases I've used it, though, it's been reliable. If it doesn't show for you right away, you're not doing anything wrong — the feature is still rolling out.

Try it

Next time you're in Copilot Cowork, drop a /cost at the bottom of your session and see your credit usage for yourself. It's the fastest way to stay on top of consumption across your different sessions.

Give it a shot — and let me know if it works on your end.

Go push some buttons. 🚀

---

Do data centers in space make any sense? Time for a rare summer-time Geek Out! Richard chats with Carl about all the hype surrounding building orbital data centers for AI workloads. Richard points out that enthusiasm for this idea surged in the fall of 2025, when the backlash against ground data centers peaked. But could you actually make the orbital data centers work? The conversation works through a reasonable satellite design, covering off the details of power, cooling, communications, and satellite management. But how many satellites would be enough? This leads to an exploration of Kessler Syndrome, where orbital debris gets out of control - and what we can reasonably do about it. Which leads to another idea - how do we make ground-based data centers not suck?



Download audio: https://dts.podtrac.com/redirect.mp3/api.spreaker.com/download/episode/72559040/dotnetrocks_2007_data_centers_in_space_geek_out.mp3

---

Welcome, Massimo Banzi of SuperModerno and co-founder of Arduino

• Introduction and SuperModerno: Massimo introduces himself as a “friendly nerd” and discusses his new project, SuperModerno
• The project aims to explain the “behind the scenes” of technology to prevent people from becoming “slaves to the platform”
• The History of Technology: Massimo expresses his passion for technology’s history, emphasizing non-American innovators to show Europeans they can also lead in technology, citing the UK-based origins of the Arm processor
• The Legacy of Olivetti: He highlights Olivetti (founded in 1908), which moved from typewriters to creating the Programma 101, the first desktop computer used by NASA to compute orbits for the Apollo program
• Design as a Differentiator: Olivetti was the first tech company to apply design to everything (products, posters, and architecture)
• This inspired Massimo’s concept of the “invisible touch”, the idea that consistent, intentional design creates a unique connection with users and gives a company a competitive edge
• The Interaction Design Institute Ivrea (IDII): Massimo’s path led him to IDII, located in the former Olivetti research building, where he transitioned from a two-week sabbatical to a four-year stay
• Learning by Making: To help students with no electronics background, Massimo drew on how he learned as a seven-year-old (“learning by making”) to remove the friction of interacting with technology
• The Founding Team: He met Tom Igoe (ITP) and David Cuartielles, and they realized students were afraid to be creative because they feared “blowing up” expensive tools like the Basic Stamp
• The “Pizza and a Beer” Price Point: Massimo aimed for a hardware cost of 20 Euros, roughly what a student would spend on a pizza and a beer, to encourage experimentation
• Building the Platform: Along with David Mellis, the team adapted Processing (a language for artists) by “surgically” replacing Java with C++ to create the Arduino IDE
• Ivrea Manufacturing: Leveraging the industrial base of Ivrea and Torino (the “Detroit of Italy”), Massimo was able to find local PCB manufacturers and assemblers just a short drive away
• From Hacking to AVR: Massimo’s early work involved hacking satellite TV PIC chips for soccer fans, but mentor Bill Verplank encouraged him to use AVR microcontrollers because they could be programmed simply in C
• Enabling Creators: Massimo shares stories of how Arduino enabled others, such as Josef Prusa, who started with Arduino as a teenager before building his global open-source 3D printer company
• The Innovation of Simplicity: Massimo argues that Arduino’s true innovation is the user experience
• This is measured by the “Time to First Blink”, the goal for a user to go from downloading software to blinking an LED in five minutes
• Standardization and “The Core”: Arduino became an ad-hoc standard by providing a compatibility layer across different microcontrollers
• Massimo believes in having a “small slice of a really large pie” by allowing other architectures to work within the ecosystem
• Hardware Architecture and the “Lasagna”: Inspired by the PC104 format, the board uses a layered approach where modules stack like a lasagna
• The “Shield of a King”: The name Arduino comes from King Arduino of Ivrea; David Cuartielles suggested that since the board was named after a king, the add-on modules should be called “Shields”
• Hardware Design Choices: The board fits a credit card size (to stay within the free version of Eagle software) and is blue because that color was thought to be less tiring for workers’ eyes
• Happy Accidents: The unique shape was chosen to be “ourselves instead of everyone else”
• During the design process, Massimo inadvertently moved a connector by half a step, creating an offset header that they kept for consistency after the first few thousand were made
• The Discovery of Auto-Reset: During a workshop in Germany, Massimo solved the frustration of manual resets by soldering a capacitor to the DTR pin, allowing the software to trigger the reset automatically
• The US Market and Legal Battles: Tom Igoe’s adoption of Arduino at NYU helped the US become the project’s single biggest market
• This growth led to a difficult legal battle for control of the brand against a former partner
• Support from Arm: Massimo credits Arm Ltd (and CEO Simon Segars) for providing the strategic support that allowed the founders to regain control of the company. Massimo believes this is the first time he has talked about the role of Arm in the difficult legal process.
• Industrial and AI Expansion: Partnerships with Intel and Microsoft (Windows 10 IoT) led to early forays into TinyML (AI on small boards) back in 2017
• The Qualcomm Acquisition: In October 2025, Qualcomm acquired Arduino, which Massimo sees as essential for bringing “advanced silicon” into the family to handle the increasing complexity of technology
• The “Arduino Formula” and Layering: Massimo views Arduino as a formula for simplification that can be applied to anything, including complex Linux machines like the Uno Q
• This is achieved by building in layers, where beginners use high-level abstractions and experts can “strip away” layers to reach the bare metal
• The Future Vision: Massimo looks forward to the “Arduino Formula” being applied to new fields, stating he is waiting for someone to develop an “Arduino for biology” using CRISPR and DNA technology

Download audio: https://traffic.libsyn.com/theamphour/TheAmpHour-726-ArduinoMassimoBanzi.mp3

Much of the conversation around AI in software development has focused on code generation. That is understandable. Code is visible, measurable, and easy to compare against the way developers have traditionally worked.

But the more interesting shift may not be that AI can write code. It may be that AI is changing how quickly ideas become tangible.

For years, software development followed a fairly familiar path. A product idea would move from discussion to requirements, from requirements to design, from design to implementation, and from implementation to testing and review. Each step served a purpose. Product teams clarified intent. Designers shaped the user experience. Developers translated ideas into working software. Testers helped validate the result.

This process exists because building software is complex. It requires specialized knowledge, collaboration, and careful decision-making.

At the same time, every handoff introduces friction. Requirements can be misunderstood. Designs can be interpreted differently than intended. Implementation can reveal gaps that were not obvious earlier. By the time stakeholders see something working, weeks or months may have passed.

That delay matters because many product decisions are based on assumptions. Teams often do not know whether an idea is useful until someone can interact with it. The longer it takes to reach that point, the more expensive learning becomes.

AI is beginning to compress that cycle.

From Idea to Prototype

Recently, I discussed this shift during a conversation about AI-assisted development and tools such as Vercel v0. What makes these tools notable is not simply that they can generate interfaces or code. Their larger impact is that they allow ideas to become concrete much earlier in the process.

A developer who is not a designer can still explore a reasonable user interface direction. A product manager can turn a rough concept into something visual enough to discuss with a team. A designer can move beyond static mockups and experiment with more interactive flows.

This does not mean the generated output is ready for production. In many cases, it will need significant review, refinement, and integration. But production readiness is not always the immediate goal.

Sometimes the goal is to learn.

A rough prototype can help a team discover whether they are solving the right problem. It can expose missing requirements. It can make abstract conversations more concrete. It can help stakeholders react to something real instead of imagining the same idea in different ways.

In that sense, the value of AI-assisted prototyping is not only speed. It is earlier feedback.

The traditional path often looked like this:

Idea → Design → Development → Prototype

AI introduces the possibility of a shorter exploratory path:

Idea → AI-assisted prototype → Feedback

That distinction matters. The prototype is not the final product. It is a tool for learning.

The Real Value Is Learning Faster

Productivity is often discussed in terms of time saved. How much faster can a developer complete a task? How many lines of code can be generated? How many hours can be removed from a workflow?

Those questions are useful, but they can be too narrow.

The more meaningful question may be:

How quickly can a team learn whether an idea is worth pursuing?

Software teams do not only lose time by writing code slowly. They lose time by building the wrong thing, misunderstanding user needs, or discovering too late that a solution does not fit the problem.

AI can help reduce that risk when it is used to support exploration. It allows teams to test more ideas, compare more directions, and make decisions with more context. A working prototype, even an imperfect one, often creates a better conversation than a written description.

This is where AI becomes less about replacing individual tasks and more about changing the shape of the workflow.

Expertise Becomes More Important, Not Less

As AI tools become more capable, it is natural to ask whether specialized expertise becomes less important.

If AI can generate a design, write code, create tests, and draft documentation, what happens to the people who previously performed those tasks?

My view is that expertise does not disappear. It moves closer to judgment.

AI can generate options, but it does not inherently know which option is right for a specific business, team, user, or system. It can produce an interface, but it cannot fully understand whether that interface supports the right user behavior. It can generate code, but it does not automatically know whether that code is maintainable, secure, accessible, performant, or aligned with the architecture of an existing product.

The work shifts from producing every artifact manually to evaluating, directing, and integrating what AI produces.

That shift raises the bar for technical judgment. A less experienced person may be able to generate something that looks impressive. But knowing whether it is appropriate still requires experience.

This is especially true in production environments. Real systems have constraints. They have legacy decisions, security requirements, performance expectations, accessibility standards, design systems, deployment pipelines, and organizational tradeoffs. AI can help navigate those constraints, but it does not remove them.

In many cases, AI makes expertise more visible because it increases the volume of output that needs to be reviewed.

Engineers as Orchestrators

One of the most important changes I see is the gradual shift in how engineers spend their time.

Historically, software engineering has been strongly associated with creation. Developers wrote code. Designers created mockups. Testers wrote test plans. Documentation was created manually. Each artifact required direct human production.

AI changes that relationship. It can assist across many of these activities, which means the role of the engineer increasingly involves orchestration.

The engineer’s job is not always to create every artifact from scratch. More often, it is to define the problem clearly, provide the right context, guide the tools, evaluate the output, and connect the pieces into a coherent solution.

This requires a broad set of skills: systems thinking, communication, architectural judgment, product awareness, and the ability to understand tradeoffs. It also requires knowing when not to use AI, when to slow down, and when a generated answer needs deeper scrutiny.

That is a different kind of work from simply writing code faster.

It is also a more strategic kind of work.

Career Implications

This shift has implications beyond a single tool or workflow. It affects how professionals think about their careers.

For a long time, many technical careers were built around specific skills or platforms. Learn a language, framework, or tool deeply enough, and that expertise could carry a career for many years. Technical depth still matters, and it will continue to matter. But relying on one skill set alone may become more fragile as AI makes certain kinds of execution easier.

The professionals who seem most prepared for this shift are not abandoning expertise. They are combining expertise with adaptability. They build strong networks, communicate clearly, teach what they know, develop reputations, and continue learning as the tools around them evolve.

AI does not eliminate the need for depth. But it rewards people who can apply their depth across changing contexts.

That may be one of the more important career lessons of this moment. The value of a professional is not only in what they can produce manually. It is also in how they think, how they decide, how they collaborate, and how they guide work toward meaningful outcomes.

The Shift From Output to Judgment

AI is lowering the cost of execution. More people can create more artifacts more quickly than before. That includes code, designs, tests, documentation, prototypes, and content.

But when output becomes easier to generate, judgment becomes more important.

The differentiator is no longer simply who can produce the most. It is who can decide what should be produced, why it matters, and whether it is good enough to move forward.

For software teams, this means the highest-value work may increasingly happen before and after generation: defining the problem well, setting constraints, reviewing tradeoffs, validating assumptions, and making decisions based on context.

The future of software development may not be about building everything manually. It may be about orchestrating people, systems, and AI tools to build the right things.

And it suggests that the most important question is not whether AI can help us move faster.

The better question is whether we are using that speed to learn better, decide better, and build better products.

Related Conversation

This post was inspired by a recent conversation I had on the We Love Open Source podcast at the All Things Open conference, where we discussed AI-assisted development, tools like Vercel v0, and how the role of software engineers is evolving.

You can watch the full conversation here: