For most of the history of software, we've adapted ourselves to the software.

You choose a CRM, accounting system, project-management tool, or operating system, and then configure your work around what it allows.

That may be changing.

AI coding agents and “vibe coding” have dramatically lowered the cost of building software for a specific need. The old problem with custom software was maintenance: someone had to build it, fix it, update it, and keep it running. That problem hasn't disappeared, but the cost of doing it is changing.

Still, I don't think everyone will become a software builder.

The more interesting future is maybe customization on top of a solid base.

The platform provides the difficult parts, the infrastructure, security, and a potentially strong base to work on, and you customize from there using prompts and AI. The user then customizes the experience and functionality around their needs.

Cloudflare OS and the Pi Agent Harness are interesting examples of this broader pattern: provide a capable foundation, then allow users or agents to build on top of it.

It could be the next evolution of software.

Not thousands of completely custom applications maintained independently, and not one generic application for everyone.

Maybe the future isn't building your own software. Maybe it's making existing software truly yours.

For decades, we optimized code for humans. We said that we write code for other humans to read, not for the machines.

Meaningful names, clean abstractions, consistent formatting, comments when necessary. The assumption was simple: someone else, or future you, would eventually read it.

Even when LLMs first appeared, that assumption mostly held. I'm no longer convinced that's where we're heading.

A good example is Google's Antigravity IDE. It started as an AI-powered IDE. Today, it has largely removed the editor and focuses on reviewing what the AI produced. The interface itself reflects a shift: less writing, more verification.

Another instance is that people are already experimenting with asking LLMs to generate assembly directly, skipping human-readable source code altogether. If humans never need to touch the code, why optimize it for us?

We're not there yet.

Human-readable code still has real advantages. It costs fewer tokens for both reading and writing, it's easier to inspect when something goes wrong, and manual debugging is still invaluable. Today's AI also benefits from well-structured source code.

But the trend is interesting. As models become better at generating, understanding, and fixing software, human-readable code may become more of a convenience than a requirement.

Interesting times; let's see where this trend leads us.

For decades, software engineering has been built around one core assumption: the same input should always produce the same output.

We designed deterministic architectures. We wrote deterministic code. We reviewed pull requests looking for correctness. We built test suites to guarantee reproducibility. We invested in CI pipelines, QA processes, and release gates because software was expected to behave predictably.

Then LLMs arrived.

Today, many engineering teams willingly accept that asking the same model the same question twice may produce different answers. AI-generated code may solve the same problem in multiple ways (just like humans). Agentic workflows make autonomous decisions that are probabilistic by nature. Instead of eliminating uncertainty, we embrace it because it unlocks something we have never had before: orders-of-magnitude improvements in productivity.

This is a fundamental shift.

The deterministic mindset that shaped modern software engineering is no longer sufficient. That doesn't mean correctness no longer matters. It means that correctness is achieved differently.

Instead of asking whether every step can be deterministic, we now ask whether we can detect wrong outputs, verify the important properties, recover safely from failures, and build feedback loops that continuously improve results.

This doesn't only affect AI features. It affects how we write code, review pull requests, test applications, and even how we think about architecture. Engineers are becoming supervisors of intelligent systems rather than authors of every single line of code.

The goal isn't to remove uncertainty. It's to manage it.

The companies that succeed won't be the ones pretending AI behaves like traditional software. They'll be the ones building processes, tooling, and architectures that acknowledge uncertainty while still delivering reliable products.

This isn't a temporary trend. It's a reset of our software engineering intuition.

AI-assisted software development is here to stay. Our challenge is no longer choosing between quality and velocity. It's learning how to achieve both in a world where not everything is deterministic anymore.

We are entering a strange communication loop. One person uses an LLM to generate a long proposal, report, or application document, and the receiver then uses another LLM to summarize it into bullet points.

We are effectively using AI to expand text, only to use AI again to compress it.

A lot of submission processes, grant applications, RFPs, and evaluation forms were designed for a pre-LLM era, when producing long, polished documents required significant human effort. Length itself was often interpreted as effort, seriousness, or competence. Today, everyone has access to tools that can generate pages of convincing text in seconds, and this changes the value of written communication.

If the real goal is to communicate ideas, requirements, risks, timelines, or proposals, then we should optimize for clarity and essence instead of document length. Personally, when I receive long documents nowadays, I often feel they were not truly written for humans to read. In a fast-moving world, concise communication matters more than ever. Bullet points, summaries, key decisions, tradeoffs, and actionable information are usually enough.

Otherwise, the workflow becomes absurd: use an LLM to generate 20 pages, use another LLM to summarize the 20 pages, then read the summary.

We should adapt our systems and expectations to the reality of the tools we now have. Instead of requiring maximum text, we should require maximum clarity.

We originally built Promies to solve a very specific problem of our own: distributing and managing promo codes for our Android apps. Once we saw how much easier it made our lives, we decided to share it with the rest of the developer community.

A few months ago, we completely re-wrote Promies from scratch. Along with that total codebase overhaul, we gave our promo code distribution system a massive, much-needed revamp.

If you’ve ever run an app giveaway, you know how chaotic it can get. Here is a look at how the new system takes the headache out of managing your promo codes.

From spreadsheet chaos to "batches"

When you export promo codes from the Google Play Console, you are handed a raw Excel sheet. From that point on, you are completely on your own. You are responsible for managing them, manually keeping track of which codes have been handed out, which ones are actually used, and which ones are still sitting idle in your spreadsheet.

With Promies, you can take those exported codes and insert them into what we call a "batch" in the code repository. Think of a batch as a clean, digital container for a specific set of codes you've generated.

Creating and sharing Promotions

Once your batches are set up, you can create a "promotion." A promotion can pull promo codes from one batch or even combine codes from multiple batches.

After configuring your promotion, you are provided with a clean, dedicated promotion URL. Instead of pasting a giant wall of text codes into a forum, where bots scrape them instantly, or users get frustrated trying already-redeemed codes, you just share this single URL.

This makes distribution incredibly easy, making it ideal for posting on Reddit, Twitter, and other online communities. Promies handles the logistics in the background, handing out codes one by one and automatically keeping track of which ones are used.

Tailor the giveaway experience

Every app campaign has different goals, so we built plenty of ways to customize your promotion pages.

For instance, you can choose to require an email address before providing a user with a promo code. This acts as an excellent speedbump against bots and serial hoarders, ensuring your codes go to actual users, since email verification is required.

To highlight the true value of what you're giving away, you can display before-and-after pricing so users have context on the value they are receiving. We've also packed in several other customization options to drive engagement, such as displaying the code's expiration date or setting up limited availability thresholds to create a sense of urgency.

Finally, sometimes a user grabs a code only to realize they can't use it or have already unlocked the feature. We've added a button that allows users to seamlessly return a code, instantly throwing it back into the pool for someone else to enjoy.

Getting free exposure for your apps

On top of making the logistics effortless, we also want to help you actually get eyes on your work.

On our homepage, we prominently showcase recent public promotions, allowing you to gather new users organically right from the platform. Additionally, we are now sending out a monthly newsletter featuring the best recent promotions directly to our subscribers, driving even more exposure to your apps.

Give it a spin for your next giveaway and let us know your thoughts!

If you do not already have one, you can sign up for a Promies developer account and get started quickly.

When we first introduced Pale Blue Spring Admin, it was a bit of a tease. You could look, but you couldn't touch. It provided a read-only window into your JPA entities, useful for a quick health check, but not exactly a replacement for the "Swiss Army Knife" experience of Django Admin.

Our goal has always been simple: we love Kotlin and the Spring Boot ecosystem, but we missed the "it just works" productivity of Python/Django.

With the latest release, we are happy to say we believe we have come closer to bridging that gap.

The missing CRUD

The headline feature is simple: Editing is here. You can now create, update, and delete entities directly from the UI. No more jumping into a database console or writing throwaway REST endpoints just to fix a typo in a production row. The UI automatically generates the appropriate forms based on your JPA annotations, keeping the "zero-config" promise alive.

Beyond the grid: Custom UI snippets

One of the main reasons people eventually outgrow auto-generated admins is the "walled garden" effect. You need a custom button to trigger a background job, or a specific chart to visualize data, and suddenly, the library is more of a hurdle than a help.

To solve this, we’ve added Custom UI Snippets. You can now define your own UI elements to extend the portal. Whether it's a specialized dashboard widget or a custom action button, you can inject your own logic and components without fighting the library.

Closing the gap

With these additions, we believe we are very close to feature parity with the core functionality of Django Admin.

We want to write backend code in our favorite language, Kotlin, with the same velocity as the Python ecosystem. We’re building this for ourselves, but we hope it makes your life easier too.

Give it a spin: Pale Blue Spring Admin

Try it out, and let us know what you think.

Happy coding!

If you’ve shipped even one mobile app, you’ve probably run into the same problem. Feedback is everywhere. Emails get lost, store reviews lack context, and feature requests end up scattered across different places.

Introducing Promies Feedback Board

A simple way to collect and manage feedback in one place, quickly and efficiently. By adding a link inside your app, you create a central hub where users can share ideas, report issues, and vote on what matters most.

It is designed to be practical and easy to integrate into your existing workflow. You can customize the board to match your app’s primary color so it feels like a natural extension of your product. You also have the option to show your email, giving users a direct way to reach out when needed.

Users can vote on ideas, helping you identify what is actually important. Voting is protected with a CAPTCHA to avoid spam and abuse. They can also subscribe to updates, and users will get notified via email when the status changes, for example, when something moves to in progress or is marked as done.

Full control for developers

From the developer side, you have full control over the feedback flow. You can reply to ideas and make those responses publicly visible, creating transparency and showing users that their feedback is being acknowledged and acted on.

You can also update the status of each idea, delete entries when needed, and view basic stats to understand what is gaining traction. In addition, you can choose to receive email notifications for new ideas so you never miss incoming feedback.

How we use it

At Pale Blue, we already use Feedback Board across our own apps. It has become our primary tool for deciding what to build next in our apps. Instead of relying on assumptions, we look at what users are voting on and subscribing to.

This, of course, is not enough, but it gives us a much clearer and more reliable signal on what to build next.

Get started

If you are building mobile apps and want a cleaner way to gather feedback, you are welcome to use it for your own apps as well. If you do not already have one, you can sign up for a Promies developer account and get started quickly.

The barrier to shipping software has collapsed. With AI code generation, any fleeting idea can become a reality almost instantly.

But there’s a catch: software that is created fast is often abandoned fast.

We are seeing a surge of "disposable software." We’re guilty of it too. While the cycle of "shiny object syndrome" has always existed in tech, AI has put it on steroids. We can now create entire repositories in an afternoon, only to realize a week later we have no desire to maintain them.

This creates a new landscape of risk. When you choose a library for your stack or a new tool for your workflow, you aren't just betting on the code, you’re betting on the people.

Code is now cheap and ephemeral. The only true constant is the team behind it. Before you depend on a new project, don't just look at the features; look at the track record of the maintainers.

In the age of AI, the code comes and goes. Make sure the humans are staying.

The hardest part of building a project isn’t always dealing with failure.

It’s dealing with a project that is doing just well enough to keep going. There is a common situation in software where a project isn’t a total disaster, but it isn’t a hit either.

It has some users and some traction, but not enough to be a clear success. This is the "middle ground," and as Dropbox founder Drew Houston once noted, it can be the most difficult place to be. If a project fails, the choice to stop is easy. If it’s a success, the choice to grow is easy. But when it’s just "okay," it stays alive and uses up energy without a certain future.

In the AI era, the timing of this decision feels different because the industry moves so fast. A few years ago, it was common to let a project sit for a long time to see if it would eventually grow. Today, a project that is only "okay" now might be outdated in a very short time because tools and markets change every month. The "wait and see" approach carries a new kind of risk. The speed of the field makes the gap between a slow-growing project and a fast-moving market much more obvious.

Deciding what to do next usually involves a mix of data and intuition.

Some look at retention data to see if users are actually staying. It is a choice between waiting for more growth or deciding that the current traction isn't enough to justify more time. In a world that moves this fast, the middle point remains a challenging spot to navigate, with no clear data-driven/rational solution.

Not long ago, junior engineers learned by working closely with more senior ones.

Code reviews, design discussions, and mistakes created friction, and that friction built understanding.

AI changed that.

Today, answers are instant. Code is generated. Progress looks fast, but depth is optional. A junior can ship without ever fully understanding why something works. That’s powerful, and risky.

During our last internship season, our intern chose not to use AI tools while coding. Short-term productivity suffered. Tasks took longer.

But something more important happened: they struggled, debugged, and built intuition. When they would introduce AI tools, the effect would be dramatic. With experience in place, AI will become a multiplier instead of a shortcut. That’s the real distinction.

AI is great at accelerating experienced engineers. It’s bad at replacing the process that creates them. If we remove friction too early, we don’t get better engineers, just faster output with hidden gaps. And those gaps surface later, when systems scale or fail.

This isn’t about banning AI. It’s about being intentional. Let juniors struggle a bit. Accept short-term productivity loss.

Otherwise, we’re not training the next generation of engineers; we’re just shipping code faster.

We recently ran into a frustrating production issue: our Spring Boot application using SQLite would occasionally lock up, and the only way to recover was to restart the entire service. After some investigation and configuration changes, we not only fixed the locking issue but also saw dramatic performance improvements. Here's what we learned.

The Problem

Our production SQLite database would intermittently enter a locked state, causing requests to hang and eventually fail. The database would remain locked until we performed a manual restart; not exactly the kind of reliability we wanted in production.

The Root Cause

SQLite is designed differently from traditional client-server databases like PostgreSQL or MySQL. It's a file-based database that works best with single-connection access. However, Spring Boot's default connection pooling configuration doesn't account for SQLite's unique requirements, leading to connection conflicts and database locks.

The Solution

We made several targeted configuration changes to our application.properties to optimize Spring Boot for SQLite:

1. Single Connection Pool

spring.datasource.hikari.maximum-pool-size=1
spring.datasource.hikari.minimum-idle=0

SQLite performs best with a single connection. Multiple connections can lead to locking issues, so we configured HikariCP to maintain just one connection at a time.

2. Aggressive Connection Management

spring.datasource.hikari.connection-timeout=10000
spring.datasource.hikari.idle-timeout=10000
spring.datasource.hikari.max-lifetime=30000

These settings ensure connections don't linger unnecessarily, reducing the chance of locks.

3. Leak Detection

spring.datasource.hikari.leak-detection-threshold=5000

This helps us spot any connections that are held longer than expected, making debugging much easier.

4. Disable Open-in-View

spring.jpa.open-in-view=false

This was crucial. By default, Spring Boot keeps JPA connections open for the entire HTTP request lifecycle. We disabled this to ensure connections are released as soon as the database operation completes.

5. Manual Transaction Control

spring.datasource.hikari.auto-commit=false

Disabling auto-commit gives us explicit control over transactions, preventing unexpected commits that could cause locking issues.

The Results

The improvements were dramatic. We load-tested our API using k6 with identical test parameters:

Before the changes:

• Total requests in 5 minutes: 1,736
• Success rate: 76%
• Failed requests: 411

After the changes:

• Total requests in 5 minutes: 11,381
• Success rate: 99%
• Failed requests: 1

That's a 6.5x increase in throughput and virtually eliminated failures. More importantly, we haven't seen a single database lock since deploying these changes.

Key Takeaways

1. SQLite isn't PostgreSQL - Default Spring Boot configurations are optimized for client-server databases, not file-based ones.
2. Single connection is key - SQLite's architecture works best with one connection at a time.
3. Disable open-in-view - This JPA pattern is convenient but problematic with SQLite.
4. Monitor your connections - Leak detection helped us identify issues during development.

If you're using SQLite with Spring Boot, these configurations can save you from production headaches and give you some nice performance wins along the way.

Having spent time as a software engineer in a large tech company and later launching my own company, I’m often asked which experience is “better.”
The honest answer is: they’re both exciting, deeply fulfilling in different ways, and not really comparable.

Being a software engineer in a big company

Working in a big company feels like being a cog in an incredible, well-oiled machine. And I don’t mean “cog” in a negative way.

The machine is complex, powerful, and built by thousands of highly skilled people. Your role is clearly defined. You are expected to go deep, specialize, and deliver excellence within your scope. When something breaks, there’s a process:

• You identify the issue
• You report it
• It moves through product managers, designers, tech leads, and prioritization cycles

Your responsibility often ends at reporting clearly and correctly. Someone else owns the decision, someone else owns the fix, and that’s by design. This separation of concerns is what allows large organizations to scale.

Something is reassuring about this. You can focus on engineering problems, grow technically, and learn from incredibly talented peers. The impact is massive, even if it’s sometimes indirect.

Launching your own company

Starting your own company feels very different.

Instead of being a cog in a large machine, you’re building a much smaller machine from scratch. And at the beginning, you are most of the parts.

The boundaries between roles are blurry or nonexistent. You might notice a product issue, report it to yourself, prioritize it, design the solution, implement it, deploy it, and then answer the support ticket that comes in afterward.

There’s no “this isn’t my job.”

Even if your official role is “software engineer” or “founder,” reality doesn’t care. If something needs fixing and you’re the best person to do it, then that’s what you’ll do.

This can be exhausting, but it’s also incredibly energizing. You see the full lifecycle of decisions. You feel the consequences immediately. The feedback loop is short and very real.

Two exciting, very different journeys

What I’ve learned is that these two worlds shouldn’t be compared as better or worse.

They’re simply different journeys:

• Big companies teach you scale, rigor, and depth
• Startups teach you ownership, adaptability, and breadth

One is about mastering your part of the system.
The other is about making sure the system works at all.

Both are exciting. Both are challenging. And both shape you in ways that stay with you.

The important thing isn’t choosing the “right” path, but understanding what kind of journey you’re on, and why you chose it.

At Pale Blue, we’ve always admired the magic of Django Admin - that moment when you define your models and instantly get a clean, intuitive interface to browse, search, and manage your data. When we transitioned our backend stack to Spring Boot, we missed that simplicity — the ability to see and interact with our data models without writing extra code or wiring up a custom UI.

So… we built it.

We’re excited to announce the release of our second open-source library: pale-blue-spring-admin

What It Does

Pale Blue Spring Admin brings an auto-generated admin interface to your Spring Boot applications - inspired by Django’s admin, but built for the Spring + Kotlin ecosystem.

Once you install the library, it auto-discovers your JPA entities and exposes them through an intuitive web interface. From there, you can:

• Browse all entities in your database
• View records with pagination, search, and basic sorting
• Navigate relationships through linked foreign keys

Currently, the interface is read-only, but we’re already working on write operations (create, update, delete) for a future release.

Designed with simplicity in mind

One of our core goals was simplicity. We wanted developers to drop the library into their Spring Boot project, define their JPA entities as usual, and immediately get a clean, intuitive interface - no boilerplate, no manual wiring, no custom views to maintain. The admin UI is intentionally minimal, predictable, and easy to navigate, making data exploration effortless even in large projects.

Access to the admin interface must be explicitly defined, giving you full control over who can reach it and how they authenticate. In our documentation, we also provide a recommended lightweight authentication setup to help teams secure the admin area quickly, while still allowing more advanced configurations if needed.

Built in Kotlin. For Kotlin.

This project is also a milestone for us - our first backend library written entirely in Kotlin, marking our ongoing shift to Kotlin for backend development. We love the clarity and expressiveness Kotlin brings to Spring Boot projects, and we’re excited to contribute something useful back to the Kotlin and Spring communities.

Get Started

The library is open-source and available now: github.com/PaleBlueApps/pale-blue-spring-admin

We’d love your feedback, contributions, and ideas on how to make it even better.

Rewriting software is a topic that sparks endless debates among engineers. The first reaction when joining an existing project is often: “This is a mess, let’s start fresh”. It’s tempting to imagine a perfect, clean system - elegant architecture, fewer compromises, faster development.

Sometimes a rewrite is justified. But what’s often overlooked are the small fixes, edge case patches, and tweaks accumulated over time. That “messy” system is often stable because of these hard-earned adjustments.

A rewrite might feel faster initially, but regaining that stability - rediscovering subtle fixes, handling edge cases, and testing thoroughly - often takes longer than improving the existing code.

The key is balance. Rewrites aren’t inherently bad, but they come with hidden costs. Stability, accumulated fixes, and historical knowledge are valuable, and any rewrite should account for them before lighting the match.

Don’t chase perfection blindly - sometimes improving what works is smarter than starting over.

Happy coding!

The concept of the T-shaped engineer isn't new. It's been around, quietly championed by forward-thinking tech leaders and organizations. But in 2025, as LLMs transform how we build software, this professional archetype has evolved from "nice to have" to essential.

What Makes an Engineer T-Shaped?

Picture the letter T. The horizontal bar represents breadth - a working knowledge across a wide range of technologies, methodologies, and domains. The vertical stem represents depth - expert-level mastery in one or a few specific areas.

A T-shaped engineer might have deep expertise in distributed systems architecture while maintaining conversational fluency in frontend frameworks, DevOps practices, data engineering, and security principles. They can collaborate meaningfully with specialists across disciplines because they understand the fundamentals, even if they're not experts in everything.

The AI Amplification Effect

Here's where the AI era changes everything.

With LLMs, both general SOTA models and countless domain-specific models, the barrier to working across multiple technologies has dropped dramatically. An engineer with fundamental understanding can now leverage AI to scaffold applications in languages they haven't touched in years, generate infrastructure-as-code configurations, or even implement features in unfamiliar frameworks.

The breadth of the T becomes supercharged. That conversational knowledge of various domains? It's now enough to effectively direct AI tools to produce working solutions across technologies you don't use daily.

But here's the critical insight: AI is a powerful accelerator, but it's not infallible.

Depth as the Safety Net

This is where the depth of the T becomes your organization's safety net and quality standard.

In your areas of deep expertise, you can catch AI hallucinations and incorrect implementations before they reach production, guide AI tools toward best practices that go beyond surface-level correctness, make architectural decisions that AI can't reliably make on its own, identify security vulnerabilities or performance issues that AI-generated code might introduce, and maintain high standards even when moving fast with AI assistance.

Think of it this way: AI gives you the ability to paint across a massive canvas. Your depth expertise ensures that the critical parts of that painting are museum-quality.

Growing T-Shaped Engineers

Becoming T-shaped isn't about forcing engineers to master everything. It's about recognizing and developing depth in areas where engineers show natural aptitude and interest, encouraging curiosity across domains without demanding mastery, creating opportunities for meaningful exposure to different parts of the stack, and celebrating both deep expertise and collaborative breadth.

The engineers who will define the next decade aren't those who can do everything or those who know only one thing. They're the ones who can go deep where it matters and go wide where AI can help - combining human expertise with artificial intelligence to build better software, faster and more safely than either could alone.

The T-shaped engineer isn't just relevant in the AI era. It's the blueprint for how exceptional engineers will work.