Showing posts with label developer. Show all posts
Showing posts with label developer. Show all posts

Why the CTO chair keeps emptying

Mike's Notes

This is the first part of an article by Gergely Orosz, available to read for free. The rest is for paid subscribers. The article was introduced in a recent issue of The Code.

I found this important for understanding what is happening in workplace culture at large SaaS/AI firms. Things to avoid at Ajabbi. For future reference.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Code
  • Home > Ajabbi Research > Library > Subscriptions > The Pragmatic Engineer
  • Home > Handbook > 

Last Updated

07/09/2026

Why the CTO chair keeps emptying

By: .
The Code: 24/08/2026

.

An exodus across Silicon Valley. Something is spooking the people who run engineering. Across startups and Big Tech, CTOs, VPEs, and heads of engineering are quitting high-status roles with nothing lined up. Veteran engineer Gergely Orosz says he's never seen this many top-tier leaders walk. In his latest deep dive, he spoke to nearly 20 on career breaks. Six in ten were already on their way out.

A range of reasons. From rapid AI adoption (or the lack of it) to long hours and burnout. Then there’s what Orosz calls “founder mode.” In smaller companies, founders are micromanaging engineering, turning VP and CTO roles into low-ROI gigs. Some leaders left to build their own startups; others were pushed out.

Across the board, these were the most consistent reasons:

  • The job got worse. Picture a founder celebrating a massive AI-generated PR while the CTO stares at the technical debt underneath. Flag the mess, and you become the office killjoy.
  • Equity looks like smoke. Leaders are trading salary for equity that feels like a gamble. Many CTOs now realize their options might never pay out due to VC payouts.
  • AI-native or bust. The best roles now want leaders who’ve actually led an AI transformation. If their current job can’t offer that, some are stepping back into IC roles rather than letting their skills go stale.
  • Teams are shrinking. Agents now handle work that once required entire teams, meaning fewer engineers and fewer layers of management.

It doesn’t stop at the top. When leaders walk, the ripple effect hits the entire team. If you're taking a leadership role, interview the company too: do founders want engineering to change, or just get cheaper? And if your job isn't giving you hands-on AI experience, get it elsewhere.

P.S. Our engineering team put together over 10 practical guides to help you kick-start your journey toward becoming an AI-native engineer. Pass this along to your colleagues today.


Headed for the Exit: the Great Engineering Leader Career Break

By: Gergely Orosz.
The Pragmatic Engineer: 19/08/2026

Big Tech and startups from the inside. Especially relevant for software engineers / AI engineers, useful for anyone working in tech.

...

Trend: more CTOs, VPEs, and Heads of Engineering are walking away from their high-status, in-demand positions. There are many reasons, mostly related to AI, and to "founder mode"

...

In my ~20 years in this industry, I’ve not seen as many capable engineering leaders opting out or taking prolonged breaks as now, with some high-ranking engineering leaders – CTOs, VPs of Engineering, heads of engineering, etc. – quitting their high-status roles and departing, if not into the sunset, then at least with nothing lined up.

To find out what might be behind this spate of sign-outs, I talked with almost 20 engineering leaders currently on a career break – or seriously considering one – and they let me into their personal reasons for deciding to jam the brakes on their careers. Thanks to everyone who shared their input!

Today, we cover:

Ten of the most common reasons for quitting, sometimes without the next gig lined up:

  1. The job got (much) worse
  2. The startup is “losing” and becoming worthless
  3. Not being AI-native enough for other skills to be relevant
  4. Their predecessor saw the “writing on the wall”
  5. Long hours – rarely decisive
  6. Smaller teams mean less need for leaders
  7. Fractional CTO work preferred over fulltime positions
  8. AI startups pay ICs more than non-AI startups pay executives
  9. Quitting to launch their own business
  10. Burnout
  • “Founder mode” looks here to stay, so how to deal with it? And has it made the CTO and VPE roles become “low ROI”?
  • ‘Work at companies that truly want to drive change’. A personal account from someone who took the VP of Engineering role at Gitpod (later, Ona, now acquired by OpenAI) and enjoyed a rewarding experience. Matt Boyle says he interviewed the employer beforehand on whether their business truly leans into the changes brought by AI.

“Just me?”

I was recently messaged by a head of engineering in San Francisco, who said:

“I’m talking to four startups in San Francisco about the head of engineering roles. Pretty normal.

But one interesting pattern is how founding CTOs/heads of engineering are stepping away to take a full career break. We’re talking about two of these four startups. And these are good startups!

Have you seen this trend? I have a small number of data points here, so you might have a broader view.”

I asked around privately, and it turns out a majority of the CTO-level folks I spoke to are considering the very same thing, or are actually in the process of leaving the office for a long spell away; 6/10 engineering leaders said they’re on the way out.

1. The job got (much) worse

Unrealistic expectations, including about AI, by founders and CEOs are the leading cause of jobs turning bad for CTOs and VPEs right now in 2026:

  • CTO expected to magically transform the company to be “AI-native”
  • CTO must make significant engineering cost cuts of up to 20-50%, including morale-sapping job cuts
  • “Do more with less” equals shipping more with fewer people (e.g., no backfills)
  • CTO faces pressure on business results as AI coding bills rack up
  • Founder slop: they want wonky AI prototypes shipped as full-blown products within weeks

Hands-on founders with “AI psychosis” make the job predictably harder, according to one CTO who just signed out of his job:

“Managing ‘AI psychosis’ with founders and executive peers has become very difficult. For example, what do you do when a founder ships a 60,000-line pull request into the product, gleaming with joy at how much more productive they’ve become with AI? They won’t see all the issues with that PR, and how do you bring up that they’ve created a massive amount of tech debt? Especially without looking like a ‘Debbie Downer’.”

Founder slop issues begin when top leaders get excited about AI’s capability, then get hands-on and start issuing PRs, and shipping code to production. It can cause issues across the board:

  • Accountability. Who’s oncall when founder-shipped code breaks? In the “you build it, you own it” culture of startups, it’s confusing when a founder gets hands-on while not owning their work.
  • Quality out the door: if a founder’s half-baked features are accepted, it sends the wider message that quality does not matter. Some people may adopt this attitude to their own work.
  • A founder can overrule whatever was previously agreed with the CTO or VPE about what to build next. Vibes the founder has or feels are reason enough.

Another way that leadership roles have diminished is that craft and quality are less important, says a VP of engineering who’s in the process of signing out of their job:

“Shipping software became all about speed. Finding differentiation with your product in the market is brutal, and speed / go-to-market becomes the biggest differentiator. Craft, quality, and care going into the product are taking a backseat.”

Things also go bad when companies don’t ‘get’ AI+engineering, except as a way to cut jobs. CTOs I talked to mentioned the likes of Ramp, Stripe, and Notion as places that understand how to integrate AI into the engineering culture with a growth mindset without forsaking quality. Elsewhere, bad vibes dominate at places where going all-in on AI leads to the cynical conclusion that product management, design, and engineering leadership are irrelevant.

2. The startup is “losing” and becoming worthless

Director+ roles have a few differences from individual-contributor engineering ones:

  • Larger equity stake in the business. Base salary at these levels is often similar to a staff engineer’s, but usually with more generous equity grants – especially at the VP of Engineering and CTO levels. A good financial outcome depends on the company becoming more valuable, and – in the case of private companies – having a good exit by being acquired or selling shares.
  • Understanding of the business and competition is a baseline. At Director+ level, a big part of the job is making strategic decisions that grow the business and help the company get ahead. It’s a nice-to-have for an engineer to possess business acumen, but director-and-above folks use it much more than most individual contributors (ICs). Great engineering leaders are good at understanding business performance and outlook.

A company that adopts AI rapidly usually falls into one of three buckets:

  • “AI-native”, building & selling AI products. The large AI labs and a select few “AI-native” startups are thriving, but many AI startups with VC funding struggle. Engineering leaders know this, and that their equity – usually issued as options – could end up worthless.
  • Software startups threatened by AI-native businesses. Good businesses in the pre-AI world can be threatened by AI today, like SaaS startups selling seat-based products in areas where agents are taking over the functionality. They have to pivot their businesses or seek an exit. Bending Spoons buying Airtable for less than the company raised is an example of a business threatened by AI and choosing to sell, instead of pivoting the whole business.
  • Unaffected by AI. Usually stable businesses which do more than software, such as with a real-world side to the operation like manufacturing or distribution.

The majority of software startups fall into one of the first two buckets of being AI-native or under threat. Senior leaders at such companies are in a good position to evaluate whether their company is a “winner” worth staying with.

Leaving due to equity becoming worthless

A CTO who quit their startup told me:

My company would have needed a massive exit for me to realize any upside. I had an equity grant that was 2% of the common shares. However, this equity was behind an already steep preference stack for investors, post Series A.”

This CTO had a very generous equity grant at 2% of shares, so what made him leave it behind? They laid out how it will be difficult to get any benefit from them because the shares are most likely rendered worthless by rules about the order in which different investors get their share of the pie:

  • Assume that this company raised a $10M seed round at a $50M valuation, then a $100M Series A at a $500M valuation. So, a total of $110M was raised across two rounds.
  • Investors typically have a 1x preference. 1x preference would mean that upon any sale, they get the first $110M of the sale.
  • But in this company, the Series A investors negotiated a 2x preference: so upon a sale, $210M goes to investors first ($10M to the Seed, and $200M to the Series A investors).
  • The company now needs to sell for at least $210M for common shareholders (like the CTO) to make any money!
  • If the CTO does not believe a $200M+ exit could happen, then their equity is worthless. A $200M+ exit is typically an acquisition, because a stock market flotation rarely happens at below a $10B+ valuation, these days.

If a VC-funded company does not have the revenue or customers to grow at a fast tick (circa 20-50% per year), then it’s often a struggle to raise the next round of funding, and the business’s actual value usually shrinks to 3-5x of annual revenue. So, if a startup is making $10M per year after raising $110M in funding, and growing 30% year-on-year, then the company is likely worth around $30-50M. Perhaps the right buyer would pay $100M, but if growth slows, the value is likely to drop.

An experienced CTO who takes a step back and assesses things can realize when there’s a high chance of their equity turning into smoke, removing a reason to not sign out of the job. It’s what happened to the CTO above, and when they couldn’t turn the business around, they quit.

Business stops growing

When a VC-funded startup’s business stops growing, the prognosis can be dire in the sense that it’s unlikely to be worth as much as in the previous funding round. This is true even when the startup becomes profitable: this might mean it could theoretically go on forever; but with slow or no growth, it won’t win in another VC funding round.

Here’s a VP of Engineering who saw their startup stop growing, partly due to wrong bets by the CEO:

“My founder/CEO was nontechnical, and was both moving too slow and too fast with AI.

Too slow, as in they did not take the time to understand what our customers wanted. We built a TON of AI stuff, it totally confused them, they churned, growth stalled, word-of-mouth growth was gone. Heck, I don’t think our customers ever wanted or needed anything with AI!

Too fast, as in they deprioritized core systems’ reliability in favor of shipping AI work to prod which did not have any commercial potential. So, our core offering started to have more outages and we lost customers because of this as well.”

I’d add that deprioritizing reliability in favor of building features may be sensible in the early days. The problem seemed to be that this company had not found product-market fit, and the new AI features didn’t resonate with customers. Basically, the CEO lacked customer understanding, business intuition, or both.

So, good on the VPE for getting out when they saw the direction of travel. If the CEO won’t accept input from the VPE – who would’ve at least prioritized reliable operation – then there isn’t much left to stick around for!

3. Not being AI-native enough for other skills to be relevant

The top-paying engineering leadership positions have one thing in common: experience of leading AI-native organisations is expected, and leaders are sought who have turned their current company AI-native, or work at such a place.

It’s new to see people signing out of large companies for feeling like they’re lagging behind in adopting new AI workflows. An ex-engineering director at a large bank told me they quit their job to accelerate their career:

“I was not getting the opportunity to ‘close the loop’ on hypotheses enough. [...] To stay relevant in the industry, I feel like I need to pull out into the “fast lane.”

Like many others, I see the future of software development is with AI. If you don’t get hands-on with your team, working with AI tools day-in, day-out, you’re falling behind.

My plan is to get on the cutting edge of things through a mix of academia and consulting AI companies. I am not saying the plan is perfect, but I need more time to do things differently than I had in my job.”

Consider this: if you stay in your job for two more years, do you expect to find career opportunities at cutting-edge companies in the future? If the answer is “no”, then there’s a risk in just staying put. Joining an uncertain startup or taking a career break to develop AI expertise is also risky, but the outcomes may be more controllable than letting your skillset become outdated, relatively quickly.

But it might actually be necessary to quit in order to get AI experience: you might be able to get this by transferring to an IC role. As Charity Majors, co-founder and CTO of Honeycomb, said in last week’s episode of The Pragmatic Engineer podcast:

“You’ve got to get AI on your resume. You just have to. If you don’t, this is a huge career risk. If you’re working somewhere where you’re not getting these skills, I would do whatever I could to change that [including taking an IC role within the company].”

There are companies where moving from Director+ to individual contributor is possible, even if these companies are the minority. If you happen to work at a place like this, consider if you can and will take advantage of this opportunity.

Most companies say they want to be AI-native, but never do

Claire Vo – founder of ChatPRD and host of ‘How I AI’ podcast, and the former Chief Product & Technology Officer at LaunchDarkly – says most companies will never become “AI native” simply because most VP of Engineering or CTO folks don’t have what it takes to pull off such a transformation. In her words:

“The VPE role used to be primarily about deploying the dark arts to defend engineers from the roadmap, and now everyone thinks that’s BS and leaders are under tremendous pressure to inflect velocity or GTFO (get the f*** out).

Engineers are unhappy (don’t make me tokenmaxx, bro!), product and design sending slop PRs, and everyone good has left for a lab.

Most of these companies’ EPD (Engineering, Product, Design) orgs will never go AI-native, not even close. Most VPEs aren’t good enough at change management to pull it off.”

It looks like there’s a deadlock:

  • The current engineering org is frustrated by how AI is making engineering culture worse, morale is down, and people are frustrated and confused
  • To resolve this, drastic changes are needed to how everyone (engineers, product, designers) works
  • To pull it off, a VP of Engineering or CTO is needed who’s capable of this; someone excellent at change management, who’s ideally done it before.
  • But most VPEs and CTOs are not experts at large-scale change management, nor have done it before.

According to this, many VPEs and CTOs are doomed to fail at making the change they want, and it’s hard to know if that’s because organizations didn’t support them properly or resisted change.

4. Their predecessor saw the “writing on the wall”

There’s (usually) a honeymoon period in a new job, when we believe in the business we’ve joined and in its direction. But when this phase passes, a fraction or all of the problems described above may emerge, and there’s a decent chance that some of them are why your predecessor signed out:

  1. Has AI helped make the role worse?
  2. Is the equity on course to be worthless?
  3. Is getting AI-native experience actually possible, or is the organization resisting change?

I’ve talked with a CTO who replaced their predecessor and founding CTO. A few years into the job, the predecessor CTO realized their equity in the business was worth almost nothing due to stalled growth, all while they were also being out-competed by AI-native rivals. So, the new CTO also resigned after a short, six-month tenure.

5. Long hours – rarely decisive

Two engineering leaders – a CTO and a VP of Engineering – mentioned “insane working hours” as a factor that contributed to them finally quitting. But there were other things as well:

  • The business struggling for growth
  • Their equity grant’s value shrinking to nothing before their eyes
  • CEO/founder ignoring or overriding efforts to help the business succeed

My sense is that at a thriving business during chaotic times like these, it’s unlikely that long hours alone would spur people to leave, if their contribution to current success counts and is valued. When things are going well, it’s possible to delegate more and take time to recharge batteries. But when things are going badly, it feels like every waking hour needs to be spent on working to turn things around.

6. Smaller teams mean less need for leaders

Several engineering leaders are stepping back into IC roles for more stability because engineering teams are smaller now.

Karthik Hariharan, engineering leader at DoorDash, notes:

“Expectations have been shifting a lot in these roles, and a lot of folks qualified for them have consciously been stepping back into IC roles or joining bigger companies for stability and better compensation.

Engineering teams are also smaller now. A VPE isn’t needed until the team is large enough to require it. A technical founder can run the team for a lot longer these days.”

Some reasons why engineering teams have shrunk:

“Fullstack engineer” is mainstream, and was even before AI. Fullstack engineering was becoming relevant a few years ago in terms of a single engineer working on both the front and backends, instead of having a frontend engineer building the UI, and a backend engineer working on backend services. Fullstack frameworks like Next.js or Ruby on Rails made all this pretty easy before AI. Today with AI coding agents, you can rely on them to write decent code on platforms you’re unfamiliar with. There’s now little to no reason why a project would need multiple devs with different specializations.

It’s normal for one, or a maximum of two fullstack engineers, to be working on any given project at Anthropic as well. Head of Claude Platform, Katelyn Lesse, shared how it works at Anthropic:

“On an individual project, you often cannot have more than two people working on it.

This is because each engineer is already running several agents. And so as an engineer, you’re already fighting against your agents, which are stepping on each other’s toes on implementation. And in this setup, you just cannot have that many humans, who also come with all their agents!”

Frontend-only and native mobile teams are also getting smaller or disappearing. Even at companies where iOS and Android are a big part of the business, more places are building using cross-platform technologies where one engineer can do the work that used to need several. For example, social media app Bluesky had a single engineer build its web, iOS, and Android apps for launch by using React Native and Expo. Bluesky later hired more people to work on the web and apps, but they all work across these three platforms. It’s not the same as hiring separate web engineers, iOS engineers, and Android engineers.

We cover this in more detail in the deep dives Cross-platform mobile development and Is there a drop in native iOS and Android hiring at startups? We also observed a steep drop in frontend engineers and native mobile engineers in our latest state of the tech jobs market report:

Demand for frontend engineers and native iOS+Android engineers keeps dropping with the trend of smaller engineering teams. Source: The tech jobs market in 2026

Tech companies have been flattening their org structures for three years now. We first covered the trend for fewer middle managers back in 2023, when Meta drastically reduced manager positions. The trend has not stopped, and many – if not most – companies have increased the number of reports each engineering manager has, while reducing the number of layers in their organization.

7. Fractional CTO work preferred over fulltime positions

The rest of the article is available to paid subscribers.

AI Didn’t Make Programming Easier. It Just Made It Differently Difficult

Mike's Notes

An excellent ACM article clearly explains how AI is making programming differently difficult. I agree with all the conclusions based on my experience. In my case, I have found that using AI has made it much easier to use my visual way of thinking to design complex system architecture, rather than memorising lots of code syntax. The AI creates the syntax from instructions I give it, driven by architecture decisions rather than code-level details.

These changes are great: they provide more opportunity and an order of magnitude more productivity, allowing more time to read, think and discuss. 10 minutes with AI generates what previously took a week to build.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

19/08/2026

AI Didn’t Make Programming Easier. It Just Made It Differently Difficult

By: Jeremy Osborn
Communications of the ACM: 14/07/2026

Jeremy Osborn (jeremy.osborn@gmail.com) is a technology leader whose work spans software, governance, sustainability, and strategy.

The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.

...

Opinion

For decades, empirical research has shown that programming is a demanding cognitive activity: Developers rely on working memory, long-term recall, and complex mental models to manipulate interacting abstractions such as control flow, data structures, and the structural design of software. This classical model frequently positioned memory and recall as both the central enablers of, and bottlenecks in, software development.

Today’s AI-powered coding assistants are changing that. These tools function as external memory systems, offloading syntax recall, boilerplate generation, and API usage from human to machine memory. As memory demands lessen, reasoning, architectural comprehension, judgment, and code-structure awareness are becoming comparatively more important.

Thus “knowing how to program” is being fundamentally redefined, but not in ways that make programming easier or that devalue the programmer. This article describes four major shifts in how programming work is changing:

  1. The field is opening to new practitioners.
  2. The work is becoming differently difficult.
  3. Education is transforming.
  4. The programmer’s role is evolving from knowledge vessel to orchestrating agent.

Together, these shifts suggest that AI is not eroding the cognitive substance of programming but relocating it—making different skills matter more and creating new forms of difficulty even as old barriers fall.

Programming as High-Memory Work

For most of the history of software development, researchers found that programming relied on a combination of reasoning ability, working memory capacity, and long-term memory recall. Brooks described programming as a cognitive process that depends on maintaining multiple interacting abstractions. [4] Pennington then demonstrated that programmers rely on complex mental models of control flow and data flow to design, understand, and modify code. [6] Studies have shown that these mental models exist in the mind as abstractions, are maintained at high cognitive cost, and are relatively fragile. They break down easily under conditions of context switching and are costly to rebuild in cognitive terms if they are not documented.

Today, however, AI coding assistants are reshaping this traditionally onerous cognitive landscape. Developers now have access to external memory systems capable of generating code, retrieving syntax, reconstructing context, and remembering and regenerating variants of previous mental constructs. This does not eliminate the need to think. But it does shift which cognitive skills are becoming most relevant for programmers.

Working memory and long-term recall.  Working memory is the limited-capacity system that supports temporary storage and manipulation of discrete blocks of information, as formalized by Baddeley and Hitch. [2] Long-term memory, conversely, serves as the repository of consolidated knowledge, including declarative information such as syntax and architectural concepts, and procedural knowledge like coding idioms and problem-solving schemas.

Programming has traditionally relied heavily on both. Soloway, Bonar, and Ehrlich found that programmers rely on internal cognitive preferences, [9] presumably based on experience and retrieved from long-term memory, to structure their approach to iterations. For example, when a loop construct matched the programmer’s natural plan, correctness increased dramatically. This suggests that programming has historically been guided not just by syntax knowledge but by the formation and execution of internal cognitive preferences retrieved from memory and expressed as mental models through design choices. Siegmund et al. used fMRI to show that code comprehension activates networks associated with working memory, attention, and language processing, [8] providing physiological evidence that understanding complex programming tasks is a resource-intensive cognitive task at the neurological level.

Theories of AI as an external memory resource.  AI coding assistants alter this cognitive landscape by acting as external memory and cognition. This aligns with Hutchins’ theory of distributed cognition, which argued that cognitive systems often extend beyond the individual to include the external environment, [5] which can extend and enhance individual cognition.

Alternate theories complement distributed cognition. Cognitive load theory (CLT) holds that AI tools can reduce extraneous load, which is the memory overhead of recalling syntax and boilerplate, thereby freeing working memory for intrinsic, high-level reasoning. The Extended Mind Hypothesis (EMH) goes further by focusing on the individual: If an AI assistant becomes reliably available, habitually used, and trusted, it can function as an integrated component of the programmer’s cognitive architecture rather than as an external tool. Under this view, the AI becomes part of the thinking process itself, shaping reasoning, decision making, and the effects of cognitive effort.

Barke, James, and Polikarpova [3] showed that developers commonly use Copilot to offload low-level work, such as typing boilerplate, recalling API details, and looking up unfamiliar syntax, while shifting effort toward validating and integrating the generated code. These findings collectively support the view that AI is not merely a faster search engine; it is at least partly an integrated extension of human cognitive architecture.

What AI removes and what it does not.  Thus, AI fundamentally changes the costs associated with imperfect memory, effectively reducing the penalty for imperfect recall. A developer can successfully request a common API usage pattern without precise internal recall or retrieve complex syntax without relying on working-memory-intensive reconstruction. This capacity directly reduces the dependency on the rapid retrieval of specific, low-level knowledge from long-term memory, mitigating the cognitive bottleneck previously identified.

However, while AI-assisted programming tools can accelerate routine development tasks, they do not eliminate the need for human oversight, particularly when work requires conceptual reasoning rather than surface-level code manipulation. Every programmer knows AI can produce code that is syntactically correct yet semantically and subjectively flawed, meaning developers must still understand program structure well enough to detect errors, evaluate coding suggestions critically, and ask the necessary “why” and “why not” questions about causal behavior.

Shihab et al. found that students using GitHub Copilot completed brownfield tasks substantially faster and with more solution progress, but in exit interviews many reported concerns about not fully understanding how or why Copilot’s suggestions worked, and the authors call for pedagogical approaches that leverage Copilot’s benefits while fostering comprehension. [7] Alanazi et al., in a meta-analysis of controlled studies of tools such as ChatGPT and Copilot in programming education, reported that while AI assistance improves task performance and efficiency, it offers only small and statistically unstable gains in learning success and ease of understanding. [1]

Taken together, these findings support the view that architectural reasoning, impact analysis, and long-term system maintenance cannot be offloaded to AI. They depend on deep, structural understanding of the codebase that remains the programmer’s responsibility. So, while AI may extend cognition and make certain programming tasks more efficient, thereby improving the productivity of trained developers, critical tasks such as debugging, refactoring, and systems analysis still require expertise and comprehension, and rely heavily on internal mental models that allow programmers to simulate execution and infer complex cause-and-effect paths within a codebase.

This marks a significant cognitive reorganization: Memory becomes a shared resource spanning human and machine; programming becomes less about what the developer can hold and manipulate in their mind and more about how clearly they can think at multiple scales when creating and ordering a complex logical system. Studies confirm that stable mental models of a codebase are essential for navigation and reasoning. Therefore, if developers outsource too much thinking to AI, those internal models can weaken. AI thus shifts cognitive load rather than removing it and speeds up writing code but increases the time spent checking and validating it.

In other words, the hard part moves from recall (“How do I write this?”) to judgment (“Does this actually make sense?”). This shift from recall-based to judgment-based programming represents the fundamental cognitive transformation at the heart of AI-assisted development. Where traditional programming demanded that developers maintain vast internal libraries of syntax, patterns, and idioms, AI-enabled programming demands instead they maintain robust evaluative frameworks for assessing correctness, coherence, and appropriateness. The cognitive burden has not disappeared—it has relocated from retrieval to reasoning.

Programming as Hybrid Cognitive Systems Work

The emerging reality is not that AI replaces the programmer, but that it becomes a second cognitive engine running in parallel. The machine surfaces patterns, stitches together APIs, retrieves forgotten syntax, and drafts first-pass solutions at a speed that reduces low-level recall bottlenecks but can also increase the burden of evaluation. The human, in turn, becomes less a conductor of keystrokes and more a shaper of intent: checking, interpreting, integrating, synthesizing, validating, reorganizing, discarding, editing, and ultimately giving structure and purpose to what the system supplies. It resembles what has already happened in medicine: Diagnostic tools lowered the burden of memorizing obscure clinical details but raised the stakes for interpretation, judgment, and error detection. Expertise became less about recall and more about reasoning.

Understanding this hybrid arrangement helps explain why AI makes programming differently difficult rather than simply easier. The difficulty has not been eliminated; it has been redistributed across a new cognitive architecture that spans human and machine. This redistribution creates new challenges even as it removes old ones.

As AI continues to function primarily as an externalized memory and a code-transformation layer, four major shifts are already visible:

  1. First, the field will open. Many who once would have bounced off the sheer cognitive overhead of memorizing libraries, syntax variations, or error-handling idioms will now find a workable entry path. The bottleneck of recall shrinks, making programming more accessible to people who might previously have struggled with syntax, library details, or unfamiliar idioms, while placing greater emphasis on problem decomposition, systems reasoning, and the ability to evaluate generated code. However, this accessibility comes with a paradox: While the barrier to producing code lowers, the barrier to producing good code may actually rise, as judgment becomes more critical and harder to develop than recall ever was.
  2. Second, the work does not become simpler, only differently difficult. Conceptual clarity, decomposition, debugging, and architectural foresight still demand effort, and perhaps more of it. The challenge moves up a level. Where novice programmers once struggled primarily with syntax errors and API usage, they now struggle with evaluating whether AI-generated solutions are appropriate, maintainable, and aligned with broader system constraints. This represents a more sophisticated form of difficulty, one that requires deeper understanding of software-engineering principles rather than surface-level language features.
  3. Third, education will shift. We will teach fewer people to memorize syntax and more to think in complex systems. The curriculum bends toward architecture, interface design, state management, failure modes, constraint negotiation, test construction, security, and long-term maintainability. Code becomes only one representation of thought among many overlapping ones. Developers must still possess the skills to analyze, adapt, and modify what AI produces, perhaps even more so than before.
  4. Fourth and most importantly, the programmer remains essential. Not as a vessel of knowledge but as the orchestrating agent who understands the parts and how they fit together, maintains the integrity of the system, and who decides what matters. This shift has profound implications for how we understand programming expertise. The most capable developers of this new era will not be those who type the fastest or remember the most, but those who can hold deep mental models while offloading everything that interferes with that. They will combine strong systems reasoning with AI-augmented recall and will treat the model almost like a cognitive prosthetic: useful, fast, but incapable of finally determining subjective-semantic correctness or coherence.

Conclusion

Taken together, these four shifts suggest AI is not eroding the cognitive substance of programming but relocating it. As external memory becomes abundant and code generation cheap, the value of the programmer moves toward interpretation, structural reasoning, and judgment. The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.

AI does not, therefore, diminish the craft; it widens it, deepens it, and makes more of the work explicitly intellectual. The work becomes differently difficult because it demands more sophisticated forms of expertise: judgment over recall, architecture over syntax, orchestration over implementation. These are not easier skills to develop or demonstrate, they are simply different ones, and perhaps ultimately more demanding.

References

1. Alanazi, M., Soh, B., Samra, H., and Li, A. The influence of artificial intelligence tools on learning outcomes in computer programming: A systematic review and meta-analysis. Computers 14, 5 (2025), 185.

2. Baddeley, A.D. and Hitch, G. Working memory. In The Psychology of Learning and Motivation 8, Academic Press. G.H. Bower (Ed.) (1974), 47–89.

3. Barke, S., James, M.B., and Polikarpova, N. Grounded Copilot: How programmers interact with code-generating models. In Proceedings of the ACM on Programming Languages 7, Article 78 (2023), 85–111.

4. Brooks, R.E. Towards a theory of the cognitive processes in computer programming. Intern. J. Man-Machine Studies 9, 6 (1977), 737-751.

5. Hutchins, E. Cognition in the Wild. MIT Press (1995).

6. Pennington, N. Stimulus structures and mental representations in expert comprehension of computer programs. Cognitive Psychology 19, 3 (1987), 295–341.

7. Shihab, M.I.H. et al. The effects of GitHub Copilot on computing students’ programming effectiveness, efficiency, and processes in brownfield programming tasks. In Proceedings of the ACM Conf. Inter. Computing Education Research (2025), 407–420.

8. Siegmund, J. et al. Understanding source code with functional magnetic resonance imaging. In Proceedings of the 36th Annual Intern. Conf. Software Engineering, ACM (2014), 378–389.

9. Soloway, E., Bonar, J., and Ehrlich, K. Cognitive strategies and looping constructs: An empirical study. Commun. ACM 26, 11 (1983), 853–860. 

Jessica Kerr on Symmathesy

Mike's Notes

I was watching "A Learning System Made of Learning Parts" on Still Burning, an episode of Kent Beck's video blog.

Jessica Kerr joins Kent by the fire to argue that AI didn't take the programmer's job; it split it in two. The part we loved, crafting code by hand, has been commoditised like IKEA furniture. What's left is harder and more human: understanding what to build, proving it works, and stewarding the living "symmathesy" of people, code, and agents all learning from each other. They get into accelerated learning, why play is a signal you're learning, the loop that "becomes a noose," and choosing excitement over fear while the ground keeps shifting."

Resources

References

  • Symmathesy — A Word in Progress Proposing a New Word that Refers to Living Systems. Nora Bateson. Nora Bateson Foundation

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Still Burning
  • Home > Ajabbi Research > Library > Authors > Kent Beck
  • Home > Handbook > 

Last Updated

02/08/2026

Jessica Kerr on Symmathesy

By: Jessica Kerr
Jessitron: 15/04/2018

Jessica Kerr manages the Developer Relations team at honeycomb.io, because observability is one way our teams learn from our software. In speaking and teaching, Jess works across languages and communities, spreading cheerful deep thoughts. Code, tools, and people are not separable; all form the team that operates useful software.

Symmathesy is a term coined by filmmaker and systems theorist Nora Bateson in 2015 to describe a learning system made of learning parts, emphasising mutual learning that occurs within and between living contexts. Derived from the Greek roots sym (together) and mathesi (to learn), it serves as a response to mechanical, rigid frameworks by shifting the focus from individual elements to the dynamic relationships that generate evolution and adaptation.

In a symmathesy, learning is not an isolated process of acquiring information; it is an ongoing, multi-contextual process of mutual adjustment and calibration.

Collective problem solving in music, art, science, and software

A Learning System Made of Learning Parts

Pipi Data Centre Operational

Mike's Notes

Very good news for Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

26/02/2026

Pipi Data Centre Operational

By: Mike Peters
On a Sandy Beach: 25/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The long-planned migration of Pipi 9 to its own data centre has been completed. It took 2 weeks to execute. The existing setup was split into an office network connected to the internet and an isolated data centre that is not connected to the internet.

Starting from zero

The initial data centre consists of a single 45U rack and some other shelving, with mainly older equipment. It will do for a start and can grow as more racks are added, equipment upgraded, and more servers are added, etc.

External hard drives being used in the shift

Issues

  • Terabytes of data on backup hard drives to shift
  • Clean reinstalls of many operating systems
  • 14 machines to configure
  • Adobe CS4 does not like Windows 11
  • Making do with what is available now
  • Go slow, think twice and get there faster

Opportunities

  • Pipi on 24x7x365
  • All systems can be turned on using multiple servers
  • DevOps automation is now possible
  • The development cycle will speed up 10x
  • The road to Pipi 10 with BoxLang is now open

Whats next

  • Seat-of-the-pants experimenting to tune the setup
  • Stress test to build resiliency and reliability

Developer access to Pipi, is coming

Mike's Notes

The data is precise on this one. Unfortunately, the current developer interest in NZ and Australia is 3% and 0%, respectively. I also can't find anyone in NZ who has the slightest technical understanding of what I'm doing. But there are plenty overseas, especially in MLOps. We speak the same language, even if the architecture and algorithms are radically different. Also, top-grade mathematicians get it. Internally, Pipi 9 uses a lot of maths.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

08/12/2025

Developer access to Pipi is coming

By: Mike Peters
On a Sandy Beach: 02/12/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The problem

To launch Pipi 9 with limited resources in 2026, the effort needs to be highly focused on developers who build large enterprise systems and have experienced failure, cost overruns, and staggering complexity. This is for them.

Waste

The staggering annual global cost of IT failures on big projects is around $US 3 trillion. How many schools or knee replacements would that be?

  • 15% succeed
  • 25% makes no difference
  • 60% fail

Web traffic stats

The steadily growing web traffic statistics of public interest in Pipi 9 are becoming very clear.

Since early 2019, the total traffic stats by country are;

  • China 19%
  • Singapore 16%
  • United States 15%
  • Hong Kong 11%
  • Brazil 10%
  • TOTAL 71%

Developer Accounts

The initial paid Developer Accounts will be restricted to experienced DevOps teams with great internal culture in those five countries. That also affects the language, currency, hours of support availability, etc. Later, as interest and resources grow, that list of countries can be expanded.

Personal Accounts

The free Personal Accounts will initially use an English interface and will not be restricted by country of residence. They will get community support.

Enterprise Accounts

The initial paid Enterprise Accounts will be supported by their associated Developer Accounts, who can charge them whatever they want for that service. They will initially use an English interface and will not be restricted by country of residence. Developer Accounts will be able to translate UI and documentation into any language and writing system.

Pipi 9 is in hiding

This engineering blog and the many other Ajabbi documentation websites are deliberately hidden from search engines. People are visiting because they are curious, as I write notes to myself and build, learning as I go. It is not easy to find the technical documentation unless you are really interested, clever and very determined. That has helped me find some early, keen technical fans who provide testing and feedback. It has also protected me from being overwhelmed by enquiries.

Communication constraints

I am a very slow writer, using assistive technology, have hearing problems and prefer video chats with people who speak good, clear English. I don't speak any other language apart from tiny bits of Maori, French and Spanish.

SEO and GEO

The SEO/GEO settings will be fixed when

  • Pipi 9 matures and becomes ready for public use
  • Community support is in place
  • Bugs fixed
  • Enough self-help documentation to help people get started.

Developer Account waitlist

There will be a signup queue to control demand, so scaling is steady with a positive resource feedback loop to solve the chicken-and-egg problem. The small queue is growing now. I will pick the best candidates with the highest chance of success. They will gain a first-mover advantage in building large, custom enterprise systems faster and at a much lower cost. The first ones will get free unlimited support. 

Relying on word-of-mouth recommendations.

There will be no marketing or sales, just good, clear documentation, live demos, and regular bookable office hours (NZ daytime) for having a chat.

Inflexion point

In the future, as workspaces mature and Pipi 10 becomes even easier to work with, resource constraints will disappear, teams will grow, and an inflexion point will be reached. Anyone will then be able to sign up.

Agents in Production on replay

Mike's Notes

The videos of the talks given at the recent Agents in Production are now available to watch. The talks are technically excellent. I watched some of it (It started at 3 am NZ Time), so I will watch the rest from now.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > MLOps Community
  • Home > Handbook > 

Last Updated

24/11/2025

Agents in Production on replay

By: 
MLOps Community: 24/11/2025

The Virtual AI Event That’s Actually... Fun

We know what you’re thinking: another virtual conference. Talking heads, awkward silences, and the constant urge to check your email… we’ve all been there.

Not this one.

100% AI Agents in Prod. BUT This Isn't Just Another Zoom Link.

Welcome to Agents in Production: the latest edition of the MLOps × Prosus AI Virtual Conference.

We’re bringing together the brightest minds building AI agents, with a high-energy format designed to keep you hooked from start to finish.

Last year, companies stopped experimenting with agents and started deploying them in the real world. We heard from the pioneers who turned hype into working systems - and this year, we’re doubling down.

Expect real progress, real lessons, and real breakthroughs shaping the future of agentic AI. You’ll get cutting-edge, actionable insights that move you from experimentation to full-scale deployment.

30+ Talks on AI Agents. I Promise You Won’t Log Off Early

Why Attend:

  • Talks from top experts – Real-world lessons, practical insights, and breakthroughs defining agentic AI.
  • Hilarious skits & live music – Because learning should be fun.
  • High-energy engagement – Interactive moments that make you part of the action.

If You Miss This, You’ll Miss:

  • Hard-won lessons – How leading companies are successfully deploying agents at scale.
  • Deep dives – Technical sessions and workshops from the voices shaping the next generation of AI.
  • Global connections – Network with innovators and practitioners across the ML community.
  • This is your chance to get up to speed on the global AI scene, connect with innovators, and experience a virtual event you’ll actually enjoy.

See you there! 

Speakers

  • Chip Huyen, Researcher @ Tep Studio
  • Aditya Gautam, Machine Learning Technical Lead @ Meta
  • Teodora Musatoiu, Solutions Architect @ OpenAI
  • Adel El Hallak, Senior Director Of Product @ NVIDIA
  • Panos Stravopodis, Co-Founder & CTO @ Elyos
  • Jiquan Ngiam, CEO and Co-Founder @ MintMCP
  • Chenyu Zhang, Founder @ GlowingStar Inc.
  • Rekha Singhal, Head Research @ Tata Consultancy Services
  • Santoshkalyan Rayadhurgam, Engineering Leader @ Meta
  • Swati Bhatia, Product Manager @ Google
  • Arushi Jain, Senior Applied Scientist @ Microsoft
  • Donné Stevenson, Machine Learning Engineer @ Prosus Group
  • Mefta Sadat, Staff Software Engineer @ Loblaw Digital
  • Sam Partee, Co-Founder @ Arcade.dev
  • Sachi Shah, Product Manager @ Sierra
  • Jasleen Singh, Staff Solutions Architect, Generative AI @ Google
  • Sanjana Sharma, AI Strategist @ Distyl AI
  • Artem Yushkovskiy, Sr ML Engineer @ Delivery Hero SE
  • Rosemary Nwosu-Ihueze, Founder @ Soteria
  • Euro Beinat, Global Head AI and Data Science @ Prosus Group
  • Washington Amolo, Product Developer @ NaviSmart AI
  • Benjamin Guo, Co Founder @ Zo Computer
  • Hamed Taheri, CEO & Founder @ Personize.ai
  • Phil Stafford, Principal Consultant, Cybersecurity & AI @ Singularity Systems
  • Quinten Rosseel, AI Engineer @ Wobby
  • Dirk Petzoldt, Co-Founder @ Explai.com
  • Tom Kaltofen, Engineer @ mloda
  • Rachitt Shah, Applied AI consultant @ Transfrm Labs
  • Vitor Balocco, Co-founder @ Runlayer
  • Frank Wittkampf, VP Applied AI @ Databook
  • Laurel Orr, AI Staff Software Engineer @ Stacklok
  • Benjamin Hindman, Founder & CEO @ Reboot
  • Ben Epstein, Co-Founder & CTO @ GrottoAI
  • Matt Sharp, AI Strategist and Principle Engineer @ Flexion
  • Audi Liu, Senior Product Manager @ Inworld AI
  • Olga Pavlov, Head of Product @ OLX Group
  • Isabella Piratininga, Director of Technology & Innovation @ iFood
  • Paul van der Boor, Senior Director Data Science @ Prosus Group
  • Demetrios Brinkmann, Chief Happiness Engineer @ MLOps Community
  • Ricky Doar, VP of Solutions @ Cursor
  • Nishikant Dhanuka, Senior Director of AI @ Prosus Group
  • Chiara Caratelli, Data Scientist @ Prosus Group
  • Simba Khadder, Sr. Manager & Software Engineer @ Redis

On a Sandy Beach, database version 2 is underway

Mike's Notes

In May, after manually reformatting every page and post of "On a Sandy Beach," I wrote.

"A blogging module needs to be built and added to Pipi 9 CMS. This could then be used to create blog posts using an underlying database, which could be modified to be more useful."

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

28/09/2025

On a Sandy Beach, database version 2 is underway

By: Mike Peters
On a Sandy Beach: 28/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The datamodel version 2 to support blogging is now being built. It is designed to support On a Sandy Beach. Yesterday, this Blogger post index was scraped and imported to initially populate the database.

In future, the blogging module will also support other blogs/newsletters, including the Ajabbi Research Monthly Newsletter, which begins next month in October on Substack.

The new database and blogger will be synced while other jobs are completed, including;

  • The tags need consolidating
  • The same tags will form a topic map and be used across Ajabbi
  • etc

Data Model version 1 (current)

  • Mike's Note
  • Resources
  • References
  • Repository links
  • Date Updated
  • Title
  • Page Url
  • Author
  • Source publication
  • Date Created
  • Author description
  • Body of the article
  • Tags
  • Comments

Data Model version 2 (now being built)

  • Title
  • Page Url
  • Site-wide Navigation
  • Site-wide Breadcrumb
  • Mike's Note
  • Author
  • Source publication
  • Date Created
  • Author description
  • Body of the article
  • References
  • Further Reading (replacing References)
  • Articles
  • See Also (cross-links to Ajabbi.com website pages, replacing Repository URL)
  • External Links (replacing Resources)
  • Keywords (replacing Tags)
  • Sharing
  • Updated
  • Forum (replacing Comments)

The 2025 DORA survey is open now

Mike's Notes

Note

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > IT Revolution
  • Home > Handbook > 

Last Updated

03/07/2025

The 2025 DORA survey is open now

By: 
DORA: Copied 03/07/2025

The DORA research program is dedicated to helping technology teams get better at getting better. That journey often starts with a moment of reflection.

We invite you to take 10 minutes for that reflection with the 2025 DORA Survey. Participants often tell us the survey itself is a valuable self-assessment, sparking immediate ideas for how their team can improve.

Your anonymous contribution will also power the industry’s most trusted research on software delivery performance. This year, we’re exploring crucial topics like AI integration, platform engineering, and developer well-being.

By participating, you:

  • Discover potential improvements for your team just by taking the survey.
  • Shape the industry’s understanding of what defines elite performance in 2025.
  • Help create the benchmark you and your peers will use to drive change.

This research is strongest when it includes diverse perspectives. Whether you’re a Software Engineer, Data Scientist, Product Manager, QA Developer, or anyone else who participates in the creation and delivery of software your voice is critical.

Thank you for helping us all get better at getting better.

Consider holding a team discussion about the survey using our discussion guide.