That was just some context on what I was thinking more than a year ago on GenAI (a term that I don’t even use anymore) before I reflect on where I am today:

My Turn

Last May I found myself unexpectedly in the job market. In my 30 years as a web and mobile developer, I had never been laid off for any reason. In my case it was a small “restructuring” that led to my position being cut (I estimate that a couple dozen of us were let go). I had always counted myself lucky up until that point.

It took me about 7 months to find my next position. This was for a few reasons, and not exclusively related to the job market.

First, I’m over fifty and the market was not in a growth position for software engineers as it was. There were and are a lot of people to choose from.

Second, I asked each hiring manager what their company and the engineering team’s positions were on AI and, more specifically agentic coding. I knew I was not taking a job with a company who had no position or a negative position on AI. I was fine with ambiguity like “we’re still kicking the tires”, but “probably not doing too much as of yet” was a hard pass for me.

Third, in my 30 years, I had never taken any sort of sabbatical outside a few minor alternate career explorations. I took some time to think, explore, and put some energy into a side business my wife and I had been slowly growing for a couple of years.

No matter how you spin it though, I did not think it would take 7 months.

I thought I was unlucky, but I had gone nearly my entire career without having to deal with unemployment, so I accepted that it was my turn. It was not fun but fortunately, I was financially able to survive it with room to spare. Not unscathed, but not sunk either. Not everyone is in that position.

The Upside

There was one thing that happened, which it turns out, was not unlucky. Having had a vision and a taste of what agentic coding was and where it was going, I had nothing but time to give the practice my full attention. I have been almost exclusively coding with Claude Code since July of 2025. Today, I fall squarely into the “I have not written a line of code” camp on all my personal projects.

It Very Much Is the Reason

There are two types of posts that, today, tell me exactly where people are at with their position on AI. The first are the posts where an engineer, CTO, or “Founder” declares “AI can’t do X” or “AI could never do Y”. I’ll make no bold assumptions on what or how they were doing things, but for every project or exploration I have tried, the coding agent was able to deliver. Perfection was never the expectation, goal, or result. When a project that would have taken 3 months to deliver with a traditional engineer took a week, bugs or no bugs, how do you think a business is going to react? “Oh, it has bugs? Might as well keep all these engineers just to be safe.” Or, “I already get bugs with all these engineers, so let’s throw a couple guardrails and tests in and trim the payroll.” It’s not a hard decision (moral and ethics notwithstanding).

The second type of post, which as of this writing is on the rise, correlates directly with layoffs being attributed to AI and efficiency. These posts suggest that AI may be part of the reason, but argue it’s not the full story. Regardless of the details or the spin, the takeaway is the same: AI is not truly the real reason. I will tell you that it is very much the reason, if not exclusively.

As someone who has been fully in this agentic coding world since the full public release of Claude Code in May of last year, using it across languages, platforms and stacks, including a few I have never used, agentic coding is very much a reason that companies are laying people off, at least the smart ones that have had anything near the experience I have had with the technology.

Many More on the Way

I may follow up with all of my “proof” but at the moment, I just want to capture my position, not document the reasoning. This is moving so fast, that in the next several months, any need to provide justification for my thinking will be absolutely moot as proven out in the industry.

If you look at my resume, you can see I’ve been doing this a while, nearly exclusively, for my professional career. There is no putting the genie back in the bottle, no putting the cat back in the bag. The die is cast, the ship has sailed, and every other poorly aligned metaphor I can pile on here applies.

When I thought I was unlucky, I realize now that I wasn’t. Getting laid off gave me the time to practice agentic coding full time, and like any other skill, it takes time and repetition to become effective at. That head start put me ahead of a sea change in engineering that is now here, one that many engineers are only beginning to see. The layoffs are real, and I am of the mind that many more are on the way.

To be clear, even with a head start, I don't think that puts me or my career in the clear. Things are weird and incredible at the same time. It is part of the reason I've headed back towards my love of the world of embedded electronics and the like. Robotics might be calling my name a bit as well (weed killing laser robot anyone?) :)

In this week’s issue of DeepLearning.AI’s The Batch newsletter, Andrew Ng hit on something that’s been on my mind as the big AI companies fight to pull you into their proprietary ecosystems:

“AI agents are getting better at looking at different types of data in businesses to spot patterns and create value. This is making data silos increasingly painful. This is why I increasingly try to select software that lets me control my own data, so I can make it available to my AI agents.”

That quote perfectly captures why I’ve been building Neemee Notes.

The Problem with AI Tool Data Silos

We’re all using multiple AI tools now. Claude, ChatGPT, Gemini, and more. But here’s what’s happening: you do research in one tool, compile a list in another, get a second opinion somewhere else, and suddenly your valuable work is scattered across different proprietary environments. You don’t really own it, you can’t easily move it around, and you’re basically at the mercy of whatever company happens to host that particular AI tool.

That’s not sustainable, especially as we move toward a future where AI agents become more central to how we work. This is part of why I built Neemee Notes, a web-clipping, lightweight notes app for the web.

What Neemee Notes Does

Neemee Notes is my approach to a solution for this growing data ownership problem. It’s a web-based app that gives you one central place for all your curated content, with three core capabilities:

1. Web Clipping That Actually Works
Highlight text your are interested in saving on any webpage, tap the “Post to Neemee” bookmarklet in your browser, configure your note, tap save, and you’re done. The content and the web link are now saved to your notes collection. No more keeping 20 read-it-later tabs open or emailing articles to yourself just to lose them in the clutter. You text is saved, as is the link to the source you captured it from. I built Neemee originally because I was constantly finding articles and job posts I wanted to reference later for social media or research.

2. True Data Portability
Everything is saved as Markdown. If you don’t know what that is, just know it’s the format most AI tools use for text output. This means you can copy, paste, or download your content anytime from Neemee without dealing with proprietary formatting like Google Docs. Your data stays flexible and accessible.

3. Cross-AI Tool Integration
This is the BIG one. Neemee integrates with many AI tools through Model Context Protocol (MCP). Any AI tool that supports MCP should be able to connect to your Neemee notes (the tools I’ve tested are here, but they are changing often, breaking things along the way). You can say “Create something in Neemee notes” in Claude, then hop over to ChatGPT and say “Pull down that note I just created so we can work on it together.”

I personally use Neemee across Claude Desktop, Claude Code, ChatGPT, and Codex CLI. The point is that your curated data remains yours and works everywhere.

The Agentic Coding Experiment

Here’s what makes this project especially interesting for me: I built Neemee Notes almost entirely using agentic coding tools, specifically Claude Code, with Codex and Github Copilot as supplemental assistants. Now, I’m a senior software engineer with experience across stacks and cloud platforms, so this wasn’t complete “vibe coding,” but I purposefully limited my hands-on interaction with the code to see how far these tools have come.

Neemee Notes itself is the experiment. It’s my test to see if agentic tools can produce code quality good enough for a stable production app. The results have been promising, but not perfect. But this experiment is really just getting started.

Why This Matters Now

I fully believe the future of interacting with our data isn’t about clicking through apps and mobile interfaces. It’s about voice and conversational interaction with AI agents. But for that future to work, we need robust tools that let you manage your data in one place while keeping it compatible across different AI systems. It is also paramount that these interactions remain simple, without bloated UI’s with lots features and button, so that our primary interactions can be boiled down to simple commands.

Neemee Notes doesn’t try to manipulate your data with AI. At the moment, it has no AI functionality at all. It’s purely about giving you control over your information so you can use it with whatever AI tools you choose. I do have plans for personal knowledge management features and graph database capabilities, but that’s phase two or three, depending on whether people find value in this foundational approach.

How It’s Different from Existing Tools

Andrew Ng mentioned Obsidian in his newsletter, which is a fantastic app that does many similar things. But I’m trying to make Neemee even simpler. I don’t want large feature sets that complicate the core use case (for me). I also don’t want the data stored locally on personal devices because I need it accessible across all my tools and devices by default. I’ve lost files that way before, so cloud-based with full export capability is my preference. Think of it as a very simplistic version of Obsidian specifically designed for the multi-AI tool world we’re living in now.

Looking for Beta Testers

This brings me to why I’m writing this post: I’m looking for beta testers to help me work out the bugs and see if there’s real value here that people want to use.

If you’re juggling multiple AI tools, frustrated with data silos, or interested in seeing what agentic coding can produce, I’d love to have you try Neemee Notes and give me feedback.

Interested? Here’s how to get access:
Visit https://neemee.app and click on the “Request Beta Access” link and I will send you an invite (timing may depend on the volume of interest, but I will likely send out your invite within a day or two).

This is the first round of testing that is happening outside of my own happy-path flows that I’ve been going through as a developer and my basic suite of tests, so there will be bumps, but if you are feeling adventurous, jump on in and sign-up!

Neemee Notes is my attempt to solve a problem that I think we’re all going to face more and more as AI tools become central to how we work. Your data should be yours, and it should work everywhere you need it.

The full quote from Andrew Ng that inspired me to finally write this post and start Beta Testing:

“AI agents are getting better at looking at different types of data in businesses to spot patterns and create value. This is making data silos increasingly painful. This is why I increasingly try to select software that lets me control my own data, so I can make it available to my AI agents...

...P.S. As an individual, my favorite note-taking app is Obsidian. I am happy to “hire” Obsidian to operate on my notes files. And, all my notes are saved as Markdown files in my file system, and I have built AI agents that read from or write to my Obsidian files. This is a small example of how controlling my own notes data lets me do more with AI agents!”

https://www.deeplearning.ai/the-batch/issue-326

If you wait a year, IMO you’ll be too late if you have any competitors in your business domain. AI coding is as much of a mindset as it is a modification of status quo software engineering.

From my experience as a senior, staff level engineer, coding with AI agents very much can do “X” in many cases, though certainly not all. And when it doesn’t do X well currently, I’ve found you can often guide it to better results. The technology continues to improve rapidly.

I’ve been doing extensive AI coding over the last several months (Anthropic Claude Code, OpenAI Codex CLI), including working on my own web-based “mini Google Docs replacement” service that lets you bring your own notes in and out of ChatGPT, Claude Desktop, Claude Code and Codex via MCP so that you always maintain control over your own work.

Purposefully, I have not touched a line of code in that project to see if I can bring it all the way to production without significant intervention with manual coding.

But stepping back from the specific “production level code” end product, if you’re A/B testing features with test groups, AI coding speeds up the iteration process for product teams considerably. If it is a POC or MVP, a little imperfection in the code is fine as long as you have guardrails that cover you and security and basic performance. You can put those in place and build some of that into automated PR reviews.

While the jury may still be out on the production viability of a 100% AI coded app, adapting our thinking around the evolution of coding seems increasingly important.

Anecdotally, the piece by Ethan Mollick that I read that inspired this post, is on the money:

Whether you're in engineering, marketing, design, or any other field, we feel the need to evolve our workflows to adopt AI tools, learn to build AI-powered applications, and somehow track every breakthrough that happens seemingly daily if we want to stay relevant.

Coming from experience, trying to stay on top of all these tools will absolutely slow you down. My pro tip this week: drop the FOMO and focus. Not on a tool per se, but how to use generative AI in general. That means learning how to "talk" with these models to get them to do things that bring direct and immediate value to you and/or your job—whether that's getting AI to draft proposals, analyze data, create designs, or write code.

We're dealing with a whole new dynamic here. Generative AI creates tools and apps that create even more tools and apps. The pace is unlike anything we've seen before. You master one framework or tool, and three more have already launched. It's not sustainable to chase everything.

To boot, the barriers to creating with AI are dropping so fast that competitive advantages disappear quickly. What takes you weeks to build, someone else might recreate in days. Yes, you can crank out work a lot faster with these tools growing in numbers and capability by the day, but so can everyone else.

Rather than letting FOMO drive your decisions, focus on what actually makes your work better. Pick the tools that solve real problems for you. Build genuine expertise instead of surface-level familiarity with dozens of platforms. The fundamentals still matter more than knowing every new tool that drops.

Learn how to talk to these tools, using your words, to get them to do things. Focus on that skill above all else. Find a tool that gives you the most mileage to that end and lean into it.

As an engineer, for me it is has been the Anthropic ecosystem and Claude Code specifically, and I've been leaning in for a couple of months. Not to the exclusion of the other generative AI players, but focusing in one space for a while have been immensely productive for me.

I've gained a clear vision for what I believe the future of software engineering work will look like in a year...and it's about clear and concise communication, not just coding syntax mastery.

It’s your words that matter more than the code you can write.

That breadth has always been a strength, but it hasn't always fit neatly into traditional roles at the companies I’ve worked for. More so because most organizations are not quite sure how to capitalize on it, combined with the fact that I was not necessarily that successful at selling that skillset.

This is part of why I've been so bullish on AI-assisted coding. I know the fundamentals of most technologies that are technically "outside my lane," so being able to tap into a more efficient way to both answer questions and implement those technologies I am still learning has been sped up exponentially.

That was the preamble. Now I’m going to shamelessly self-promote this Expert Generalist article co-authored by Martin Fowler with Unmesh Joshi and Gitanjali Venkatraman that promotes the Expert Generalist concept since I now know that I am one.

I won’t spoil the article (go read it), but one theme in the piece highlights the value of software engineering generalists when it comes to breaking through vertical siloes within organizations:

"The ability to see complex systems across their full breadth can be essential when things go wrong. Faults are often not in the depth of a single technology, but in the implicit interactions between them. If specialists can't see the whole picture, they easily miss what falls between the gaps."

One of the larger projects I worked on in my last role fits that description precisely.

Vindication!

Last week I wrote a piece on this Substack called "Breaking Down Engineering Silos with AI Coding Tools: DevOps" where I posited:

"AI coding assistants like Claude Code aren't just transforming how we write code; they're enabling silo bridging between traditionally separated engineering functions. For mobile and frontend engineers who've been focused on their platforms, these tools provide a gateway to understanding infrastructure concepts and handling routine tasks that would otherwise require immediate DevOps assistance."

Martin’s article presented the following observation which completely aligns with my own experience and that quote from my piece:

"Large Language Models and tools based on LLMs are growing in prominence. We've observed that Expert Generalist capabilities are considerably more valuable with these LLMs. The relationship between Expert Generalists and LLMs is often similar to that between Expert Generalists and specialists in a team. Similarly to a specialist, an LLM can rapidly answer questions that an Expert Generalist will have when working in a new domain. This significantly lowers the barrier for exploring completely new and unfamiliar tools, offering a quick way to get started."

Could not agree more.

Here’s to the rise of the Expert Generalist in the age of generative AI. I’ve found my codified place in the world.

This isn't about replacing DevOps expertise but enabling collaboration across the full stack. When mobile and frontend engineers understand infrastructure decisions, DevOps engineers can focus on architecture and optimization rather than routine tasks. From my perspective, this makes teams more effective, especially when DevOps designs appropriate guardrails that let other engineers contribute safely without risking production systems.

For the past month, I've been experimenting with an important question: How effectively can AI coding tools help non-DevOps engineers manage cloud infrastructure, including complex tasks like cost optimization? The results have been intriguing enough to share and suggest there's real potential worth exploring further.

What AI Can and Can't Do

To be specific about the silo bridging I'm describing: AI tools show real potential for helping with routine infrastructure tasks like resource provisioning, basic monitoring setup, and cost optimization through configuration adjustments. However, they don't replace the deep expertise needed for designing fault-tolerant systems, implementing security best practices, handling complex networking scenarios, or making architectural decisions that affect system reliability at scale.

Think of it this way: AI tools help application engineers speak enough "infrastructure" to have meaningful conversations and handle day-to-day tasks, while DevOps engineers remain essential for the strategic decisions that keep systems secure, scalable, and resilient.

This infrastructure literacy addresses a common organizational challenge: engineers who don't understand their infrastructure often write code that ignores resource consumption and scaling costs. Minor inefficiencies can become expensive at scale. AI tools help non-DevOps engineers see these connections, creating a culture where everyone considers their code's downstream impact, reducing both DevOps monitoring burden and costly surprises.

The Experiment

I set up Claude Code with AWS and GCP CLI tools and used it to:

• Provision infrastructure for various projects (FastAPI apps, Neo4j databases, n8n workflows) using GCP services like Cloud Run, Compute Engine, Cloud SQL, Cloud Secret Manager, and Terraform, plus AWS services like SES for email routing

• Troubleshoot deployment issues

• Analyze and optimize cloud costs

• Configure appropriate resources for proof-of-concept deployments

The attached screenshot shows a concrete example: Claude Code helped me identify and resolve a Cloud Run cost issue through iterative resource optimization over just a few days.

These experiences taught me valuable lessons about the current capabilities and limitations of AI-assisted infrastructure management.

Why This Exploration Matters

You might wonder: Why not just use managed services like Render, Heroku, or DigitalOcean? These PaaS offerings are excellent and often the right choice. My goal wasn't to avoid them, but rather to explore how AI tools could help engineers who traditionally work at the application layer understand and manage the infrastructure layer when needed.

This capability becomes valuable for:

• Understanding the full stack to make better architectural decisions

• Prototyping ideas that require specific infrastructure configurations

• Debugging issues that span multiple layers

• Contributing to infrastructure discussions with more context

• Reducing the communication gap between application and infrastructure teams

From a cost perspective, PaaS solutions work well for focused deployments. However, organizations running hundreds of applications often find that managing their own cloud infrastructure becomes more economical than paying PaaS premiums at scale. For these companies, having engineers who can navigate cloud platforms directly, even without deep DevOps expertise, becomes a significant advantage.

Key Insight

I'm not a DevOps engineer. I know enough to deploy to production, but infrastructure optimization isn't my specialty. Yet with Claude Code, I successfully managed complex infrastructure tasks that would typically require deeper expertise.

This experience revealed something important: AI coding tools aren't replacing DevOps professionals. Instead, they're creating opportunities for better collaboration. When engineers from different domains can understand and contribute to infrastructure decisions, it leads to:

• More informed architectural choices

• Better communication between teams

• DevOps engineers freed up to tackle complex challenges rather than routine tasks

• Platform engineers who can prototype and validate ideas independently

The result? I've deployed and optimized multiple open-source applications while significantly reducing costs. This demonstrates how AI coding tools are breaking down silos between engineering functions, platforms, and technology stacks, fostering a more collaborative and efficient development environment.

The Bigger Picture

As AI coding assistants continue to evolve, we're seeing the emergence of more versatile engineers who can work across traditional silos. This doesn't make specialists obsolete; it makes them more valuable. When everyone has basic literacy across domains, specialists can focus on the truly complex problems that require their deep expertise, while routine tasks become accessible to a broader range of team members.

For organizations, this means more flexible teams, faster prototyping, and better cross-functional understanding. For individual engineers, it means the opportunity to break out of traditional silos and become more effective collaborators.

Looking Forward

This month-long experiment revealed something crucial for larger corporations exploring AI: when engineers can rapidly provision and optimize infrastructure without waiting for DevOps cycles, the pace of generative AI experimentation accelerates dramatically. Teams can prototype ideas, test hypotheses, and validate AI use cases faster than ever before. In an era where AI innovation speed matters, breaking down these engineering silos isn't just about efficiency; it's about competitive advantage in the race to implement transformative AI solutions.

This is where AI Engineering and adoption consulting looks to me to be becoming and essential practice. Organizations need more than just access to AI tools. They need stewardship, education, and practical guidance on integrating these technologies without disrupting what already works.

After 30 years in mobile/web/cloud development, I'm finding this intersection of technical expertise and organizational change management aligns perfectly with my own growing interest in helping teams bridge the gap between AI potential and AI reality.

The tools exist. The education and implementation strategy? That's the real opportunity.

Evolving as a Software Engineer

The immediate challenge is packaging my skills and passion for building dynamic, sustainable, fact-based systems (fundamental in GenAI) in a way that clearly demonstrates where I can help organizations navigate AI adoption. I can't be the only software engineer evolving alongside the industry while waiting for these new types of roles to crystallize within organizations.

AI Engineering and GenAI Adoption Consulting is the direction I'm defining for myself, even though job boards don't yet reflect what I believe organizations actually need quite yet. "AI Engineer" positions are appearing more frequently, but they typically have requirements like "3+ years delivering generative AI applications" and focus on technical delivery rather than the educational and organizational change management that most companies desperately need. I believe the change management and implementation are two sides of the same coin. You can’t split them in my opinion.

The gap is clear: organizations have access to powerful AI tools but lack the expertise to implement them effectively without disrupting existing workflows. That's where the real opportunity lies.

It's a wild time to be job hunting, but I'm seeing a definitive rise in opportunities that align with what I want to build. The demand is there, even if the job descriptions haven't caught up yet.

That's actually the best news.

My working theory is that the reason it feels so overwhelming is because of the sheer scale of this shift. I get into that scale further down in the post, but the key difference with GenAI is that the technology can help build itself. Generative AI is being used to create more generative AI, which means the tools are now helping build more tools. That recursive nature means the pace of change isn’t just fast-it’s accelerating exponentially.

In October 2024, Thoughtworks released a Technology Radar report that described a "Cambrian explosion" of generative AI tools (https://www.thoughtworks.com/en-us/radar). That is where I first heard the term. The report highlighted a sudden surge in agent frameworks, evaluation tools, guardrails, vector databases, and observability platforms. It compared this moment to the JavaScript framework boom of the mid-2010s, but faster and far more complex.

Not to split hairs, but I’m thinking the term Cambrian Bloom might be a better fit here. The term comes from biology, where the Cambrian period saw an explosion of life forms in a short span of time, resulting in rapid diversification and complexity. Bloom suggests not just an explosion, but a flourishing. A diverse, fast-moving ecosystem growing in all directions. Generative AI isn’t limited to one domain. It’s reshaping how we build software, create media, do research, and run businesses.

Before we can fully understand the scale of what's happening with generative AI, it helps to look back at the other major technological shifts that came before it. Each one brought new capabilities, new ways of interacting with software, and entirely new business models. But none of them had the kind of exponential self-propelling growth we’re seeing now.

The PC Era

The PC era introduced computing to individuals and laid the foundation for personal productivity software and early desktop tools. It laid the foundation for personal productivity software and early desktop applications. The innovation was significant, but mostly focused on standalone tools. It created a new industry but didn’t yet connect the world.

The Web Era

The web era brought connection. With the rise of browsers, websites, and online services, software became global. Businesses could now operate online, and the internet became part of daily life. This shift was more than a new toolset. It changed how we shared, sold, and experienced information.

The Mobile Era

The mobile era put software in everyone’s pocket. Smartphones made apps the dominant interface for digital services. The app economy exploded. New business models and personal, always-connected user experiences emerged. Mobile scaled software’s reach more than ever before.

The GenAI Era

Now comes GenAI. And unlike previous shifts, this one is recursive. Generative AI is being used to build generative AI. Tools, platforms, and workflows evolve daily. Language is becoming the interface. Developers are moving from UI kits to APIs to prompts to autonomous agents. The Cambrian Bloom isn’t just about apps. It includes everything that makes them possible, including model infrastructure, safety systems, protocol standards, and evaluation methods.

In terms of scale, GenAI makes past shifts look small. The PC era brought computing to individuals. The web connected the world. Mobile made it personal and portable. GenAI is everywhere at once. It touches every domain and evolves at a pace that no single person or company can fully wrap their head around.

Comparing the Scale of Each Era

It can be hard to put this moment into perspective without looking at what came before. Each previous technological shift brought its own kind of disruption, but also had its limits in terms of reach and impact. GenAI isn’t just a new kind of technology. It operates on a completely different scale than what came before. This table offers a rough, imaginary sense of how each wave compares to the next in terms of influence and growth velocity.

Finding Your Footing

The Cambrian Bloom is a helpful way to think about what’s happening right now. It reflects just how quickly and widely things are evolving. This isn’t just another wave of innovation. It’s more like a feedback loop, where tools help create more tools and new systems pop up faster than anyone can keep track.

If we look back at earlier tech shifts, they all brought big changes, but none moved with this kind of speed or touched this many areas at once. GenAI is changing how we build software, run businesses, and even how we think about work itself. And because it can improve and extend itself, the pace keeps picking up. It’s a lot to take in. But if we can step back and see the broader shape of what’s happening, it gets a little easier to find our footing and move forward.

One of the biggest challenges right now is simply finding your footing. That’s something I’ve been working on myself as a software engineer, trying to stay grounded in what and where I spend my time on, while everything shifts so quickly.

Whether you're leaning into AI or intentionally steering clear, it helps to have a steady point of reference. Something you can return to as the landscape keeps evolving. Reorientation is becoming a skill in itself.

Borrowing from Apple’s old tag line, it’s time to “Think Different”.

It’s certainly a wild time to be job hunting—both for personal reasons (being 50+ among them) and because the tech hiring climate feels pretty uncertain, at least anecdotally, from what I’ve been seeing and hearing over the last year or so.

That said, after nearly 30 years in the web and mobile space, I do feel incredibly fortunate—this is actually my first experience being directly impacted by any sort of layoff, large or small. To be clear, this sucks, but I've always had a bit of a lemons-to-lemonade starting position when life happens.

One thing is for sure: I'll be getting a firsthand look at the reality of the market starting... now.

Rethinking the Job Search

This job hunt is without a doubt going to be a journey. Instead of trying to mold myself to fit specific job descriptions, I'm working on clearly articulating the kind of role that's the right fit for me—and being transparent about that along the way.

One of the trickier parts is that the kinds of roles I'm most interested in are still evolving. Some are only just starting to hybridize in a way where the responsibilities I'm after are beginning to show up in the job descriptions (hint: Generative AI-related).

In thinking about this—and in answering a former colleague who asked what kind of role I’m looking for—I realized two things:

1. I don’t want to fall into the “what ya got?” mindset that my broad skillset sometimes tempts me into.

2. I’m mostly focused on roles at organizations that are seriously exploring how Generative AI can be applied impactfully to software engineering, application development, and infrastructure. That’s where I’m most aligned and where I believe I can have the most impact.

Where I’m Coming From, and Where I’d Like to Go

I'm still narrowing things down, but my core skillset is in mobile iOS development, with broader experience across full stack web, cloud platforms (AWS, GCP), and most recently, GenAI.

I’m open to tech lead, solution architecture, or senior IC roles—ideally somewhere I can combine my mobile and GenAI experience and help shape where things are headed in that space.

In my last role at The New York Times (it’s my last week as of the time of this writing), I helped co-organize an internal AI Community of Practice focused on implementation, governance, and knowledge sharing around Generative AI and LLM-backed application development. I was part of a small group exploring how these technologies could reshape software development (think coding assistants) and application architecture at an organizational level. We helped teams explore and evaluate stack components and options for GenAI-backed systems, and the company was actively investing in shared learning to prevent siloing.

It’s important to me to continue this kind of work—whether it’s embedded directly in a role or as part of a collaborative contribution. I want to be part of the conversation about what’s next, and ideally help shape it.

“Why,” you ask?

A New Abstraction Layer: Programming in Natural Language

Software engineering is experiencing a paradigm shift as natural language becomes the newest and most accessible level of abstraction in the long evolution of programming. From early machine code and assembly language to higher-level procedural and object-oriented languages, each leap in abstraction has expanded who can build with code. Now, natural language interfaces are opening the door even wider, lowering the barrier to entry for non-programmers while still requiring experienced engineers at the helm to guide, validate, and shape the systems being created (for the moment...).

This moment marks a profound transition—not just in tools, but in who gets to participate, and how. We’re in the early days of watching programming shift from a domain-specific languages to a more conversational one, and with that comes enormous opportunity, but also a need for stewardship.

This is where I believe I can help.

It's nearly impossible to imagine how, as an engineer, you'll be able to do your job in the coming years without leveraging GenAI. You'll need an AI assistant to help keep you up-to-date and informed on software development trends based on your personal preferences and domain, and this completely glosses over the fact that you'll be using a copilot in your day-to-day programming workflows.

This focus on information wrangling is the foundation of my GenAI learning journey. In previous posts, I've talked about trying to define the LLM-backed App Stack I wanted to use, but it's clear we're moving into a world where these stacks are far more dynamic, composable, and adjusted based on the specific business problem a GenAI application aims to solve. You can't throw a predefined stack at these types of applications, that much has become clear.

If I can't learn a predefined stack like before, what does the new approach to application development look like?

Ultimately, That question is what I am working on and it is really baking my noodle. The good news is that I love these types of meta problems and I know where to start now.

The Diminishing Value of Syntax Mastery

The days when a developer could rely on a tutorial or technical article to accomplish a task in a particular language and expect it to stay relevant and useful for months or years are fading fast. Chunks of syntax and example code have less utility now. Coding copilots provide them right out the gate. A focus on memorizing or mastering syntax is likely to have a diminishing value as natural language slowly becomes the next highest level abstracted language in our programming toolbox.

The Shift to Problem-Solving Over Syntax

Engineers who love syntax and semantics will find themselves increasingly vulnerable in the years to come compared to those who thrive on tackling complex problems that require deeper algorithmic and systems thinking. The rise of natural language as an abstract programming interface emphasizes the need for engineers to shift their focus from syntax mastery to more creative problem-solving.

Leveraging GenAI effectively requires learning to interact with various Language and Multimodal Models, each with unique strengths and weaknesses, not unlike working with people with diverse skills and personalities. The rapid evolution of GenAI tools is reshaping the skill set required for software engineers, demanding a combination of technical depth, adaptability, and a preternatural love for continuous learning. From what I am seeing, engineers should prioritize developing skills and workflows that enable effective collaboration with advanced AI tools to remain competitive in the evolving job market over the next couple of years.

Interesting… So Now What? 

Next week, I plan to use Google Colab with LangChain's LangGraph as my orchestration layer to experiment with different LLM capabilities in an interactive notebook environment.  Colab has Gemini available as a GenAI coding assistant, which will help speed up my learning since it is not an environment I’ve worked with yet (I usually skip the hands-on portions of the tutorials I’ve been watching).

The Meta Meta

• My posts will never delve into coding specifics, as the internet is already full of those. Instead, they're about the refactoring of my own coding and architecture skills, including some significant mental rewiring in how I think about software engineering in this new GenAI era.

• I also hope that the tools and frameworks I mention along the way could be valuable if you're on your own GenAI learning journey. If nothing else, if you haven't heard of some of the things I talk about, you can go kick the tires on your own.

I've started experimenting with n8n, a low-code workflow automation tool, to create workflows that automate email newsletter content parsing, summarization, and named entity extraction (my GenAI "Hello World" project, as it were). Through this process, I've found that n8n does indeed work well as a playground for my LLM experiments. Instead of focusing solely on specific implementations of the various technologies in a tech stack, I'm using n8n to directly engage with different LLMs and determine which can consistently extract and summarize content from email newsletters. This shift allows me to streamline my approach while learning the capabilities of a wide array of LLMs in practical hands-on scenarios.

Information overload

Information overload has been my biggest challenge, so I'm making it a top priority to address. The pace of development in the LLM ecosystem is relentless—new models, new tools, improved capabilities, and changing costs all make it nearly impossible to manually keep track of the available LLMs. As an engineer learning how to build LLM-backed applications, it's clear that before I even attempt to understand LLM capabilities, I need a system to manage the information about them.

That's why I'm pausing my deep dive into specific LLMs to build a knowledge management system that brings information from newsletters, blogs, and community updates directly to me in a digestible form. My aim is to automatically collect, summarize, and organize the latest updates on GenAI and LLMs. Using tools like n8n, I plan to automate this information flow—ingesting incoming emails, summarizing their contents, extracting named entities, and creating a consolidated daily update for myself. This will serve as my foundation, a steady intake of LLM-related knowledge that will ultimately enable me to make informed decisions on which models to use and when.

Abstraction is key

Another realization this week is the need for flexibility. Whatever LLM stack I assemble must be able to adapt as new models and better technologies emerge. This means having a way to swap LLMs and other components in and out seamlessly, and using agentic workflows to leverage multiple LLMs, each specialized in its own domain. In practice, this could look like one LLM coordinating tasks while other, specialized LLMs handle more niche functions.

The journey is not just about understanding what LLMs exist, but also about creating a robust, semi-automated system for tracking and understanding this rapidly evolving landscape. With this foundation, I hoping to be able to explore LLMs a bit more confidently, knowing I have the information I need to stay on top of developments—without drowning in the noise.

Developing a schema for LLM-backed applications

Another focus this week has been developing a schema to outline the essential components needed for building LLM-backed applications. To start fleshing out this schema, I used a couple of resources. The first is an article from Andreessen Horowitz on emerging LLM stacks from last year, which provides a detailed overview of the components and data flow involved in LLM-backed systems. I'm also looking at LangChain’s orchestration tools, specifically their Components, which offer a structured breakdown of the key elements necessary for coordinating tasks within LLM applications.

By combining these two sources, I’ve begun developing a more simplified and practical schema to help me (and possibly others) understand and keep tabs on the evolving options for the core components of LLM-backed applications. This schema is still in development, but I'll share more details in a future post.

The meta-meta

Ongoing reflections on GenAI-assisted learning and writing, "learning in public," and the topic of GenAI application development.

• This journey of learning and understanding LLM-backed applications is also serving a dual purpose as an exploration of how generative AI can assist in my writing process.

• Leveraging tools like n8n and various LLMs, I'm working on new ways to enhance my learning workflows, experiment more efficiently, and document my learning in real time. It feels like building a course you want to teach, using content about a technology that was, in some cases, released just a week before. Craziness.

• I've also started using OpenAI's new Canvas tool to help with the writing process, which has provided an additional layer of support and flexibility in drafting and refining my ideas.

• The rapid change in this field of software development—both in the tools used to build applications in general and in the stacks for building LLM-backed applications—is moving so fast that by the time I finish an article, my thinking has already evolved. It's a bit of insanity... but the kind I fortunately love.

• These reflections will continue to evolve as I build out this larger body of work in this Substack, sharing both the challenges and the innovations that emerge along the way. I already feel like I need to bump up to yet another higher level of abstraction to keep on top of this field.

1. I just started this “Learning Generative AI (GenAI)“ writing project recently. I’m a longtime mobile and web developer expanding my skillset into the GenAI space. I’m still figuring out the Substack community, ecosystem, and the Generative (GenAI) tech content that is already flowing in this space. I had avoided Substack for years, but now that I am here, I don’t know why. Lots of great content and contributors in this space. I already like it much more than Medium and other swipe swindling, gaze gluing, scroll holing apps (aka social media).

2. I’m still dusting off my writing skills and starting to use GenAI as a writing tool. I don’t need it to tell me what to write, so it is a writing assistant, editor and sounding board for me so far. I also have not tried to define my audience as of yet, but I’ll stick to working on writing habit for now.

3. I was sharing my process for evolving a new tech stack for building LLM-backed apps. I wasn't building a completely new stack, but instead relying on my trusted methods for selecting the layers of the stack I planned to use for full-stack GenAI app development. Unfortunately, what had once been tried-and-true turned out to be tired-and-blue in this rapidly evolving world of software development that leverages natural language at multiple layers.

You Are Here

Let’s get oriented on what I’m writing about.

My first post laid out the layers of the stack I was considering. The second post started to offer some details as to the what and why of each layer, as well as sharing some of my initial implementation investigations.

In my first stack layer exploration with a new CMS, I quickly ran into the typical “not on my machine“ configuration issues that almost always come up whenever diving into new stacks or frameworks. That was expected. But what I quickly realized after spending more time that I wanted on the CMS was that I was starting this GenAI app development learning adventure backwards. I was not working at the highest level of abstraction for my given objective. So that begged the question: What is my primary business objective?

The primary objective for this learning adventure is to learn how to build LLM-backed applications and services. Does learning a new CMS or web framework get me there? Not directly. Those can come into play down the road. For now I needed a much faster way to prototype some basic workflows or spin up endpoints that execute some GenAI processing, be it text or multimodal.

That brings us a little closer to where I am today. I did have one more stop to make on my way to where I am today though. That was to kick the tires on no-code / low-code visual AI workflow automation tools. Surely these types of tools will limit the time spent on messing with configuration and cranking out boiler plate code. This would bring me much closer to my objective as I need to be to get moving faster…or so I thought.

New and Shiny Visual AI Workflow Builders

I dove right into n8n, a partially open-sourced visual AI workflow building tool, to explore an idea I’ve been working on for a while. The first step was to create a flow that could directly ingest and parse incoming emails in their raw format. Using n8n, I quickly set up an endpoint to which I forwarded raw emails from SendGrid. I was able to quickly test my flow and watch as the email was successfully received and parsed by a node I had just visually configured. Great!

Next, I started to work on using an LLM to extract entities and summarize the content of the email. Adding credentials for my OpenAI API account was simple enough. Firing up and configuring an “Information Extractor“ node was easy as well. I sent another test email, and there it was. My extracted entities and summarization as a JSON Schema formatted output. Bravo!

Wait…it made up some names. OK. I swapped the LLM I was using via the node configuration settings and I changed the temperature. Next I tweaked the output format a bit. Hmmm. Totally different response quality. Testing it again tripped the rate limit for the model I have selected.

Ohh… Wait a minute. I see the problem.

One more level of abstraction

The shortest path to learning about LLM app development is by have as limited a set of intermediaries between me and the LLM to get started. Not only that, but I need a way to keep track of what LLM’s are out there, what they are good at, what their token, context windows, pricing and API rate limits are. And that is just to get started. Are they open source, closed source, open weighted and suited to my app’s business objective? There will be no LLM apps if I can’t tackle how to manage all this information about LLMs themselves.

With the rate of LLM development and releases, this is a significant issue to tackle. When you’d adopt and learn a new framework in the past, you could count on having almost a year to work with it before you had to learn the new major developments with it. LLMs and the tooling and orchestration layers evolving around them are moving so fast, as an application engineer, how are you supposed to keep up?

Managing information overload

Effectively managing all this information around LLMs is essential for developing LLM-based applications. Without staying informed about the rapidly evolving landscape of models and their capabilities, you will continually struggle to choose the best option for your application or fail to maintain up-to-date knowledge of LLM trends.

That is where I’m at today. I’m working on a few approaches to these issues from both the hands on standpoint interacting with LLMs as well as the knowledge management aspect. I’ll come back to those in future posts.

If you’re a software engineer or application developer like I am and want join my learning journey, subscribe to stay in the loop.

Subscribe now

If you are someone with experience in the GenAI application development space and have anything to help illuminate the various waypoints on this journey, your input will be greatly appreciated.

Leave a comment

One of my objectives with this tech stack is to have a modular set of components that I can use at the highest level of abstraction possible. With so many tools and frameworks evolving around Generative AI, my aim is to create a stack that can easily adapt to the rapid changes in the ecosystem—something both robust and flexible. Ideally, I want a foundation where I can focus more on exploring concepts and less on spending time wiring systems together and learning new syntax and semantics. After all, natural language is essentially the latest programming language.

I suggested that I felt confident in my research on each layer of the proposed stack, having settled on the final contenders. However, after digging in further, I've reassessing that assertion—I'll revisit this point at the end of the post. For now, I'll review the stack layers I'm currently working with or planning on using:

🟢 Continue 🔴 Stop 🟡 Explore

Swift

🟢 Mobile Development (my bread and butter)

Swift and iOS development is a given no matter where my Generative AI explorations go. It is at the heart of my day job. That being said, Apple Intelligence and the evolution of Siri Intents that will turn apps into Retrieval Augmented Generation (RAG) data sources for Siri is something that I'm keenly interested in exploring more this year.

Ruby on Rails

🔴 Full-stack Web Development / CMS

This has been my default web stack for nearly a decade, and I've always appreciated its conventions and full-stack coverage. However, the ongoing changes to the JavaScript layer, along with attempts to avoid it, have increasingly become a long-term liability. Now, the approach is to embrace JavaScript, especially since other tools I want to leverage depend on it.

Strapi

🟡 Headless Content Management System (CMS)

I need a CMS to replace my custom-built Rails solution, and I was looking for one that offers advanced capabilities for managing content hierarchies and more complex relationships. After exploring several options, Strapi checked many of my boxes during the initial review. The fact that it is open source was another influencing factor.

Next.js

🟢 Web Application Framework

This is my chosen replacement for Ruby on Rails. While there are lots of options available, this one suits my style well. I’ll also integrate Prisma as my new Object Relational Mapping (ORM) layer to help encapsulate data models and database interactions. Additionally, Vercel's (the authors of Next.js) hosting and service add-ons provide a complete end-to-end platform, allowing me to focus on development rather than infrastructure management.

FastAPI

🟡 Python-based API Framework

I've only worked with Python a bit over the years, so this is mainly an opportunity to revisit it. Given its ubiquity in the Generative AI space, the general exposure has value. While somewhat redundant given Next.js's API capabilities, I found a reference architecture on Vercel's site that allows combining a Next.js app with a FastAPI service within the same codebase, so that should be fun.

LangChain & LangGraph 

🟡 LLM Application Framework & Agentic Workflow Orchestration

For my LLM-backed application development needs, this is where I'll begin. They offer both JS and Python versions, providing flexibility in case I need to integrate tools that may not be supported in both languages.

Postgres

🟢 Relational Database and Vector Store

I'm not ready to abandon my preference for ORMs and relational databases, so I'll continue using Postgres for now. Since Postgres also has vector store capabilities, I'd prefer to avoid adding another tool and give it a try in this new LLM-backed application space. I'm actually more interested in graph databases and RAG at this point, so I'm hoping Postgres's vector store capabilities will meet my initial needs.

Neo4j

🟢 Graph database

I haven't yet deeply explored graph databases, but given my experience with highly related data and CMSs, I'm optimistic about their potential utility. Specifically, in the Generative AI space, I'm particularly interested in using Neo4j as my graph database and incorporating it into agentic workflows using RAG. 

That covers the overview of the core elements of my new proposed stack. The next part is to actually start pulling together the shell of an app that stitches them all together and get it up in the cloud. Before I do that though, my thought was that I should stand up a CMS so I’ve got a place to keep my content as we hit the ground.

The Rubber Hits the Road: Let’s get building

When I initially chose to explore the Content Management System layer from my selected tools first, I quickly realized I might need to reassess my priorities.

After running into a few issues with library dependencies while setting up the local development environment for Strapi, I had a bit of a reality check. I decided to step back from Strapi and explore some other CMS options, each offering different levels of abstraction from a developer's perspective. I reviewed platforms like Wix, Storybook, Builder.io, and Contentful—each with its own idiosyncrasies, learning curves, and specific features aimed at different audiences.

So that begged the question: Does a CMS fit into my desire for a streamlined, abstracted workflow for delivering GenAI backed applications? I do need to manage content, but learning another complicated tool now seems like a distraction.

Instead of a CMS, I’m abstracting a level and exploring a low-brow admin interface for Next.js apps. I think Next Admin might do the trick. I need to manage basic content at this point, not a full ecosystem of content managers, users and another standalone application. I also came across Novel, a WYSIWYG web editor that, teamed up with a basic admin, lets me handle the basic content needs I’ve got at the moment.

Thus ends my first tangible step forward on this adventure.

I’ve actually already got a Next.js app fired up with FastAPI swizzled into it along with a Postgres database, all comfy and cozy over on Vercel. I have one more tool to explore before I go full steam ahead, but I’ll save that for another post.

These are not the Tech Blog Posts You Are Looking For

I should mention that I don't plan to posting many in-depth articles about the technologies I'm using in my GenAI application development journey.

I believe that application development is fundamentally changing now, and will grow less and less familiar in the next couple of years. My writing on this site will focus on exploring that shift—from the syntax and semantics of programming languages to a future where natural language becomes the primary tool for instructing computers to achieve specific business objectives and other desired outcomes.

This is a massive paradigm shift that is also coming on a wave of research, tools, frameworks and architectural patterns that are being developed and released on a cadence that makes it nearly impossible to keep up as an engineer.

This is site is my pulling out the surfboard and riding that wave as I enter into the fourth season of my programming career.

1. For my day job, I’m a Staff Software Engineer at the New York Times.

2. For the other part of my world, I work part-time on my “retirement business”, Daily Grains, with my partner in life and business Ashley.

You will likely be seeing things about tech and bakeries, but not necessarily mixing to the two. But who knows what I’ll get up to at this point. It’s too early to say. 

Nearly every year that I've been a developer since 1996, I take some time to survey the tech stacks I use as well as investigate any new technologies I am interested in exploring. This year, Generative AI is the central theme that is now at the center of my 2024 investigations.

I've completed enough research at the time of this writing to have settled on the stack I am digging into. The main goal it to support my typical need for some sort of content management system, an API I can build and expand for managing and processing a lot of interrelated data.

I plan on writing up a brief post on each item in my new stack as follow up post, but for now, here's the list:

I'm actually doing this more for my own benefit at the moment to consolidate my selections and record my reasons for posterity.

As I mentioned, I'm also trying to start up a writing habit again by making small posts here since centralized social media platforms are the devil's playground. 😏

Subscribe now