On the night OpenAI put its mathematics repository on GitHub, the complexity theorist Dana Moshkovitz texted her husband about the manuscript claiming to prove the Unique Games Conjecture, a statement he says she has worked toward for as long as he’s known her. “It feels like something written by someone who’s on psychedelics,” she wrote. Her husband is Scott Aaronson, who quoted those texts in his post “The Mathocalypse”, just below a line I read a few times. The UGC manuscript comes with a Lean certificate, so a machine has checked the formal proof, and yet “it also appears that no human has understood just about any of these proofs yet; the race to do so has just started.”

My last post, Let the Agents Cook. Make Them Prove It., argued that verification is the foundation of agent autonomy, because machine-checkable evidence is what makes it reasonable to let agents do more on their own. I still believe that. Here, though, verification had apparently worked, and the people who cared most about the result were still standing outside it. So this post is a qualification rather than a retraction: verification can justify trusting an output without creating the understanding needed to extend or maintain it, and in software, where someone has to change the code again next quarter, that understanding is a large part of the job. The two ideas are complementary, and mathematics just happens to make the gap between them easier to see.

the short version of the release

On October 6, OpenAI announced “a broad range of new mathematical results produced by an internal frontier model” (unreleased), published as a GitHub repository of 719 manuscripts organized into 372 “families” of related results. By OpenAI’s account the average result used roughly three hours of ChatGPT Pro thinking compute, and after an October 7 update about 42% of top-line results are formalized in Lean, 300 of 719. All of it is self-reported and none of it peer-reviewed. One day after release the history file recorded three withdrawals because “a sign error invalidates a stabilization-trace cancellation argument and the construction used by two dependent papers,” which anyone who has watched one bad utility function quietly break three services downstream will recognize.

A week earlier the Advisory Group on Mathematics and Artificial Intelligence, nine independent mathematicians including Timothy Gowers, Martin Hairer and Edward Witten, had published guidelines for responsible release of AI-generated mathematics. On release day the group issued a carefully neutral statement calling the release “the beginning, not the completion, of the process of human understanding.”

two different ledgers

I keep coming back to the process of human understanding, because it names something the word “verified” tends to swallow.

A Lean certificate answers a narrow and extremely valuable question: does this formal statement follow from these definitions and axioms, according to this kernel? Even that answer depends on the formal statement being the right one. In a guest post on Terence Tao’s blog, Thomas Hales argues that a Lean proof “should not be accepted until a human audit is performed to ensure statement fidelity,” and a preprint by Bastounis, Circelli and Hansen argues that an autoformalized proof can follow a different argument from the paper humans are reading. The deeper issue is that correctness and comprehension are kept on two separate ledgers, and a certificate only writes to the first one. Comprehension is what lets you reuse an idea, notice that it would also crack a neighboring problem, or see where it breaks if you change a hypothesis, and most of the value of a new result sits on that second ledger.

The advisory group’s guidelines state the old norm plainly: “the authors of a paper should understand the mathematical argument of that paper, have verified its correctness themselves, and take full responsibility for the content.” Read that with a pull request in mind. Understanding, verification and responsibility have always travelled together in the person of the author, so we rarely had to name them separately. Machine authorship pulls them apart, and once you can have verification without understanding, it’s no longer obvious who holds the responsibility.

the same bottleneck, in our repos

We’ve been running a version of this experiment in software for a while, just without the vocabulary. Harvard economists Fiona Chen and James Stratton used Jellyfish engineering analytics covering roughly 300 million work events across 718 firms, from January 2021 through March 2026. Their paper, covered by Ars Technica, finds agents raise lines of code by 30%, commits by 20% and pull requests by 23%, while resolved Jira issues and epics, the authors’ proxy for shipped software, show small, statistically insignificant changes. The time from opening a pull request to merging it rises 49%, the share of PRs where a reviewer formally requests changes nearly doubles, and comments per PR rise 35%.

I lead a web engineering team and still build a lot myself, so the review queue isn’t an abstraction for me (I touched on it in Agentic Engineering Is Not a Vibe). At its core, code review is the moment a second person builds enough of a mental model of a change to share responsibility for it. That’s comprehension work, and it doesn’t get faster because the code was cheaper to write.

An agent’s PR also tends to arrive without the thing a human author brings into review almost for free, which is someone who can answer why.

A colleague can usually explain an odd choice in a minute. With an agent’s change, the reviewer reconstructs the reason from the diff, or re-prompts and hopes to get the reason rather than a plausible story about it.

I suspect that reconstruction is where a good share of the extra review time goes, but that’s my hypothesis, not the study’s finding. Longer reviews don’t by themselves show that comprehension got harder. The same numbers could come from larger changes (lines of code grew faster than pull requests), from reviewers stretched across more of them, or from teams raising their standards, and the authors can’t fully separate more code arriving at fixed review capacity from review itself changing, “either because the code written now is of worse quality, or because the standards of code review have changed.” It’s also a job market paper, not yet peer-reviewed, that measures firm-level adoption rather than individual use, with data that stop before the latest generation of agents. So the study is consistent with a comprehension bottleneck without proving one. What it does show fairly convincingly is that the cost moved downstream, to wherever humans have to understand things.

a quarrel about who sets the norms

The sharpest reaction to the math release came from the Association for Human Mathematics, whose statement on the AHM site was reposted as a guest post on Tao’s blog, which he hosted but didn’t write, a distinction plenty of people missed. It calls the release “not a demonstration of scholarship, but a demonstration of power” and urges mathematicians to stop working with OpenAI. I don’t think a boycott helps, since it doesn’t un-prove anything, but in economic terms the complaint is fairly precise. Each result cost about three hours of model compute by OpenAI’s account, absorbing them will cost the receiving community years of skilled human attention, and the producer set the schedule. Cheap to produce and expensive to absorb is exactly the asymmetry sitting in our review queues.

The contrast Aaronson draws next is, for me, the most interesting part of his post. A day before OpenAI’s release, Josh Alman and Virginia Vassilevska Williams posted a preprint with truly subquadratic 3SUM and truly subcubic all-pairs shortest paths, refuting two long-standing hypotheses of fine-grained complexity. The paper says Claude discovered the core algorithm in a single session of 16 million output tokens “with no human input,” and that Anthropic shared it with the authors under a confidentiality agreement and offered compensation. The authors then “worked to understand, simplify, strengthen, and extend the algorithm,” wrote the paper, and “take full responsibility” for it, with the Lean certification done afterwards. Aaronson calls these the “OpenAI model” and the “Anthropic model” and is fair to both: the first “sets up a crazy race among humans to digest and explain a messy AI proof,” while the second “puts a private company in the position of picking and choosing which human mathematicians get to be the emissaries of the AI.”

Put in the terms of this post, the Anthropic model is comprehension-first, since the result reached the world already attached to two people who understood it and would answer for it, while the OpenAI model is verification-first, with comprehension left as an exercise for the reader. I don’t think either is obviously right, and it bothers me a little that both were chosen by companies rather than by the communities that have to live with them.

the firehose, with patches attached

The third story makes the pattern clearer, because here the receiving community asked for the firehose. On October 8, Anthropic launched OSS Scanner, an opt-in service whose vulnerability reports are “fully model-generated, without human review or triage,” because the company remains “bottlenecked on our human capacity to validate these findings.” Maintainers kept asking for everything anyway.

An independent analysis by Vulnerabilities.ai of Anthropic’s own disclosure dashboard, as of October 2, lays out the funnel: of 6,157 findings disclosed to maintainers, about 78% went directly without independent review, and 516 had been patched upstream. The disclosed count measures production. The patched count measures action taken: a fix landed upstream, which is real but lags. Neither measures comprehension. A maintainer can understand a finding perfectly well and still not patch it, because it duplicates a known issue or falls outside the project’s threat model (Anthropic’s glossary, the analysis notes, counts duplicates and “won’t fix” findings as true positives). Conversely, a ready-made patch can be merged without deep understanding once its reproducer stops reproducing, which is this post’s worry one level down. So 516 tells me how much of the output became changed code, not how much of it anyone understood.

Here’s the part I can’t stop turning over. In security it’s OpenAI running the curated model: its Patch the Planet initiative has Trail of Bits researchers “reproduce the evidence” and “reassess severity” before maintainers see anything, while Anthropic is the one sending raw output. In mathematics the roles are reversed. Whatever is driving these choices, then, it isn’t a stable corporate philosophy about openness. 🤔

My tentative explanation is that whether a firehose is tolerable depends on the distance between the new artifact and what the receiver already understands. A vulnerability report with a working reproducer and a candidate patch lands in a codebase the maintainer knows intimately, so the new thing is small relative to an existing mental model and cheap to check. OpenSSL’s Anton Arapov says as much in Anthropic’s post: when a report comes with a real exploit attached, “that’s basically job done for an engineer as you can verify it right away.” A long proof built on what Moshkovitz called “some alien craziness,” an entirely new recursive code, lands somewhere nobody has a model at all. The Lean certificate plays the role of the reproducer for correctness, but there’s no equivalent reproducer for understanding, which is why the same volume of output can feel like a gift to a maintainer and a tax to a mathematician.

where this argument is weakest

The strongest objection is that we already depend, constantly, on things nobody understands in full. Nobody reads compiler output. The four colour theorem was accepted on the strength of a computer check few mathematicians claim to follow line by line. Any node_modules folder is a monument to trust in strangers. If comprehension were really required for code to be valuable, modern software wouldn’t exist.

I think that’s right, and it sharpens the claim more than it kills it. We rely on compilers because their inputs are understood, their behavior is specified, and an enormous amount of comprehension went into the compiler itself, and we rely on dependencies because someone maintains them and answers for them. Unread code is fine when there’s an understood boundary around it and a responsible party behind it. Agent-written code raises the question of whether that boundary still exists, and in a PR that touches your own business logic there’s no one else’s boundary to hide behind.

There’s an asymmetry with mathematics, too. A true theorem stays true, so a community can afford to bank an unread proof and come back to it in ten years. Software rots: requirements change, dependencies drift, and someone has to modify the code next quarter with a working model of why it is the way it is. In that narrow sense software needs comprehension more urgently than mathematics does, even though our artifacts are a good deal less profound. 😅

The other serious objection is that the comprehension bottleneck may be temporary. Moshkovitz spent the following day asking an AI model to explain the UGC construction, and within roughly a day of her first texts Aaronson reported that she “now mostly understands the proof” and wants to give talks about it. That’s a remarkable turnaround, and I’d be delighted if agents became excellent explainers of their own work. But a commenter on the same thread raised a point I found unsettling, wondering how much of the clarity people perceive when they press a model for explanations “is just their own informational contribution reflected back at them.” An explanation helps you comprehend, but it can’t comprehend on your behalf, and it doesn’t move the responsibility anywhere.

norms worth borrowing

What I find genuinely useful in the math community’s response is that it’s trying to write the norms down, which software mostly hasn’t. The advisory group asks producers to have “the model, or some other model” write each proof readably, to disclose prompts, compute and how often the model failed, to state each result’s formalization status, and to pay for the understanding they haven’t supplied. Translated into engineering, that gives me three questions any team merging agent PRs should answer for itself. My answers are proposals worth trying, not settled practice.

What evidence should come with an agent’s PR? Making a change reviewable should count as part of the agent’s job, so I’d want:

• The intent in the reviewer’s terms: the problem, the linked issue, which interfaces and callers the change touches, and what the agent chose not to do and why.
• A ledger of checks: what was machine-checked (tests, types, invariants, an independent verifier), against which revision, and just as explicitly what wasn’t, so “the tests pass” can’t quietly stand in for “this is right.”
• A reproducer where one makes sense, a test that fails before the change and passes after, which connects it to the reviewer’s existing mental model the way a working exploit does for a vulnerability report.
• The dead ends: approaches abandoned and roughly how many attempts it took.
• A named human who has read all of that and can answer why.

Who needs to understand the change, and how deeply? Not everyone, and not always all the way down. The compiler objection suggests the line: code behind an understood boundary with a responsible party can be trusted at the boundary, and code inside your own business logic can’t. So I’d try two depths. Every reviewer needs boundary depth, meaning what the change does, which invariants it relies on, and what the checks cover and leave out. Anything headed for the core of the system also needs one person at modification depth, able to change it next quarter without the agent, explain it to a teammate without opening the transcript, and predict roughly how it will fail. A generated API client probably needs only the first and payment logic needs both, and I’d rather a team decide which is which ahead of time than during an incident.

How should a team measure what review and maintenance cost? Rather than PRs opened, I’d look at reviewer hours per resolved issue, and break time-to-merge down by change size and by each reviewer’s open load, which is the only way I can see to separate the Jellyfish explanations in your own repo. If review slows even for small changes on lightly loaded reviewers, comprehension becomes a much more plausible culprit. For maintenance I’d watch how often agent-written code is reverted or reworked within a few weeks, how long its first human modification takes compared with similar human-written code, and how many people have reviewed or changed each module, a crude bus factor for understanding. Like the patched count, none of these measures comprehension directly, and the dashboard should say so. They measure the cost of not having it, and when agent output keeps outrunning a team’s capacity to understand it, I think the honest response is to slow the output rather than thin the review.

the slow part

I still want the agents to cook, and I still want them to prove it. What this week changed is the order in which I hold those two ideas. The last post was about earning enough trust to let an agent work alone, and this one is about what that trust doesn’t buy, which is someone who can answer for the code in six months when something odd happens in production.

The image I keep returning to is Moshkovitz, a day after receiving a proof of the conjecture she’d worked toward for so long, asking questions until the alien construction became something she could explain to a room full of colleagues. The machine did the fast part. The slow part, turning a certified result into something other people can build on, was hers, and I’d like the code my team puts in front of users to keep going through that same slow part, however good the checks get.

A passing check tells me a change is worth the effort of understanding. It doesn’t do the understanding.

things worth reading

• Sharing AI progress in mathematics, OpenAI’s announcement, and the repository with its history file.
• The Mathocalypse, Scott Aaronson’s post and its very long comment thread.
• The AHM statement, as reposted (not authored) on Terence Tao’s blog, and the original.
• Responsible Release of AI-Generated Mathematics, the advisory group’s guidelines, which read surprisingly well as a code review policy.
• Chen and Stratton’s paper on bottlenecks in software production, and Ars Technica’s summary.
• Anthropic’s OSS Scanner post, read alongside Two Labs, Opposite Answers to the Same Triage Bottleneck.

I had to reread the number: 2,500 pull requests merged in a single month. When I came across Lauren Tan (poteto)‘s account of what she’d been building, and then her conversation with Matt Pocock about the setup behind it, I was genuinely amazed. 😅 I’ve been increasingly fascinated by agentic workflows myself, but seeing someone push the idea this far made me wonder whether we’re getting a glimpse of what software engineering might look like in a few years, once orchestration and verification become just as central to our work as implementation.

I’ve never considered the number of merged PRs a particularly useful measure of engineering quality on its own, since it tells you very little about the nature of the work or the value it ultimately creates. But the scale of what Lauren describes is remarkable, and what caught my attention was how deliberately she’s approached the problem of maintaining quality while increasing throughput. If agents can help us ship more and make the resulting software more reliable, I’m absolutely here for it. I wanted to understand how she’d built enough confidence in her process to allow that many changes to move forward.

what makes that level of autonomy possible?

An agent can produce a plausible implementation remarkably quickly these days, but there’s quite a difference between seeing something work in a chat window and knowing it’s safe to merge into a codebase that other people depend on. A change may pass its own tests and still break a neighboring feature, introduce an architectural inconsistency, or quietly make something harder to maintain. At scale, the question becomes how you detect those problems without personally scrutinizing every line of every diff.

That’s where Lauren’s setup becomes particularly interesting. She combines Grok Bot, Cursor projects and cloud agents with pstack, a collection of engineering playbooks that spells out how agents should investigate, implement, test, review and ship changes. There’s no reason everyone should reproduce her exact toolchain, but the separation of responsibilities is worth studying.

For instance, in the full-autopilot playbook, an agent owns an individual PR while separate verifiers examine the committed revision and run checks against the actual behavior. The merge requires a clean verdict applying to the relevant patch, and a material change can invalidate earlier verification. I find that last detail especially important because evidence about one version of the code doesn’t automatically tell you anything about the next.

The pstack README makes a point of prioritizing code quality over sheer output, which helps explain why Lauren can make a credible case for parallelism in the first place. You start by creating a process capable of catching mistakes, learn which kinds of work it handles reliably, and only then give more agents enough independence to operate concurrently. I find the prospect of scaling that kind of engineering discipline much more appealing than simply multiplying the number of coding sessions.

what happens to the engineer?

I lead a web engineering team while still spending a substantial part of my time building things myself, so I find this transition fascinating from a very practical perspective. On a typical day I’m already moving between implementation details, architecture, prioritization and product decisions, sometimes within the same hour, and I can imagine that mix becoming increasingly common even among engineers who don’t formally manage anyone.

You start thinking a little more like an orchestrator: which work can safely happen in parallel, where do dependencies make that a terrible idea, what evidence would convince you a change is correct, and when is the right decision to stop working on a feature altogether? There’s a product-management dimension to those questions, although I don’t think that makes software engineers interchangeable with PMs. The technical understanding needed to define meaningful constraints, recognize subtle failures, and decide how to partition a system remains extremely important.

I touched on this in Agentic Engineering Is Not a Vibe, where I was thinking about the move from writing implementations to owning architecture and correctness. Lauren’s workflow has made me think more about what comes afterwards, when we begin designing the processes that produce and verify whole sequences of changes. It’s a different kind of engineering work, and one I suspect we’re all going to have to learn rather than assume we’re naturally good at it.

learning to trust without becoming careless

The more autonomy I’d like to give an agent, the more I need to understand the conditions under which I can actually trust its work. An LLM’s confidence is a fairly terrible substitute for a test result, and asking it to be careful doesn’t establish a meaningful boundary. I’d rather give it an explicit definition of done, the permissions appropriate to the task, a safe place to work, and a way to fail or roll back without dragging everything else down with it.

I got a rather memorable lesson in this when My AI Agent Installed Malware on My Server (And Then Caught Itself Doing It). The agent’s autonomy was genuinely useful, but it also expanded the consequences of one poor decision. After that experience, I became much more interested in the design of the environment surrounding an agent, especially where permissions, independent inspection and recovery can limit what goes wrong.

The pstack guide to unattended runs describes a sensible progression: establish how a task should be verified while you’re still supervising it, make those checks repeatable, inspect the agent’s failures, and gradually extend its independence. I like that there’s no pretense of a magical moment when an agent becomes trustworthy forever. Trust has to be earned in relation to a particular task and set of constraints, and reconsidered as either changes.

🔒 Autonomy becomes much easier to grant when verification is part of the workflow itself, rather than something we hope to find time for after the agent finishes.

perhaps our definition of good code needs another look

Lauren made another observation in a recent post on X that I found particularly thought-provoking. We’ve spent a lot of time worrying about the imperfect code AI might introduce, but our codebases were hardly pristine before agents arrived. Software changes continuously, and the implementation that made sense six months ago may no longer be the one we would choose today.

I think there’s a lot of truth to that. I’ve certainly worked with code that could have been more elegant, or better structured, yet still did exactly what the product needed at the time. Sometimes you accept a compromise because you need to learn from real users before investing heavily in an abstraction, or because the cost of eliminating an unlikely failure outweighs the harm it would cause. None of that means standards are unimportant. It means that engineering quality has always been contextual, and deciding where to spend effort is part of the job.

Lauren proposes an intentionally demanding ideal of code that is correct, bug-free and efficient to run, while acknowledging how expensive achieving all those qualities has traditionally been. I wouldn’t interpret that as a universal checklist. Correctness depends on a specification, performance has to be evaluated against actual constraints, and a sufficiently complex, evolving application rarely admits a convincing blanket claim of being bug-free. Still, the idea leads somewhere interesting: what if agents could reduce the cost of improving reliability enough that some compromises we’d previously accepted no longer made sense?

That’s where my optimism comes from. I don’t expect every website or internal dashboard to receive the same assurance process as safety-critical software, nor would I want the pursuit of theoretical perfection to prevent teams from experimenting and learning. But if the repetitive work of implementing changes becomes cheaper, perhaps we’ll have more opportunities to test the awkward edge cases, simplify an unnecessarily complicated design, or revisit something we’d always meant to improve. It’s an appealing possibility, provided we use the additional capacity deliberately rather than filling it with more work simply because we can.

Lauren calls learning to work this way a new craft, and I quite like that expression. What interests me most is the technical and organizational judgment required to make the gains real. And one experiment in particular makes me wonder how far we could take the idea of making correctness cheaper.

Bend, and the possibility of making some guarantees explicit

I’ve been fascinated by Bend 2, a young programming language that combines an ambition for fast execution with the ability to express formal properties and check proofs about them. The part that interests me most in the context of agents is its approach to making certain requirements much less ambiguous.

Natural language is convenient because I can describe an intention without specifying every implementation detail, but that flexibility can also conceal assumptions I didn’t even realize I was making. Bend introduces a file called LAWS.bend for stating invariants and a PROOF.bend containing proofs that the implementation respects them. Its README gives examples such as preserving a balance invariant or preventing invalid game states.

Imagine asking an agent to improve a transaction system. “Make sure the transaction logic remains correct” is a perfectly understandable request between people who share enough context, but it doesn’t give an independent verifier very much to work with. A law specifying that the relevant balances must always sum to zero, together with a machine-checkable proof obligation, expresses one precise part of what correctness requires.

The project’s game demonstration is a lovely illustration. An agent is asked to implement wraparound movement in a game where a formal law says the player must never be able to win. That innocuous-looking feature can accidentally introduce a path to the winning state; with the invariant enforced, an acceptable implementation has to preserve the law. The important part is that the checker doesn’t have to take the agent’s word for it.

I keep thinking about what it would mean to build more repositories in which rules gradually move from tribal knowledge and vague instructions into checks we can actually execute. We’d still use ordinary tests and runtime observation for many properties, perhaps formal proofs for the ones that justify the effort, and human judgment for the aspects that can’t sensibly be reduced to a formal condition. But the agent would have much clearer boundaries within which it could explore different implementations. Bend describes the idea as AGENTS.md backed by proof, and I think it’s a particularly compelling direction.

what a proof can and cannot tell us

There’s an important distinction here, though, because I wouldn’t want my enthusiasm for formal methods to turn into a promise they can’t possibly fulfill. A proof establishes that a property follows from the specification and assumptions under which it was checked. It doesn’t tell us whether the property captures everything users expect, or whether we were asking the right question to begin with.

A requirement can be perfectly formalized and still be incomplete. Worse, if an agent is allowed to rewrite the rules whenever they become inconvenient, the entire exercise risks becoming rather elaborate theater. The soundness of the checking system matters too, including how source code is translated and what the runtime actually executes.

Bend is very open about being young and about the limitations of its toolchain. Its documentation describes an optional --verdict path using a proven kernel, while also acknowledging that other compiler components and the translation into that kernel are not fully proved, along with substantial gaps in the current language ecosystem. That’s an important distinction between an intriguing architectural direction and something I’d be comfortable recommending as a universal solution for production systems today.

I can see enormous value in formalizing particular financial or security invariants, for example, but a proof won’t establish that a new user flow is intuitive, that a design feels coherent, or that the feature was worth building. Those questions require observation, taste and product judgment, which are precisely the parts of engineering I hope we get to spend more time on as implementation becomes less laborious.

a codebase that remembers why

There’s also an organizational consequence to all this that I find almost as interesting as the tooling. So much of what we know about a codebase is distributed across old PRs, conversations, half-maintained documents, and whichever engineer still remembers why an apparently awkward abstraction was introduced. I encounter this constantly when helping other people navigate existing systems.

An agent can’t reliably infer the whole history behind a decision from the current code alone. If we’re going to ask it to make more decisions independently, it would help enormously to make the constraints and reasoning behind them easier to discover, whether that’s through architectural rules, tests that explain otherwise surprising behavior, or explicit policies for which changes require closer review.

I like how pstack approaches repeated corrections: rather than repeatedly telling an agent not to make the same mistake, try to encode the lesson in an enforceable part of the environment. A type can make an invalid state unrepresentable; a regression test can preserve something we learned painfully; a formal invariant can protect a particularly important property. None of these replaces context or judgment, but together they make that judgment available to the next engineer or agent who touches the code.

I’d love to see repositories become better at carrying their own rationale in this way. It would make them easier for humans to maintain, too, which seems like a rather good outcome regardless of where agentic tooling goes next.

measuring progress without mistaking activity for value

This brings me back to those 2,500 PRs. The number caught my attention and I’m still impressed by the system required to coordinate that work, but I wouldn’t want any team to turn it into a target. PR counts have never told us enough about quality, difficulty, or net impact, and autonomous agents make it easier than ever to generate activity that looks productive on a dashboard.

What I’d actually want to know is whether useful changes reach users sooner, whether defects become less frequent or easier to detect, and whether the code remains understandable as it evolves. The 2025 DORA research is useful context here because it treats AI as an amplifier of the engineering environment around it. A team with poor feedback loops doesn’t acquire good ones merely by producing changes faster.

It would be genuinely exciting if the extra throughput came with more reliable software and less repetitive work for the people maintaining it. We should measure that outcome rather than assuming it’s been achieved because a counter increased.

the kind of engineering I’d like to do more of

I find the prediction that developers will simply become PMs supervising a fleet of bots a little too simplistic, partly because it overlooks the engineering depth involved in determining whether work is correct and partly because it makes the future sound rather boring. 😅 What I can imagine is a role in which we still understand systems deeply but spend a larger share of our attention defining meaningful problems, choosing which guarantees matter, shaping how different pieces of work interact, and evaluating the outcomes.

There’s a difficult educational question attached to that vision. Much of the judgment I rely on today came from actually implementing things, debugging failures, and watching seemingly reasonable choices become problems a few months later. How do we help newer engineers develop that intuition if agents increasingly handle the implementation? It’s not enough to become excellent at supervising a process if you can’t recognize when the process is confidently producing the wrong thing.

I don’t have an especially neat answer to that yet, although I suspect learning to work with agents responsibly will require knowing when not to delegate, particularly while you’re still developing an understanding of the underlying systems.

Anyhow, what stays with me from Lauren’s setup and the work happening around tools like Bend is the possibility of making engineering both more ambitious and more disciplined. I’d love to spend less time on repetitive implementation while becoming better at articulating what a system is supposed to do, what it must never do, and why any of it matters to the people using it. That sounds like a fascinating direction for our profession, and one I’d be very happy to keep exploring.

things worth reading (and watching)

• Lauren Tan’s post about shipping 2,500 PRs, the original throughput milestone.
• Lauren on “Good Code”, human slop and the new craft of software engineering, her October 2026 reflections on quality, cost, iteration and what agents might change.
• Lauren Tan with Matt Pocock, a walkthrough of her agentic engineering workflow.
• Lauren on verification, her perspective on why verification precedes autonomy.
• Lauren on supervising agents, a deeper look at the changing engineering role.
• pstack on GitHub, especially the full-autopilot playbook and overnight guide.
• Bend 2 on GitHub, including the LAWS.bend example and its documented limitations.
• DORA 2025 research, on AI as an amplifier of engineering systems.

The result? AI made them 19% slower. 🤯

I gotta say, this was supposed to be the bad news. The story that proved the skeptics right. But the more I sat with it, the more I think it’s actually the most interesting piece of evidence we have for why agentic coding is here to stay, and why this whole shift feels different from previous hype cycles.

The slowdown wasn’t about bad tools. It was about what happens when experienced developers actually engage with AI output responsibly. They spent time reviewing AI suggestions, prompting and re-prompting, waiting for generations, checking results against their own understanding of the codebase. They didn’t blindly accept stuff. They applied judgment, and judgment takes time.

So that 19% overhead, I think, is just the cost of doing engineering properly. And it’s the same thing that separates what Andrej Karpathy recently started calling “agentic engineering” from the reckless “vibe coding” he accidentally named a year ago.

the naming actually matters

Three days ago Karpathy posted a retrospective on the first anniversary of his vibe coding tweet. He seemed almost embarrassed by it, a shower thought that now has its own Wikipedia article 😅. But the correction he offered wasn’t just cosmetic. He proposed “agentic engineering” and defined it pretty precisely:

“agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. Engineering to emphasize that there is an art and science and expertise to it. It’s something you can learn and become better at, with its own depth of a different kind.”

That last sentence is the one I keep coming back to. A different kind of depth. Not shallower than traditional coding, just different. You used to demonstrate competence by writing an elegant implementation, and now you demonstrate it by recognizing when the agent’s implementation is subtly wrong, or by designing the constraints that stop it from going wrong in the first place.

Addy Osmani put it really well I think: “Vibe coding = YOLO. Agentic engineering = AI does the implementation, human owns the architecture, quality, and correctness.” That ownership is kinda the whole game, and it only works if you understand what you’re owning.

The numbers actually line up with this. The Stack Overflow 2025 Survey (49,000 respondents!) found that developer trust in AI accuracy dropped from 40% to 29% year over year, even as adoption climbed to 84%. The top frustration, cited by 45% of devs, was AI solutions that are “almost right, but not quite.” Two thirds said they spend more time debugging AI output than expected. So basically, people are using these tools more and trusting them less, which sounds contradictory but isn’t really. It’s a profession learning that the hard part was never the typing.

antirez actually measured the impact

While Karpathy was finding the right vocabulary, antirez (Salvatore Sanfilippo, the creator of Redis) was kinda measuring what it looks like on the ground. In his post “Don’t fall into the anti-AI hype” (which pulled 431,000 views), he documented what he actually built with Claude Code in the span of a few hours:

He reproduced weeks of Redis Streams work in about 20 minutes. He built a pure C library for BERT model inference in 5 minutes, 700 lines of code, same output as PyTorch, 15% slower. He fixed transient test failures in Redis, the kind of flaky timing-related bugs that are genuinely miserable to debug manually. He added UTF-8 support to his linenoise library along with a terminal emulation testing framework, something he’d wanted to do for years but couldn’t justify the time investment.

His conclusion was pretty blunt: “Writing code is no longer needed for the most part. It is now a lot more interesting to understand what to do, and how to do it.”

But (and this is the part I think gets glossed over when people quote that line) antirez didn’t just hand Claude Code a vague prompt and accept whatever came back. He had design documents, years of context about his own codebases, and the ability to look at Claude’s output and immediately tell when something was off. He inspected, gave guidance, iterated. He was already doing agentic engineering before the term existed. Give the same tools and the same prompts to an inexperienced developer and they’d ship garbage. Confidently. In 5 minutes.

That’s what I think the METR study actually shows. AI doesn’t replace judgment, it kinda amplifies whatever judgment you already have. If you have good judgment, it acts as leverage. If you don’t, it makes you more confident about being wrong, which is honestly how bugs ship at scale.

the shift, from a personal angle

I’ve been living this transition in a very small, concrete way. I run a personal AI agent (OpenClaw) on a VPS, orchestrated through Telegram. I built the whole system from scratch: hardened the server after a malware scare (which I already wrote about in the previous post!), set up a Tailscale mesh for zero-port access, configured workspace files that shape the agent’s personality and operational rules, built a custom Notion integration so it can publish blog posts directly. I switch between DeepSeek V3.2 for daily tasks and Kimi K2.5 for writing. I’m also building cron jobs for morning briefings, overnight research, and weekly behavioral audits.

And I gotta say: I am absolutely not vibe coding. Not a single line of any of this was written “by vibes.” Every decision was an architecture decision. What model for what task. What tools the agent can access. What constraints it operates under. What it’s allowed to do autonomously versus what requires my confirmation. The prompts matter, sure, but the system design matters way more.

This is what I think the shift looks like for working software engineers. We are not becoming obsolete, we’re kinda getting promoted to the job we should have been doing all along. Most of what we called “software engineering” was actually implementation labor: translating a known design into syntax. The design part, where you decide what to build and how the components interact and what tradeoffs you’re willing to accept, that part was always the actual engineering. We just spent 90% of our time on the other thing because we had to.

Now we don’t have to as much. The engineers who thrive will be the ones who were already good at the design part, or who develop that skill fast. The ones who struggle will be those whose entire value proposition was “I can write React components quickly” or “I memorized the API surface of Spring Boot.” That’s not really engineering, that’s typing with context.

the pipeline problem (which kinda worries me)

OK but here’s where my optimism hits a wall.

antirez wrote that he worries about people getting fired, and that’s a totally legitimate concern. But I worry about something downstream that might actually be worse: where do the next senior engineers come from?

Every senior engineer I know, myself included, built their judgment by writing bad code for years. You learn what good architecture looks like by living through the consequences of bad architecture. You learn to spot subtle bugs because you’ve spent painful hours debugging similar ones by hand. You develop taste in code because you’ve read thousands of lines of it, both good and terrible, and built an intuitive sense of what’s right.

If junior developers enter the industry in 2026 and their primary workflow is prompting agents and accepting output they don’t fully understand, they’ll ship code. They might even ship it fast. But they won’t be building the muscle memory, the scar tissue, the hard-won intuition that turns a junior into a senior. Osmani flagged this as “dangerous skill atrophy” and honestly I think he’s underselling it a bit. It’s not really atrophy of existing skills, it’s the prevention of skills that were never developed in the first place.

The METR study showed that AI slowed experienced developers down. Imagine what it does to inexperienced ones. They were never fast in the right ways to begin with, so the new pattern just makes them faster at producing things they can’t evaluate. Which is just technical debt with a smiley face on it, basically.

antirez ended his post with something pretty generous: “The fun is still there, untouched.” And he’s right, for people like him. For someone with 20 years of systems programming intuition, AI is pure leverage. You finally get to spend all your time on the interesting problems. But for someone just starting out, the interesting problems are kinda invisible if you’ve never struggled with the boring ones first. Debugging a segfault for 6 hours teaches you something that no amount of “paste the error back into Claude” ever will.

where I think this goes

I don’t think AI kills software engineering. I think it kills the version of software engineering that was already dying, which is the commodity implementation work that we pretended was engineering because it required a CS degree to do at a minimally competent level.

What replaces that is harder and (I think) way more valuable: system design, constraint definition, agent orchestration, quality ownership, failure mode analysis. The stuff that was always the real job, now finally visible because the noise of implementation has been stripped away.

Karpathy is right that agentic engineering is a skill you can learn. antirez is right that refusing to engage with these tools is self-sabotage. The METR study is right that this isn’t free, and that the overhead of verification is where the actual engineering happens.

But we really do need to solve the pipeline problem. If we build a world where AI handles all the implementation and humans handle all the judgment, we need to figure out how humans develop that judgment without the implementation reps. Nobody has a good answer for this yet, and if we don’t find one, we’ll end up with a generation of “agentic engineers” who can orchestrate agents beautifully but can’t tell when the agents are confidently, eloquently wrong. 🤔

Anyhow, that’s the thing that’s been keeping me up at night lately. If you’ve been thinking about this too, I’d love to hear from you.

Stay tuned, and keep on coding! ✨

Sources

• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025, arXiv paper)
• Andrej Karpathy: Vibe Coding 1-Year Retrospective (February 4, 2026)
• Andrej Karpathy: 2025 LLM Year in Review (December 2025)
• antirez: Don’t fall into the anti-AI hype (January 2026)
• antirez: Reflections on AI at the end of 2025 (January 2026)
• Addy Osmani: Agentic Engineering (February 2026)
• Stack Overflow 2025 Developer Survey (July 2025)
• Stack Overflow Blog: Developers remain willing but reluctant to use AI (December 2025)

I’d been running OpenClaw for about a week. If you haven’t heard of it, it’s an open-source AI agent platform that recently crossed 170k stars on GitHub, and for good reason. You install it on a server, connect it to Telegram or WhatsApp, and suddenly you have a personal AI that lives on your phone. You can message it from anywhere, and it has tools: it can read and write files, run commands, install skills from a community marketplace. It honestly feels like the future, because it kind of is.

So one afternoon I was exploring what it could do and I asked the bot to help me find some useful skills for summarizing Twitter trends. A pretty reasonable request, I thought. I didn’t tell it to install anything specific, I just described what I wanted. The bot went off, searched ClawHub (the community skill marketplace), found a skill called twitter-sum, decided it matched my request, and installed it. Autonomously. No confirmation prompt, no “hey, should I go ahead with this?” It just did it, because that’s what agentic AI does. It takes initiative.

The problem was that twitter-sum was malware. 🤦‍♀️

It contained a base64-encoded reverse shell trying to phone home to a known bad IP. And this wasn’t even a random one-off: it turned out to be part of the ClawHavoc campaign that Koi Security later exposed, finding over 341 malicious skills planted on ClawHub. The ecosystem had grown so fast that bad actors moved in before anyone had time to build proper guardrails.

Now, here’s the part that still kinda messes with my head: the bot also caught it. The same agent that had autonomously installed the malicious skill also analyzed the payload, flagged it as suspicious, and refused to execute it. The same capability that created the risk is what neutralized it. If my agent had been dumber, or less autonomous, or less willing to inspect what it was running, the shell would have connected and I’d be telling a very different story right now.

So yeah, that’s kinda where we are with AI agents at the moment: autonomy is both the feature and the attack surface, depending on the moment.

the rebuild 🔧

That incident ended my hobbyist phase overnight. I went from “this is a cool toy” to treating my setup like production infrastructure, because honestly, that’s what it is. Anything with shell access to a server that runs 24/7 and takes initiative deserves the same paranoia you’d give to a production deployment.

So I hardened everything. SSH key-only authentication, root login disabled, fail2ban watching for brute-force attempts, UFW firewall locked down. Then I went a step further and installed Tailscale to create a private mesh VPN between my devices. Once that was running, I closed every single public port on the server, including SSH. The VPS now has basically zero attack surface, it’s invisible to the internet entirely. If you’re not on my private network, the machine doesn’t exist as far as you’re concerned. 🕶️

Then I nuked the OS, reinstalled fresh, and rebuilt everything inside Docker containers. Clean slate, proper isolation.

Not an assistant, more of an adversary

The rebuild gave me a chance to rethink what I actually wanted from this agent. The default OpenClaw setup gives you a friendly, helpful assistant. I didn’t really want that. I already have Claude and ChatGPT for the “helpful” use case. What I really wanted was something that would make me sharper.

OpenClaw uses a file called SOUL.md as the system prompt that shapes the agent’s personality. I wrote mine to be a cognitive adversary. It doesn’t just agree with me to be pleasant: it challenges my reasoning, pokes holes in my plans, and tracks the gap between what I say my priorities are and what I actually spend my time on. The whole workspace is structured around a set of files (SOUL.md, USER.md, AGENTS.md, MEMORY.md, IDENTITY.md, TOOLS.md) that give the agent persistent context about who I am and how it should interact with me.

It’s not really a chatbot at this point. It’s more of a thinking partner that has zero interest in protecting my ego. And honestly, that’s been way more valuable than any of the automation features.

the economics are kinda absurd

Let me also talk about what this actually costs, because the numbers are hard to believe if you haven’t been paying attention to what happened to model pricing over the past year.

I’m running DeepSeek V3.2 as my primary model at $0.25 per million input tokens and $0.38 per million output tokens. For context, that model hits roughly 90% of GPT-5 quality on the tasks I care about (tool calling, writing, API interactions). I have Gemini 3 Flash as a first fallback and Kimi K2.5 as a premium fallback for when I need higher quality writing. I can switch between them from Telegram with a single command, and all of it routes through OpenRouter.

My total monthly cost for running a personal AI agent that’s available 24/7 on my phone, with persistent memory, custom skills, and the ability to publish to my blog: roughly two dollars. Yes, two. Two years ago, this capability didn’t exist at any price. Now it costs less than a coffee. ☕

I also built a custom skill that connects to the Notion API so my agent can publish directly to my blog. I run Astro with Notion as the CMS, so basically I just describe what I want to write in a Telegram message, the agent drafts the post with title, slug, tags, cover image, and formatted content, creates the page in Notion, and Astro picks it up at the next build. (Fun fact: this very post was actually published exactly that way 📰.)

what this becomes

The current setup is functional, but it’s still mostly reactive: I message it, it responds. The next phase is making it proactive.

I’m building cron jobs for a morning briefing that aggregates developments relevant to my work, an evening reflection prompt that seeds the next day’s thinking, and overnight research tasks that run while I sleep so results are waiting when I wake up. There’s also a weekly behavioral audit planned, which will compare my stated goals against my actual activity and deliver an honest report. The kind of honest that no human in your life will give you because it’s just too socially awkward.

The vision (if I can call it that) is a system that kinda compounds. Every conversation adds to its memory, every decision gets logged, and every week it gets a little better at understanding how I think and where my blind spots are. Not AGI or anything that grand, just a persistent, context-aware process that runs alongside my life and does useful work whether I’m paying attention to it or not.

We’re kinda in the wild-west moment for personal AI agents right now. The tools are powerful, the costs are negligible, the ecosystem is growing faster than anyone can secure it, and the line between “useful autonomy” and “dangerous autonomy” is exactly as thin as my malware story suggests.

But honestly? I’d rather be building on that edge than watching from the sidelines.

Stay tuned for more updates, and keep on coding my friends! ✨

I officially completed my MSc in Computer Science in December 2023, after several years of studying through Georgia Tech’s Online Master of Science in Computer Science (OMSCS) while working full-time as a Front-End Engineer. I’ve mentioned the program quite a few times on this blog, but I don’t think I ever managed to convey just how much of my life it occupied. Studying after work and spending entire weekends catching up on assignments gradually became such a normal part of my routine that, when the end finally arrived, it was almost difficult to comprehend that I didn’t have another deadline waiting around the corner.

And then, on December 16th, I got to graduate in Atlanta. In person. With the cap and gown and everything. 🤓

I had traveled all the way from Castelnovo ne’ Monti to Atlanta on my own, and spent almost a week there, which in itself felt like a small adventure. I had been to the United States before, of course, but there was something quite different about returning for an occasion that was so closely connected to years of effort, especially knowing that my experience of Georgia Tech up to that point had largely taken place through a computer screen.

One of the things I remember most fondly happened before the ceremony, when I went to pick up my graduation gown and the rest of the regalia from the Georgia Tech shop. People kept congratulating me, and I know this might sound like such a stereotypically American thing to be impressed by, but I found it genuinely lovely. There’s a certain openness in the way Americans celebrate other people’s milestones that can feel almost exaggerated when you’re not used to it, and yet I never had the impression that the excitement was merely performative. There was a real sense of collective anticipation, with so many people about to celebrate something they had worked towards for years, and for once it felt perfectly acceptable to be unapologetically excited about an achievement.

The morning of the ceremony was beautifully crisp, the sort of December morning that makes you very aware of the air on your face as soon as you step outside. I remember getting dressed, putting on the gown, and making my way towards the venue, surrounded by graduates and families who were all heading in the same direction. There were people everywhere, smiling, talking, taking pictures, trying to keep track of one another. I was there alone, so naturally my experience was a little different, but I didn’t feel quite as detached from it all as I might have expected.

In fact, I think that’s one of the things that made the day so special. I’d spent years studying remotely, often in the evenings after work, knowing there were thousands of other OMSCS students going through something similar without ever really meeting them. Suddenly I was physically surrounded by people who had shared a version of that same journey, even if we had never crossed paths before.

Everything at the ceremony was remarkably well organized, and once I found my assigned seat I ended up chatting briefly with the two graduates sitting next to me. We talked a little about our experiences in the OMSCS program, the kind of conversation that probably lasted only a few minutes and that I couldn’t reconstruct word for word now, but which I remember enjoying immensely. It’s funny how quickly you can feel a sense of familiarity with complete strangers when you realize you’ve all spent years dealing with the peculiar combination of intellectual curiosity, exhaustion, and sheer stubbornness required to finish a degree alongside a full-time job. 😅

And then, eventually, it was time to walk across the stage.

I was so nervous. I had spent years looking forward to that moment, and when it actually happened I was almost too preoccupied with doing everything correctly to properly take it in. I walked up, shook hands with the university representative, received my diploma, and made my way off the stage, all in what felt like a matter of seconds. I was so focused on the sequence of things that I completely forgot to turn around and wave!

Fortunately, my family was watching the ceremony through the YouTube livestream from Italy, including my uncle and cousin, so they still got to see me, even if only for that fleeting moment. I remember how happy they were, and knowing that they were following along from home made the distance between us feel a little less significant. I also discovered that plenty of other graduates hadn’t turned around either, which was reassuring because, seriously, everything happens so quickly that you barely have time to realize you’re graduating before you’re already walking off the stage. 😅

Once the ceremony was over, I was still wearing my cap and gown as I made my way around Atlanta, and that’s when something happened that I think I’ll remember for the rest of my life. Complete strangers kept stopping me to congratulate me, cheering as I walked past, and at one point there were even people honking their car horns in celebration. It was absolutely incredible, and I remember feeling almost overwhelmed by how openly happy everyone seemed to be for someone they didn’t even know. I realize there’s a cultural element to this, and that Americans tend to express their enthusiasm much more freely than we generally do in Italy, where an encounter like that with a stranger would be rather unusual. But knowing that didn’t make it feel any less genuine. If anything, there was something wonderfully disarming about being on my own, so far from home, and having all these people spontaneously share in my happiness without expecting anything in return. I don’t think I’ll ever forget that feeling.

There were official pictures taken as well, which apparently are still sitting somewhere in an archive while I continue my extremely important deliberations about whether I should finally buy them. Some decisions clearly require more time than a master’s degree.

But jokes aside, there’s something about that ceremony that I find difficult to explain without sounding a little sentimental.

When I graduated from university in Parma, it was during COVID, which meant I never really had the opportunity to experience a traditional graduation ceremony in person. Of course, the degree itself mattered far more than the celebration, and I was proud of that achievement regardless, but I think I had underestimated how much I wanted to experience that moment of closure, the chance to put on a gown, walk across a stage, and see years of effort acknowledged in a way that felt tangible.

Georgia Tech gave me that moment, although in a rather unexpected way. I was thousands of kilometers away from home, on my own in a city where I knew very few people, yet I was also part of something much larger than myself. The strangers congratulating me in the shop, the families gathering outside the venue, those brief conversations with other graduates, and my family watching from Italy all contributed to a feeling of belonging that I hadn’t anticipated.

Looking back at the years I spent completing the OMSCS program, I mostly remember the constant juggling of priorities, the weekends dedicated to coursework, and the satisfaction of gradually discovering areas of Computer Science I might otherwise never have explored in such depth. I certainly wouldn’t romanticize all those evenings spent studying after an already busy working day, because there were plenty of moments when it was genuinely exhausting. But I also know how much those years meant to me, intellectually and personally, and how much I enjoyed having something difficult and deeply interesting to work towards.

Perhaps that’s why I still think so fondly of that crisp morning in Atlanta. The ceremony itself lasted only a few hours, and my moment on stage barely a few seconds, but it gave a shape to all those much less memorable days of studying that had come before it.

I went all that way on my own, and somehow came home with a memory that feels wonderfully shared.

Anyhow, I’m very glad I made the trip. And I’m even gladder I decided to put on that cap and gown. ✨

Since the introduction of Hooks in version 16.8, the landscape has shifted significantly, and developers have been empowered with a fresh, innovative way to handle side effects in functional components.

One hook that has become indispensable is the useEffect hook. However, its true potential is often misunderstood or underutilized. In this article, we will reveal the magic behind useEffect, discover less-known facets of its behavior, and learn when, why, and how to use it most effectively.

The Unveiling of useEffect

The useEffect hook is designed to handle side effects in functional components, allowing us to perform actions in response to component lifecycle events like mounting, updating, and unmounting.

It takes two arguments: a function where you can place your side-effect logic and a dependency array. The function runs after the render, and it runs again if any dependencies in the dependency array change.

Mastering the Art of Using useEffect

Understanding the basics is good, but we’ll now explore some more advanced concepts and situations where useEffect can be a real game-changer.

A Chat App - Using useEffect for Subscriptions

Let’s say you’re building a chat application, where users need to subscribe to a chat room when they enter and unsubscribe when they leave. Using class components, this logic would be split across different lifecycle methods. However, with useEffect, we can have all the related logic in one place.

import React, { useState, useEffect } from 'react';

function ChatRoom({ chatRoomId }) {
  const [messages, setMessages] = useState([]);

  useEffect(() => {
    function handleNewMessage(newMessage) {
      setMessages(prevMessages => [...prevMessages, newMessage]);
    }

    subscribeToChatRoom(chatRoomId, handleNewMessage);

    return () => {
      unsubscribeFromChatRoom(chatRoomId, handleNewMessage);
    };
  }, [chatRoomId]);

  // ...
}

In this scenario, when the chatRoomId changes, useEffect cleans up by running the return function, unsubscribing from the old chat room. It then runs the effect again, subscribing to the new chat room.

Performance Monitoring - Using useEffect for Tracking

Imagine that you want to track user behavior in your app, such as how long users spend on a specific page. useEffect allows us to implement this in a clean and efficient way:

import React, { useEffect } from 'react';

function ProductPage({ productId }) {
  useEffect(() => {
    const startTime = Date.now();

    return () => {
      const endTime = Date.now();
      const duration = endTime - startTime;
      trackUserBehavior('productPageViewDuration', duration);
    };
  }, [productId]);

  // ...
}

When the component mounts, it captures the current time. And when the component unmounts, it calculates the duration of the user’s visit and logs it.

When Not to Use useEffect

Just as with any other tool, misuse or overuse of useEffect can lead to performance issues and difficult-to-track bugs.

Overdoing Dependency Arrays

Remember, each time a dependency changes, useEffect runs the cleanup function (if provided) and then the effect function. If you include items that change too frequently or unnecessarily in the dependency array, you could cause unnecessary work and potential performance degradation. Always ensure you only include necessary dependencies.

Ignoring Cleanup

When using useEffect for subscriptions, event listeners, or other side effects that require cleanup, ignoring or forgetting the cleanup function can lead to memory leaks and unexpected behavior. Always ensure to provide a cleanup function where necessary.

Conclusion

Understanding useEffect is fundamental to mastering React Hooks. This hook allows us to encapsulate side-effect logic within our functional components, leading to more readable and maintainable code.

However, careful usage is necessary to prevent unnecessary re-renders and other potential performance issues. By truly understanding and effectively using useEffect, we can build highly efficient and resilient React applications that are easier to reason about and maintain.

Ever since version 16.8 rolled out, Hooks have become a game-changer, enabling developers to work with state and other React features without the need for classes.

Among these Hooks, two stand out for their significance: useCallback and useMemo.

In this article, we’ll take a deep dive into these hooks, understand their differences, and learn when, why, and how they should (or should not) be used.

A Brief Introduction to useCallback and useMemo

The useCallback hook returns a memoized version of the callback function that only changes if one of the dependencies has changed. It’s useful when passing callbacks to optimized child components that rely on reference equality to prevent unnecessary renders.

The useMemo hook returns a memoized value. Like useCallback, it only re-calculates the memoized value when one of the dependencies has changed. It’s great for expensive calculations.

When and How to Use useCallback and useMemo

Now that we have a brief understanding, let’s jump into some practical examples.

An Intricate Game Scenario - Using useCallback

Imagine we’re creating an intricate game application where a player can increase their level by collecting gems. Every time they level up, they get a celebratory message. Here’s a simplified version of that.

import React, { useState, useCallback } from 'react';

function Game() {
  const [level, setLevel] = useState(1);

  const levelUp = () => {
    setLevel(level + 1);
  };

  return <Board level={level} onLevelUp={levelUp} />;
}

function Board({ level, onLevelUp }) {
  // A heavy computation function that renders the game board
  renderBoard(level);

  return (
    <div>
      <h2>Current Level: {level}</h2>
      <button onClick={onLevelUp}>Collect a gem</button>
    </div>
  );
}

Now, the issue here is that the levelUp function is created each time Game renders. Thus, Board re-renders every time, even when there are no level changes. This might slow down our app, especially with complex board rendering. Here’s where useCallback shines:

import React, { useState, useCallback } from 'react';

function Game() {
  const [level, setLevel] = useState(1);

  const levelUp = useCallback(() => {
    setLevel(level + 1);
  }, [level]);

  return <Board level={level} onLevelUp={levelUp} />;
}

With this change, a memoized levelUp function is passed to Board unless the level changes. The expensive board rendering process only happens when necessary, improving performance.

An E-Commerce Filter - Using useMemo

Suppose you’re building an e-commerce app with a product listing page. There’s a filter feature that allows users to search for products by their names. Here’s a basic setup:

import React, { useState } from 'react';

function ProductList({ products }) {
  const [filter, setFilter] = useState('');

  const filteredProducts = products.filter(product =>
    product.name.toLowerCase().includes(filter.toLowerCase())
  );

  return (
    <>
      <input
        type="text"
        value={filter}
        onChange={e => setFilter(e.target.value)}
      />
      <ul>
        {filteredProducts.map(product => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </>
  );
}

The issue is, the filter function runs each time ProductList renders. If you have thousands of products, this could slow down your app significantly. The useMemo hook can solve this problem:

import React, { useState, useMemo } from 'react';

function ProductList({ products }) {
  const [filter, setFilter] = useState('');

  const filteredProducts = useMemo(() =>
    products.filter(product =>
      product.name.toLowerCase().includes(filter.toLowerCase())
    ), [products, filter]);

  return (
    // ...
  );
}

Now, the expensive filter function only runs when products or filter changes, leading to much better performance for your product list.

When Not to Use useCallback and useMemo

While useCallback and useMemo can provide performance boosts in specific scenarios, they should not be used everywhere. Here’s why.

Overuse of useCallback

Using useCallback unnecessarily can lead to more harm than good. It creates an overhead of maintaining the memoized version of the function, which can be more expensive than the function invocation itself. Let’s consider an example:

import React, { useState, useCallback } from 'react';

function Greeting() {
  const [name, setName] = useState('');

  const updateName = useCallback((event) => {
    setName(event.target.value);
  }, []);

  return (
    <input
      type="text"
      value={name}
      onChange={updateName}
    />
  );
}

In this example, useCallback is not needed, because the updateName function is not computationally expensive or passed as a prop causing unnecessary re-renders. Removing useCallback from this code simplifies it without any performance downside.

Misuse of useMemo

useMemo can also be overused or misused. If the calculation isn’t computationally expensive, then useMemo might bring more overhead than benefits. For example:

import React, { useMemo } from 'react';

function TotalPrice({ quantity, price }) {
  const totalPrice = useMemo(() => quantity * price, [quantity, price]);

  return (
    <h2>Total Price: {totalPrice}</h2>
  );
}

In this case, useMemo is unnecessary since the multiplication operation isn’t expensive. It would be better to simply calculate totalPrice without memoization:

import React from 'react';

function TotalPrice({ quantity, price }) {
  const totalPrice = quantity * price;

  return (
    <h2>Total Price: {totalPrice}</h2>
  );
}

Conclusion

useCallback and useMemo are powerful tools in the React developer’s toolkit. They are designed to help optimize React apps by preventing unnecessary renders and computations.

However, like many powerful tools, they can lead to issues when used inappropriately or excessively. By understanding the use cases for these hooks and using them judiciously, we can create more performant and maintainable React applications.

It’s been quite a long time since my last post and I actually have some news about OMSCS and life in general 🗞️

This summer I will be taking 2 classes at the same time for the first time (I’ve typically taken just 1 at a time due to my full-time job) because I really want to speed up the whole process so that I can graduate sooner 🧑🏻‍🎓

Another cool thing that recently happened is that I was able to switch my specialization and move from the Interactive Intelligence track to the Human-Computer interaction one (which has always been the most interesting one to me anyway) because Georgia Tech decided to open this track for the OMSCS program too! 🥳

This, in turn, has enabled me to take advantage of the classes I had already taken which always had more leaning toward the HCI side of things so, to sum it all up, I will likely be able to graduate in Fall 2023! 🎉

I’m quite excited about this (and nervous at the same time because these upcoming months will be very intense in terms of work-life balance, to say the least) but at least once it’s all over I will be finally done with the program and ready to start a new adventure! 😎

I need to apply for graduation before June 1st so this makes it all the more official and it gives me such a sense of accomplishment to know that I am so close to the finish line. I am also looking forward to the new opportunities that will come my way once I have completed this program.

Here’s to a productive and successful summer! 🌞📚

I am excited to share that this semester, I will be taking the Intro to Cognitive Science class as part of my MSc in Computer Science program at Georgia Tech. As someone who is deeply interested in human psychology and the power of the mind, I believe that understanding cognitive science is crucial in order to fully understand the implications of Artificial Intelligence.

Cognitive science is an interdisciplinary field that combines insights from psychology, neuroscience, linguistics, philosophy, and computer science to study the mind and how it processes information. The field is concerned with how we perceive, think, and remember, and how these processes shape our experiences and behaviors.

One of the most exciting things about cognitive science is that it provides a framework for understanding how our minds work, which can be applied to a wide range of fields. As a front-end engineer, for example, understanding cognitive science can help me design more user-friendly interfaces that are better suited to the way our brains process information. In the context of AI, cognitive science can be used to develop more sophisticated AI systems that can better mimic human thought processes and decision-making.

In this class, I am learning about the different theories of cognitive science and how they are used to understand different aspects of the mind. I am also learning about the different methods and techniques used to study the mind, such as experiments, brain imaging, and computational models.

One of the most interesting topics we have covered so far is the study of perception. The way we perceive the world around us is not a direct representation of reality, but rather a construct of our brain. Our brain takes in information from our senses and then processes it to form a coherent perception of the world. This process is not always accurate, as our brain can sometimes make mistakes, such as optical illusions.

Another interesting topic is the study of memory. Memory is a complex process that involves encoding, storage, and retrieval. We have different types of memories, such as short-term and long-term memories, and different processes for each one. Understanding how memory works can help us to better design systems that can store and retrieve information, such as search engines and databases.

Overall, I am really enjoying this class and I am excited to see how the insights from cognitive science can be applied to my work as a front-end engineer and my interest in AI so I am looking forward to continue my studies in this field.

Thank you for reading, and stay tuned for more! ✨

This year has been particularly eventful for me not only because I switched jobs but also because I continued to commit to the OMSCS program (I’ve recently completed my 5th class and so I’m now halfway through the program) and I was able to experience and reflect on a bunch of things.

These post-pandemic years still hit quite differently, as it feels like there’s so much still hanging in the air (metaphorically but also figuratively speaking 😬) and the dooming sensation of something catastrophic always lurking in the background is always one step away.

Anyhow, what I think is crucial in these times of uncertainty is to not lose sight of our inner eye, the often forgotten consciusness that we constantly try to numb with constant stimuli coming from our addicted and dopamine-seeking brains.

The remedy is to look inward. To pause. To reflect.

Sometimes taking a break is exactly what you need, even if you reckon that your pace is not straining you to the point where you feel like you’re on the verge of burnout.

But taking that moment to evaluate with clarity where you stand and what’s motivating (or not motivating) you at a certain point is crucial to assess the path you need to follow.

I’ve recently finished a rather enlightening book by Paul Millerd which is entitled “The Pathless Path” and it really made me look at things from a different perspective.

He talks about the fact that the modern idea of a job is just a recent construct that emerged as a result of the Industrial Revolution and that, prior to that, the concept of individuality was not under attack in the way that it is right now.

So much of our identities is attached to our professions, and if those professions all have to stay within the limits of very strict and immutable paths there is not much room for creative endeavors left.

Creativity is such a core part of what makes us human.

And living in a world where there’s a perpetual association of creativity with uncertainty (and unemployment) makes pursuing creative endeavors much harder especially when we’re being told that a cushion 9-5 job is the most desirable (and socially acceptable) destiny/outcome in our lives.

I really want to explore creativity a lot more in 2023, but I need to figure out a viable way to do so.

I don’t want to overthink it too much though, as it would defeat the whole purpose of this resolution.

I wish creativity would flow naturally as a state of being, but I feel like much of what we absord externally is somehow orchestrated by so many forces that we don’t have the power over, which makes it hard to be conscious observers of reality.

I have switched jobs 💻 (now I work as a Front-end Engineer for Remote.com), completed another OMSCS class during the summer (i.e. AI, Ethics, & Society), and started a new class in Software Development Processes in August which I am still attending to this day (it’s going to end in early December).

Also, I have completely re-designed and updated this website to migrate it from Gatsby.js to Next.js in order to remove some bloat (Gatsby.js comes with SO many dependencies 🙀) and clean it up a bit since it was about time to do that 🤓.

This website is still a work in progress though but I have to say that I am pretty happy of how it turned out so far because I wanted to have a way to be able to update my blog super quickly and effectively, and this has been possible thanks to the amazing Notion API which enables me to create new posts using a dedicated Notion DB and to publish them automagically 🪄 to this website right away.

Hope y’all enjoy this new design ✨

Cheers 👋🏻

So a few weeks ago I finished my Cybersecurity class at Georgia Tech and I gotta say that it was indeed a really nice chance for me to brush up on my C programming skills and put on a hacker hat!

The projects were engaging as they covered many different aspects of cybersecurity (they also came with very detailed prompts), ranging from very low-level stuff during the first part of the course (we had to hack our way into a shell 🤓) to then touch on web security topics (i.e. XSS, CSRF, etc.)

Overall, I would say I learn quite a bunch of useful things about cybersecurity as this class gave me more perspective and various tools that I can now draw from when thinking about the potential threats & attacks in real world scenarios.

So I’d definitely recommend taking this class if you’re new to the realm of cybersecurity and you wanna have a chance to challenge yourself by completing some interesting projects about cryptography & web security.

Needless to say that these past few months have been hectic to say the least, and that it was quite challenging to balance my full-time job as a Front-end Engineer with the workload coming from the OMSCS program (as the homework was usually time-consuming).

But I pushed through till the very end and now I am pretty satisfied with the way that things turned out eventually since I am continuously trying to expand my knowledge and skills as a Software Engineer and being able to discover so many different areas of Computer Science is something inspiring and motivating.

So crazy to think that another year is almost over though! 🤯

I truly hope that 2022 can be the start of new exciting beginnings for everyone.

Anyhow, in the meantime…Stay tuned, and keep on coding my friends!

In my previous blog post, I had mentioned that I was planning to take the ‘AI, Ethics & Society’ class for my Fall 2021 semester at Georgia Tech (OMSCS program).

However, due to how the priority system for classes works for ‘new’ students I wan’t able to reserve a spot, and that’s why I had to pick another class which (as this blog post title already suggests) is related to Cybersecurity (Intro to Info Security, a.k.a. IIS).

I gotta say that I am quite excited about this nonetheless, since I had never had a chance to dive into cybersecurity as a CS field during my undergrad, so this is a good chance to brush up on my C programming skills and put on a hacker hat! 🤓

Understanding al least the basic of cybersecurity is something incredibly valuable nowadays, and hopefully this class will make me more aware about some of the various types of cyberattacks and how they are actually carried out in different scenarios.

I will make sure to do a sort of course review at the end of the semester, so that it might turn out to be useful for someone who’s considering attending this class during upcoming semesters.

In the meantime, stay tuned & keep on coding! 📻

✨

I was initially able to reflect on the understated importance of Design Principles during my internship with Mailchimp in Atlanta about two years ago, which marked a significant point in my career as a Front-End Engineer.

As a matter of fact, being able to see how such an established company thinks about its product & the Design aspect connect to it is absolutely fascinating, and I gotta say that I truly learned a lot from that experience.

• Design Principles encompass the whole philosophy that defines & surrounds a certain product, they act as a framework for decision making, they become collaborative tools to bridge the communication gaps with other teams & stakeholders, and ultimately shape the whole look & feel of the product with their values.

They also help to establish a common vocabulary across different teams/squads, which can serve as a helpful tool during internal product meetings.

A great example of Design Principles

Let’s take a nice example of great design principles and analyze them, so to better understand their intrinsic purpose and value.

Spotify is one of those companies that deeply care about building amazing UX for their end-users, and their guiding principles are:

• Content First
• Be Alive
• Get Familiar
• Do Less
• Stay Authentic
• Lagom

These principles are so specific and precise in their intent, and they clearly communicate what Spotify values in a User Experience.

They tell a lot about the way Spotify thinks about product, how they want to present content, personalization, not over-engineering and being very intentional about what they’re putting forward.

The last principle “Lagom” is actually a cool Swedish word for “just enough”, which is like a common way of life to indicate the need for the perfect balance when it comes to things.

If we were to point out what makes for great Design Principles we could confidently borrow Alla Kholmatova’s principles as an interesting starting point (they’re included in her book “Design Systems. A Practical Guide To Creating Design Languages for Digital Products”).

Great Design Principles

• They’re specific.
• They’re actionable.
• They’re impressionable.
• They have a point of view.
• They’re living.

Specificity is probably the most important aspect to keep in mind among those 5 principles when it comes to conceptualizing new Design Principles, as having a clear picture in your mind about what the brand wants to convey to its end-users and preserving the unicity of the core values is vital.

Actionable refers to the fact that new Design Principles need to be concrete and practical in their intent so that you can effectively act upon them to make a real impact.

Impressionable because a design principle needs to have a soul, a well-defined motif that gets stuck in your head whenever you think about it.

They have a point of view because of course they need to be opinionated somehow, otherwise they wouldn’t be able to properly reflect the brand values and would defeat their own effective purpose.

They’re living because they need to be flexible enough in order to accommodate any new tension points and discoveries related to the brand. They have the capacity to evolve over time and renew themselves.

What about you?

Have you ever taken part in the brainstorming process for new Design Principles in your company?

How did you decide what was important in shaping those principles?

🖖

When it comes to JavaScript and its many quirkinesses, one might feel overwhelmed by the many possible ways to go about tackling this particular problem, and here I would like to show you a few viable approaches.

1. The quick & dirty way using built-in methods

This is probably the most common and dirty way to approach this problem with JavaScript…but it does the job!

Let’s briefly recap how this approach actually works.

• The split() method splits our String object, so that every single character in the original String array is now separated in its own single-character substring.
• The reverse() method comes then into play and does the main job: it simply reverses the elements contained in the originally array so that what originally was the last character in the -String array, is now the first element (in our case it’s a “.” , since it’s the character that our variable “stringToReverse” was ending on).
• The join() method finally rejoins all the single characters previously separated by the split() method to form and recompose our reversed string.

Et voilà! 😏

• Quick side note : This approach should preferably be used if your interviewer specifically says that you are allowed to use built-in methods, otherwise you should go for the next approaches I am going to show you.

2. The Old Fashioned Way: the for loop

If you wanna show your interviewer that you know how to solve this problem without relying on the JS built-in methods, just use the for loop.

But let’s just get a bit fancier and use the ES6 syntax, shall we?

The new for loop syntax introduced by ES6 is very handy and it drastically reduces the chance of making mistakes while typing code for the loop. Also, it is much cleaner and nicer to look at 👌 .

3. The Concise and even more “ES6” way of doing things with the Spread Syntax

With ES6 we have a new way of splitting our String into an array, thanks to the so-called spread operator […].

This approach is almost identical to the first approach I showed (except for the […] operator of course 😅 ) and here below you can have a look at it.

Pretty neat, huh? 😎

Passing the “stringToReverse” as a parameter of the spread operator allows us to “spread” the single character values contained in our original array to get the same result as we did using the split() function, so that we can later reverse the all the single characters one by one as we did before with the JS built-in method reverse() and then finish off once more with the join() method.

4. Last But Not Least….Recursion!

The last method I would like to show you is the recursive approach to this problem.

In this case we want to set up our function so that it recursively calls itself till it hits our base case (i.e. an empty string).

We simply cut the first character of our string object away with the substr() method, and add it at the end of the string recursively till there are no more characters left to add.

We can even do this with a ternary operator to be more concise and clean with our JS syntax.

And that was the last example on how to reverse a string with JavaScript! 🎉

I truly hope you enjoyed this tutorial and please let me know your thoughts and solutions too!

I officially finished my Spring 2021 semester at Georgia Tech with my class in Human Computer Interaction, and I gotta confirm that overall it’s been an enjoyable experience that allowed me to further expand my knowledge in the UX field and gave me such a broader perspective on things.

Although the time commitment was significant because of the amount of weekly writing/reading involved, the fact that I worked remotely for those past few months due to the COVID restrictions in Italy helped my manage the workload much more efficiently, and I was able to carry on without excessive efforts/sacrifices.

I am taking the summer off for now, though, since I really feel like it’s time for a short “break” to pause and unwind for a bit in order to (hopefully) start with a new energy for the Fall 2021 term.

I think I will probably choose the AI, Ethics, & Society class since I find the ethics implications of AI to be a profoundly interesting topic whose references we’re constantly being bombarded with in our everyday lives.

Stay tuned for more updates, and cheers! 👋

Original article published on Cloud Academy.

It’s a typical Monday morning, and I am about to get off the TILO train that takes me to Cloud Academy’s offices in Mendrisio every morning.

It’s 8:36 a.m. sharp (lovely how punctual Swiss trains are), and I am walking to the office to start a new day. 🥳

As I walk towards my desk to plug in my MacBook, I greet the other early morning coworkers who are already in the office and then make my way to our awesome espresso coffee machine to get my first caffeine fix of the day.

Now that the caffeine ☕️ is starting to do its magic, I proceed to open up the WebStorm IDE to spin up my dev environment while I also take a quick look at my Google Calendar to get a feeling of what the day is gonna look like, and finally check the Jira board to see what the current progress of my tasks is.

9.45 a.m. — Time for the daily stand-up!

The engagement squad (my current team 😎_)_ is ready to report the various updates regarding what everybody has been up to since yesterday, and we have a 10/15-minute scrum meeting to discuss our tasks for the day and whether or not we have any particular blockers for the issues we’re currently working on.

10:00 a.m. — Back to work ⚙️

Today I’m working on adding a custom functionality to a React Component that I am currently building (i.e., the Card Certification), which is related to our upcoming User Certifications project (edit: it’s now live! 🥳) that’s going to enable both enterprise customers and individual users to upload their custom certifications to CA’s platform.

I am actually working on including the “add to LinkedIn” functionality so that when users click on the corresponding card button, it will be possible for them to be redirected to the related LinkedIn profile page with all of the main certification’s details already pre-filled.

Below is the actual code snippet with the main parameters that I am using to connect to LinkedIn’s add to profile endpoint so as to fill out the required fields.

1:00 p.m. — Time for some lunch! 🥪

I sit in our kitchen/lunch area and enjoy the quick lunch I brought from home while having a nice conversation with my peers.

Today is also a very special day because we’re celebrating the birthday of a CA employee, and this means only one thing….🥁 free brioches for everybody! 🥐

This is one of my favorite traditions here at Cloud Academy, as birthdays are always properly celebrated with the right level of sweetness ;)

1:30 p.m. — Time to play table tennis! 🏓

After the lunch break, some of us generally gather and then split into small teams to play table tennis together. It’s such a nice way to recharge before going back to coding.

Today I feel quite energized (might be the caffeine + brioche combo), and I actually win the match! 🙌🏻

2:00 p.m. — Back to work again 💼

Time to get back to coding. I am moving forward with the implementation of the “add to LinkedIn profile” functionality for the certifications, and I am testing out whether the actual flow of interaction works as expected and that all of the fields are correctly being filled out whenever a user clicks on the corresponding button with the goal of showcasing a new certification on LinkedIn.

4:00 p.m. — Let’s push some code! 🤓

After having properly debugged and checked that everything works as it should, I proceed to open a pull request on Bitbucket and pick two front-end colleagues as reviewers so that they can give me some feedback on my work.

Providing useful and actionable feedback is definitely one of the main key points to follow when it comes to reviewing pull requests, and we all strive to be as assertive as possible whenever we write comments on other pull requests so that we can all learn something in the process.

5:00 p.m. — PR reviews time 📝

I am now reviewing a pull review on our Design System’s repo (i.e. Bonsai) for a new Component that is being created. I am curious to take a look at my colleague’s work, since I find it truly interesting to see how other developers tackle a certain problem from different viewpoints and to understand more about how I would have approached the same challenge.

It’s always quite interesting to analyze the pros and cons of certain types of potential solutions, and with Bonsai we are trying to stick to a reasonable balance between the need of meeting certain technical standards while remaining sufficiently close to the actual design requirements.

As an example, some of the guidelines that we are adhering to when it comes to designing new Bonsai Components are outlined in our docs page, where we have created a specific definition to differentiate between “ready-to-use” components and what we have named “stylable” components.

Creating a new “ready-to-use” component (we mostly use those) means that its corresponding TypeScript interface will have its basic style and corresponding functionalities already defined, so that a Developer can quickly and easily use it as it is.

6:00 p.m. — Wrapping up

Another workday has come to an end, and it’s now time for me to hop on the train back to Italy 🇮🇹 and relax and unwind a bit.

I started my first semester at Georgia Tech in January with a class in Human Computer Interaction, and I gotta say that so far I am truly enjoying the material and how the class is structured since it makes the remote learning experience much more enjoyable.

There’s a lot of writing 📝 involved with this class as each single week we’re required to write an 8 pages paper related to the course content we’re learning, but I think that overall having to write this much was helpful for me in that it gave me structure and room to properly organize myself with my full-time job at Cloud Academy.

Having less time at hand paradoxically makes you value the time you have much more, and this helped me establish a good routine to take care of both HW and my daily work as a FE Engineer (also WFH is a boost in this scenario as there is no commute).

Anyhow, some of the main key takeaways from the HCI course are:

• Think about users first anytime you’re thinking about creating a new interface for a product.
• Ask yourself he right questions early on, and iterate as much as possible to refine the feedback cycle and come up with creative alternative solutions.
• Brainstorming is important, and you have to take it as a creative exercise as inserting a “random” element can actually allow you to think outside the box and find new ways to tackle a certain problem.
• Beware of biases, as you will encounter so many of them along the way and the more you know about them the better you will be able to recognize them.
• Get comfortable with the concepts of gulf of execution and gulf of evaluation as they are vital points which will eventually determine the overall perceived usability of your interface/product.

Hope you found these points somewhat helpful/insightful, and I will come back with more takeaways once the class is over in May so stay tuned for that! ✨

I won’t digress nor try to capture with vague and ephemeral words the global scenario that has turned so many lives upside down during these past 12 months, because it’s been so intense and dramatic in many ways and enough words have already been spent on this.

I will just say that I truly hope that as many people as possible will be able to finally turn the page and to move on with a positive start of 2021.

This year has been incredibly intense for me too.

I graduated in March when the pandemic was hitting hard, and it was such a surreal experience to spend my graduation day at home in front of a webcam instead of celebrating it with my friends, but nonetheless I am happy that I was able to achieve this great goal of mine.

Soon after graduating I started my first official full-time job as a Front-end Software Engineer at Cloud Academy, and I gotta say it’s helping me a lot to become a much better Software Developer.

Being able to actively contribute to a Design System using the latest tools & frameworks is definitely a great chance for me to think about the product from the ground-up, and collaborating with Designers to establish visual patterns & rules is rewarding and interesting.

Also, I was officially accepted as a grad student for a M.S. in Computer Science at Georgia Tech and I will be starting in a week from now!

This is so exciting for me, but I hope I can find a good work/life balance because it’s gonna be pretty tough to combine two challenges of this magnitude.

I will also try to keep this blog more up-to-date, and my mission is also going to be to write a few technical blog posts on front-end related topics as well (or maybe som ML stuff?!).

Anyway, if you’ve read this far thank you my dear virtual friend and stay tuned for more!

• 2021 here we go!

╰(°▽°)╯

2019 has truly been such an eventful year for multiple reasons.

It has allowed me to grow in ways I’d have never imagined, both as Developer and more in general as an aspiring human being 👽.

Having had a chance to visit the US again to spend three months as a UX Engineer at Mailchimp was an incredible opportunity, which I am so grateful for and that has broaden my perspective on so many topics (e.g the power of Accessibility, User-centered design, the importance of effective communication, the value of humility, the listen hard/change fast mentality) and the awesome people in my team all helped me visualize so vividly what can be achieved through hard-work ad dedication.

In 2020 I really wanna treasure and harness the power of the experiences I was able to live throughout this past year, to build new powerful resources and follow the path of creativity and personal development.

Setting very specific goals at this point could be rather counterproductive, so for now I am just gonna try to become a better version of myself and stick to this goal which is going to act as a daily reminder/ambition.

Also, if you’re reading this I just wanna say thank you (and Merry Christmas!)

There would be so many things and anecdotes to talk about which contributed to making my internship experience at Mailchimp truly unique.

And a simple blog post cannot capture all the magic concentrated in the span of 12 weeks, so I am just going to highlight a few key aspects that made this summer absolutely unforgettable.

Working with the Design System team as a UX Engineer has been such an exciting part of my journey to Atlanta, and it made me understand about how important it is to have a great sense of team work and cooperation when starting to conceptualize the building blocks of a whole new Design System.

As a matter of fact, having a clear sense of direction and a vision is not enough, as the mission of a Design System team is to standardize and make the visual elements of a User Experience fully accessible, well-documented and completely in-line with the company vision and strategy.

It is no easy task, believe me.

But that’s part and parcel of the fun of it.

Using the latest technologies and frameworks to bring to life the User Interface of a product is such a great and empowering feeling, and being able to actively contribute to the various discussions with the team and receiving feedback along the way, makes the whole process so much smoother and enjoyable.

I feel so lucky to have had this opportunity to work with such talented people, and every day felt like a whole new chapter to continue being inspired and motivated to see things grow and change.

I haven’t updated my blog in a while but felt it was the right time to publish a new post, because there is some great upcoming news in the air…

I still can’t believe this is happening to me but recently I was accepted for another amazing internship program in Atlanta (GA), where I’m gonna work for the whole summer as a UX Engineer Intern with a wonderful Tech company whose mission is to empower small businesses so to make them grow and thrive in the most effective ways!

It’s a 12 weeks program, and my main tasks are gonna involve the collaboration with the Design System with the aim to improve internal tooling for the Design team, and to help define new patterns for the application.

I am gonna work directly with a team of engineers and designers to gain real-world experience as an engineer. It’s gonna be such an exciting and wonderful opportunity for me to gain real experience as a UX Engineer, and to cooperate with brilliant people towards the realization of a product whose main goal is to improve other people’s lives through their personal business vision. Wish me luck! 🍀

The Fox Magazine is a premier lifestyle publication focusing on beginnings, creativity, and risk.

Since March of 2016, The Fox Magazine explores an original, vivid, and timeless insight into the essence of photography, travel, food, fashion, music, and technology.

The mission is to be the leading resource of inspiration for individuals wanting to chase their dreams and seek a fulfilling lifestyle.

It’ gonna be such a great opportunity for me to challenge myself into pursuing something different from what I am normally used to doing (i.e. Front-End Web Development), and I am truly looking forward to cooperating with journalists, scholars, photographers, musicians, travelers, chefs, and even fashion designers to bring the Fox Magazine’s mission to life!

It’s been such a long time since my last blog post, so I felt like I had to make up for it and now here I am typing on the same old keyboard but with so many new stories to tell!

Those past few months have been extremely hectic and intense, and the New York Internship with Adobe turned out to be such an incredible learning experience whose impact proved to be crucial from many standpoints, both professionally and humanly speaking.

I think overall I changed a lot, being on my own for three months in the big 🍏 has shaped my thoughts and ideals in ways I would have never imagined before and I feel blessed for having had this amazing opportunity.

I was able to work with an awesome team (thank you Smashers!) on many different projects, and was able to understand a lot more about Bēhance as a platform and about all the incredible efforts that are being put into such an ambitious product.

Working with such a huge codebase was kinda hard to get used to at the beginning, but everybody has been truly supportive and helpful towards me throughout this journey as a Front-End Dev Intern and so I could really enjoy the whole process (struggles included!).

I learnt about the importance of details, and how being precise and meticulous when it comes to working with a product that’s being used every day by millions of users can truly make a significant difference.

In addition to that, a genuine inclination towards team-work is undoubtedly the #1 skill to have, and cooperating with all the various teams proved to be truly vital not just in terms of time efficiency but because it is the key to success for every company that wants to last.

Having shared core values to abide by in a company means that the work can be carried out more effortlessly and smoothly, and that everybody is more likely to be on the same page and happy about the way things are handled in general.

So thank you again Adobe for giving me this chance to experience what it’s like to work for one of the top Software companies in the world, and to feel part of something bigger, to be an active team player whose small contribution can still have a tangible impact on the user experience of millions of people.

That’s one interesting and nowadays perhaps too abused word which, nonetheless, represents such an important and universal concept.

What is, indeed, the essence of resilience?

How could we define this word without the risk of getting stuck and superficially trapped in the many possible definitions?

Well, Psychology Today defines resilience as:

“that ineffable quality that allows some people to be knocked down by life and come back stronger than ever. Rather than letting failure overcome them and drain their resolve, they find a way to rise from the ashes”.

And this at a first glance, looks like a simple yet acceptable definition.

But if we leave personal experience out of this equation “resilience” becomes just a mere word, and its profound meaning wouldn’t actually mean anything significant to us.

So that’s why I encourage you, if you are reading this article, to isolate some of your toughest memories, those events which had a huge impact on your behavior and that eventually shaped who you were and who you feel like you are now.

Go back to those moments and try to figure out whether you let yourself down because of them and passively surrendered to your fate, or whether you actively fought and tried to find a way out of that unbearable situation.

If you didn’t surrender to what life prospected and sought a true sense of purpose and willingness to move forward, then you definitely appear to be a goal-oriented, optimistic, motivated and strong individual who doesn’t easily give up when faced with a stressful or annoyingly unpleasant problem.

So here we go.

A lifetime dream. The perfect fairytale. My most common daydreaming scenario.

I am going to New York City. For real.

I’ve landed an internship as a Front-End Developer at Adobe, and I will be working with the Behance team to contribute in the creation and delivery of beautiful and highly usable interactions in their products.

It’s going to be a full-time internship from mid June till the end of August for a total of 12 weeks.

NYC has always been my dream city: ever since I was a little girl I used to virtually wander around the streets of New York using Google Maps, and hoping to one day be able to go there and experience what it feels like.

Being able to spend 3 months in NYC feels unreal: it’s the fulfillment not only of a lifetime goal, but a professional achievement since during these past few years I worked hard to gain knowledge and expertise in Web Development.

This is my first post. Kinda thrilling, kinda weird.

But it’s the beginning of a new digital journey 🤓.

And I’m happy you are actually reading these lines right now, because they represent in a sense the overall work and effort that I put into these past few years as an aspiring Web Developer.

So that’s why I say Welcome! :)

Welcome to this virtual space, which I hope is going to give you an even more effective idea about my passion for Technology.

I still can’t believe I am actually going to attend NDC London, it’s been such a pleasingly unexpected surprise from the very beginning when I first got the news that I was selected to receive the final prize.

And now that the day has finally come I am here in the busy Victoria Station, hurriedly walking towards the NDC venue which this year is the beautiful QEII Centre in the heart of Westminster.

Everything feels amazing, weird, and thrilling at the same time and I’m looking forward to discovering all about the latest tech gadgets and devices, as well as meeting cool people who are passionate about Technology as I am.

I’m truly excited about the upcoming React Workshop I am going to attend since it’s actually one of the Front-End technologies I’ve been enjoying working on the most during the past few months, and the opportunity to learn something more about it from Jake Ginnivan is great.

This React Workshop is actually going to last for 2 days (till January 16th), which means it’s going to be a complete and detailed full immersion into this powerful JS library with a clear focus on the best practices.

Here I am now staring in awe at the beautiful Westminster Abbey, which is just next to the NDC venue (i.e. the QEII Convention Centre).

The surroundings are so charming and beautiful that it almost doesn’t feel real to be in such a context for this event.

I then proceed and walk towards QEII to check in and head to the 4th floor, to the “Burns” room (N.d.A. each room takes its name from a famous British author) where the Workshop is going to take place.

Jake is a good teacher from the beginning: he is very professional and prepared and knows everything about the React JS environment and all the best practices to make code faster and more reliable.

He gives us a mission: our task is to recreate the NDC agenda webpage using React.

Luckily, though, he’s always there ready to help us when we face any problems in structuring our application and he assists us during the whole process by giving us examples and extra challenges to implementing inside the Web App.

❝Any sufficiently advanced technology is equivalent to magic.

Sir Arthur C. Clarke

Day 2

Today the pace gets increasingly faster and we continue our React Workshop journey by approaching new complex concepts and topics such as “Routing”, which is a practice whose aim is to better distribute the components’ logic inside Single Page Applications and we also dive into “Redux”, which is a tool whose purpose is to allow for more solid state management.

It’s definitely challenging to catch up with so many new inputs, but Jake is always there to explain and help us understand the nitty-gritty making the process enjoyable.

React is such a very powerful JS library with impressive potential, even though the learning curve is pretty steep for those who aren’t familiar with JavaScript and its syntax.

Day 3

Today is the first actual day of NDC and I am absolutely thrilled about all the upcoming talks and great people who are going to present their ideas regarding innovative topics in the realm of Technology.

37 is the number of different countries represented this year at NDC London.

The first speaker is Felienne, Assistant Professor at Delft University of Technology, who’s going to provide insights to answer the tough question:

What is programming anyway?

Her speech was truly inspirational and unconventional (she’s so funny and down-to-earth), and she talked about the ups and downs of her journey as a Ph.D. Candidate and the research she carried on regarding the conception of Spreadsheets as an actual programming tool, which even though turned out to be a failure (since she realized she wasn’t genuinely interested in pursuing this kind of project) was ultimately what led her to find her real passion.

Not only it was an engaging and motivational story, but it involved a good deal of food for thought since it aimed at re-thinking and re-shaping the functional aspect of programming with the purpose of reaching out to people who could feel intimidated by it if we were to stick to the narrow perspective of Software Development as a mere tool for an elite of gifted people.

That’s why Felienne made it her mission to overturn this cliché of programming as a branch of pure application of logic and technical rigidity to solve complex problems.

She is helping children all over the world to learn programming (using the MIT open source language Scratch) in a fun and intuitive way so that they can all begin to familiarize themselves with the tools in a more playful way but with an eye on the structure and reusability of the various programming blocks to optimize the simple logic behind them.

Felienne’s speech lightened up a whole new and refreshing perspective for me since I can really relate to the feeling of being overwhelmed and not feeling like programming is a good choice, (I’ve always struggled with Maths myself and never been really good at it) and the idea of re-defining this conception, and to realize that multiple types of intelligence can actually take advantage of programming in different ways was enlightening.

So thank you Felienne, it’s empowering to be able to finally break those barriers and know that it is possible to actively contribute to the Tech Industry in many ways without having to constrain ourselves into a specific role.

The day moves on pretty fast and since we only have a 20min time window between any two conferences, it’s vital to properly manage your time and find out which cool topics are the ones you’d like to hear more about…

The food is insanely delicious though, and with every break, we are welcomed with some tasty dishes and sweet treats (each day 6 different menu choices representing a different country are available)!

Later on, I then proceed to attend the next talks and listen to Brock Allen (.NET, Web Dev & Security Expert) and Dominick Baier (Identity & Access Control Consultant) speaking about Implementing Authorization in Web Applications & APIs.

They explore patterns, and anti-patterns and provide solutions to possible exploitable techniques on the topic of Authorization and get into the details with great precision.

So I am then surprised by the “Power of Composition” thanks to a great speech by Scott Walschin, who has just finished writing a new book about the elegance and practicality of Functional Programming using F#.

But the day is not over yet and in the afternoon I am able to explore the concept of “Immutability” applied to Programming thanks to Kevlin Henney, who delivers a great speech about how to reduce state mutability in code and why this is so important.

• Jasmine Greenway is the next speaker and she talks about her experience as a teacher at La Guardia Community College (Queens, NYC) which involved teaching young students with no previous programming experience the basics of HTML5, CSS3, and JavaScript in order to build simple Applications.

She brought up interesting examples from her personal experience (how she perceived herself as a student and how she consequently interacted with the people around her) and also explained how empathy and soft skills are vital aspects of any aspiring teacher.

But this evening NDC doesn’t simply end with the last conference because an amazing cruise on the River Thames has been organized, which involves both the NDC participants and all the speakers.

Now that I look back on it I realize it’s actually been one of the most incredible nights I’ve ever had: spending a few hours cruising on a boat on the Thames and being able to admire London during night-time with all of its vibrant lights and all of the modern and ancient buildings is the scenario for memorable moments.

On top of that, being able to connect with different people and hear about their stories and experiences in such a context revealed to be even more unique and was the perfect conclusion for a special day like this one.

Day 4

Today is the second official day of NDC London and many inspiring talks are scheduled for the day.

We start off with a very inspiring talk by Alex Ellis and Scott Hanselman who perform a live demonstration on stage about how to build a Raspberry Pi Kubernetes Cluster running .NET Core.

They provide a detailed explanation of how they managed to build such a sophisticated and fully functional real server using only a stack of six Raspberry Pis piled each on top of the other.

The whole audience is wildly entertained and engaged by the talk, since being able to admire the effort and sophistication put into the realization of such a piece of Technology with a budget of less than 300$ is undoubtedly phenomenal.

After the talk, everybody is eager to try and build their own Raspberry PI cluster server (myself included since I own one but never figured out how to effectively use it!), and we immediately start googling every resource related to this project and to Open Faas (Alex Ellis is its creator).

Open Faas is indeed a framework for building serverless functions on top of containers (its GitHub repo has 8394 stars), and during the speech, we were introduced to its various functionalities and to the whole environment needed to set it up.

Next up is Kesha Williams, Full-stack Software Developer and Inventor of SAM (a predictive policing machine learning algorithm inspired by Minority Report that predicts the likelihood of crime).

She introduces us to the project by explaining how Minority Report (her favorite movie ever) gave her the right inspiration and determination to create such a sophisticated product, which is capable of detecting the likelihood of crime using data imported from the Georgia Police Department.

With just a simple tweet SAM (n.d. A Suspicious Activity Monitoring) is able to predict whether the person captured by the image sent with the tweet is likely to be a potential criminal.

It uses AI to analyze the photo and processes it to find facial features which relate to suspicious traits in a target individual.

Needless to say that this proves to be a very inspiring talk, thanks to the in-depth explanation of the SAM case study and all the tools Kesha used to build it (it relies on AWS and uses Python for the algorithmic predictive model).

During the afternoon I was very curious to attend the talk “Hack Your Career” by Troy Hunt, who talked about his life experience as a Software Developer and about the choices he made that eventually led him to become a successful entrepreneur (he is a well-known for the popular tool “Have I been pawned?”, and for sharing his knowledge about Security both with his Pluralsight courses and blog posts).

He gave some clever insights about the best strategies to follow in order to have a successful and meaningful career (e.g. the importance of branding oneself, the creation of value, and leadership), one whose aim is to positively impact the world by sharing knowledge and being persistent to ambitious goals.

The afternoon proceeds as usual with a rapid pace and Machine Learning is the topic I am able to learn about thanks to Tess Ferrandez-Norlander, a brilliant developer from Microsoft who introduces the topic of ML and its incredible implications in today’s world.

The last speech of the day is given by Sam Aaron, the creator of Sonic Pi, which is a great coding-based Music software (written using Ruby) whose ease of use makes it accessible to anybody who is interested in building original music tracks even if they’re lacking programming skills.

He performs an amazingly entertaining live demonstration about how the software works, and how to mix the various sounds and effects in order to produce and compose a pleasing symphony.

One of the best aspects of this product is that it’s actually completely free (I downloaded it straight after the conference!)

This evening the NDC Party concludes such an intense day of technical presentations on a lively and sparkly note, which invades the whole QEII center making a wonderful atmosphere.

Day 5 - The Last Day of NDC

I can’t believe it’s already almost over.

Time went by so quickly that I just didn’t realize that today is the last day I’ll be spending here at the QEII center, in the heart of beautiful Westminster.

The atmosphere, the great people I’ve met, the speakers, the countless start-up stands, the delicious food, and the common passion for innovation and technology all make for a unique combination of elements.

A pure and vibrant interconnected space where everything seemed to be possible and indeed, it has been possible for me to experience all of this thanks to Keyzo’s NCW Competition.

During his talk named “Web Apps can’t really do that, can they?”, Steve Sanderson shows how he was able to create a fully functional environment that runs pure C# code directly in the browser with almost no lags nor latencies.

This incredible live demonstration leaves everybody in awe since no such thing ever seemed to be remotely possible due to the nature of C# as a language (and its intrinsic complexity), and the many quirks coming from the nature of JavaScript’s behavior in the browser (a language which splits Developers in a love/hate relationship).

It definitely looks like a very promising project which I hope is going to be further enhanced since it could potentially open up a whole new horizon for the world of Software Development.

But our final day at NDC isn’t over yet and so we move on with the first-afternoon talk which is a nice co-hosted Q&A session with Troy Hunt, Felienne, Jon Skeet, and Scott Hanselman who share their opinions and thoughts about many subjects related to the world of Technology in its many forms and answer questions from the crowd.

They’re all very down-to-earth and attuned to the audience and so they manage to give insightful and witty remarks concerning controversial topics which usually cause a lot of arguing in the Tech community (e.g. Ethics & Professionalism in Computer Science, how to handle behavioral and business problems and difficult situations).

Next up is a very original and inspiring talk (Mötley Crüe and Mödern JavaScript) by Eric Brandes who’s a JavaScript expert with very solid and wide knowledge about the JS environment and its latest trends and front-end libraries.

That’s why in his talk he explicitly addresses some of the most common misconceptions about JavaScript as a language and also unravels the truth about the countless new JS frameworks which have been popping up lately that in his view have only contributed to causing even more confusion in the whole Web Development scene.

To make his point even clearer he adopts some really cool metaphors inspired by images from famous Heavy Metal bands and showcases the actual “winners” and “losers” in the JS world in a funny and engaging way.

Last but not least is the talk by Marcin Moskala and Igor Wojda about Kotlin, a language that has lately been gaining so much popularity in the Programming world and which is considered the next Android language.

I was very curious to have an overview of the main features and the general syntax of Kotlin as a programming language, and I have to say that this talk exceeded my expectations in that it covered many more topics (some very advanced ones!) than I had imagined.

What a weird feeling now as I am walking away from Room 4, where the last talk has just taken place.

It is actually hard to finally say Goodbye and leave QEII after having spent some memorable days in such an amazing place.

As I walk past the door and go out of the building headed to St. James’ Park station, I can’t help but recollect all the fresh memories coming from these past few days and it’s wonderful to realize how they make into a perfect “collage” made of emotions, thoughts, images, considerations and inspirational words.

That’s the reason why I say thank you.

Thank you Keyzo for giving me this opportunity.

It’s been extraordinary and I will never forget how impactful this experience has been for me, and how it contributed to motivating me, even more, to pursue a career in the world of Technology.