Look, I need to get something off my chest. I've been writing software professionally for over fifteen years, and I have opinions. Bad ones, probably. But I've earned them through mass deployments, mass migrations, and mass existential crises in production at 3 AM on a Saturday.
So here they are. My hot takes for 2026. You're welcome. Or I'm sorry. Depends on how attached you are to your current architecture.
Tabs vs Spaces Is Dead, Long Live Whatever Claude Outputs
I remember the passion. The fury. The religious wars over whitespace characters. Tabs vs spaces was the vim vs emacs of formatting debates, and people cared. Like, Slack-thread-essay cared. PR-comment-novel cared. Put-it-in-the-engineering-handbook cared.
And now? In 2026? Nobody manually types enough code for it to matter.
I ran the numbers on a recent project. Roughly 60% of the code in our latest sprint was AI-assisted. Not "AI wrote it and we shipped it blind" -- more like "AI drafted it, a human shaped it, and Prettier formatted it." The formatting debate isn't tabs vs spaces anymore. It's .prettierrc vs .editorconfig, and even that's a stretch because everyone just commits whatever config Claude suggests and moves on with their lives.
The real formatting debates that actually matter now? Prompt structure. How you organize your context window. Whether your system prompt is a masterpiece of concise instruction or a rambling novel that burns half your tokens before you even ask a question. I've seen engineers spend twenty minutes crafting the perfect prompt and zero minutes thinking about their tab width, and honestly? That's growth.
The new holy war is "do you check your AI rules file into the repo or not." Now that's a hill I'll die on. (You check it in. Obviously. It's part of your codebase now. Fight me.)
Your Microservices Are Just a Distributed Monolith
I need you to sit down for this one.
If Service A calls Service B which calls Service C, and they all share a database, and you deploy them together every Thursday, and if any one of them goes down the whole system falls over -- congratulations, you've built a monolith. You've just added network latency and operational complexity as a treat.
I've consulted for teams that proudly showed me their "microservices architecture" diagram. Seventeen services. Arrows everywhere. It looked like a conspiracy theorist's wall. And when I asked "can you deploy Service 7 independently without touching anything else?" the room went quiet. That particular silence. The silence of engineers who know the answer but don't want to say it out loud.
Here's the thing: microservices are genuinely great. For organizations with 200+ engineers who need independent deployment pipelines and team autonomy. For your twelve-person startup? You need a well-structured monolith, a good deployment pipeline, and to stop cosplaying as Netflix.
At Apptitude, we've talked teams off the microservices ledge more times than I can count. The conversation usually goes: "But what about scale?" And we say: "You have 400 users." And they say: "But what about future scale?" And we say: "A Rails monolith handled Shopify until they were doing billions in GMV. You're going to be fine."
Ship the monolith. Extract services when you have a real reason. "I saw a conference talk about it" is not a real reason.
Nobody Reads Your Documentation (But Write It Anyway)
This is the great paradox of software engineering. Documentation is simultaneously the most ignored and most critical artifact in your organization.
Nobody reads the docs. I know this because I've written docs. Beautiful docs. Docs with diagrams and examples and carefully formatted code blocks. And then someone Slacks me the exact question that's answered in the first paragraph of the doc I sent them last week. The human experience is universal.
But here's the twist: the one time someone reads your docs is when everything is on fire. It's 2 AM. Production is down. The one person who knows how the payment service works is on a flight to Tokyo. And suddenly that runbook you wrote six months ago that got zero pageviews is the most important document in the entire company.
Write the docs. But write the right docs.
Architecture Decision Records over Confluence pages. Every single time. A good ADR tells you why a decision was made, not just what the decision was. "We chose PostgreSQL" is useless. "We chose PostgreSQL over DynamoDB because our access patterns are highly relational and we didn't want to pay a consultant $50K to model our data for a NoSQL database" -- that's an ADR that saves someone's sanity in eighteen months.
Also, hot sub-take: your AI context files are documentation now. Your system prompts, your rules files, your configuration docs -- these are living documents that describe how your system works. Treat them with the same care you'd treat an architecture doc, because unlike your Confluence wiki, these actually get read. By a machine. Every single time. Which, honestly, is more than you can say for anything you've ever put in Notion.
"We Use Agile" Is Not a Personality
Quick poll: Does your team do two-week sprints with a planning meeting, a standup, and a retro? Cool. That's not agile. That's Scrum. And if your sprint planning is really just your PM reading out a pre-decided list of tickets while everyone nods, that's not Scrum either. That's waterfall with a standup.
Real agility -- the thing the Agile Manifesto was actually about -- is responding to change over following a plan. It's having a conversation with your customer and pivoting when you learn something new. It's shipping something small, getting feedback, and iterating.
Most teams I've seen use "agile" as a noun, not an adjective. "We do Agile." No. You are agile, or you aren't. And if your sprint commitments are carved in stone three months in advance by someone who hasn't talked to a user since Q2, you aren't.
The teams that actually ship great software? They usually can't describe their process cleanly. It's messy. It's "we have a board, we talk a lot, we ship when it's ready, and we change direction when we need to." That's not a methodology. That's just... being good at building software.
Kill the ceremony. Keep the communication.
The Best Code Is the Code You Delete
I once watched a senior engineer delete 4,000 lines of code in a single PR. The tests all passed. The application worked exactly the same. It was the most beautiful thing I've ever seen in a code review.
Every line of code is a liability. It's a line that can break. A line that needs to be understood by the next developer. A line that has to be maintained, updated, and migrated when you upgrade frameworks. The fetishization of writing code -- of output as a metric -- is one of the most destructive forces in our industry.
The best engineers I've worked with solve problems by removing things. "Oh, we don't need this service anymore because the new library handles it natively." "This entire module exists to work around a bug that was fixed two versions ago." "We built this feature and literally no one uses it. Let's kill it."
Deleting code is an act of courage. It requires understanding the system deeply enough to know what's load-bearing and what's dead weight. Junior engineers add code. Senior engineers remove it. Principal engineers prevent it from being written in the first place.
Next time you estimate a project, try this: after you plan what you'll build, spend an hour asking what you can remove. You'll be amazed at how often the answer simplifies everything.
AI Won't Replace Developers, But Developers Who Use AI Will Replace Developers Who Don't
I know, I know. You've seen this take before. But most people deliver it as a threat, and I want to deliver it as an observation, because I've been living it.
Here's what actually happened at our studio over the past year: the developers who embraced AI tools didn't become less skilled. They became more dangerous. They ship faster, not because the AI writes perfect code, but because it handles the mechanical parts -- the boilerplate, the test scaffolding, the "I know exactly what this function needs to do but I don't want to type it" parts -- and frees up mental energy for the hard stuff. Architecture. System design. Figuring out what to build in the first place.
The developers who refused to use AI tools aren't unemployable. They're just... slower. And in a world where shipping speed is a competitive advantage, slower is expensive.
But here's the nuance nobody talks about: AI makes experienced developers more productive because they know what good looks like. They can review AI output and catch the subtle bugs, the architectural mistakes, the "this works but it's going to be a nightmare to maintain" patterns. A junior developer using AI without that judgment isn't 10x -- they're 10x in the wrong direction.
The skill that matters most in 2026 isn't writing code. It's evaluating code. Knowing what to keep, what to refactor, and what to throw away. Which, if you've been paying attention, brings us right back to the previous take.
The best code is still the code you delete. Even if an AI wrote it.
We're Apptitude -- an app development and AI consulting studio that ships software and has opinions about it. If you want to work with a team that will tell you your microservices are a distributed monolith to your face (lovingly), let's talk.