Forem: Filipe Brito Ferreira

We're Shipping More Code Than Ever. We Understand Less of It.

Filipe Brito Ferreira — Sun, 03 May 2026 00:00:00 +0000

A few weeks ago I watched a junior push four commits to the same pull request, each one a fresh Claude paste at the same bug. Each round he was more confident. Each round he was no closer to fixing it, because the bug was in his prompt, not in the code. By round three nobody on the call could explain what the function was supposed to do.

The junior wasn’t the failure here. The pipeline was. We hired juniors into a process that quietly stopped doing the one thing it was supposed to do for them, which is to push back when they ship something they can’t defend. They learned to lean on AI because we let them, and then we trained them to.

In 2026, 76% of developers use an AI coding assistant, up from 44% two years ago. AI now writes roughly 41% of the code shipped. And yet 65% of developers still report burnout, AI-generated code carries 1.7× more issues than human-written code, and incidents per pull request are up 23.5% year-on-year.

We’re moving faster on paper while learning less, shipping worse, and burning out harder. The tools aren’t the problem. The expectation that they replace thinking is.

Yes, We’ve Heard This Before

Every five years a new tool gets blamed for breaking software engineering. IDEs were going to kill our ability to write Makefiles. Stack Overflow was going to produce a generation of copy-paste developers. Offshoring was going to gut institutional knowledge. None of those predictions aged well, and the industry survived each one.

So why is this time different? Because LLM output doesn’t look foreign. A Stack Overflow paste was obviously someone else’s code: different style, different variable names, different formatting. You knew you hadn’t written it. AI-generated code is formatted to your conventions, named after your variables, and commented in your tone. The social cue that used to say "stop, read this carefully" is gone. The output looks like it came from you, even when nobody on the team understood it.

That changes the failure mode. Old tools eroded specific skills. This one erodes the line between writing code and reading code, which is the line that mentorship, review, and learning all sit on.

This piece is about what happens when an organisation crosses that line at scale. If you’re a solo founder or a two-person shop, AI-shipped speed isn’t a failure of discipline, it’s the job. What I’m worried about is what breaks when companies scale those habits without scaling accountability.

The Speed Illusion

Output volume is up. Real velocity isn’t.

In a study of experienced developers using AI tools, participants took 19% longer to complete tasks while believing they were 20% faster. A 43-point gap between perception and reality, one of the largest "expectations gaps" recorded in modern software engineering research. The dashboards show acceleration. The clock shows the opposite.

The pattern repeats at the team level. According to a recent Cortex report, pull requests per author are up 20% year-on-year, incidents per pull request are up 23.5%, and change failure rates have risen by roughly 30%.

We’re measuring the wrong things. Lines of code, pull request count, story points closed: all up with AI. Time-to-resolution, incident counts, rework, weekend on-call hours: also up, faster. If you only look at the top of the funnel, AI looks like a miracle. If you look at the full ledger, the miracle starts to look like a loan.

The Habits That Don’t Get Fixed

In 2018, a junior who copy-pasted a Stack Overflow answer they didn’t understand would get stopped in code review before lunch. Someone would ask "why did you write it this way?" and the gap would surface. In 2026, that same junior gets a thumbs-up emoji and the pull request merges, because the senior who would’ve caught it is reviewing five times more code in the same hour.

Here are the habits I keep watching not get corrected:

Copy-paste without reading. Developers ship code they couldn’t have written by hand and can’t explain in review. That isn’t laziness. It’s a rational response to a quota that assumes AI velocity but pays for human throughput.

Stack traces become LLM input, not learning. Pasting a trace into Claude isn’t the problem. Pasting it without reading what came back is. When the model is right, you ship. When the model is wrong, you’ve got nothing to fall back on, because you never built the muscle that lets you read the trace yourself.

AI-generated tests no one validates. Green CI doesn’t mean correct code. Tests that mirror the implementation pass even when the implementation is wrong. Coverage numbers go up while real coverage goes down. We’re watching codebases where every line is "tested" and nobody can explain what any of it actually verifies.

Pattern atrophy. Developers are forgetting basic shapes: recursion, loops, common data structures, even the order of arguments to functions they wrote last month. Try this on yourself this weekend. Write merge sort with no AI, no Google, just a blank file. If it surprises you how rusty you feel, the atrophy already started. The skill rusts the same way any skill does when you stop using it.

The same dynamic plays out beyond closed teams. Open-source maintainers are now drowning in plausible-looking pull requests submitters can’t defend in review, the same broken feedback loop, just with no shared employer to escalate to.

None of this would survive a real review. That’s the whole problem. Reviews used to be where bad habits died. They’ve become a throughput gate.

Debugging Is Where the Bill Comes Due

You can ship code you don’t understand. You can’t debug it.

Production incident at 2 a.m. The AI doesn’t know your system’s quirks, your team’s conventions, or which of the seven retry layers is the one masking the real failure. You’re now reading code you wrote but never read. A debug cycle that took thirty minutes in 2020 takes three hours in 2026, not because the bug is harder, but because the mental model the original author should have built was never built. Compound interest on every shortcut taken during the original pull request.

This is also why the productivity numbers lie. The hours you saved during the pull request get quietly spent during the incident. The accounting is hidden because the two events happen on different days, owned by different on-call rotations, and reported in different dashboards. Speed booked in one quarter, cost paid in the next.

If you think this is just my anecdote, look at GitHub itself.

On 23 April 2026, GitHub’s merge queue silently corrupted code in 2,092 pull requests across 230 repositories. The root cause, in their own words: "existing test coverage primarily exercised single-PR merge queue groups, which did not exhibit the faulty base-reference calculation." A predictable edge case nobody thought to test. That gap wasn’t a memory failure, it was a velocity failure. The tests that would’ve caught a multi-PR squash regression are the kind you write when you’re slowing down to think about how a feature actually behaves under load. They’re the first tests to get cut when the team is told to ship faster.

The company that ships AI dev tools to the rest of us shipped at AI velocity, and an obvious failure mode reached production unguarded. If GitHub is hitting these walls, your team is too. You just haven’t noticed yet, because nobody is paying you to write a public availability report.

"But AI Saves Real Time, Right?"

The wins are real. They’re also narrow.

Boilerplate is genuinely faster. Scaffolding new files, projects, and test fixtures is much faster. Searching documentation for an unfamiliar library, translating between formats, drafting commit messages, generating regex you’d otherwise spend forty minutes on Stack Overflow for: all real wins. I use these tools every day at work.

The point isn’t that AI is bad. The point is that the wins are concentrated on the easy work, while the cost lands on the hard work. System design, debugging novel failures, writing code that survives a refactor in two years: none of that gets easier with AI. It gets harder, because the developer trying to do the hard work has less practice on the easy work that used to build the muscles.

You can ship a product without ever doing the hard work. You can’t keep one running.

The Quota Got Higher, Not the Pay

AI didn’t free up time. It became the new baseline expectation.

Scientific American reports that developers using AI tools are working longer hours, not shorter ones. TechCrunch’s February 2026 piece put it more bluntly: the first signs of burnout are coming from the developers who embraced AI the most. 65% of developers are reporting burnout in 2026 even though 61% of organisations have rolled AI into their development pipelines.

Most engineering managers didn’t set this quota. They received it. The line manager telling the tech lead that review is a bottleneck is themselves being told their team’s velocity needs to double now that Copilot is paid for. The pressure runs from the top of the org chart down, and the cognitive load of reviewing AI slop lands on whoever is holding the bag at the bottom.

Microsoft is the public version of this story. Satya Nadella reportedly described some of Copilot’s own integrations as "almost unusable". Windows 11 hit a Patch Tuesday so bad that users couldn’t shut down their machines. The company that bet hardest on AI shipped at AI velocity, and the bug reports caught up with them faster than the marketing did.

Same pattern as the games industry collapse I wrote about last year: short-term thinking, growth-at-all-costs, no investment in longevity. New tool, same mistake.

How Can We Turn This Around?

None of the fixes here are revolutionary. They’re the basics a lot of teams have stopped doing. Skip the platitudes; here’s what to actually do on Monday morning.

For developers. Don’t merge code where you can’t delete one line and predict the effect. If you can’t, you don’t understand it. Before pasting a stack trace into the LLM, give yourself ten minutes alone with the trace. Keep the muscle alive. Treat AI output like a draft, never a deliverable.

For seniors and tech leads. Make "can you explain this in plain English?" a required review comment on any pull request that smells AI-generated. It costs the author thirty seconds when they understand the code, and it surfaces the gap immediately when they don’t. That’s mentorship at scale, not theatre.

For managers and engineering leaders. Pair every velocity metric on your dashboard with change failure rate. The upward script is short: "velocity is up, but the share of changes that need a fix or rollback is up faster, and that’s the risk we’re taking." That framing survives the conversation with finance because it reads as risk visibility, not as a veto. Then watch your own measurement. Change failure rate gets sandbagged the moment teams notice it matters: incidents quietly drop in severity, rollbacks get rebranded as "follow-up PRs". If the number isn’t moving, the gaming probably already started. The metric is only useful when paired with a definition you don’t let drift.

For solo founders, OSS maintainers, and anyone owning the whole stack. Keep a SHORTCUTS.md in the repo root. One line per AI shortcut you knowingly took, with a date and the reason. When you’re debugging at 2 a.m. three weeks later, that file is your map. The accounting trick that hides the bill from corporate teams doesn’t exist for you (you’re the one being paged), but the corners you cut still vanish from memory if you don’t write them down.

For everyone. Slow down to learn. Compound interest works in both directions.

The 2 a.m. page is the part of this loop you can still avoid. The shortcut is yours, the debugger is yours, and the mental model that gets you back to bed is yours too. None of that is going to be built by the system that’s asking you to ship faster.

Why I Interview Once a Year (Even When I'm Not Job Hunting)

Filipe Brito Ferreira — Sun, 06 Oct 2024 15:25:00 +0000

Recently, my direct manager asked me, "Why did your LinkedIn status change to 'open to work'?" It’s a fair question, and one that I’d like to address. Every so often, about once a year, I go on what I call an "interview spree." This practice isn’t because I’m actively looking to leave my current role, but rather, it’s designed to help me understand the current job market and assess where I stand within it.

In this blog, I want to explain the reasoning behind this approach and how it can benefit your career as well.

Key Benefits of Interviewing Once a Year

Interviewing once a year, even if you're not actively looking for a new job, can offer several key benefits for your career growth and professional development. Here are some reasons why it’s a good idea:

Market Awareness

The job market is constantly changing, with new roles, skill demands, and salary benchmarks emerging. By interviewing regularly, you get a pulse on these trends. You’ll learn which skills are in demand, what new technologies or methodologies companies are adopting, and what qualifications they value most. This allows you to stay competitive and informed, even if you're content in your current position.

Benchmarking Your Skills

Interviewing helps you gauge how your skills and experiences stack up against industry expectations. It provides insight into where you excel and where there might be gaps. This feedback can guide your ongoing professional development, helping you pursue new certifications, projects, or trainings that enhance your marketability.

Networking Opportunities

Job interviews often allow you to meet and engage with people in your field, expanding your professional network. Even if you don’t take the job, building relationships with interviewers or companies can lead to future opportunities or collaborations down the line.

Confidence Boost

Going through the interview process once a year helps you refine your communication skills and keeps you sharp. It forces you to articulate your achievements, projects, and strengths, which builds confidence in your own abilities. Regular interviewing ensures that you're always ready to talk about your work, whether at an impromptu networking event or during a surprise promotion conversation.

Plan for the Unexpected

Even if you're happy in your current job, things can change—companies restructure, industries shift, or personal situations evolve. Regular interviewing prepares you for the unexpected by keeping you familiar with the process, ensuring that you're never caught off-guard if the need to find a new position arises.

Leverage in Your Current Role

When you're aware of your value in the market, you can use this knowledge in discussions with your current employer. Whether you're negotiating a raise, asking for a promotion, or proposing new responsibilities, knowing what other companies would offer you gives you a stronger bargaining position.

Career Reflection

Interviewing allows you to reflect on your current job satisfaction and career trajectory. It prompts you to consider questions like: Am I growing in my current role? Are there better opportunities elsewhere? Is this the right career path for me? This self-assessment can help you ensure that you're not becoming stagnant and that you're continuously moving toward your career goals.

Discussing Your Interview Practice with Your Manager

Informing your manager about your decision to interview once a year, even if you're not actively seeking to leave, can foster transparency, strengthen your relationship, and even enhance your professional development within the company. Here’s why it’s a good idea:

Builds Trust and Transparency

Being open with your manager about why you're interviewing demonstrates honesty and transparency. When you proactively explain your motivations—such as staying current with market trends or benchmarking your skills—it shows that you’re committed to personal and professional growth. This can prevent any misunderstandings or suspicions about your intentions.

Enhances Communication

Open communication is essential for a healthy employee-manager relationship. By having this conversation, you're showing that you respect your manager enough to keep them informed about your career development efforts. It encourages a two-way dialogue where you can openly discuss your career goals and aspirations within the company, as well as outside opportunities.

May Lead to Internal Growth

By sharing your market exploration with your manager, it may lead to internal career advancement discussions. If your manager knows you’re evaluating your market position, they may offer opportunities for growth within the company, such as additional responsibilities, a new project, or even a promotion. This could help keep you motivated and ensure that your role continues to align with your career goals.

Encourages Skill Development

When you let your manager know you’re interviewing to gauge market expectations and skill demands, they might offer support in helping you bridge any skill gaps. For instance, they could recommend training programs, certifications, or stretch assignments to help you stay competitive, not just for external roles, but within the company as well.

Preempts Concerns

If your manager notices that you’ve changed your LinkedIn status to "open to work" or hears that you’ve been interviewing elsewhere, it could raise concerns about your commitment. Proactively informing them allows you to clarify that you’re not actively looking to leave, but rather participating in interviews as a professional development tool. This preempts any negative assumptions or worries.

Shows Initiative and Ambition

When you discuss your market exploration with your manager, it signals that you’re serious about your career trajectory and personal development. This ambition can be viewed positively, showing that you're someone who takes initiative and constantly seeks to grow and improve, which are qualities most employers value highly.

Adds Value to the Organization

Understanding the market and how your role compares to others in the industry can help you bring fresh insights back to your current job. By discussing this with your manager, you might share information on industry trends or best practices you’ve learned during interviews, adding value to your organization. This can position you as someone who’s not only focused on personal growth but also on contributing to the company's success.

By making interviewing an annual habit, you stay agile, aware, and prepared for whatever your career may bring. It’s not about being disloyal to your current employer; it’s about taking proactive control of your professional development.

Supper Club GraphQL as an Aggregation Layer with Filipe Ferreira of Sky TV

Filipe Brito Ferreira — Mon, 16 Sep 2024 04:50:12 +0000

I Was on the Syntax.fm Supper Club Podcast!

I’m excited to announce that I recently had the pleasure of being a guest on the Syntax.fm Supper Club podcast, hosted by Wes Bos and Scott Tolinsky.

During the episode, we discussed my experiences building GraphQL servers and developing JavaScript/TypeScript applications at Sky. It was a great conversation covering a range of topics from the benefits of GraphQL as an aggregation layer to practical insights into modern JavaScript and TypeScript development.

You can check out the episode and listen to our discussion here: GraphQL as an Aggregation Layer with Filipe Ferreira of Sky TV.

I’d love for you to give it a listen and let me know what you think. Your feedback and thoughts are always appreciated!

From Coding Challenges to Real-World Skills: Rethinking the Modern Interview Process

Filipe Brito Ferreira — Sun, 08 Sep 2024 12:43:41 +0000

After a decade of experience as a software developer, both as an interviewer and an interviewee, I’ve come to realise that many interviews fail to effectively showcase a candidate’s true skills.

The most common interview format involves solving problems similar to those found on LeetCode. In over 250 interviews, I’ve repeatedly encountered the same types of problems, such as FizzBuzz or a debounce function. This format often seems more like a test of how many interviews you’ve attended rather than a genuine assessment of your abilities.

From my experience interviewing candidates, many struggle with these problems and frequently run out of time. This doesn’t necessarily reflect their ability to handle real-world issues. Moreover, these interviews often discourage candidates from using resources like Google or MDN, which feels unfair given the stress and pressure involved. I always encourage candidates to use any online resources they would normally rely on in their daily work.

Ultimately, I’m more interested in understanding how you approach and solve problems in a real-world work environment rather than how you perform under test conditions. After all, we’ve all experienced times in school where we struggled with a test but excelled in regular classwork.

Another common interview format involves take-home coding exercises. These are generally more effective than the previous format, especially when candidates are not timed. In my experience, candidates tend to showcase their skills better in this setting, as it more closely resembles a normal working environment. However, issues arise when these take-home exercises are hosted on online platforms with strict monitoring, where candidates are timed and their screens are recorded to ensure they aren’t using tools like ChatGPT, Google, or MDN.

Many companies now offer AI coding tools—such as ChatGPT, which I use daily at ROKU. While these tools don’t solve everything for you, they are akin to power tools. Just as a power screwdriver makes the task faster and easier, AI tools can enhance productivity without replacing fundamental skills.

Despite these challenges, securing an interview feels like a rare relief in today’s job market. Many candidates apply to over 100 job postings just to land one interview. This paradox is puzzling, especially when hiring managers complain about the difficulty of finding qualified candidates. Throughout my career, I’ve rarely been in a position where we had a fully staffed team and weren’t hiring. We’re always looking for talent, so why are so many roles left unfilled, and why do candidates struggle to find jobs?

The disconnect between the abundance of open roles and the difficulty in filling them may stem from a variety of factors. One possibility is that job descriptions are often overly specific or unrealistic, setting an unattainable bar that deters qualified candidates. Additionally, the hiring process itself may be overly rigid, with a heavy emphasis on traditional coding tests and a lack of focus on practical, real-world problem-solving skills. This can lead to a situation where even highly skilled candidates are overlooked because they don't fit a narrow set of criteria. Companies might also be struggling with internal inefficiencies or biases that prevent them from recognising and onboarding talent effectively. Addressing these issues requires a reevaluation of hiring practices, a broader understanding of what constitutes valuable experience, and a more inclusive approach to assessing candidate skills.

Furthermore, the rapid pace of technological change means that the skills and experiences required for many roles are constantly evolving. This can create a gap between what companies need and what candidates offer. Many job seekers may have the relevant experience but lack specific keywords or certifications that are currently in vogue, which can hinder their chances of being noticed. Additionally, the emphasis on cultural fit and soft skills in many organisations can sometimes overshadow technical abilities, leading to mismatches between job requirements and candidate profiles. To bridge this gap, employers should consider adopting more flexible criteria for job qualifications, focusing on candidates' ability to learn and adapt rather than strictly adhering to a predefined list of skills. Embracing a more holistic view of candidate potential can help to better align hiring practices with the dynamic nature of the tech industry.

In conclusion, the current state of the job market reflects a complex interplay of evolving skills, rigid hiring practices, and mismatched expectations. Despite the abundance of job openings, many qualified candidates struggle to secure positions due to unrealistic job descriptions, outdated evaluation methods, and a narrow focus on specific credentials. To address these challenges, both companies and candidates need to adopt a more flexible and forward-thinking approach. Employers should reassess their hiring criteria to emphasise practical problem-solving abilities and potential for growth, rather than strictly adhering to traditional qualifications. Meanwhile, candidates should focus on showcasing their adaptability and real-world problem-solving skills. By fostering a more inclusive and realistic hiring process, we can better align the needs of employers with the capabilities of job seekers, ultimately leading to a more efficient and equitable job market.