2026 on Funky Si's Blog

Portfolio: Live Azure Workloads, AI Search, and Dev Tools

funkysi1701@gmail.com (funkysi1701) — Mon, 01 Jun 2026 20:00:00 +0000

Featured Projects

Three live Azure workloads I own end-to-end — CI/CD static delivery, AI-backed search on real content, and full-stack Blazor with actual users.

🔧 Episode Atlas

Track TV progress at scale with per-user state and cloud-backed data.

What it does: Per-user episode lists, “last watched” markers, and curated metadata links — so long-running franchises stay manageable.

Tech used: .NET Blazor, Azure Static Web Apps, Azure Functions, Cosmos DB, GitHub auth.

Why it’s impressive: Demonstrates scalable data modelling and cloud-first architecture for user-driven applications.

Deployed to AzureImplements authentication / APIs / caching

Outcome: Turned a personal “where was I in 900+ episodes?” problem into a maintainable multi-tenant pattern for identity, persistence, and UX for ongoing shows.

Links: episodeatlas.com

🔧 Semantic Search

AI-powered natural language search for discovering content beyond keywords.

What it does: Accepts conversational queries, retrieves meaningfully related posts, and surfaces them alongside the site’s JSON index search.

Tech used: .NET, Azure, Cosmos DB, OpenAI.

Why it’s impressive: Showcases practical LLM integration in .NET beyond basic chat interfaces.

Deployed to AzureDesigned with clean architecture

Outcome: Explored how vector-style retrieval and operational concerns (cost, latency, content freshness) fit next to a static Hugo site without compromising the authoring workflow.

Links: search.funkysi1701.com · linked from Search

🔧 Blog Platform

Technical blog on Azure with CI/CD—fast static pages, search, and comments without babysitting an app server.

What it does: Publishes posts, generates RSS and a JSON search index, integrates Giscus for discussions, and deploys on every merge.

Tech used: Hugo, GitHub Actions, Azure Static Web Apps, Giscus.

Why it’s impressive: Highlights modern static-first architecture with automated deployment pipelines.

Deployed to AzureCI/CD via GitHub Actions

Outcome: Demonstrates a production-shaped static pipeline — preview builds, repeatable deploys, and content-driven SEO — suitable as a reference architecture for docs and marketing sites.

Links: GitHub repository

💼 Cloud & Production Systems

The featured trio — Episode Atlas, this blog (Hugo on Azure), and Semantic Search (search.funkysi1701.com ) — is fully described in Featured Projects above and not repeated here. Below is the rest of the catalogue by category.

🔧 Thorne Pentecostal Church

Dependable church presence online—clear for newcomers, simple for volunteers to keep current.

What it does — Presents service times, beliefs, and visitor information with a simple structure so members and newcomers get answers in one place.

Tech used — HTML/CSS, Azure Static Web Apps.

Why it’s impressive — Demonstrates proportionate engineering: production-grade static hosting and clear information architecture for stakeholders who need reliability, not complexity.

Engineering signals: Deployed to Azure · CI/CD via GitHub Actions

Outcome: Delivered a first web presence focused on clarity and sustainability so non-developers can keep content current with minimal process overhead.

Links: Thorne Pentecostal Church

🛠 Tools & Utilities

🔧 Mandelbrot Generator

Interactive Mandelbrot exploration in the browser—smooth zoom, pure WASM, zero server-side rendering cost.

What it does — Renders the Mandelbrot set in the client with zoom for desktop and mobile, demonstrating CPU-bound UI work in WASM.

Tech used — .NET Blazor WebAssembly, Azure Static Web Apps.

Why it’s impressive — Demonstrates client-side compute discipline in Blazor WASM: rich, interactive UI with predictable cost because heavy work never hits the server.

Engineering signals: Deployed to Azure · Designed with clean architecture

Outcome: Built the tool to stress-test interactive Blazor WASM performance and touch UX patterns — a small codebase that still informs decisions about heavier client-side workloads.

Links: Mandelbrot Generator

💡 Ongoing exploration

Areas I keep hands-on with outside these shipped projects:

.NET Aspire — Cloud-native composition and local dev parity
Kubernetes — Orchestration and service boundaries
Elasticsearch — Search and analytics stacks
Azure Functions — Event-driven and serverless patterns
DevOps automation — CI/CD, IaC, and release hygiene

🤝 Collaborate With Me

Interested in collaborating on a project or discussing an idea?

Contact Me — Get in touch
GitHub — Code and experiments
LinkedIn — Connect professionally

📚 More resources

Tools & Resources — Recommended development tools
About Me — Background and experience
Blog Posts — Technical writing

Episode Atlas: Track Your Star Trek Rewatch Journey

funkysi1701@gmail.com (funkysi1701) — Mon, 01 Jun 2026 12:00:00 +0000

If you have ever tried to rewatch Star Trek properly—not just dip into a favourite episode, but work through hundreds of instalments across multiple series—you will know the feeling. You pause Deep Space Nine for a few weeks, start something else, and suddenly you have no idea which episode you were on. Spreadsheets help for a while, then they do not. Notes on your phone get lost. Memory is unreliable when you jump between TNG, DS9, and whatever new show has just dropped.

That is the problem Episode Atlas exists to solve: search 900+ episodes and films, mark what you have watched, and always know what to watch next—without treating a rewatch like a project-management exercise.

Why I built it

I write about Star Trek on this blog from time to time—episode reviews, top-50 lists, thoughts on new series. The honest origin is simpler than that, though: I wanted a better way to track my own rewatches.

Generic TV trackers are fine if you watch a bit of everything. They are less helpful when you care about one enormous franchise with inconsistent stardates, films mixed in with series, and the urge to jump to “all the Borg episodes” rather than the next sequential instalment. Episode Atlas is deliberately narrow (if you can describe a database of over 900 episodes and films narrow!): all of Star Trek, in one place, with features shaped by how fans actually rewatch.

You can use Episode Atlas without creating an account. Search the catalogue, open episodes, browse collections, and spin the random picker—no signup required.

When you want your progress to stick, sign in and start your captain’s log. Mark episodes watched, and the site remembers where you left off across every series—even if you detour from DS9 to TNG and back again.

Your service record

Once you are logging watches, the homepage gives you a service record at a glance: how many of the 900+ episodes you have seen, your percentage through the franchise, and your current watch rank (from the early ranks up through Lieutenant, Commander, and beyond). The site shows how many more episodes you need for the next rank, so a long rewatch feels like progress rather than a vague “I think I am halfway through Voyager.”

You can also earn commendations and build an active duty streak—small nudges to keep visiting when you are in the middle of a serious rewatch. It is the same idea as a fitness streak, but for Star Trek.

Find any episode in seconds

Search is the front door. Most visits start with “I know roughly what I want” or “which episode was that again?” Filter by series and season to narrow the list; keywords catch titles and descriptions you only half remember. Every series and the films are in one catalogue.

Episode pages: context and next steps

Open any episode and you get what you need for a rewatch session: metadata, previous and next navigation within the series, season progress, and actions to mark the episode watched or jump to the suggested next episode. Your captain’s log ties it together—what you logged today, what you have already seen, and where to pick up when you return.

The flow the site describes is simple: search → open → mark watched → move on. Three gestures, no spreadsheet.

Collections when you want a mood, not a season

Collections answer a different question from search: “It is late; show me something good in this mood.” Each collection points at Borg stories, time-travel episodes, holodeck highlights, and similar lists—fan knowledge encoded as browseable sets, so you skip filler without digging through every season.

Random episode when you cannot decide

The random episode picker is for the evenings when you and the sofa have agreed on Star Trek but not on which Star Trek. One click, one suggestion—useful when commitment is the hard part.

How it compares to other sites

Episode Atlas is not trying to replace Memory Alpha for lore or IMDb for cast lists. It is built for progress: what you have watched, what rank you have earned, and what to play next. If you have ever bounced between a wiki, a ratings site, and a generic tracker and still not known where you were in DS9, this is the gap it fills.

Try it

episodeatlas.com — free to browse, sign in when you want your captain’s log saved. Search, mark your first episode, and see your rank climb.

How do you track long rewatches—spreadsheet, app, or pure memory? If you try Episode Atlas, I would genuinely like to know what works for you and what does not: features you love, gaps that annoy you, or anything that would make a rewatch easier. Leave a comment below, or use the feedback option on episodeatlas.com —both reach me, and both help shape what I build next.

How I Use AI on Side Projects: ChatGPT, Cursor, and Copilot

funkysi1701@gmail.com (funkysi1701) — Fri, 10 Apr 2026 12:00:00 +0000

There is no shortage of AI tools aimed at developers right now: chat assistants, IDE completions, agents that promise to run your tests, and new products every month with overlapping features. I am not going to argue which one is “best.” Instead, here is what I am actually using today on hobby code: ChatGPT for quick, low-context questions, Cursor when the work needs my repository in the loop, and GitHub Copilot for fast inline help while I type. That trio might change, but it reflects how I have learned to spend money and attention in 2026.

The through-line is simple: match the tool to how much context the problem needs. That stops me from dumping half a repo into a browser tab for a vague design question, or firing up an editor assistant when I only wanted a two-paragraph explanation of something I could read in the docs.

This is not a product review. It is a snapshot of how I work, using the projects on my projects page as concrete examples.

ChatGPT: questions that do not need my codebase

ChatGPT is still my first stop when I am trying to frame a problem. I use it when the answer is mostly portable knowledge: comparisons, vocabulary, “what should I read next,” and sanity checks that do not depend on the exact shape of my solution.

A few examples from things I have built:

This blog (Hugo + Azure Static Web Apps) — I might ask how people usually implement site search on static sites, or what the trade-offs are between generating a JSON index at build time versus leaning on a hosted search service. I am not looking for a drop-in patch to my theme; I want a short list of options so I can decide what fits a hobby budget.
Episode Atlas (Blazor, Functions, Cosmos DB) — good prompts sound like “patterns for tracking per-user progress through a large catalogue” or “when a tiny Blazor app might still justify a separate API layer.” Those are design conversations. The model does not need to see my episode containers to help me think about partition keys and stale data.
Mandelbrot Generator (Blazor WebAssembly) — I have used general chats to reason about why browser-side fractals feel CPU-bound, or what people typically do first when zoom performance tanks. Again, that is physics-of-the-platform stuff, not “line 40 of my render loop.”
Experiments — when I am poking at .NET Aspire , Kubernetes, Elasticsearch, or Azure Functions in my own time, ChatGPT is useful for learning paths: what to skim first, what terms I am mixing up, and what I am over-engineering for a toy.

Where ChatGPT falls down is predictable: anything that requires my wiring—pipeline YAML that only fails in CI, a Hugo partial that interacts with three others, a Blazor component that only breaks after publish. For that, context wins.

Cursor: when the answer is in the repo

Cursor (or any “chat with your codebase” style editor) is where I go when I need consistency across files and diff-shaped output. Side projects accumulate small decisions—naming, folder layout, how strict nullability is—and the model only respects those if it can see them.

Typical jobs:

Blog platform — adjusting a Hugo layout or partial, fixing warnings after a Hugo upgrade, or tweaking GitHub Actions / Azure Pipelines so the build still emits RSS and the JSON search index. Those changes are boring, fiddly, and easy to get subtly wrong if you guess from memory.
Episode Atlas — refactoring a Blazor page, aligning a Function endpoint with what the client expects, or tightening a Cosmos query once I know the access pattern. Here I want suggestions that match my project structure, not a generic sample from the internet.
Mandelbrot — iterating on rendering code where small mistakes show up as wrong colours or runaway iterations. Having the file in context beats describing the algorithm in chat.
Thorne Pentecostal Church site — simple HTML and CSS still benefit from repo context when the goal is “match what is already there” rather than “invent a new design system.”

I still treat Cursor as an accelerator, not an author. I read diffs, run the site or tests, and verify anything touching hosting or secrets. Side projects are a great place to learn when to trust an edit—and when the model confidently invents an API that never existed.

GitHub Copilot: the inline teammate

GitHub Copilot fills a different gap. Where Cursor often drives multi-file or exploratory edits, Copilot shines on local work: finishing a line, sketching a test, or repeating a pattern I have already established in the file.

I reach for it when:

I am writing repetitive Blazor markup or boilerplate DTOs.
I am editing YAML or shell and want a plausible next stanza that matches the block above.
I already know what I am doing and want speed more than architecture.

There is overlap between Copilot and Cursor in my workflow, and I am fine with that. If you only pay for one tool, you can still apply the same principle: shallow context versus deep context.

A quick decision table

Situation	What I use
“What are my options?” / compare approaches	ChatGPT
“Change this project to do X”	Cursor
“Finish this method / this pipeline step”	Copilot
Security, secrets, production incidents	Me, plus docs—AI optional and heavily verified

Boundaries, privacy, and verification

What I do not put in AI tools. I treat anything that could identify a person, anything contractual from work, and anything that unlocks production (passwords, API keys, connection strings, private certificates) as off-limits unless the product’s policy and my employer’s policy both say otherwise. For side projects that usually means personal repos only, secrets in environment variables or Key Vault—not in chat—and if I need help with a failing pipeline I redact resource names and paste error text, not the whole variable block. If you have a day job, your company’s acceptable-use rules beat anything you read in a blog post; when in doubt, use vendor docs and internal support channels instead of a model.

How I check output before it counts. I never merge a multi-file change on trust alone: I read the diff file by file, run hugo / dotnet build / whatever the project’s normal build is, and exercise the path I changed in the browser or with a quick manual test. If the assistant suggested a library call or HTTP API I do not recognise, I cross-check the official documentation or source before I rely on it—side projects are where I have been burned by plausible-but-wrong method names. For anything security-sensitive (auth callbacks, CORS, SQL, dependency upgrades), I assume the model is giving me a sketch and I still apply the same review I would give a junior’s pull request.

Learning paths are still verified. When I use ChatGPT to orient around Aspire, Kubernetes, or Elasticsearch, I use it to build a mental map and a reading list, then I confirm version-specific behaviour in Microsoft Learn, Kubernetes docs, or Elastic’s docs. The goal is to shorten where to look, not to skip looking.

Closing thought

AI tools have not replaced the fun of side projects for me. Projects like Episode Atlas exist because I wanted a better way to track Star Trek rewatches across hundreds of episodes; the Mandelbrot app exists because fractals are still cool; this blog exists because writing things down forces clarity. What has changed is how fast I can get through the glue work—if I pick the right assistant for the amount of context the task really needs.

If you are a developer experimenting with the same stack—.NET, static sites, Azure—how do you split tools today? I would be interested to hear what works for you in the comments.

AI Won't Replace Developers, But It Will Redefine Us

funkysi1701@gmail.com (funkysi1701) — Sat, 14 Mar 2026 09:00:00 +0000

Introduction – The Shift We are Living Through

As I write this, I have just been made redundant. AI is not being used to explain this particular redundancy, but it is being used to explain many redundancies across the industry.

I just got laid off..... Again...... I am still in shock. I loved my new job and was creating great impact but here we are again. Layoffs are not personal so I am ok but yeh will be looking for something new...... Again......
— Debbie O'Brien (@debs_obrien) February 27, 2026

I listened to an excellent talk at NDC London by Debbie O’Brien about using AI to do amazing things with Playwright MCP . If people who are using AI to its fullest are losing their jobs to AI, what hope is there for our industry? Are we all going to be writing AI prompts and that’s it?

But let’s stop for a minute. Software development is an ever-changing industry. There is always something new to learn and this AI craze is no different.

The role of the developer has always shifted as tools improved. We moved from writing assembly to high-level languages, from manual deployments to automated pipelines, and from managing servers to deploying infrastructure with a few commands.

The real question is how our role is changing and how we need to adapt and make the most of the new tools available to us.

What’s Actually Changed?

There’s a lot of noise around AI in software development. Headlines swing between “AI will replace developers” and “AI is just autocomplete.” The truth, as usual, sits somewhere in the middle.

But something real has changed. Not just the tools we use, but the speed, shape, and workflow of software development.

From Reactive to Proactive

For years, developer productivity tools focused on helping us type faster.

We had IntelliSense, snippets, code generation tools, and IDE refactorings. These were useful, but they were fundamentally reactive. They waited for the developer to start typing and then offered suggestions.

AI coding tools have crossed a different threshold.

Instead of simply completing the next line, they can:

Generate entire classes or modules
Suggest architecture patterns
Write tests
Perform multi-file refactors
Explain unfamiliar codebases
Propose fixes for bugs

The important shift is this:

The tool is no longer just responding to the code — it’s responding to the intent.

You describe a goal, and the AI attempts to produce the implementation.

This moves AI from being an autocomplete engine to something closer to an execution partner.

It’s not autonomous in the sense of replacing developers, but it does change the relationship between the developer and the code.

We’re no longer writing every line ourselves. Increasingly, we are directing the creation of code rather than manually constructing it.

The Cost of a First Draft Has Collapsed

Historically, one of the hidden costs of software development was simply getting started.

Creating a prototype involved:

Setting up project structure
Writing boilerplate
Defining models
Creating basic tests
Wiring components together

None of this work was intellectually difficult, but it took time.

AI tools have dramatically reduced the cost of that first draft.

You can now describe a feature and quickly get:

A rough implementation
Basic unit tests
A starting architecture
A prototype that actually runs

This doesn’t mean the output is perfect. In fact, it often isn’t. But the barrier to experimentation has dropped significantly.

Ideas that might have taken half a day to prototype can now be explored in minutes.

And that has a subtle but powerful effect on development culture:

When experimentation becomes cheap, developers try more ideas.

This encourages iteration, exploration, and rapid feedback in ways that previously required more discipline and effort.

Writing Code Is No Longer the Bottleneck

One of the most surprising outcomes of AI coding tools is that they reveal something many experienced developers already suspected:

Typing code was never the hardest part of software development.

The real difficulty lies elsewhere:

Understanding the problem
Designing a clean solution
Managing complexity
Communicating intent to other developers
Maintaining systems over time

AI can produce large volumes of code very quickly. But that doesn’t automatically translate into good software.

If anything, it shifts the constraint.

The bottleneck is no longer how fast code can be written.

The bottleneck is now:

How clearly can problems be defined
How well can systems be designed
How effectively can code be reviewed and maintained

In other words, AI accelerates the mechanical part of development, but the thinking part becomes even more important.

What Hasn’t Changed (But People Think It Has)

With every major technological shift, there’s a temptation to assume everything is different now. AI has amplified that feeling in software development. When tools can generate large amounts of code in seconds, it’s easy to believe the fundamentals of the profession have been rewritten.

But when you look closely at real software projects, something interesting appears: many of the hardest parts of software development haven’t changed at all.

AI has accelerated the mechanics of coding, but the underlying challenges of building reliable, useful software are still very much human problems.

Understanding Requirements Is Still the Hardest Problem

Software projects rarely fail because developers can’t write code. They fail because the problem wasn’t clearly understood in the first place.

AI tools can generate implementations, but they rely entirely on the input they’re given. If the requirement is vague, incomplete, or contradictory, the output will reflect that.

Consider how requirements often arrive in real projects:

A stakeholder describes a problem in business language.
Important edge cases are discovered later.
Different teams have slightly different expectations.
Requirements evolve as users interact with the system.

None of this has changed with AI.

The ability to ask the right questions, clarify ambiguity, and translate business needs into technical solutions remains one of the most valuable skills a developer can have.

In fact, as code generation becomes easier, clear problem definition becomes even more important.

Architecture and Trade-Offs Still Matter

AI can suggest design patterns, propose architectures, and generate project structures. But good software architecture isn’t just about picking the right pattern.

It’s about making trade-offs.

Questions like these still require human judgment:

Should this be a microservice or part of the monolith?
Is the added complexity of caching worth the performance gain?
What level of abstraction will make this system maintainable in five years?
Where should the boundaries between components sit?

These decisions depend heavily on context:

Team size
Deployment environment
Operational constraints
Long-term maintenance costs

AI can offer suggestions, but it cannot fully understand the organisational and operational realities of the system it’s helping to build.

That responsibility still sits with the developer.

Accountability Doesn’t Disappear

One thing that definitely hasn’t changed is ownership.

When software breaks in production, nobody blames the IDE. The same principle applies to AI.

If an AI-generated query deletes the wrong data, or a generated implementation introduces a subtle performance issue, the responsibility still lies with the developer who reviewed and shipped the code.

Production systems still require:

Careful testing
Monitoring and observability
Security awareness
Performance tuning
Ongoing maintenance

AI can assist with many of these areas, but it doesn’t remove the need for human accountability.

At the end of the day, someone has to understand the system well enough to take responsibility for it.

And that hasn’t changed at all.

The New Developer Skill Stack

If we accept that AI has collapsed the cost of a first draft, then the skill stack shifts upward.

Not because the old skills are irrelevant, but because they’re no longer the limiting factor as often.

Syntax still matters. Fundamentals still matter. But the competitive advantage moves towards the parts of the job that are hard to automate: precision, judgment, and system-level thinking.

Think of it as an evolution of the same craft.

Prompting as a Technical Skill

“Prompting” sounds fluffy until you realise what it actually is in practice: specifying a problem clearly enough that another agent (human or machine) can make progress without guessing.

The better you are at being precise, the more useful the tool becomes.

That means getting specific about:

The goal (what “done” looks like)
The constraints (performance, security, backward compatibility, tech stack)
Inputs/outputs and edge cases
The environment (language version, framework, database, deployment model)
The trade-offs you care about (simplicity vs flexibility, latency vs cost)

If you ask an AI to “build a feature”, you’ll get a lot of code, but it will almost always bake in assumptions you didn’t mean to make.

The best results come when you treat it like a junior developer with infinite typing speed:

Ask it to propose an approach first
Get it to list assumptions and risks
Then implement one slice at a time (and keep the changes small)

Finally, iterative refinement becomes the workflow.

You rarely get the best output on the first prompt. But you can converge quickly if you review the result, point out what is wrong or missing, and re-run with tighter guidance.

In other words, prompting is less about “magic words” and more about feedback loops.

Code Review Becomes Critical Thinking

When AI can generate 200 lines of code in seconds, reviewing becomes the high-leverage skill.

That review can’t just be “does it compile” or “does it look idiomatic”. It has to be critical thinking.

AI-generated code often fails in ways that are subtle:

It handles the happy path beautifully and ignores weird real-world inputs
It silently changes behaviour (especially around dates, nulls, and defaults)
It introduces concurrency bugs that only show up under load
It uses a library/API incorrectly but convincingly
It passes tests that are too shallow to be meaningful

The most important thing to review is not the code itself, but the assumptions underneath it.

I find it useful to explicitly ask:

What does this code assume about the data?
What does it assume about ordering, timing, and retries?
What happens when dependencies fail?
What would I see in logs/metrics if this breaks in production?
What tests would convince me this is correct?

This is where experienced developers become even more valuable: not because they can type faster, but because they’ve seen how systems fail.

Systems Thinking > Syntax Knowledge

AI is good at syntax and local patterns. It is much worse at understanding the bigger picture.

The developers who thrive in this shift will be the ones who can hold the system in their head:

How data flows through the application
Where the boundaries are between components
What needs to be observable in production (logs, metrics, traces)
What makes the codebase maintainable for the next person

Systems thinking is what stops an AI-generated “solution” from becoming a future incident.

It’s also why the old advice from The Pragmatic Programmer matters even more now: remember the big picture.

Not “can we generate this function”, but:

Is this the simplest thing that could work?
Can we operate it at 2am?
Can we change it safely in six months?
Are we making the system easier to understand or harder?

AI accelerates output, but it doesn’t automatically improve outcomes, and that creates real risk if we aren’t careful.

The Risk: Shallow Engineers

The biggest danger is not that AI replaces us.

The biggest danger is that it makes us lazy.

If we outsource too much thinking to tools, we can accidentally create a generation of engineers who can ship quickly but cannot explain what they shipped, why it works, or how to fix it when it fails.

That risk shows up in subtle ways:

Copying generated code without understanding the trade-offs
Accepting tests because they are green, even when they don’t test anything meaningful
Mistaking confidence in the AI’s tone for correctness in the implementation
Losing touch with fundamentals like debugging, data structures, networking, and performance

This is especially dangerous under delivery pressure. If a team rewards speed above all else, AI can amplify the wrong behaviour: lots of output, little understanding.

And that debt compounds.

Six months later, nobody trusts the codebase, incidents increase, and every change becomes risky.

So yes, AI can make us faster. But if we use it without discipline, it can also make us shallow.

The antidote is simple, even if not always easy: use AI to accelerate execution, not to bypass understanding.

The Opportunity: Increased Leverage (For the Right People)

The upside is huge for developers who combine AI with strong engineering habits.

When you can generate a solid first draft in minutes, you can spend more time where value actually lives:

Better problem framing
Better architecture decisions
Better test strategy
Better operational design
Better developer experience for your team

This is where leverage appears.

One thoughtful developer with AI support can now do the kind of end-to-end work that used to require more hand-offs and more waiting.

Not because they became magically smarter overnight, but because the mechanical drag has been reduced.

If your fundamentals are strong, AI multiplies your impact.

If your fundamentals are weak, AI multiplies your mistakes.

That is the real divide.

Practical Advice for Developers

If you want to stay relevant and thrive in this shift, here is what I would do right now.

1. Treat AI Output as a Draft, Not Truth

Assume every generated answer is a proposal.

Read it. Challenge it. Test it.

Never merge code you cannot explain to another developer.

2. Strengthen Your Core Engineering Muscles

Double down on:

Debugging
Testing strategy
System design
Observability
Performance and security fundamentals

These are durable skills and AI makes them more valuable, not less.

3. Get Better at Problem Framing

Before asking AI to implement anything, write down:

The problem in one sentence
The constraints
The non-goals
The acceptance criteria

This habit improves both the AI output and your own clarity.

4. Work in Small, Reviewable Slices

Ask AI for smaller changes, not giant rewrites.

Small slices make it easier to reason about behaviour, review quality, and rollback safely.

5. Raise the Bar for Code Reviews

Review assumptions, failure modes, and operational impact, not just style.

A useful question in every review: “What breaks first in production?”

6. Build a Personal AI Workflow

Create repeatable prompt patterns for tasks you do often:

Writing tests
Refactoring legacy code
Generating migration scripts
Creating docs from code

Treat these as reusable tools in your engineering toolbox.

7. Keep Shipping Real Things

The best learning still comes from production reality.

Build, deploy, monitor, and improve. Feedback from real users teaches lessons no model can replace.

What This Means for Juniors vs Seniors

AI changes the game for everyone, but not in exactly the same way.

For junior developers, AI can be a force multiplier for learning if used correctly.

It can explain unfamiliar concepts, generate examples, and speed up experimentation. But juniors still need mentorship and deliberate practice to build judgment.

If you skip the fundamentals and rely only on generated output, you’ll progress fast on paper and slowly in reality.

For senior developers, the expectation shifts from individual output to system-level impact.

Seniors become the multipliers of multipliers: setting standards, designing guardrails, mentoring teams, and ensuring AI usage improves quality rather than eroding it.

In short:

Juniors should use AI to learn faster
Seniors should use AI to scale better decisions

Both groups win when curiosity stays high and ego stays low.

The Big Question: Are We Becoming Directors Instead of Builders?

Partly, yes, and that is not a bad thing.

More of our time is moving toward direction:

Defining intent
Making trade-offs
Reviewing outputs
Orchestrating systems

But we are still builders.

Good directors in software are grounded in reality. They understand implementation details, constraints, and failure modes. They can still get into the code when needed.

So the role is not “director instead of builder.” It is “builder with broader leverage.”

We are not giving up craftsmanship.

We are applying craftsmanship at a higher level of abstraction.

But let’s be honest about the uncomfortable part of this question.

If one developer with AI can now do the work that previously required three, the natural business response is to hire fewer developers. That is already happening. It is likely to continue.

The optimistic framing — that AI creates more software demand and therefore more developer jobs — is plausible in the long run. But it does not help the developer who is looking for work today, and it does not guarantee the transition is smooth or fair.

I am not going to pretend the economics are simple.

What I do believe is that developers who understand systems, take ownership of quality, and use AI as a serious tool will remain competitive for the work that does exist. That work will increasingly require judgment, not just output.

The shift is real. The disruption is real. But the craft is not going away — it is just raising its entry bar.

Conclusion – My Opinion

I do not believe AI will eliminate software developers.

I do believe it will split the field.

Developers who keep learning, think in systems, and take ownership of outcomes will become more effective — not despite AI, but partly because of it.

Developers who treat AI as a shortcut, blindly trusting its output without understanding the system underneath, will increasingly struggle to hold ground.

The disruption happening right now is real. But I think the long-term demand for engineers who can reason clearly, design well, and take responsibility for what they ship is going to hold.

The path forward is straightforward even if the road is uncertain: stay curious, deepen the fundamentals, use AI seriously, and never stop questioning the output.

Call to Action

As mentioned at the start of this article, I am a .NET developer looking for my next role. If you know of any opportunities where I could help, please reach out.

And if you are in the same position, message me as well. We are stronger when we support each other.

Azure Container Registry vs AWS Elastic Container Registry: A Developer's Comparison

funkysi1701@gmail.com (funkysi1701) — Mon, 23 Feb 2026 20:00:00 +0000

As someone who works with both Azure and AWS regularly, I’ve had hands-on experience with both Azure Container Registry (ACR) and AWS Elastic Container Registry (ECR). Recently, while migrating my blog’s deployment pipeline to use ECR, I encountered some interesting differences that are worth sharing.

The Basics

Both services provide secure, private Docker container registries that integrate seamlessly with their respective cloud ecosystems. They’re designed to store, manage, and deploy container images for your applications.

Azure Container Registry (ACR)

Fully managed Docker registry service
Integrated with Azure Kubernetes Service (AKS), Azure Container Instances, and other Azure services
Supports Docker images and OCI artifacts
Available in multiple tiers: Basic, Standard, Premium

AWS Elastic Container Registry (ECR)

Fully managed Docker container registry
Integrated with Amazon ECS, EKS, and AWS Lambda
Supports Docker images and OCI artifacts
Single pricing model with pay-as-you-go

OCI artifacts are container-related objects that follow the Open Container Initiative (OCI) specifications. Originally, OCI defined standards for Docker container images, but now it covers a broader range of artifacts—including Helm charts, software bill of materials (SBOMs), and other files—stored in container registries.

Pricing Comparison

This is where things get interesting.

Azure Container Registry

ACR uses a tiered pricing model:

Basic: £4.23/month + storage (£0.083/GB) + bandwidth
Standard: £16.93/month + storage (£0.083/GB) + bandwidth
Premium: £42.32/month + storage (£0.083/GB) + bandwidth + geo-replication

The Premium tier adds features like:

Geo-replication across Azure regions
Content trust for image signing
Private link with private endpoints
Enhanced throughput

AWS Elastic Container Registry

ECR uses simple pay-as-you-go pricing:

Storage: $0.10/GB per month (£0.08/GB)
Data Transfer: Standard AWS data transfer pricing
No base fee - you only pay for what you use

Authentication & Setup

This is where I hit some friction with ECR.

Azure Container Registry

ACR authentication is straightforward:

# Login using Azure CLI
az acr login --name myregistry

# Or use service principal
docker login myregistry.azurecr.io -u $SP_ID -p $SP_PASSWORD

# In pipelines, it's seamless with Azure DevOps tasks

The Azure DevOps integration is particularly smooth - the Docker@2 task handles authentication automatically when using service connections.

AWS Elastic Container Registry

ECR authentication requires an extra step:

# Get login password and pipe to docker login
aws ecr get-login-password --region eu-north-1 | \
 docker login --username AWS --password-stdin \
 111111111111.dkr.ecr.eu-north-1.amazonaws.com

In my Azure Pipelines, I had to:

Install AWS CLI (not included by default)
Configure AWS credentials as environment variables
Run the login command manually

- task: CmdLine@2
 displayName: "Install AWS CLI"
 inputs:
 script: |
 curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
 unzip -q awscliv2.zip
 ./aws/install --bin-dir ~/.local/bin --install-dir ~/.local/aws-cli
 
- task: CmdLine@2
 displayName: "Login to ECR"
 env:
 AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
 AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)
 inputs:
 script: |
 export PATH=$HOME/.local/bin:$PATH
 aws ecr get-login-password --region eu-north-1 | \
 docker login --username AWS --password-stdin \
 111111111111.dkr.ecr.eu-north-1.amazonaws.com

Winner: ACR (simpler authentication, especially in Azure DevOps)

Image Naming & URLs

Azure Container Registry

Clean, predictable naming:

myregistry.azurecr.io/myapp:v1.0.0
myregistry.azurecr.io/namespace/myapp:latest

AWS Elastic Container Registry

Includes your AWS account ID:

111111111111.dkr.ecr.eu-north-1.amazonaws.com/funkysi1701/blog:10.1.1.123-develop

The account ID in the URL may pose a security consideration - it’s visible to anyone who has access to your images or deployment configs. Attackers could use the account ID for targeted phishing, social engineering, or brute-force attacks. If combined with leaked credentials or misconfigured permissions, it makes it easier for someone to identify and target your AWS resources.

Winner: ACR (cleaner URLs)

Features Comparison

Feature	ACR	ECR
Image Scanning	✅ Premium tier	✅ Included
Vulnerability Scanning	✅ Premium tier	✅ Basic + Enhanced
Geo-Replication	✅ Premium tier	❌ Manual setup
Webhooks	✅ All tiers	✅ Included
Image Retention Policies	✅ All tiers	✅ Lifecycle policies
Private Endpoints	✅ Premium tier	✅ VPC endpoints
Image Signing	✅ Content Trust	✅ AWS Signer
Cross-Region Replication	✅ Premium	❌ Requires manual setup
Import from Docker Hub	✅ Built-in	❌ Manual

Integration with Kubernetes

ACR + AKS

Seamless integration with Azure Kubernetes Service:

# Attach ACR to AKS cluster
az aks update --name myaks --resource-group mygroup --attach-acr myregistry

AKS nodes can pull images without credentials. Magical.

ECR + EKS

Also integrated, but requires IAM roles:

# Attach IAM policy to EKS node role
aws iam attach-role-policy \
 --role-name eksNodeRole \
 --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly

Works well once configured, but requires understanding of AWS IAM.

Winner: Tie (both integrate well with their respective K8s offerings)

Developer Experience

What I Like About ACR

Simple authentication in Azure DevOps
Clean, readable image URLs
Excellent documentation
Azure Portal UI is intuitive
Helm chart support is first-class

What I Like About ECR

No minimum cost - truly pay-per-use
Built-in vulnerability scanning at all levels
AWS CLI is powerful and ubiquitous
Great for multi-cloud strategies
Excellent API and automation support

Pain Points

ACR:

Premium tier gets expensive for features that should be standard
Minimum £4/month even for tiny projects
Geo-replication requires Premium tier (£42/month)

Geo-replication is important because it allows your container images and artifacts to be stored and accessed in multiple geographic regions.

ECR:

Authentication is more complex outside AWS
Account ID in image URL
Requires AWS CLI installation in non-AWS CI/CD

My Real-World Experience

For my blog’s deployment pipeline, I recently migrated from ACR to ECR primarily for cost reasons. Here’s what I learned:

The Migration

Before (ACR):

Cost: ~£4.50/month (Basic tier + minimal storage)
Authentication: Seamless in Azure DevOps
Image URLs: Clean and simple

After (ECR):

Cost: £0/month (due to free trial)
Authentication: Required custom pipeline steps
Image URLs: Include AWS account ID

Was It Worth It?

For my small personal project, yes - saving money is meaningful. But the setup was more complex than I expected.

For enterprise workloads, I’d still choose ACR Premium if I needed:

Geo-replication
Content trust
Azure-native integration
Enterprise support

Recommendations

Choose ACR if

✅ You’re heavily invested in Azure ecosystem
✅ You need geo-replication
✅ You want seamless AKS integration
✅ You value simplified authentication
✅ You need Azure-native compliance features

Choose ECR if

✅ You want zero minimum costs
✅ You’re on AWS or multi-cloud
✅ You need built-in vulnerability scanning
✅ You prefer pay-per-use pricing
✅ You’re comfortable with IAM and AWS CLI

Conclusion

Both ACR and ECR are excellent services. Your choice should depend on:

Your cloud platform - Use the registry that matches your deployment target
Your budget - ECR wins for small projects, ACR Premium for enterprise features
Your team’s expertise - Stick with what your team knows
Your requirements - Need geo-replication? ACR Premium. Need low-cost? ECR.

For my personal projects, I’m happy with ECR’s cost savings. For enterprise work, I still recommend ACR Premium for its advanced features and Azure integration.

What’s your experience with container registries? Let me know in the comments!

Resources

NDC London 2026

funkysi1701@gmail.com (funkysi1701) — Mon, 02 Feb 2026 20:46:00 +0000

For the second year running, I had the privilege of volunteering at NDC London – one of Europe’s premier software development conferences. This year’s event was packed with insights on AI, accessibility, testing automation, and the future of software development. If you’re interested in my first experience, check out my 2025 report .

The volunteer experience was just as rewarding as last year – the team was fantastic, the energy was incredible, and the sense of community was palpable. In this post, I’ll focus on the talks I attended and the key insights I gained from them.

As I mentioned last year, volunteering gave me a superpower: increased confidence to network with speakers, vendors, fellow volunteers, and attendees. The connections you make at conferences like this are invaluable, and being part of the team made it even easier to engage with the community.

Wednesday

Let’s Break Some WCAG Rules (Speaker: Elise Kristiansen)

This eye-opening talk examined how pervasively websites violate Web Content Accessibility Guidelines (WCAG). For those unfamiliar, WCAG provides a framework to make web content accessible to everyone, including people with disabilities. The guidelines are organized into three conformance levels:

Level A - The bare minimum requirements
Level AA - The legal requirement (what most laws mandate)
Level AAA - The gold standard, aspirational but not legally required

The statistics Elise shared were sobering: 15-25% of people have some form of disability (whether permanent, temporary, or situational), yet a staggering 94.8% of websites contain at least one WCAG AA violation – meaning they’re actually breaking the law.

One of the most powerful demonstrations was a colour blindness test where only colour blind individuals could read certain numbers. It really drove home how design choices can inadvertently exclude significant portions of our users.

Key Takeaways:

WCAG compliance isn’t optional – it’s a legal requirement and moral imperative
Stop using <div> for everything; HTML is semantically rich for a reason
Consider learning to use a screen reader to understand user experiences better
Accessibility benefits everyone, not just those with disabilities

A timely reminder that as soon as humans enter the equation, social engineering becomes a significant security risk. This talk explored various tactics malicious actors use to manipulate people into divulging confidential information or performing actions that compromise security.

Pawel demonstrated real-world scenarios like phishing emails that appear to come from trusted colleagues, pretexting phone calls where attackers impersonate IT support, and how seemingly innocent information shared on social media can be weaponized. The human element remains the weakest link in any security chain.

Supercharged Testing: AI-Powered Workflows with Playwright + MCP (Speaker: Debbie O’Brien)

I’d heard Debbie discuss the Playwright MCP (Model Context Protocol) on .NET Rocks, but seeing it demonstrated live was transformative. This session showed how AI can dramatically enhance testing workflows by understanding test intent and generating Playwright test code.

I’ve already started using it to write some tests for this very website!

Key Takeaway:

Experiment with the Playwright MCP – it’s a game-changer for test automation

The Undersea Cable Network (Speaker: Richard Campbell)

Richard took us on a fascinating journey through the history of undersea telecommunications cables – the literal backbone of the internet. He explored how these cables are laid, maintained, and the significant challenges when they’re damaged (whether accidental or deliberate). It’s humbling to realize that our globally connected world depends on physical cables crossing ocean floors.

Java Sucks (So C# Didn’t Have To) (Speaker: Adele Carpenter)

An entertaining and insightful exploration of Java’s history, examining how its early popularity locked in certain design decisions that became problematic over time. Adele showed how C# learned from Java’s mistakes and made different choices that enabled better evolution. The key lesson: early success can create technical debt that’s nearly impossible to pay down.

View the slides

Think Like a User: Practical UX Design Tips for Developers (Speaker: Lex Lofthouse)

This session challenged developers to shift perspectives and consider user experience from the ground up. Lex provided practical, actionable advice for creating more intuitive interfaces.

View the slides

Recommended Reading:

The Design of Everyday Things by Don Norman

Thursday

OpenTelemetry At Scale 101: Intro to OpAMP (Speakers: Aakansha Priya and Adriana Villela)

This session introduced OpAMP (Open Agent Management Protocol) for managing OpenTelemetry collectors at scale. While the scale discussed was beyond my current needs, it was valuable to understand the challenges and solutions for production observability in large distributed systems.

A Defence of Technical Excellence (Speaker: Chris Simon)

Chris made a compelling argument for maintaining high technical standards even under pressure to deliver quickly. Technical excellence isn’t about perfectionism – it’s about sustainable, maintainable code that serves the business long-term.

How to Git Away with Murder (Speaker: Sergès Goma)

A humorous yet practical look at Git workflows and how to recover from common (and not-so-common) Git disasters. The Q&A session at the end turned into a group therapy session where attendees shared their most spectacular Git mishaps and recovery stories. If you’ve ever accidentally force-pushed to main, this talk was for you!

Code That Writes Code: .NET Source Generators (Speaker: Glenn F. Henriksen)

Source generators are one of .NET’s most powerful yet underutilized features. Glenn demonstrated how they can eliminate boilerplate, improve performance by moving work to compile-time, and create type-safe code generation patterns. This is definitely an area I need to explore more for my own projects.

Warm and Fuzzy: Semantic Search in .NET (Speaker: Jonathan “J.” Tower)

Jonathan delivered an excellent introduction to implementing semantic search using vector databases. He covered several options for .NET developers:

SQL Server 2025 with native vector support
Azure Cosmos DB for NoSQL vector storage
Qdrant as a specialized vector database

The talk also touched on Semantic Kernel, which is now part of the Microsoft Agent Framework – a significant development for building intelligent applications.

Action Items:

Implement semantic search for my blog to improve content discovery
Explore the demo code on GitHub

Coding 4 Fun: 8-bit Game Emulation in .NET (Speaker: Alex Thissen)

Pure fun! Alex walked through building an 8-bit game emulator in .NET, demonstrating low-level programming concepts in a modern language. A great reminder that not everything we build needs to be “enterprise-ready” – sometimes coding is just about learning and enjoyment. Lots of shifting bytes around, so a great example of the different things you can do with .NET.

Friday

Keynote: AI-Powered App Development (Speaker: Steve Sanderson)

Steve Sanderson delivered an inspiring keynote on how AI is transforming application development. The GitHub Copilot CLI was demonstrated, with a new feature added in front of our eyes. Hundreds of Pull Requests can be generated with AI, but they all need reviewing and maintaining by Software Developers and there are no easy answers for managing that.

What in the Hunger Games is Happening with Recruitment? (Speaker: Suzi Edwards-Alexander)

A frank and often amusing look at the current state of tech recruitment. Suzi traced how we arrived at today’s challenging hiring landscape – from the first interview questions created by Thomas Edison, to the rise of LinkedIn and modern recruitment processes. Recruitment is broken, and there are no easy ways of fixing it.

The Great Brain Robbery: Navigating the Dark Future of Online Manipulation (Speaker: Jeff Watkins)

A sobering examination of how online platforms use psychological manipulation and dark patterns to exploit users’ attention and data. Jeff didn’t just highlight the problems – he offered strategies for recognizing and resisting these tactics, both as developers and as users. This talk was rather bleak reinforcing the notion that you can not trust anything you see or read online.

Beyond the AI Hype: What’s Real, What’s Next (Speaker: Richard Campbell)

Richard cut through the AI hype to examine what’s genuinely transformative versus what’s just marketing. He explored current capabilities, realistic near-term developments, and the fundamental limitations we need to understand. A perfect counterbalance to the morning’s optimistic keynote – both perspectives are necessary for making informed decisions about AI adoption.

Resilient by Design (Speaker: Chris Ayers)

The final session I attended focused on building resilient systems in Azure from the ground up. Chris covered how much downtime you can have if your SLA is 99.99% (8.6s a day see uptime.is ) – but more importantly, the mindset shift required to design for failure rather than just success. In production, it’s not if things will fail, but when and how gracefully.

Networking Break: JetBrains Rider Team

I skipped one session to have an extended conversation with the JetBrains Rider team at their booth. These unstructured conversations are often where you get the most value at conferences – I am a big fan of Visual Studio, but I have never tried Rider, this informal chat has encouraged me to download Rider and give it a try.

Final Thoughts

NDC London 2026 was another incredible experience. The breadth of topics – from accessibility and UX to AI, observability, and system resilience – reflects the diverse skills modern developers need.

My key takeaways from this year:

Accessibility is non-negotiable – both legally and morally
AI tools are here to stay – learn to leverage them effectively
Technical excellence matters – shortcuts today become tomorrow’s technical debt
Community is everything – the conversations between sessions were as valuable as the talks themselves

Huge thanks to the NDC organizing team, my fellow volunteers, all the speakers who shared their knowledge, and the attendees who made this such an engaging event. If you get the chance to attend (or volunteer at) NDC Conferences , I highly recommend it.

Interested in attending NDC London 2027? Follow @NDC_Conferences for updates!

See you at NDC London 2027! 🚀

2025 in Review and Goals for 2026

funkysi1701@gmail.com (funkysi1701) — Thu, 01 Jan 2026 09:00:00 +0000

2025 in Review

What a year 2025 has been! I published 24 blog posts covering a wide range of topics from cloud-native technologies to AI experiments, and even some personal reflections. Here are the key themes and highlights from my blogging year:

Cloud-Native and DevOps

This was a major focus area for me in 2025, not really surprising as I moved into a DevOps role this year, with deep dives into modern infrastructure:

Learning Kubernetes - Started my journey into container orchestration and shared my beginner experiences
Deploying Hugo with Helm - Deployed this very blog to Kubernetes using Helm charts
Kubernetes and Let’s Encrypt - Tackled SSL certificate management in Kubernetes
Monitoring with Nagios Docker - Explored monitoring solutions in containerized environments

.NET and Development

My bread and butter continues to be .NET development, with several posts exploring new features and tools:

Blazor and .NET 10 - Covered breaking changes, fixes, and new features in the latest .NET release
Adding Elasticsearch with .NET Aspire - Integrated search capabilities using Aspire
Aspire 9.2 - Explored the latest Aspire release
NuGet Central Package Management - Streamlined dependency management
What’s New in C# - Covered the latest language features
Exceptions - Best practices for error handling

Observability and Monitoring

Understanding what’s happening in production became a key theme:

Getting Started with OpenTelemetry - Made observability easy with modern tracing
OpenTelemetry Logs - Extended observability to include logging
Setting up Grafana - Built dashboards for monitoring

Cloud Platforms

Merging Two Projects into One - Shared my experience consolidating codebases

AI and Creativity

Fun with AI - Explored ChatGPT’s image generation capabilities
Using AI - Practical applications of AI in daily work
Mandelbrot Set - A fun mathematical exploration

Professional Development

The Pragmatic Programmer - Book review of this classic software development book
The Hacker Ethic - Reflections on developer culture and values
Stepping Outside Your Comfort Zone - Personal growth and career development
Volunteering at NDC London - My experience at this major .NET conference
Periodic Table of DevOps 2025 - A visual guide to the DevOps ecosystem

Fun Projects

Festive Naughty or Nice Checker - A seasonal AI-powered fun project

Thank you to everyone who read, commented, and shared my posts throughout the year. Your engagement and feedback mean the world to me!

2025 by the Numbers

24 blog posts published
Major topics: Kubernetes, .NET, OpenTelemetry, AI
New skills acquired: Helm, Kubernetes, observability tools
Conferences attended: NDC London (as a volunteer) and DDD North
Submitted content to https://festivetechcalendar.com

Goals for 2026

Looking ahead to 2026, I’m excited to build on this momentum. Here are my blogging and technical goals:

Content Goals

Publish at least 24 posts - Maintain the pace from 2025
Deep dive into AI/ML - Go beyond experimentation to practical implementations
More hands-on tutorials - Provide step-by-step guides that readers can follow along with

Technical Skills

Master Kubernetes - Move from beginner to intermediate proficiency
Advanced observability - Implement comprehensive monitoring across distributed systems
Cloud-native patterns - Explore microservices, event-driven architectures, and service mesh
AI integration - Build practical AI-powered features into applications
Platform engineering - Create better developer experiences and internal platforms

Walking

At the end of 2024 I made the following goal:

2024 took an unusual turn. In June, I walked a half marathon across the Peak District, and since then,
I have been doing lots of walks. Walking is good for my physical and mental health,
so I intend to do more of it in 2025. I have a 5k scheduled for January,
which should be lots of fun as it is around the wildlife park.

Well I enjoyed my walk in January 2025, which then led to two 10k walks (in July and September) and a 7.5k night walk (in Blackpool to see the Illuminations). This led me to explore parkrun and I completed my 8th run this morning. I say run, not walk as I am slowly becoming more of a runner and less of a walker.

So my goal here is to keep doing this, as I am so far enjoying getting out and about.

What Would You Like to See?

I’d love to hear from you! What topics would you like me to cover in 2026? Are there specific technologies, patterns, or problems you’d like to see explored?

Drop a comment below, reach out on social media, or send me a message. Your feedback helps shape the content direction for the year ahead.

Here’s to a fantastic 2026 filled with learning, building, and sharing! 🚀

2026 on Funky Si's Blog

Portfolio: Live Azure Workloads, AI Search, and Dev Tools

Featured Projects

🔧 Episode Atlas

🔧 Semantic Search

🔧 Blog Platform

💼 Cloud & Production Systems

🔧 Thorne Pentecostal Church

🛠 Tools & Utilities

🔧 Mandelbrot Generator

💡 Ongoing exploration

🤝 Collaborate With Me

📚 More resources

Episode Atlas: Track Your Star Trek Rewatch Journey

Why I built it

Browse first, sign in to save

Your service record

Find any episode in seconds

Episode pages: context and next steps

Collections when you want a mood, not a season

Random episode when you cannot decide

How it compares to other sites

Try it

How I Use AI on Side Projects: ChatGPT, Cursor, and Copilot

ChatGPT: questions that do not need my codebase

Cursor: when the answer is in the repo

GitHub Copilot: the inline teammate

A quick decision table

Boundaries, privacy, and verification

Closing thought

AI Won't Replace Developers, But It Will Redefine Us

Introduction – The Shift We are Living Through

What’s Actually Changed?

From Reactive to Proactive

The Cost of a First Draft Has Collapsed

Writing Code Is No Longer the Bottleneck

What Hasn’t Changed (But People Think It Has)

Understanding Requirements Is Still the Hardest Problem

Architecture and Trade-Offs Still Matter

Accountability Doesn’t Disappear

The New Developer Skill Stack

Prompting as a Technical Skill

Code Review Becomes Critical Thinking

Systems Thinking > Syntax Knowledge

The Risk: Shallow Engineers

The Opportunity: Increased Leverage (For the Right People)

Practical Advice for Developers

1. Treat AI Output as a Draft, Not Truth

2. Strengthen Your Core Engineering Muscles

3. Get Better at Problem Framing

4. Work in Small, Reviewable Slices

5. Raise the Bar for Code Reviews

6. Build a Personal AI Workflow

7. Keep Shipping Real Things

What This Means for Juniors vs Seniors

The Big Question: Are We Becoming Directors Instead of Builders?

Conclusion – My Opinion

Call to Action

Azure Container Registry vs AWS Elastic Container Registry: A Developer's Comparison

The Basics

Azure Container Registry (ACR)

AWS Elastic Container Registry (ECR)

Pricing Comparison

Azure Container Registry

AWS Elastic Container Registry

Authentication & Setup

Azure Container Registry

AWS Elastic Container Registry

Image Naming & URLs

Azure Container Registry

AWS Elastic Container Registry

Features Comparison

Integration with Kubernetes

ACR + AKS

ECR + EKS

Developer Experience

What I Like About ACR

What I Like About ECR

Pain Points

My Real-World Experience