Related to my prior post, I believe there’s a shift happening that builders and companies aren’t really thinking about today but will be forced to soon.

Over the last year, everything has been about adoption and usage. “How can I get my team to use AI,” “how can we create systems that support safe and high quality AI enabled work” etc.

These pursuits have made sense in the context of the reality of the time. We’re likely somewhere near an inflection point for “everyday” users. AI companies still subsidize usage in an attempt to create leverage and switching costs, enterprises continue to experiment broadly, and the implicit message often still is: get in, figure it out later.

The tokenmaxxing signal from the likes of Uber, Amazon, Meta, etc. are showing what’s coming next. While frontier models got all the attention, the shift is now going to be focused on real measurable efficacy.

Obviously there will be exceptions where the power of a Fable level model is essential, but my hypothesis at its core is that the winning companies will be those who harness the right model for the right task, in the right system and keep their switching costs low.

Counter to Sam Altman’s view that OpenAI should be viewed as a utility that we’re all billed for in perpetuity, I think things will go in a different direction, or at least I hope they will.

The sustainability problem is real

The raw dollar cost of frontier models might be the focus of this piece. Fable, by Anthropic’s own policy defaults to consuming 2x faster than Opus 4.8, an already extremely “hungry” model. The results are powerful (or were until it was pulled).

However, other concerns such as power consumption, water usage, and compute cost aren’t abstract concerns anymore, as they’re showing up in infrastructure budgets, sustainability reports, and board conversations. These aren’t problems that scale away. If anything, unchecked AI usage makes them worse. Maybe data centers in space will be the answer. Maybe not. Another post for another day.

The same tension is playing out internally. Teams with broad, undisciplined access to expensive frontier models are generating a lot of AI activity. Whether that activity maps to business outcomes is a different question that hasn’t really been answered.

Or, to some degree, it has. Budgets are tightening and scrutiny on “is this really doing anything good for us” is increasing.

Just like everything else in time, the “free pass” is going away because of real costs.

Lock-in is fake.

AI providers are betting on lock-in. The theory is that once enterprises go deep on a platform, the switching costs keep them there regardless of price changes. That may be true at the infrastructure layer. It’s also true at the hardcore workflow level to some degree. I do not believe it is true at the model / harness level per se.

Additionally, tasks like summarization, classification, drafting, analysis, routing etc. do not require the most capable model that exists. You need a model that’s capable enough, fast, secure, and cheap. You also need it to be where you’re doing your work already, where you’re collaborating. Ideally not “another tool.”

Perhaps one but not a half dozen. And then there’s the theory that as the cost of building goes down that Anthropic will just build everything and that every piece of software on the internet will magically be replaced. I would venture to say that the quality of the experience and the ability to seamlessly collaborate will win out over one provider eating the world.

The companies that built adoption strategies around “use the best model for everything” are going to have a reckoning when the subsidies roll back. The companies that built a framework for matching model capability to task requirements are going to be fine.

Measurement is still underrated.

Before you can optimize AI usage, you have to be able to measure it. And most organizations can’t. They can measure token utilization, but rarely measure where it gets them.

Not because the tooling doesn’t exist, but because the foundational work hasn’t been done. Operational processes are poorly documented. Baseline metrics don’t exist. There’s no clear definition of what “better” looks like, so there’s no way to know whether any of the AI investment is actually working. Sounds familiar if you’ve ever come into an organization and tried to drive any type of change. Those problems didn’t magically go away as AI became embedded in work.

Simply, you can’t improve what you can’t measure and in order to not be left behind, companies are (often) spending faster than they’re learning.

How to address this in practice

The companies who get this right will treat AI enablement the way they treat any serious capital investment, with governance. Yuck! But, that doesn’t have to be a four letter word that elicits visceral reactions. It’s going to give us an opportunity to really rethink enablement in a way that values:

• A clear framework for evaluating which tasks warrant which model tier

• Cost attribution at the team or workflow level, not just aggregate spend

• Outcome measurement tied to business metrics, not just usage volume

• Regular audits, the same way you’d audit any significant vendor relationship

Having the right leader and team working through this will make literally all the difference in the world. Either teams will hate this, cry foul, etc. or they won’t really have to think about it at all. It’ll “just happen” because you’ve designed an incredibly effective system for making it work in a way that feels useful to teams.

This likely means a new role or set of roles emerge:

There’s a category of work that doesn’t really exist yet at most companies: the people who sit at the intersection of model capability, business process, and measurement.

Not prompt engineers. Not ML engineers. Something more like an AI program architect; someone who understands the model landscape well enough to make intelligent tradeoffs, understands the business well enough to design for actual outcomes, and can build the measurement infrastructure to know whether it’s working.

Over time, these roles will likely absorb a lot of what traditional eng ops and product ops teams do today. The organizations building these capabilities now are going to have a significant head start.

How does this all happen

We’ll likely see one of two archetypes emerge. Treating this period of time as a serious investment in capability, doing the foundational work, building the measurement frameworks, getting disciplined about where to use what and how and for what, and those who don’t do those things and either give up or keep writing checks for things they can’t really see.

The second group is going to hemorrhage cash on diminishing returns. They’ll have the AI spend line on the budget and nothing concrete to point to for it. And increasingly, the questions that will be asked will be hard to answer without the infrastructure to answer them in place.

The first group will have compounding advantage built not on having the best models, but on knowing how to use them.

There’s probably a few companies that spin out of this too as their core competency that go well beyond what LangChain or OpenRouter does today but build on a similar foundation.

As employers continue to create fear driven cultures around AI layoffs, workers will trend towards what creates the perception of “value creation” and safety. At times, this will be done regardless of the “actual value” of the work being done.

You don’t have to look far to spot this behavior in action.

So, what are we really doing here? What's being optimized for? Who are we trying to please (fool)?

Look, I do not actually know where to put myself on the AI spectrum at the moment. I am someone who has actively driven to put AI strategies and structures into place from zero in multiple organizations.

I have half a dozen solo projects of varying levels of seriousness to learn new skills, understand emergent patterns, prove concepts and solve problems, small and large.

I leverage Claude and Perplexity in day to day life for things well beyond research or cited web searches and towards more of an embedded operating system to pieces of life.

That said, things I have always valued is using the right tool for the right purpose and intent and being efficient.

The sheer idea of “maxxing” is antithetical to how I think in general, so this always rubbed me the wrong way. That said, I had to dig deeper to ensure that it wasn’t some strange FOMO driving the sentiment.

The longer I sit with it, the more I’d like to think that I understand it.

People are grasping at straws right now. They want to keep their jobs. They want to appear “innovative.” We are trained to chase rewards. All of us have watched people actively not solve the real problem at hand because of perverse incentives at play, and that’s exactly what I see happening in many businesses right now.

To create a healthy culture of AI adoption, I truly believe that it’s a very human thing you must tap into. Find real problems, teach people skills, scaffold them so that it doesn’t feel daunting, scary or out of reach. And, most critically, make it clear what the objective at hand is.

I have watched many people and companies completely lose sight of any actual goal to solve a problem or help a customer and simply obsess about tool adoption and usage.

My favorite analogy thus far is that we’re watching an Uber Eats completion for miles driven with no regard for meals delivered. You solve no customer pain, but you sure did do a lot of stuff.

Keep it real simple. Solve a problem, care about people.

AI should be used to let people do the job they were hired for at their maximal level of impact. How much time spent on toil can you reduce for an engineer, how much time saved on data synthesis, problem diagnosis and triage etc. to get to actually solving a problem.

Move what you measure, adjust what you reward and the behaviors will follow.

If you want a counterpoint to this perspective which is arguing for aggressive but pragmatic adoption of these new tools which will and are fundamentally reshaping the way we work, look no further than this.

It’s an understandable position, if not a bit extreme in approach. I think this is akin to saying “We’ve never had cars before. Here’s a car. Now, everyone is going to drive as much as possible all the time, no matter where, for what, how fast, safely or in what direction. Just go. Just keep going until the wheels fall off.”

We likely are observing a fundamental shift away from a division of labor model in software development in a traditional sense and towards a hyper collaborative culture focused on co-creation. Here, I’ll explore some of my thoughts on this evolution and how it can come to life within organizations.

Before: Sequential waterfall masquerading as agile

• Even at its most efficient, the process for building software is still largely linear, whether you’re doing Kanban, Agile, Waterfall or some mix of all these smashed together as most of us are accustomed to

  • Product spec → Design mocks → Engineering tickets → QA —> Release —> Repeat

  • When handing off work, there’s inherent lost context and waste that is difficult to quantify and has become all but expected.

Soon/Now: Real-time collaborative execution - seeing, reacting, adjusting in real-time

• Example: Designer manipulating live code while PM adjusts business logic in natural language

• Engineer prototyping directly with customers while researcher captures insights programmatically

• The medium of creation becomes shared, fluid and more instantaneous

• To consider: Can Conway's Law become obsolete when the communication structure itself becomes fluid; the inherent ability to collaborate more in real time should help to ease the pain of Conway’s law on organizations but requires openness towards this method of working by teams

From Collaboration to Co-creation

As we experience this shift, we’re actually moving from functional collaboration within teams and towards co-creation within teams. This starts to tear down traditional barriers and boundaries, many of which typically create some comfort within teams because members know their lane but also create a real amount of friction and frustration.

• Traditional model: Deep expertise in narrow domains

  • Engineers who "don't do design"

  • Designers who "can't code"

  • PMs who are "just the business side"

• Key shifts that become enabled:

  • The "latency collapse" - as iteration cycles go from days to minutes

  • The death of artifacts as boundaries (PRDs, design files, tickets); these may still be useful but as real-time inputs to generate alignment and discussion and to drive a usable output

  • The closer the cost of experimentation moves towards zero, you spend less time planning and more time testing and iterating on feedback more immediately

• AI-enabled model: Domain expertise applied through universal tools

  • Everyone becomes a "builder" with different lenses that underscore their deep expertise and background, so the power and applicability of specialized skill is not negated, but how it is applied heavily evolves

  • Example: A designer using their spatial reasoning to architect system flows

  • Example: An engineer applying systems thinking to user journey optimization

  • Example: A product manager directly building a feature to solve a known customer problem

Natural Language becomes standard for human-computer interaction:

English (or team's agreed upon language) as the programming language isn't metaphorical. It is literally how the team is collectively engaging with the interface they’re manipulating. We are and will move to natural language as the programming language of the future, with the syntax and output in terms of code being just a bi-product vs the primary knowledge base.

New team dynamic: "Socratic development" - progress through questioning will evolve, and therefore the ability of teams to communicate effectively with each other and operate in a low ego way will be critical. High engagement, low attachment must become the norm and expectation of teams.

The emergence of "linguistic code reviews" to understand what functionally must change vs what must change from a syntax standpoint. In this regard, the code itself is yet another temporary artifact, despite it “living” within the shipped product. The primary work product itself is not the code but the solution it enables. Yes, code is still shipped, but less of the focus is on the nature of this artifact itself.

Beyond the natural language itself it underscores the key skill needed to succeed - Communication. While effective communication, empathy, soft skills and the like have been increasing in importance for years, they are now going to be table stakes for high performance in every function and situation.

This will fundamentally challenge certain worker types and teams and require material change and evolution

The Paradox of Increased Agency / The Ownership Paradox

Everyone can build anything → Curation becomes critical

• We will make a shift from "who has permission" to "what should we build” as a collective perspective from the team.

• New role of taste and judgment becomes critical as execution is commoditized. Taste and judgment become more important than ever. The ability to ship instantly or more instantly could lead to a proliferation of terrible ideas making their way to production if teams do not take care to emphasize things like taste and judgment in their work. These qualities become key skills, not just squishy sounding words.

• At the bottom of this, shared ownership should actually increase perception of agency vs diminish it, although it will not feel that way at first. Pride of authorship has always been a bug not a feature, and now we can further eradicate this.

Speed of iteration changes decision making:

• When a strong decision making framework is in place and there’s high trust within the team you can move from:

  • "Let's plan this carefully" to "Let's try three versions"

  • A/B testing at the ideation phase

  • Example: Testing 10 landing page concepts in an hour vs one in a week

  • Experimentation cultures have elements of this today, but this moves experimentation even further up in the flow towards ideation.

How to measure this shift:

• Begin to focus on outcome velocity, iteration count, user impact speed, which are not solely novel, but novel in that the entire team would now be measured against these metrics in a more focused way. More on this later.

Organizational Antibodies and Adoption Patterns

The identity crisis: When everyone can do everything, who am I?

• PMs threatened by the ability for everyone to be testing and learning

• Engineers threatened by PMs shipping features

• Designers grappling with engineers making aesthetic choices

• Mitigation: Celebrating lens diversity over tool ownership, meaning that the varying perspectives on the team are still incredibly important but tools / functions are less sacred.

• We have long talked about the three-legged stool, but ironically those legs never quite touch or intertwine except to hold up the seat…interestingly a very apt picture of three separate functions coming together at the end of a process to achieve an outcome, so we’ll need a new metaphor for what we’re creating here wherein the collaboration is much more intertwined and the functional lines are more blurred. Jazz ensemble, triple helix?

New performance metrics needed:

• Moving from "lines of code" or "designs shipped" to "customer problems solved"

• Attribution becomes collective vs individual by default

• Incentives for teams must be aligned to value creation, problem solving vs traditional box-ticking to enable the next step in the assembly line

• The biggest barriers aren't technical but cultural and structural…

  • Traditional performance reviews break in a no-ownership model. No more “well I did my job” sufficing to incentivize and reward an individual, so much more measurement moves towards the collective. This becomes a management challenge to better evolve assessment practices to understand how each team member is contributing to the key outcomes desired and whether team members are making the people around them better as they move through the creation process.

  • The threat to middle management and technical gatekeepers. There’s plausible continued movement towards a world with fewer full time middle managers and technical gatekeepers. I do not believe this means that management as a skill goes away, that architecture goes away, etc. I actually think that this evolves towards someone who has acumen in each area and a high level of ability to be a player coach. Many organizations have long moved away from the ivory tower approach, and I simply see this as furthering that. Ample space and value must be placed on skilled leadership and management in this new model, however paradoxical that may seem.

  • The "expertise identity crisis" - when your specialty feels commoditized, what’s your identity within a team. As stated earlier, I do not believe that this erodes the value of unique skills, backgrounds or perspectives, but it does challenge and morph it in ways that will reward those who are eager to see the collective succeed and punish those who want individual credit at the expense of others.

The New Team Topology

Teams reshape around problems, less around functions. The most valuable member of the team becomes the “glue person” who brings the team together, achieves shared context, and helps guide towards outcomes and away from task execution prowess. This is already happening with the notion of Pods, Durable Teams, etc. but this likely becomes a much more standard way of working. Teams may sustain in order to maintain chemistry but their flexibility is more around a problem / opportunity space than a depth of technical background. ie we begin to move away from “but x is the only one who understands this system, so they have to be on this team” and towards a world where teams are formed and maintained based on their collective expertise of solving a real problem. Finally, leaders will fundamentally be X shaped in nature much more than has been true to this point in time.

Building blocks:

• Engineers: From syntax masters to system thinkers and constraint definers

• Designers: From pixel pushers to experience philosophers and pattern recognizers

• PMs: From requirement gatherers to context providers and success definers

• "Problem pods" that form and dissolve more dynamically, particularly as the speed to solve a problem goes up and the cost goes down.

• The rise of the "context keeper" role

• New skills: “prompt architecture” to align teams, such that the inputs are clean, therefore ensuring the outputs are clean

• Expertise becomes about knowing what to ask for, not how to build it

• New hiring criteria: curiosity quotient over technical prowess

The Competitive Advantage of True Collaboration

Speed compounds differently and we look for different 10xers:

• Traditional: 10x individual productivity = 10x output

• Collaborative: 10x individual productivity = 100x exploration space

• The traditional definition of any single 10x individual somewhat dissolves. Conversely, the dynamics of the team itself become much more critical. Think a pro sports team metaphor. Every player is fluent in the sport, but optimized for not only their specific depth of skill but as to how they contribute to a winning team.

Emergent innovation from boundary dissolution:

• Best ideas come from intersection of disciplines

• Example: Designer's mental model improving database schema

Where to Begin?

Strategies for gradual transition without organizational rejection. A material risk here is that organizations that are fully optimized for the traditional way of working may face real challenges in evolving, as it will feel like moving the cheese, forcing an arbitrary change that is unnecessary or devaluation of skills. This is largely a mirror of human nature in change resistance. To overcome, we’ll have to find champions, create an environment of shared success and rewarding learning and incentivize the behaviors that we want to see. This is true in any organization, but one that is being asked to fundamentally change even when things are “working as they should” has to be approached thoughtfully.

From ownership to stewardship:

• Code/designs/specs as community gardens where everyone can engage productively

• Ego dissolution exercises (pair / swarm everything)

• Celebration of collective wins only vs individual heroics

New hiring profiles:

• Curiosity quotient over domain expertise becomes the norm and expectation

• Comfort with ambiguity is a must, because the inherent nature of co-creation means that the level of concrete thought and detail going into many executions will be lower than before

• Systems thinking ability is a must have to lead. If you cannot understand how pieces come together and respect and assist those things, you will struggle to lead.

Pilot program structure:

• Ideally start with a greenfield project if possible to test this while limiting “drag”

• Mixed skill pod of 3-4 people who exhibit collaborative tendencies, communicate well, have high skill and low ego. You may quickly find you run thin on people who match this criteria per the points above about what we optimized for before vs what we will optimize for in the future

• Shared KPIs, no individual attribution - this will be really hard, but where the team succeeds, celebrate and share the wealth of that success

• Weekly rotation of who "drives" different aspects while respecting the domain expertise each team member brings to the table

• Embrace discomfort throughout this process

Tool stack considerations:

• Choose tools that are becoming ubiquitous or that may be already in limited use in the org to ease the learning curve:

  • Cursor/Windsurf for collaborative coding

  • Figma's Dev Mode as early example

  • Evolved use of Jira / Confluence: Natural language requirement tracking - moving from strictly tickets and more towards collective inputs —> shared outputs

• Emphasis on more synchronous collaboration and more real time feedback being welcomed

Building blocks:

• Start with "AI pair programming" sessions across disciplines

• Create "role rotation sprints" where team members use AI to work outside their specialty and are welcomed in and taught

• Focus on "outcome ownership" instead of "feature ownership"

• Build "learning loops" that are faster than "development loops" - rapidly learn to not only speak each other’s language but to productively ask questions, learn and adapt quickly

• Measure "time to user value" not "time to deployment"

Key Tensions I’ll Explore Further in the Future:

1. How do we maintain quality when everyone can ship?

2. What happens to senior/junior dynamics?

3. How do we preserve institutional knowledge without silos?

4. Where does accountability live in a collective model?

In Closing:

Ideally, the future is not looked at as a completely zero sum game wherein AI just replaces all of us and our effective working model completely collapses. More ideally, it helps to dissolve boundaries between roles and within teams. The teams that will win will be those that embrace this dissolution and rebuild their collaboration culture from first principles. This is not about moving around people on existing teams, it’s about fundamentally rethinking what it means to build and create and be a part of a team altogether.

Useful reference materials

• Reference: Marty Cagan's discussion of feature teams vs empowered teams and follow on post

• Use case: Replit Teams

• Reference: Anthropic's Constitutional AI

• Reference: Kevin Kelly's "1000 True Fans" applied to internal product decisions

• Reference: IDEO's "T-shaped" professionals concept, but evolved to "X-shaped"

• Reference: Ethan Mollick's research on "Cyborg Centaurs" vs "Cyborg Minotaurs" summary

• Case study: Replit's multiplayer coding as precursor

• Reference: Stuart Kauffman's "adjacent possible" in team dynamics

• Josh Comeau's thoughts on AI and web development evolution

I have expressed interest in picking up medium format film photography for some time, and for my most recent birthday my wife purchased me a Mamiya 645 Pro with a 80mm f/2.8 lens, and a prism viewfinder. She did a ton of research, chatted with folks on Reddit and ended up buying the rig from KEH, who were very helpful in the process. She’s obsessed with the details, as am I, so her efforts were rewarded with a beautiful camera, and I was rewarded with an incredibly thoughtful gift.

We found a manual here that someone had graciously uploaded. You can find these around the internet, and it’s really awesome that people are helping to keep this type of information flowing. Additionally, there are some great YouTube resources for getting started. I may go back and create some short form videos for particular aspects of using the camera in the future as well.

Now, I quickly took the camera on a long weekend trip to Healdsburg, CA and was so excited to get the film back and develop it.

Quick tip: when flying, you can easily request a hand inspection of your film and camera, so you can avoid running it through the scanners. Regardless of ISO, I have now done this several times, and it’s really simple, so I’d just do that to be safe.

Learnings: this is not 35mm film. Now, for those more familiar, this will be incredibly obvious, but when you finish a roll of 120 film, you effectively lick it like a stamp and seal the roll to avoid light getting to the film itself. I did not do this. My film was ruined from this trip! Also, let go of things quickly. I was so disappointed, but at that point there was nothing to be done.

I had another chance to practice, this time in Seattle, WA. During this trip, I succeeded in shooting a couple rolls and coming back with a half used roll. I dropped the finished rolls at Glazer’s in Seattle before flying home. They were very helpful and easy to work with, and I received a WeTransfer link with my photos in the time they estimated and my negatives in the mail shortly thereafter. This time, I was happy with the results! Sharing a couple here, and you can find more here as well.

Getting started, I really focused on some basics of recalling the ins and outs of manual focus, and I utilized the metering from the prism viewfinder, focusing mostly on adjusting aperture for depth of field and light control. This simplified the number of variables up front and made acclimating easier.

The thrill of shooting film vs digital is never lost on me, but I also take lots of photos with my iPhone and due to the expense of film will always mix approaches, using film sparingly for the shots I think most effectively will translate to the medium. That said, there’s no substitute for taking 15+ photos and not knowing what you achieved until you see the results for the first time. Quick tip: while leveraging a light meter such as a Sekonic L-308S is a great way to ensure you’re exposing accurately, you can also snap a few photos on your iPhone to check and adjust settings prior to setting up your film capture. For me, it’s mostly an exercise in just trialing the camera and seeing what it produces and learning to tweak and adjust as I go.

I shot the following film while there and was very pleased with the grain structure and saturation: Kodak Ektar 100 color; Kodak Portra 400 & Ilford HP5. Shooting 100 ISO is awesome, but just be sure you really have sufficient light if you’re going to be shooting handheld.

My next purchase is likely to be a plunger, and I’ll share more about my initial gear setup in a future post. In addition to the gear setup, I edited in Lightroom and am also relearning that tool as well after quite a long time! I’ll write a follow up that includes some learnings and observations from using Lightroom for these photos. I’ve only scratched the surface thus far.

Subscribe now