Showing posts with label work. Show all posts
Showing posts with label work. 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. 

The real cost of living, city to city

Mike's Notes

Got this from reading Vitaly Friedman (Smashing Mag) on LinkedIn. Will need to know what the cost of living is around the world. For contractors, staff, volunteers, interns, research grantees, etc.

Smashing Magazine is a fantastic resource for CSS, designing accessibility in web UX, design systems and much more. Has a ton of references to useful resources. I follow it daily to build Pipi UX so anyone can use it easily.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

10/06/2026

The real cost of living, city to city

By: Vitaly Friedman
LinkedIn: 03/06/2026

Vitaly is the founder and editor-in-chief of Smashing Magazine since 2006, an online magazine for designers and engineers, where he helps curate friendly, inclusive UX conferences (SmashingConfs).



Cost of Living and Quality of Life Comparison (https://cityparity.com), a lovely tool to decide if a move from one city to another is worth it — and compare cities against take-home pay, childcare, healthcare and social safety net. Designed to help answer one single question: "If I take this offer in another country, what salary do I need over there to keep my life roughly the same?"

1. Every City Can Be a “Perfect” City

Every city has its own advantages and disadvantages. Living in Europe, I sincerely appreciate the quality of healthcare and a social safety net. Of course it comes at a cost, but it doesn’t surprise me much that Scandinavian countries are happy to pay larger contributions to make sure that they don’t have to worry about anything — from kindergarten to hospital bills to recovery courses in case of accidents to retirement.

I’ve moved between 7 cities and countries in my life. And looking back, I keep thinking that for every period in life there is a “perfect” city — and that’s a city where you build strong and sincere relationships, where you meet incredible people, where you make memories and experiences for the entire lifetime.

It can be pretty much any city in the world. And usually it's just the one where you happen to be, and where life brings you to.

Really the perfect city is the one where you have incredible people around you, and where you can build relationships that will last your entire lif

2. Numbers Aren’t Everything

Of course numbers will tell you what you can afford, but not where you’ll love the vibe and the people. If anything, it’s always a good idea to travel and stay in a place for a while to really start feeling it. 

As time passes by, even within the same city you can find places to explore and get lost, but then also to relax and calm down, and then to build a family and spend time with children. Finances might matter significantly more in life early, but the chase for finances often fades away as we grow older.

And sometimes it might feel like just the right time to reshuffle things — and that’s a great opportunity to explore a very different city on the other side of the Earth. Even despite lower pay.

If you're looking for another quick tool to compare the quality of life between cities, you can also look up Numbeo (https://lnkd.in/e8yMXJFB), which is world's largest cost-of-living and quality-of-life database with millions of crowdsourced reports on living, housing, crime, healthcare, transport and other key indicators.

And if you already found a perfect place — please leave a comment and share where it is! I’d love to hear your story, and I’d love to learn just what place in the world makes you feel genuinely happy! 💚



How I work effectively

Mike's Notes

I found it helpful to get this down on paper, so the process I use is conscious and can be tweaked over time.

This process has slowly evolved over many years since I was 15, when I started by grabbing non-fiction public library books off the shelves each week based on intuition. Practising this visual learning method, getting better over time and adding more steps seems to have worked a treat.

Most important is testing all assumptions.

I'm happy to receive suggestions or feedback on this.

Resources

References

  • Reference

Repository

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

Last Updated

03/08/2026

How I work effectively

By: Mike Peters
On a Sandy Beach: 30/07/2026

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

My creative problem-solving and build process is evolving, and the loop is getting faster.

  • Understanding the problem starts with reading or talking with someone, watching a YouTube talk, or listening to the radio.
  • Do lots of research, mostly reading books (days to months).
  • Cheap thought experiments. What ifs.
  • Drink plunger coffee.
  • Print off a paper(s) or article(s) and file it in an indexed A4 3-hole ring-binder.
  • Drink Chamomile tea.
  • Daydream (solutions come within hours or months later).
  • Drink plunger coffee.
  • Draw the solution as many colour-coded A4 architecture drawing(s).
  • Drink more coffee (Cappuccino).
  • File the drawing(s) with the printed paper.
  • Use the drawings to prompt Google Search AI Mode (free) with detailed instructions on what to build.
  • Output teaches me, describes data model, code, documentation.
  • Print off and file with the rest.
  • Walk a dog. Plant a tree. Watch the sun rise.
  • Read the printed AI output, colour-code, add doodles, correct, test, edit names, build, use in Pipi, while listening to music. (I don't copy-paste. I manually type to copy, because it helps me learn and understand.)
  • Throw away all the paper except for the original research, which is moved from DevOps to the research library.
  • Pipi then generates self-documentation, including mermaid drawings.
  • Repeat.

Each loop cycle takes weeks to years. There are hundreds of cycles running in parallel at any one time. It's a pull system. I work on Pipi when something needs to be solved using my library of solutions. Totally intuitive, like an artist, not an engineer, and always fun like a kid playing with Lego.

Another important part of this process is writing up notes for this blog. As a slow writer, I need to allocate a regular slot each day to do this using Grammarly. I find it reflective; it makes me think a lot. A bit like teaching someone else a skill you have.

It's becoming more important to have regular habits (an autism strength) and replace personal deadlines with going with the natural flow (artistic strength). It's more productive in the long run.

These changes are made possible because of the detailed work done over the last few months, removing barriers, including modifications to Pipi, reorganising space, equipment, and routines. It's also been made possible by the rapid advances in LLMs in 2026.

I think I have now solved all major problems to get Pipi 9 Core (Loki) running 24x7x52. Anything else that pops up can be quickly solved along the way as part of maintenance.

Output has gone up 100x. Now to execute very fast.

No posts for a wee while

Mike's Notes

I was on holiday for the last few weeks and am back now. There will be no blog posts, newsletters or meetings until Pipi Core is back up and running.

Update 27/05/2026

Lots of surprises. Making rapid progress. The peace and quiet are bliss.

Update 31/05/2026

The problem and solution are how things are named. Pipi auto-generates thousands of code names using multiple pattern languages, and all the naming conventions require many minor fixes for several unexpected reasons after migrating from a developer laptop to a production server environment. Everything else is absolutely fine.

Other naming problems are also being solved now, including:

  • The rapid development of Boxlang by Ortus has brought forward another challenge. Pipi 10 will be migrated to run on top of Boxlang in 2027 to support multiple languages, including C++, CFML, COBOL, Go, Java, JavaScript, PHP, Python, Rust, etc.
  • Future integration with cloud-based LLMs.
  • Future integrations with Office365, Google Workspace, Zoho, LibreOffice, etc.

The common solution is to create standardised naming systems that are simple, stable, robust, schema-based, versioned, self-documenting, and extensible to meet unanticipated future needs.

This is done by replacing code-based naming rules with database-driven ones that can be easily edited in the future via an admin UI.

90% of these names are internal, hidden in the closed core, and how they work and what they are will not be discussed here. The rest will be publicly and fully documented as part of the open-source workspaces for developers to work with.

Update 02/06/2026

I'm changing the disclosure boundary between the Pipi closed-core and open-source workspaces. Previously, "disclose everything unless there is a security reason not to". This is now changed to "disclose on the basis of need to know".

Closed-core accounts for 90% and open-source workspaces for 10% of lines of code, databases, etc.

This will reduce the documentation burden, given Pipi's vast scale. So, the open-source workspaces will be fully shared and documented on GitHub, etc, without restriction. This includes;

  • Standards schema
  • Ontologies
  • Parameters
  • Laws of physics
  • HTML + CSS
  • Algorithms
  • Module DDD models
  • Workflow diagrams
  • Documentation
  • API schema
  • UI code
  • etc

This also means some existing technical documentation about the closed-core will become hidden and only available internally.

Update 07/06/2026

Pipi Core is the IDE used to edit Pipi Core (AKA: which came first, the chicken or the egg?). Temporary UIs have been created and are being used across multiple engines to edit the names in use. This is much faster than directly editing data, which had to be done initially. The next step will be turning auto-generation back on. Once that's done, temporary UIs will be used to build permanent UIs. More automation will then be enabled via the UIs, and so on, as Pipi Core builds itself with a human in the loop.

Update 08/06/2026

The list of code cases available to use now for auto-generated naming, I/O translation, etc with examples, includes;

  • camelCase: userProfilePicture
  • kebab-case: user-profile-picture
  • PascalCase: UserProfilePicture
  • snake_case: user_profile_picture
  • SCREAMING_SNAKE_CASE: USER_PROFILE_PICTURE
  • Train-Case: User-Profile-Picture
  • flatcase: userprofilepicture
  • UPPER-CASE-KEBAB-CASE: USER-PROFILE-PICTURE
  • Sentence case: User profile picture
  • Title Case: User Profile Picture
  • middot·case: user·profile·picture
  • dot.case: user.profile.picture
  • UPPER CASE: USER PROFILE PICTURE
  • lowercase: user profile picture

Update 12/06/20026

Checking that these changes to variable names and internal messaging do not clash with the Gödel Machine.

Update 17/06/2026

The DevOps Engine (dvp) has unexpectedly proven to be critical to solving this puzzle. Mostly fixed last night. Watching the rather excellent live Google talk, Beyond the GPU: Maximising goodput with self-healing AI infrastructure, this morning has given me valuable insights into how to fix the remaining issues by reviewing Google HPC YAML files. 😎😎 Sometimes insights come from the strangest places.

Update 01/07/2026

The main work now is rapidly configuring Pipi for production and full autonomous automation. Using Google Search AI Mode (Gemini) and then Grammarly Pro makes the work easier and 100x faster.

  • I have decided to have Pipi re-render the many Ajabbi draft public websites with the new and missing developer information. (20K pages)
  • The website's .robot.txt file will then be unlocked to enable search engines.
  • The HTML will be updated to make it easier for AI to read.
  • This blog will be imported into Pipi, cleaned up, re-exported from Pipi, and published to Blogger via the API.
  • The new posts created in Pipi will return to A Sandy Beach to discuss something already built rather than being built.

Update 02/07/2026

The DevOps and IaC engines are getting rapid data model overhauls. The IaC engine is a great test for the variable names. I'm building a capability into Pipi to autonomously and automatically run OpenTofu and Ansible, initially targeting the Pipi Data Centre, then GCP and AWS for deployments. It's going very well and making rapid progress.

Update 05/07/2026

Pipi will initially run the open-source enterprise applications on Google Cloud Run and Google Cloud Storage (GCS). The code is complete and will be very low-cost to run, giving Ajabbi, a bootstrapping-purpose startup, a very long runway.

Update 18/07/2026

The job has now shifted to configuring, networking and deploying many physical servers. Installing software, including Pipi, labelling cables and rack gear, throwing out junk, tidying, etc., leaving nothing to chance. Shipping delays are holding up part deliveries.

Update 28/07/2026

Most of the equipment has arrived, and the small data centre setup is coming together. More deliveries later this week. It's already running a lot better and is much more productive.

Update 31/07/2026

Work on Pipi has reached a tipping point or system phase change as Pipi takes over tasks using autonomous automation. Pipi now has deadlines, not me. Soon it will set the deadlines. It's now a downhill run; daily posts from me resume tomorrow, and much more will come.

In hindsight. This whole project has been systematic trial and error, spending 10 years learning how to crack a hard problem.

Resources

References

  • Reference

Repository

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

Last Updated

31/07/2026

No posts for a wee while

By: Mike Peters
On a Sandy Beach: 15/05/2026

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

I was on a no-coding holiday for the last few weeks to clear my mind, and it has been great. I am back on the job today.

Suspended

Until the closed-source Pipi Core is back up and running 100% on autopilot, 10x faster, the following are suspended.

  • New posts "On a Sandy Beach
  • All newsletters, including the weekly Friday Report and the monthly Ajabbi Research Newsletter.
  • The fortnightly online Open R&D meeting.

Rapid refocus

  • A new developer area with five coding screens, designed to be more productive for hypervisual learners.
  • A better library has been set up for my A4 drawings in ring binders, the many reference books I use, and more bookshelves are on the way.
  • The server rack has been moved to a better location.
  • The light levels have been adjusted.
  • A big office tidy is almost done. An office-work-only desk has yet to be set up with a cat bed included.
  • A separate area with no screens for the happy cat, coffee, music, reading and drawing.

Less is more

Minimise screen time to be more productive at work. The new setup is also much less tiring.

Get the job done

The good thing is that, with a holiday and lots of drawing, I now have mental clarity about what needs fixing and how to fix it. Mainly, quite delicate changes here and there, organised into a list of steps. Now, I need to concentrate on one thing only: go as fast as possible, without meetings, post-deadlines, phone calls, or other distractions.

How

1. Use an AI workforce

Be the architect, and AI fills in the dots to make it happen.

Use Google Search AI mode (Gemini) to generate 99% of the code in one-page chunks (including references) to copy and paste, then manually change the variable names and SQL. Careful, test everything, resulting in 100x faster progress. Know how everything works and rapidly raise personal skill level.

2. Then build a cathedral

Make a wooden scale model of a cathedral for the builders. Google Search AI mode (Gemini) makes each brick, and Pipi Core assembles the bricks into floors, arches, walls, and vaults...

Speed is king

With the 100x coding productivity gains from Google Search AI mode (Gemini), plus the 10x10x10x speedup of Pipi Core currently underway over the next few months, what previously took a year will be done in hours and better.

Phase transitions

Once these initial migration issues from laptop to server are resolved, further transitions can be anticipated as the number of engines rapidly increases beyond 20. Increasing the number of engines slowly changes the whole system's behaviour from deterministic to probabilistic and adaptive.

Here is a partial list of transitions expected as the number of engines increases from 0 to 200. The actual numbers are a bit of a guess.

  • 20 engines enable Pipi 9 Core in a simple, deterministic structure.
  • 40 engines enable a workspace with a UI for administering Pipi Core.
  • 60 engines enable self-generation of user documentation.
  • 80 engines enable REPL and IAC (infrastructure-as-code).
  • 100 engines enable Workspaces for different user accounts.
  • Different Pipi 9 editions are made with the same engines, which recombine differently in response to the external environment.
  • And so on until...
  • 200 engines self-organise into a multi-layered complex fluid structure with probabilistic behaviour and emergent properties, as engines also act as agents.
  • 200+ engines enable Pipi 10 to interact with externally cloud-hosted LLMs, combining the very different strengths of both.