The illustration of the city above is all CSS. There are no images, no SVG, no JavaScript… there isn’t even any HTML!*

Here’s the source code on CodePen:

(Click on the 1x, 0.5x, and 0.25x buttons to zoom in or out and see more of the illustration. Alternatively, you can also visit the CodePen details page, where you can zoom in/out and resize the window for better results)

You may ask “how did you do it?” And the answer will be “with a lot of patience.” I started this CSS Art two years ago, and worked adding small things little by little: a building here, some tree there, a bus stop close by… But, due to personal and professional reasons, I stopped adding things around a year ago, and haven’t touched the code since. I’d love to expand it into a full city someday.

Basically, it is all a big collection of CSS gradients: radial, linear, conic… I event used the repeating ones. All of them sized and positioned so they fit within a particular spot in the illustration.

This drawing is different from other CSS Art I usually do. I tend to do small things that are responsive, but this is an infinite drawing and it uses absolute units.

It is infinite because it doesn’t matter how much you resize, the illustration just goes on and on. This was achieved by playing with background sizes and positioning, so the same elements repeat ad infinitum. Examples of these elements are:

• The bricks on the wall
• The tree tops behind the wall
• The grayed buildings in the very background
• The park houses

The absolute units are pixels, and I used that instead of vmin or em, to make sure that all the things will fall exactly in the place I wanted them to be. When using relative units, sometimes something will fall in a half a pixel position and the result looks off.

When drawing and adding elements, I started from the bottom center of the image, and position everything based on that point, growing from there upwards and sideways.

I added some basic animations (but commented them for performance while coding, you can uncomment the code, but it’s not much), so the traffic light actually works, the water in the fountain flows (poorly) or some of the lights flicker. I considered adding a car that stops at the traffic light and an UFO that flies above the city –that won’t be seen unless you zoom out considerably or have a large/tall screen.

And all this using just the :root element. I could still use the ::before or ::after pseudo-elements to do add more things. In particular, animated things. But I dropped the idea because adding them caused the performance to drop considerably. Still, I would like to continue adding more things when I have time.

What do you think? Have you ever done a single div CSS Art?

*The CodePen demo may not show any HTML, but it automatically adds a structure that is hidden from view but can be seen reviewing the source code. There is a way to run CSS on the browser without the need to import it from HTML. Unfortunately, it requires updating some settings in the web server, and only one browser supported it last time I checked (Firefox). If we did this, the illustration would be completely CSS only.

I’ve been a CTO long enough to have onboarded dozens of developers across teams of varying maturity. The pattern that works has never changed: a new developer reads existing documentation, explores the repository, implements small tasks – often ones designed by a senior to expose how the system’s key features work.

How is the API structured?
Where does state live?
How do data flows connect?

The developer learns by doing, making mistakes, and reflecting on what went wrong.

AI hasn’t killed that process. But poorly thought-through adoption of AI has made it much harder for developers to learn a project and the logic behind it. When a developer delegates everything to an AI assistant without reflection and when AI implements the onboarding task, the developer just submits the PR – the task got done, but the onboarding didn’t happen. The developer no longer learns from mistakes or learns by discovery, because there were no mistakes to learn from and nothing to discover.

That’s not an AI problem. It’s a process problem.

The productivity question

AI tools make developers faster. But the gains aren’t as straightforward as the headlines suggest.

Less experienced developers often see the largest raw productivity gains. They can produce working code faster than ever before. But the quality and sustainability of that output depends almost entirely on the process around them.

With good onboarding, clear guardrails, and access to company context, a developer using AI performs significantly better than one without it. In a less structured environment, the results can go sideways quickly. Developers who haven’t yet built strong engineering instincts may accept any AI suggestion without reflection because they don’t have the experience to question what looks correct but isn’t.

Senior engineers, by contrast, tend to capture a reliable productivity uplift regardless of process maturity. They already have the judgment to validate, reject, or reshape AI output. The difference isn’t the tool. It’s whether the organization has invested in the process to support it.

Three patterns worth watching

These aren’t new failure modes created by AI. They’re existing risks that AI makes faster and less visible.

The reload loop

When AI-generated code breaks, there’s a natural instinct to copy the error back into the chat. A patch arrives. Another error. Repeat. This is a human psychology problem when presented with solutions time after time, people tend to switch off and keep reloading. If something doesn’t work after implementation, it usually signals a gap in project comprehension, not a missing patch. The right response is to step back: trace the data flow, read the related tests, understand the code surrounding the problem. Without that comprehension, both the AI and the developer produce shallow fixes that mask the real issue.

Architecture drift

AI can assist with architectural work, but only when it has proper project context. Without it, developers treat a codebase as a collection of independent prompts rather than a coherent whole. Libraries get introduced for problems that already have internal solutions. Patterns multiply. Data flows become harder to trace. The real challenge is preserving architectural knowledge across AI sessions. Decisions and conventions need to persist between conversations, and that requires deliberate documentation, not just good intentions.

Uncritical acceptance

Developers sometimes accept AI-generated code because it looks right. The output has a confident, professional structure. Developers who haven’t yet built strong debugging instincts may trust polish over correctness, including code with security vulnerabilities. The mitigation is the same as it’s always been – senior review at the PR stage. But it can also be addressed earlier, during refinement, by identifying security-sensitive areas and including specific checks in the task definition.

Across all three patterns, one thing is conspicuously absent from most discussions – automated guardrails. Linters, type checking, CI/CD pipelines, unit tests – these catch entire categories of problems before any human reviews anything. A conversation about AI-assisted development that ignores automated safety nets is incomplete.

What’s actually at risk

Every codebase is an artifact of decisions made under pressure. It contains frameworks chosen after failed experiments, workarounds born from production incidents, edge cases that took months to surface, and security patches whose context lives in decision logs.

What healthy organizations do is build infrastructure that makes context accessible, clean consistent architecture with documentation that explains not just what was built but why; and indexed, discoverable component libraries shared across teams.

Even with all of this, there’s knowledge that lives in places humans struggle to navigate, scattered across repositories, buried in years of commit history, distributed across documentation platforms. This is where AI code intelligence platforms add genuine value: collecting unstructured knowledge from across the organization, auto-documenting code, and serving it as context to AI assistants on demand.

Understanding code before generating

Before writing new code, a developer should be able to answer:

Does a solution to this problem already exist in our codebase?
How have other teams handled the same pattern?
What decisions shaped the module I’m about to modify?

AI assistants can answer some of these questions well, especially within a single, small-to-medium-sized repository. Where it breaks down is across organizational boundaries: multiple repositories, years of accumulated history, cross-team conventions, decisions that were never documented in code. That’s where additional context layers change the equation.

Consider a developer implementing retry logic for a billing service. A general-purpose AI assistant working within the current repo will produce a functional, contextually grounded implementation. But if the best reference implementation lives in a different repository, a RetryStrategy class written by a staff engineer for another service eight months ago, a single-repo tool won’t surface it. A code intelligence platform that indexes across repositories can. The developer gets the class, it’s calling context, the middleware it connects to, and the logging conventions the team adopted.

That’s valuable. But it’s not the end of the story. The solution was created in a different system, and not everything will translate directly. It’s the developer’s job to understand the pattern and work with their AI assistant to adapt it. The platform provides compressed discovery, not compressed implementation. Human understanding remains the critical step.

What actually helps? Building an organizational system

Individual habits like “check if this exists elsewhere” are fine advice, but they rely on personal discipline and don’t scale. What works is building organizational infrastructure that makes good practices the default.

Layer 1: Automated guardrails.

Linters, formatters, type checking, testing strategies. These catch problems before any human reviews anything and encode team standards into automation. This is the foundation, and it costs zero effort per task once configured.

Layer 2: AI configuration infrastructure.

This is where most organizations have untapped potential. AI assistants can be configured with system instructions that encode your team’s conventions, architectural principles, and preferred patterns. Sub-agent definitions and skills libraries can capture tribal knowledge in a form that AI can use during code generation. Written decision logs and architectural guidelines become prompts, not just documents.

Critically, developers need to understand how AI assistant memory works so that decisions and context persist between sessions. Without this, every AI conversation starts from zero and accumulated understanding is lost. Organizations should treat AI session configuration: memory, context documents, progressive context building, as part of their development infrastructure, not as something each developer figures out on their own.

Layer 3: Knowledge aggregation.

Code intelligence platforms indexing across repositories. Documentation platforms connected and searchable. The goal is that when a developer asks “how do we handle this pattern?” the answer draws from the entire organization’s experience, not just the current repo.

Layer 4: Feedback loops.

This is what makes the whole system improve over time rather than decay. Guardrails and linting rules are updated on a regular cadence. Instruction libraries, prompt templates, and skills definitions are refined based on outcomes. Code intelligence platform searches and recommendations improve through feedback. Documentation, tests, and architecture decision records are generated with AI assistance and kept current.

Here’s the key insight: AI both creates the context problem and provides the solution. Writing good documentation, thorough tests, and clear ADRs used to be expensive and time-consuming, so teams skipped it. Now AI makes it fast. We just need to build the infrastructure to capture that context and establish the feedback loops so it improves itself over time.

The real gap

The productivity difference between a new developer and an experienced one exists because experienced engineers have contextual maps built over years. AI can generate output that looks senior-level without building any of that understanding.

When evaluating AI tooling for your team, the right question isn’t “how much code does it generate?” It’s “how much does it help developers understand the system before changing it?”

AI doesn’t replace the journey from new team member to trusted contributor. With the right process: structured onboarding, automated guardrails, well-configured AI tools, organizational knowledge made accessible, and continuous feedback loops; it compresses that journey. Developers onboard in weeks instead of months because they’ve understood the system’s history and patterns, not because they’ve generated their way past them.

Not faster output. Better understanding, at speed.

Thoughts, pushback, and real-world examples welcome in the comments.

Today’s session was a mix of core Java fundamentals + tricky logic + real-world usage 💡
We explored how conditions work, how loops behave without braces, user input handling, and even touched JSON/XML basics.

Let’s break it down step by step 👇

🔹 1. Condition Must Be Boolean (True/False)

In Java, every condition must return either true or false.

❌ Invalid Example

int i = 1;
while(i) {   // ❌ Compilation Error
    System.out.println(i);
}

👉 Why error?

• Java does NOT allow non-boolean conditions
• Unlike C/C++, numbers are not treated as true/false

✅ Correct Example

int i = 1;
while(i <= 5) {
    System.out.println(i);
    i++;
}

✔ Condition → i <= 5 → returns boolean
✔ Hence valid

🔹 2. True / False Direct Conditions

You can directly use true or false in conditions.

✅ Example

if(true) {
    System.out.println("Always runs");
}

✔ Output:

Always runs

❌ Example

if(false) {
    System.out.println("Never runs");
}

✔ Output:

(no output)

👉 This is useful for testing or debugging

🔹 3. Removing Curly Braces { }

Java allows skipping { } if only one statement is present.

✅ Example

for(int i = 1; i <= 5; i++)
    System.out.println(i);

✔ Output:

1 2 3 4 5

⚠️ Tricky Case

for(int i = 1; i <= 5; i++)
    System.out.println(i);
    System.out.println("Done");

✔ Output:

1 2 3 4 5
Done

👉 Only the first statement is inside loop
👉 Second statement runs once after loop

🔹 4. Infinite Loop (By Default True)

If condition is always true → loop never stops 😱

Example

for(;;) {
    System.out.println("Infinite Loop");
}

👉 This is equivalent to:

while(true) {
    System.out.println("Infinite Loop");
}

✔ Used in:

• Servers
• Continuous monitoring systems

🔹 5. break and continue

🔸 break → stops loop completely

for(int i = 1; i <= 5; i++) {
    if(i == 3)
        break;
    System.out.println(i);
}

✔ Output:

1
2

🔸 continue → skips current iteration

for(int i = 1; i <= 5; i++) {
    if(i == 3)
        continue;
    System.out.println(i);
}

✔ Output:

1
2
4
5

🔹 6. Taking Input from User (Scanner)

To read input in Java, we use Scanner.

Example

import java.util.*;

public class Test {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);

        System.out.print("Enter your name: ");
        String name = sc.nextLine();

        System.out.println("Hello " + name);
    }
}

⚠️ Important Notes

❌ Java does NOT directly support char input
✔ Workaround:

char ch = sc.next().charAt(0);

✔ For String:

String name = sc.nextLine();

🔹 7. Multiple Inputs Example

Scanner sc = new Scanner(System.in);

System.out.print("Enter Tamil mark: ");
int tamil = sc.nextInt();

System.out.print("Enter English mark: ");
int english = sc.nextInt();

int total = tamil + english;

System.out.println("Total mark: " + total);

✔ Output Example:

Enter Tamil mark: 80
Enter English mark: 90
Total mark: 170

🔹 8. JSON vs XML (Basic Understanding)

🔸 JSON (JavaScript Object Notation)

{
  "username": "Manikandan",
  "password": "1234"
}

✔ Lightweight
✔ Easy to read
✔ Mostly used in APIs

🔸 XML (Extensible Markup Language)

<user>
    <username>Manikandan</username>
    <password>1234</password>
</user>

✔ Structured format
✔ Used in older systems / configs

🔹 9. Do-While Loop

👉 Runs at least once, even if condition is false

Example

int i = 1;

do {
    System.out.println(i);
    i++;
} while(i <= 5);

✔ Output:

1 2 3 4 5

🔥 Key Difference

🧠 Key Takeaways

✔ Condition must always be boolean
✔ Java does NOT allow non-boolean conditions
✔ Without {}, only one statement is considered
✔ Infinite loops happen when condition is always true
✔ break → exits loop
✔ continue → skips iteration
✔ Scanner is used for user input
✔ JSON is lightweight, XML is structured
✔ do-while runs at least once

🏁 Conclusion

Today was all about understanding how Java actually behaves under the hood 🧠

These small concepts are very important when:

• Writing automation scripts
• Handling test data
• Building logic-driven frameworks

🔥 Step by step, building strong fundamentals in automation!

🤖 A Small Note
I used ChatGPT to help structure and refine this blog while keeping the concepts aligned with my learning.

Bubble shooters are one of those genres that looks solved. Match three, clear the board, repeat. The core mechanic is so well-established that most developers treat it as a template rather than a design problem.

I didn’t want to build a template. I wanted to build something that stayed interesting past level 50.

Why bubble shooters are harder to design than they look
The fundamental challenge with bubble shooters is entropy. Every level starts with a cluttered board and ends with an empty one. That’s the whole game. Once players internalize the basic color-matching mechanic, the only way to maintain engagement is variety — and variety in a bubble shooter is surprisingly difficult to achieve without breaking the feel of the game.

The standard approach is to add obstacles. Frozen bubbles that need multiple hits. Stone bubbles that can’t be destroyed by color matching. Walls that change the bounce angles. These work, but they’re additive complexity — more things to remember, more exceptions to the core rule.

What I found more interesting was multiplicative complexity: elements that interact with each other to produce emergent outcomes the player didn’t fully predict.

Designing 20 special bubble types

Popverse ships with 20 unique special bubble types. Getting to 20 required drawing a hard line between bubbles that added genuine strategic depth and bubbles that just added visual noise.

The ones that made the cut share a property: they change what the optimal move is, not just how hard the move is to execute.

Bomb bubbles are the clearest example. When a Bomb is on the board, the best move is rarely the most obvious color match — it’s often to deliberately set up a chain that detonates the Bomb at the right moment. The presence of a single Bomb bubble reframes the entire board.

Rainbow bubbles work differently. They match any color, which sounds like a pure advantage, but they introduce a decision cost. When you have a Rainbow in your queue, every shot becomes a question: is this the right moment to use it, or should I save it? That friction is the design doing its job.

Lightning bubbles create chain reactions across rows. Portal bubbles teleport shots to unexpected positions. Healer bubbles restore frozen neighbors. Each type introduces a different kind of thinking rather than a different intensity of the same thinking.

The 500+ level problem

500 levels is a lot of content for a solo developer to produce. The practical solution is a level generation philosophy rather than designing each level individually from scratch.

I organized levels into clusters of roughly 15-20, each cluster built around a specific mechanic combination. One cluster focuses on portal bubble navigation. Another introduces Bomb timing under shot pressure. A third combines Frost and Lightning bubbles in ways that force the player to choose between clearing fast and clearing efficiently.

Within each cluster, the first few levels introduce the mechanic cleanly. The middle levels add secondary complications. The final levels remove the scaffolding and let the mechanic run at full difficulty.

This structure means designing 30 clusters rather than 500 individual levels — a much more manageable problem.

What the random puzzle mode taught me

Popverse includes a random puzzle generator alongside the main level progression. I added it as a secondary feature, expecting it to be used occasionally.

Players used it constantly.

The insight this gave me: a significant portion of bubble shooter players aren’t trying to progress through a story. They want an infinite supply of fresh boards to solve. The level progression serves one type of player. The random mode serves another. Both are legitimate, and a game that only ships one of them is leaving half its potential audience underserved.

Technical decisions worth mentioning

Popverse is built with Cocos Creator targeting both browser and mobile from a single codebase. The physics of bubble shooting — arc trajectories, wall bounces, cluster detection — are all handled in TypeScript. Cluster detection in particular is worth getting right early: the algorithm that determines which bubbles to pop after a match affects how satisfying every single shot feels.

The browser version is live at phyfun.com. The iOS version is on the App Store.

If you’re building a puzzle game with a large level count, the most useful thing I can tell you is this: design the system before you design the levels. The system generates the levels. The levels don’t generate themselves.